jueves, 31 de diciembre de 2020

¡HNY 2021!

 

Y, finalmente, parece que se está por ir el 2020. Y la novedad es que por suerte algunos llegamos vivos para verlo. La desgracia es que muchos, y muy cercanos, no lo han logrado. El año ha sido, si se quiere, terrible no solo a nivel personal sino para la humanidad toda, ... ¡vaya novedad!. 

Cuando era chico me resuenan las palabras de mi abuela contando, con cierta reticencia, los terribles momentos de la pandemia de 1919, la infame gripe española. Aquella gripe en realidad fue mal llamada "española" como ésta es mal llamada "china". Esa pandemia, curiosamente también creada por un coronavirus como la que nos golpeó en éste año que se va, produjo la friolera de 20 millones de muertos en dos años, antes de desaparecer tan misteriosamente como llegó, algunos conjeturan que porque luego de tantos infectados y muertos se alcanzó finalmente lo que se llama "inmunidad de la manada". Dos de ellos de mi familia, los que hubieran sido mis tios Raul y Rosa, los "bebés" como siempre se los conoció en mi familia pues lo eran al momento de ser alcanzados por la pandemia. Un siglo después, con la medicina moderna, con los métodos modernos de diagnóstico, con drogas maravillosas y con el saber humano capaz de producir no solo una vacuna sino de hacerlo en menos de un año el costo en vidas será posiblemente una fracción del de aquel entonces, pero eso es poco consuelo para quienes partieron por su culpa, o mejor dicho, para quienes quedaron y vieron partir a sus seres queridos. He perdido familia, otros también, es una tragedia. Solo queda levantar la vista y ver porque sendero continuar.  Pero, como dijera Friedich Nietzsche "lo que no nos mata nos fortalece". Hemos aprendido, hemos adoptado estrategias de supervivencia, de cuidarnos, de trabajar en forma remota, de interrelacionarnos con cuidado, de ser resilientes en el cuidado de nuestros afectos. Hemos sentido, mas allá de "grietas" tontas, un cierto sentido de comunidad, de entorno, de "no dejaremos a nadie atrás", de "mientras nosotros no caigamos no dejaremos que nadie alrededor nuestro caiga". En alguna forma hemos aprendido a ser mejores, mas solidario, a pesar de la adversidad. Ya no es cuestión de cuidarnos, es cuestión de cuidar al otro también, una dimensión que pocas veces en mi vida he percibido tan claramente. No es general, no es con todo el mundo, es solo con algunos, pero es un comienzo.

Usualmente, y como lo vengo haciendo en mi blog desde hace mas de 20 años (primero en lu7hz y luego aquí como lu7did) solo resta a esta altura celebrar, todo lo relevante para éste blog se ha dicho en el año que se está yendo, y lo que no se pudo se dirá en el próximo.

Pero antes de hacerlo quisiera detenerme a compartir el enorme auxilio que representó para mi en éste año la actividad de radio. Tener en que aplicar el tiempo ocioso (no libre) que de repente todos nos vimos forzados a tener, poder desarrollar proyectos en los que estar ocupado (algunos de ellos documentados en éste blog) para que mi cabeza tuviera herramientas para manejar la enorme ansiedad que implica la incertidumbre, poder participar de actividades que otros tuvieron la gentileza de organizar a modo de distracción para entretenernos mientras esperamos por lo desconocido y, en general, obtener todos los beneficios de un pasatiempo para distraernos no tiene precio, su valor es inconmensurable; el coronavirus tenía lo suyo, pero la ansiedad y angustia que generó también. Espero que algunas contribuciones hechas hayan ayudado a otros, pero ciertamente quiero agradecer las que hicieron otros y ciertamente me ayudaron.

Finalmente, y ahora si, levantemos las copas y pensemos mucho en nuestros planes futuros  mientras lo hacemos, junto a nuestros afectos. No sabemos si tendremos futuro, pero si lo hay... ¡que no nos encuentre sin planes!


¡HNY 2021 DR OM 73 ES DX ES 88 TU BK!

¡Μολὼν λαβέ 2021!

EchoLink para Raspberry PI, SVXLink de SM0SVX

A fuerza de la necesaria honestidad que el comienzo de un nuevo año merece realmente el sistema EchoLink nunca me llamó demasiado la atención. Nacido como un sistema de tecnología VoIP (Voice over IP) desarrollado sobre plataforma Windows y madurado a lo largo casi una década de uso en una respetable red de mas de 6000 nodos y alrededor de 200000 usuarios a nivel mundial.
La propuesta tecnológica es simple y sofisticada al mismo tiempo, los usuarios acceden a un nodo EchoLink que escucha y transmite en un canal de VHF normalmente, ocasionalmente UHF. Lo que el nodo escucha lo retransmite a todas las estaciones que estén conectadas a ese nodo a traves de un cliente EchoLink. Conexión se hace mediante Internet usando tecnología VoIP, no muy diferente a la que usan programas muy usados como Skype, Teams, Zoom o Google Meet, tan en boga durante el necesario trabajo cooperativo remoto durante el confinamiento de la pandemia. Sin embargo, al momento de su lanzamiento no había muchos programas que usaran esa tecnología, algunos ya no existen mas y otros como Skype se han ido modernizando. El sistema tiene un programa servidor, que opera sobre Windows y programas cliente que operan en un número de plataformas, las mas populares Windows y sistemas operativos de telefonía celular, como Android por ejemplo. El nodo es de instalación relativamente simple; en su configuración mas simple opera en, valga la redundancia, simplex. Lo que el servidor escucha lo retransmite por VoIP a todos los conectados y si alguno de los conectados habla se le comparte al resto de los conectados y lo envia por aire también. Eso permite instalar un sistema sencillo, pero relativamente eficaz de uso compartido entre estaciones operando en radio y estaciones operando en Internet. En su variante "duplex" el sistema se adosa a un repetidor existente, de esa manera permite interconectar muchas estaciones en radio con muchas estaciones en Internet. La interfaz para hacer la conexión es muy simple, poco mas que conectar las salidas y entradas de una placa de sonido a un transceptor VHF/UHF, configurar el software y se está en el aire. Los nodos pueden formar parte de configuraciones relativamente complejas con "salas" geográficas, temáticas y por nodo. También es posible formar parte de la red Echolink sin ningún componente de RF, es decir solo con nodos que gestionan tráfico exclusivamente por Internet.

Ventajas y Desventajas 

En lo técnico el sistema es relativamente simple de instalar y configurar si se despliega un servidor y mas simple aún de usar si solo se usa el cliente, lo que es atractivo para quienes tengan una aproximación a la radio mas orientada a la comunicación que a la experimentación. En algunos casos permite hacer algo de actividad de radio, aunque pudiera paradójicamente no incluir ningún componente de radio, cuando por dificultades de antenas, equipos o propagación hubiera sido imposible de otra manera. Permite también la relación de personas que están físicamente muy dispersas, completamente fuera del alcance de un enlace de VHF o incluso de HF, con una precisión de horarios que la propagación no permite alcanzar. Tiene, claramente, muchas ventajas operativas.
Tiene unos cuantos puntos débiles, los que contribuyen a alimentar eternas polémicas sobre si es un uso legal o incluso ético de la radio. En general son discusiones estériles. En lo reglamentario no hay nada que impida su uso y la ética es una colección amorfa y gaseosa de conceptos que cada uno le dá la forma que le conviene para demostrar lo que necesita. Es claro que, discusiones estériles al margen, hay algunos cuestionamientos técnicos que limitan su utilidad. El mas severo es que es un sistema que depende de redes por fuera de la radio, específicamente Internet. Sin Internet no hay EchoLink.
El otro aspecto, y ya es mas opinable, es que técnicamente es una "caja negra" con poco o ningún lugar para la experimentación fuera de algunas interfaces simples entre equipos de radio y computadoras; técnicamente puede ser un medio "aburrido" (tomar en forma muy liviana y opinable éste concepto). Finalmente, desde el punto de vista de seguridad, tiene algunos puntos debatibles. Cualquiera puede obtener una copia del cliente y con el acceder a recursos que pueden implicar el uso de frecuencias de aficionado, y la cadena para demostrar que se tiene licencia para hacerlo es debil, muy debil. Potencialmente puede haber usos no autorizados de enlaces radiales y hay pocos, poquisimos, recursos para impedirlo.

Mis experiencias

Por todos éstos factores en varias oportunidades he instalado sistemas servidores para experimentar un poco con ellos, pero nunca encontré la motivación para hacer de ellos un sistema permanente. Básicamente implica tener una PC y una estación de VHF andando permanentemente, nada que no haya hecho antes como por ejemplo cuando tuve el nodo ABROWN de packet por casi una década, pero en aquella oportunidad fue la base para una inagotable cantidad de actividad experimental la que incluyó el primer gateway Packet-Internet online que funcionó en Argentina. Aquí en cambio, al ser un sistema cerrado las chances de experimentar son bien pocas, por lo que usualmente al cabo de unas pocas pruebas el sistema quedaba apagado o directamente des instalado. 
Del lado del cliente corrió un poco de mejor suerte, casi siempre he tenido un cliente instalado, en especial desde que se hizo común su disponibilidad en teléfonos celulares, en la última década por decir un marco temporal aproximado. Por lo que ocasionalmente lo he utilizado, tanto para contactos pre-establecidos, como atender eventos en "salas" específicas como para alguna prueba casual durante viajes cuando no tenía nada mas a mano. Pero el uso siempre fue mas bien marginal, siempre preferí usar equipos de radio.

Algo cambió... veamos de que se trata

El estado de cosas anterior se mantuvo hasta que Daniel (LU9DPD), conocedor de cierta experiencia en la plataforma debido a otros experimentos que fui haciendo públicos, me preguntó un día si creia que fuera posible desplegar un nodo Echolink usando una Raspberry Pi.
Para que funcione en una Raspberry Pi primero tiene que funcionar en Linux, y EchoLink lo tenía como un sistema tradicionalmente basado en Windows, mundos que parecen destinados a no juntarse como los protagonistas en la película "El Hechizo del Halcón".
No fue necesario buscar mucho, lo encontré rápidamente, el programa SVXLink, creado por Tobías (SM0SVX), el que no solo brinda soporte completo a un sistema servidor EchoLink bajo Linux sino que también ... ¡soporta a la placa Raspberry Pi!.
El programa es un clon funcional, que tiene capacidad de integrarse a la red EchoLink sin restricciones y ser reconocido como uno nodo perteneciente a ella. Provee además una serie de funciones avanzadas que el programa EchoLink original no contiene.

Instalación y configuración

Como casi cualquier proyecto lo primero que hay que hacer es ingresar al sitio svxlink.org y recorrer la documentación disponible. A continuación hay que realizar un paso crecientemente obligado de buscar en YouTube sobre proyectos similares al que se intenta llevar a cabo (por ejemplo éste, entre muchos otros mas antiguos y mas recientes).
Claramente se trata de un proyecto muy popular, muy transitado y con muchos ejemplos.
Empecé entonces con inicializar una placa Raspberry Pi Zero W con un SD card conteniendo una imagen estandard del sistema operativo Raspbian a último nivel, para hacerlo hay que seguir uno de los miles de tutoriales que indican los distintos pasos. Una vez que ese ambiente estuvo disponible comencé la instalación del hardware y software necesario. 
Elegí como transceptor para el experimento un handy Baofeng, aparato noble y resistente si los hay, a quien le construí un arnés simple para realizar la interfaz de audio. En principio y en un primer enfoque simplificado asumí que el PTT se activaría mediante un sistema VOX. En la placa Raspberry adosé una USB soundcard genérica. Intenté instalar SVXLink desde binarios pero claramente no están preparados para la placa Raspberry Pi Zero y dá numerosos errores; al intentar instalar desde sources mediante la carga de pre-requisitos y compilación del aplicativo también obtuve un número muy elevado de errores, probablemente con tiempo y paciencia esos errores eventualmente se pueden superar, pero no me sobraba ninguno de los dos ingredientes asi que tomé por un camino alternativo. Estoy convencido que a la placa le sobra potencia para operar como nodo, después de todo es un procesador ARM con un clock de 1 GHz para procesar señales de un ancho de banda de unos pocos KHz.
El camino alternativo fue comenzar la instalación de vuelta pero sobre una placa Raspberry Pi 3 B disponible en el cluster que tengo.
La instalación anduvo perfectamente, tanto haciendola a partir de sources (link) como de binarios directamente (link).

Configuración

La configuración del programa svxlink una vez instalado es bastante obscura, la documentación no ofrece "escenarios" sino que mezcla parámetros que son necesarios para funciones muy diferentes del servidor, con lo que termina no siendo demasiado claro que parámetros hay que cambiar y cuales hay que dejar como están. Y cuando se los cambia cual debería ser el valor adecuado para un determinado propósito.
La configuración se realiza cambiando el contenido del archivo /etc/svxlink/svxlink.conf donde los parámetros están indicados por su nombre simbólico seguido del signo "=" para a continuación estar el o los valores que se le asignan (ej. CALLSIGN=LU7DID), en general los parámetros no son sensibles a las mayúsculas. El archivo de configuración debe ser editado mediante sudo pues está ubicado en un directorio de acceso escritura solo para root (bueno, si saben Linux ya saben eso, y si no lo saben descubrirán la necesidad de aprender eso y otros temas antes de hacer ésta instalación).
Finalmente, por prueba y error encontré cual es la configuración mínima que es necesaria para configurar un nodo en simplex, que de eso se trataba. Obviamente hay que cambiar referencias a mi localización, frecuencia y licencia por las que se necesiten configurar.

######################################################################                Configuration file for the SvxLink server        

[GLOBAL]
LOGICS=SimplexLogic
CFG_DIR=svxlink.d
TIMESTAMP_FORMAT="%c"
CARD_SAMPLE_RATE=48000
CARD_CHANNELS=1
LOCATION_INFO=LocationInfo

[SimplexLogic]
TYPE=Simplex
RX=Rx1
TX=Tx1
MODULES=ModuleEchoLink
CALLSIGN=LU7DID-L
SYSOPNAME=Pedro
SHORT_IDENT_INTERVAL=60
LONG_IDENT_INTERVAL=60
EVENT_HANDLER=/usr/share/svxlink/events.tcl
DEFAULT_LANG=en_US
RGR_SOUND_DELAY=0
REPORT_CTCSS=136.5
MACROS=Macros
FX_GAIN_NORMAL=0
FX_GAIN_LOW=-12

[Rx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:1
AUDIO_CHANNEL=0
#AUDIO_CHANNEL=1
SQL_DET=VOX
SQL_START_DELAY=0
SQL_DELAY=0
SQL_HANGTIME=2000
VOX_FILTER_DEPTH=20
VOX_THRESH=200
CTCSS_MODE=2
PEAK_METER=1
DTMF_DEC_TYPE=INTERNAL
DTMF_MUTING=1
DTMF_HANGTIME=40
DTMF_SERIAL=/dev/ttyS0

[Tx1]
TYPE=Local
AUDIO_DEV=alsa:plughw:1
#AUDIO_CHANNEL=1
AUDIO_CHANNEL=1
PTT_TYPE=NONE

TIMEOUT=300
TX_DELAY=500

PREEMPHASIS=0
DTMF_TONE_LENGTH=100
DTMF_TONE_SPACING=50
DTMF_DIGIT_PWR=-15

[LocationInfo]
APRS_SERVER_LIST=euro.aprs2.net:14580
STATUS_SERVER_LIST=aprs.echolink.org:5199
LON_POSITION=56.23.00W
LAT_POSITION=34.48.00S
CALLSIGN=EL-LU7DID

FREQUENCY=145.10
TX_POWER=3
ANTENNA_GAIN=0


Finalmente, de todos los servicios posibles (¡muchos!) solo uno se configurará y pondrá operativo en éste esquema básico y es el correspondiente a EchoLink mismo, para ello hay que editar el archivo localizado en /etc/svxlink/svxlink.d/ModuleEchoLink.conf

[ModuleEchoLink]
NAME=EchoLink
ID=2
TIMEOUT=60
ALLOW_IP=192.168.0.0/24
SERVERS=servers.echolink.org
CALLSIGN=LU7DID-L
PASSWORD=password
SYSOPNAME=Pedro
LOCATION=Adrogue,BA (GF05TE)
PROXY_SERVER=elp108.pi9noz.ampr.org
PROXY_PORT=8100
PROXY_PASSWORD=PUBLIC
MAX_QSOS=10
MAX_CONNECTIONS=11
LINK_IDLE_TIMEOUT=300
DESCRIPTION="You have connected to the LU7DID node\n"
            "QTH:     Adrogue,BA, Argentina (GF05TE)\n"
            "QRG:     Simplex link on 145.20 MHz\n"
            "CTCSS:   No Tone\n"
            "Trx:     BaoFeng UV-5RE\n"
            "Antenna: 5/8 at 12 mts\n"


En ésta configuración se establecen algunos parámetros clave para el funcionamiento del sistema y su integración en la red EchoLink global, para el cual debe registrarse la licencia del nodo (LU7DID-L en éste caso). Tal como está configurado se integrará a la red global a traves del servidor servers.echolink.org.

Funcionamiento

Si bien con lo anterior ya configurado es posible levantar la versión local del programa mediante
el comando

sudo -u svxlink svxlink

lo que irá indicando mediante un "trace" las distintas acciones y si hay algún error en la configuración que deba ser reparado.

Son necesarios sin embargo algunos pasos mas para llegar a tener un sistema funcional.

El primero y mas obvio, o quizás no, es tener registrado el nodo en la red EchoLink. Si se tiene registrada la licencia LU7DID (por ejemplo) la configuración anterior no andará, se requiere tener también registrada la licencia LU7DID-L, para el sistema EchoLink son cosas diferentes (y está bien que lo sean para no perder la capacidad de usar el cliente al mismo tiempo que el servidor está andando).

A continuación notaremos que si bien el nodo se conecta exitosamente a la red EchoLink y aparece publicado como activo no se puede llegar a el. Eso ocurre por las caracteristicas que típicamente tiene una conexión de Internet hogareña, donde el router cambia la dirección IP con que se expone a la red mediante una acción llamada NAT (Network Address Translation, traducción de dirección de red). Eso se hace así para por un lado proteger los dispositivos que uno tenga en casa del acceso externo y por el otro para que todos los dispositivos se presenten a la red como provenientes de una única dirección IP, eso es bueno en general para el uso diario pero no lo es tanto cuando quiero acceder desde el exterior a un dispositivo en particular dentro de una red hogareña, en éste caso la máquina que corre el nodo server.

Hay varias soluciones posibles, la mas neta es abrir un puerto en el router lo que involucra un procedimiento técnicamente complejo (simple cuando se sabe lo que se quiere hacer) pero que requiere reconfigurar la red hogareña entera, queda fuera del alcance de ésta entrada explicarlo.

El problema se explica con cierto detalle en el sitio EchoLink (link).

Una solución mas simple es utilizar un nodo "proxy", es decir que reciba las llamadas para nosotros y mediante un esquema de conexión donde nuestro nodo va a buscar la conexión en vez de esperar recibirla es posible sortear el problema de la traducción de direcciones. Después de todo es un problema muy común para el cual le han pensado ésta solución simple. Hay una lista bastante extensa de nodos proxy disponibles (link), en ocasiones esa página dá problemas de seguridad pero son falsas alarmas y pueden ser ignorados. Claramente no es una solución que escale en tráfico e introduce latencias adicionales que pueden ser molestas, pero para una prueba de concepto es perfectamente aceptable. En la configuración el proxy que utilizo es elp108.pi9noz.ampr.org aunque hay muchos otros.

Finalmente, un último obstáculo a superar, con el proxy configurado puedo acceder al nodo local desde un cliente cualquiera EchoLink, pero el audio es inservible y con una fuerte realimentación. Eso se debe a que la mayoría de los handy tienen una conexión de audio "económica" destinada a simplificar y hacer económico el micrófono, pero que no se lleva bien con éste tipo de uso, se crean lazos de masa indeseables que hacen realimentar la salida a la entrada. Para evitarlo es necesario aislar galvánicamente el circuito de micrófono con el de parlante del handy y los correspondientes a la entrada y salida de la placa de sonido. Eso se logra con un transformador de audio como los que se utilizan para, justamente, eliminar lazos de masa en sistemas de audio.
Con ese último agregado el sistema funciona perfectamente, tiene un retardo aproximadamente similar al del resto de los nodos que funcionan en la red y es por lo tanto usable. Acepta conexiones múltiples y se comporta, a todos los efectos prácticos como cualquier otro nodo de la red EchoLink.

El sistema, como tal, es mucho mas abierto y configurable que su contrapartida en EchoLink, sin ir mas lejos se disponen de los fuentes con lo que se pueden introducir modificaciones al código, y sin llegar tan lejos hay media docena de funciones tales como repetidor Echo, enlaces por red, conexión con APRS y otros que vale la pena explorar. Estimo que hay para muchos meses de experimentación para quien quiera ir en ésta dirección, y es posible que sea un proyecto muy interesante.

Estoy convencido, además, que aunque una placa Raspberry Pi 3 sea suficientemente "pequeña" el uso de CPU y otros recursos es tan bajo que el sistema, con tiempo y paciencia, tiene que poder funcionar en una Raspberry Pi Zero. Un proyecto en si mismo.

Muchas de las objeciones que puede tener el EchoLink como sistema son abordadas por las modernas redes digitales (por ejemplo DMR, Yaesu System Fusion, etc.) a las cuales EchoLink también se puede integrar, generando un interesante ecosistema analógico-digital.

¡No digan que no es tema para abordar en el 2021!




miércoles, 30 de diciembre de 2020

MicroSOTA y los microtranceptores QRPp

 

Revisando los canales YouTube habituales hubo un anuncio que fue manejado con bastante anticipación, con lo que genera expectativa. Se trata de la operación "MicroSota" que prometía la operación en SOTA (Summit on the Air) con el transceptor mas pequeño.

Fue anunciada bastantes días antes de ser publicada  con lo que generó alguna legítima expectativa. 

La corriente "SOTA" es un patrón de actividades en radio que premia el contacto con estaciones que operan desde "alturas" (cumbres, summit en inglés). Cada cumbre significativa (creo que la loma de 15 metros de altura donde vivo no cuenta como válida) tiene un código que la designa, cada país tiene su inventario de cumbres válidas y la actividad consiste en distintos formatos de colección de "cumbres". Tiene un esquema similar conceptualmente al de IOTA ("islands on the air") que quizás es un poco mas establecido, aunque su activación es mas costosa por la logística que suele involucrar llegarse a una isla que califique como válida. En el caso de SOTA son actividades mas al alcance de un grupo pequeño, o incluso un individuo, con una logística muy frugal, casi la propia de una excursión de campamento. Es sin duda un motivo de diversión a quienes contactan, pues se arman "pileups" significativos como para el que opera pues implica habilidades operativas similares, aunque de menor escala, que las de un operador DX-pedition. 

Hay un esquema de anuncios de activaciones y registro de planes futuros que, siendo muy organizados, completan la operación de ésta modalidad. En principio, no hay restricciones a las antenas, equipos o potencia con la que opere la estación en la "cumbre", pero en general llegar allí implica travesías a pie literalmente cargando con los equipos, antenas y fuentes de energía. Existe entonces un imperativo práctico para que las estaciones que van a la "cumbre" lleven equipos lo mas pequeños posibles, que utilicen la menor energía posible y las antenas de las menores dimensiones posibles. En ocasiones lo práctico es llevar un handy y operar la cumbre en V/UHF, en ocasiones eso puede dar acceso a una audiencia de centenares de kilómetros a la redonda, sobre todo en las cumbres cuyas faldas dan lugar a valles extensos, algunos con cierta densidad de población. Eso ocurre en casi toda nuestra pre-cordillera andina, en las sierras de Córdoba y San Luis así como en lugares seleccionados de la llanura pampeana (Balcarce, Tandil, Ventana, etc.). Pero, el condimento que siempre se trata de agregar es poder operar en HF, y para ello se debe apelar a transceptores muy pequeños, en ocasiones comerciales y en ocasiones caseros. Operando con potencias QRP (5W o menos) o incluso QRPp (1W o menos), usualmente en CW pero en ocasiones en Fonía o modos digitales. Con antenas usualmente portátiles verticales de dimensiones reducidas o de hilo tipo random wire, long wire o, con mucha frecuencia, antenas tipo EFHW (End Feed Half Wave). La energía es usualmente provista por baterías y ocasionalmente por energía solar, no conozco casos de energía eólica, pero seguramente alguien los habrá utilizados. Sin embargo cualquier modo de generación es típicamente voluminoso y por lo tanto lo que domina la activación es hacerla con la menor potencia posible. Las activaciones, dada la naturaleza del lugar, suele realizarse durante una jornada o fracción.

No he realizado SOTA activamente transmitiendo desde una cumbre, no al menos bajo el marco del programa de premios; si he comunicado en ocasiones con estaciones en cumbre. El desafío es bastante interesante, pues si bien la concurrencia es menor que cuando se contacta una DX-pedición, las capacidades de la estación en cumbre son drásticamente menores, por lo que se necesita una enorme habilidad operativa en el "cumbrero" para realizar éste tipo de operación y que sea divertida para todos.

Sin embargo, en casi 20 años de vivir en Córdoba, operé muchas veces desde las sierras de Córdoba, en condiciones QRP o QRPp y con fuentes de energía "off the grid", mayormente a batería pero ocasionalmente solar. Esas operaciones las hice en su enorme mayoría en CW, pero ocasionalmente en fonía (con buenos resultados dado el muy bajo ruido en esas locaciones) y con toda una gama de antenas portátiles. Muchas de las antenas están plasmadas en éste blog o en su predecesor lu7hz.blogspot.com . Por eso cuando finalmente apareció el video en el canal YouTube de Adam (K6ARK) (ver aqui link) me fue imposible no compartir inmediatamente el entusiasmo que transmite durante su expedición tanto por el lugar desde donde opera como por el equipo con que lo hace.

El equipo, cuyas especificaciones técnicas no indica exceptuando que es un prototipo, lo menciona en un tramo como una variante del legendario Pixie, circuito que he experimentado hasta la nausea en diseños propios y ajenos. Curiosamente Adam se "queja" de lo rústico del transceptor y sus pobres capacidades de selectividad. Todo conocido. Pero, claro, ... ¡2.7 gramos!. No está claro como se llega a eso ni a una potencia de 850 mW pues, nuevamente, no dá detalles técnicos. Refiere a un video anterior donde habla del "mini Pixie" siendo el de ésta oportunidad un "micro Pixie", supuestamente mucho mas pequeño. 

Conociendo el circuito estoy seguro que el par de gramos no incluye batería ni antena, fin de la discusión.

Tampoco, sin certeza pero sin dudas al afirmarlo, incluyen conector alguno o el keyer.

La potencia  indicada es, seguramente, de entrada y no de salida, concordando con los clásicos 400-500 mW típicas de un Pixie, pero me genera cierta curiosidad el manejo de la disipación. El Pixie se le puede extraer 500 mW de RF pero sin disipador bastará una "T" un poco larga o un poco de QRQ para que la etapa final resulte dañada, ni hablar de una antena con pobre adaptación. No, el Pixie es noble, pero las potencias mas seguras están en el entorno de 100 a 250 mW de RF.

Para que el transceiver mismo pese eso es claramente una versión reducida del Pixie, dado que el clásico pesa unos 50 gramos. 

Hay diseños de Pixie que construidos con componentes SMD pueden dar el factor de forma mostrado por el video y el peso, aunque claramente la construcción requiere típicamente una placa impresa especial, no es un diseño minimalista para prototipos. Sin embargo, hay servicios que permiten realizar tiradas de impresos muy pequeñas, algunos incluso individuales, a precios muy bajos, asi que es posible. Claramente, hay que ver los detalles, donde como sabemos el Diablo siempre se esconde.

Mientras reflexionaba sobre posibles enfoques técnicos recordé un proyecto hecho hace ya varios años, un híbrido entre el Curumim de PY2OHH, el Pixie clásico y la evolución de otros diseños propios presentados en mis blogs; ese proyecto lo llamé en su momento Arin y lo publiqué en mi blog anterior (link) en varias entregas, como un sistema de construcción que empieza por la descripción conceptual, continúa con la construcción y finaliza con el diseño del impreso. Por lo que recuerdo el peso del mismo era de unos 10 gramos con componentes convencionales una vez construido y operaba por un tiempo (breve) desde una batería convencional de 9V. Creo que hoy con los packs LiPo de alta capacidad de recarga de celular mas un "cable" conversor de 5V a 12V (creo que no hay de 5V a 9V) tiene que andar muy bien a un costo en términos de prestación vs. peso mas que razonable. Un arrancador de auto portátil basado en batería LiPo es también una opción atractiva en peso, tamaño y costo.

Es un proyecto interesante para aggiornar, ver como con tecnología un poco mas moderna es posible mantener la simplicidad al mismo tiempo que se incrementan las prestaciones (¿un DDS miniatura? ¿medidor de potencia? ¿tono? ¿offset? ¿CAT? ¿modos digitales?), creo que un objetivo razonable sería unos 20 o 30 gramos (sin antenas ni baterías) con un factor de forma de una pulgada cuadrada.

Pero mas allá del solaz y la anticipación de alguna diversión futura encarando ese proyecto como desafío creo que el Arin tal como estaba es un potencial compañero de andanzas de alguien que haga SOTA, así como fue planteado, una década atrás .... ¡por lo menos merece una prueba!



miércoles, 16 de diciembre de 2020

Construyendo puentes, el componente BridgeX



Un poco para ir redondeando el año técnico quería compartir (¿documentar?) un logro técnico que perseguí por mucho tiempo con mi estación concursera y en la que por distintos motivos gasté una enorme cantidad de horas. Para dar contexto me tengo que remontar a casi una década atrás. Luego de unos primeros intentos con software de logging de concursos claramente no apropiados, porque no eran para concursos o porque eran demasiado frágiles, adopté el famoso programa N1MM (por entonces la versión anterior). Esa decisión fue, en perspectiva, mucho mas durable que lo que podría hacer suponer un simple experimento. Con el tiempo probé otros software de concurso como AATest o WinTest, pero volví al N1MM. Los programas para logging de concursos tienen una enorme cantidad de funciones pues deben operar en una enorme variedad de configuraciones, satisfacer una igualmente enorme cantidad de posibles gustos y preferencias y además estar constantemente siendo ajustado a las siempre cambiantes reglas de los concursos alrededor del mundo. Tom (N1MM) y su equipo hacen un magnífico trabajo en lograr posicionar su plataforma, gratuita, como uno de los programas top en la materia y someterlo a constantes actualizaciones (en ocasiones varias por semana) en, por lo menos que me conste, la última década. Posiblemente desde antes. El primer traspié fue que todo el resto de los programas que quería usar no eran compatibles con N1MM pues se basaban en la plataforma OmniRig, que N1MM no le dá soporte. Al principio, inocentemente presumo, crei que era una omisión involuntaria. Por eso en distintos foros de soporte plantee la cuestión y me sorprendí un poco por el tipo de respuesta airada que obtuve de algunos miembros del equipo de desarrollo, no de Tom es bueno decirlo, opinando sobre mis motivaciones equivocadas y arriesgando que era técnicamente "imposible". Con el tiempo y otras interacciones con Alex (VE3NEA), autor del OmniRig y del CW-Skimmer entre otros,  mediante me di cuenta que había algun tema dando vueltas entre ambos equipos y que no podía esperar que ninguno de los dos fuera demasiado cooperativo. La principal razón para necesitar esa integración es que varios programas obtienen información del CAT del transceptor, frecuencia en particular. Y el CW-Skimmer, que a pesar que jamás lo usé como decodificador de CW, que es tan bueno o malo (según se prefiera) como otros decodificadores, tiene uno de los filtros mas potentes que conozca. Filtros Bayesianos. Un tipo de filtro que con el tiempo trabajé bastante en investigación académica y que solo se puede implementar con técnicas DSP. Es cuestión de tiempo que se desarrolle un hábito en el sintonizar las estaciones haciendo "click" en la señal de la misma, desarrollar una técnica para agudizar la coordinación cerebro-oido prestando atención al waterfall del CW-Skimmer y otras facilidades. El CW-Skimmer es el motor atrás del potente Reverse Beacon Network, además. Con el tiempo desarrollé el dispositivo para habilitar la operación SO2R primero y SO3R después. Primero en hardware y luego en software. Nuevamente, cada vez mas dependiente de poder administrar los equipos por fuera del N1MM. Pero el N1MM seguía sin incluir al OmniRig pues "no se podía". En realidad sería muy facil desarrollar el soporte en N1MM para el OmniRig, no es novedoso siquiera pues lo hacen otros programas como AATest o WinTest, simplemente se define un transceiver que sea "OmniRig" y se envian los comandos por alli, dejando que el OmniRig "traduzca" los comandos al transceptor físico que fuera, todos los comandos que usa el N1MM son, por supuesto, soportados por OmniRig. Todo el resto es pelea de pueblo chico pero que no se puede hacer nada sobre ello. No pasó mucho tiempo para que dejara de lado semejante pamplina y desarrollara (hace casi 10 años atrás) un programa denominado MM2OR (n1MM 2 OmniRig) que básicamente es un artefacto típico de integración de sistemas, como los que he construido o sido responsable de construir docenas en mi vida profesional. Utilizar alguna de las interfaces de un software para colocar un traductor que lo haga hablar con otro, sin que naturalmente ninguno de los dos esté pensado para hacerlo. En el caso del N1MM ese punto de apalancamiento fue la comunicación serie con el transceiver. Básicamente el programa MM2OR simula un puerto serie (mediante el programa com0com) y escucha en el. Cada vez que el N1MM envía un comando al transceiver el MM2OR lo intercepta y lo envía al transceiver en su nombre, usando OmniRig. La respuesta, también por OmniRig es enviada a N1MM por el mismo puerto serie virtual. N1MM "piensa" que está hablando con un transceiver. Conceptualmente es simple, prácticamente no lo es tanto. En primer lugar había que entender que comandos usa el N1MM para comandar al transceiver, por prueba y error fui sacando que comandos envía permanentemente (status y frequencia), que comandos espera del transceptor (frecuencia y modo) y que comandos puede tirar ocasionalmente (tipo cambio de VFO, split, modo, banda, etc.). Luego encontré que el N1MM tenía bugs, por ejemplo, enviaba dos comandos juntos al transceiver, ... y esperaba las respuestas juntas (como seguramente lo hacía el transceiver). Sin embargo cuando "parseando" los dos comandos primero se proveía la respuesta a uno y luego a otro el N1MM simplemente quedaba confundido. Como anécdota solo cabe aclarar que comentado el problema con uno de los desarrolladores ni siquiera entendieron de que se trataba y porque era un problema. Como quiera que fuera, con todo éste lio era entonces posible que varios programas Y el N1MM hablaran simultaneamente con un transceiver, y luego con dos (máximo que soporta OmniRig). Nació allí el sistema SO2R que usé por muchos años con distintas combinaciones de radios. Primero con un FT100, luego un FT740 con un FT100, luego el FT100 lo reemplacé por un FT790 y finalmente agregué a la mezcla un IC706 y el FT817. Para operación normal no es necesario pues uso software de teclado y logging (AALog, BandMaster y CWType) que si es compatible con OmniRig. El tema era solo con concursos. Salvo la molestia de tener que modificar el programa MM2OR cada vez que agregaba un nuevo transceptor para "enseñarle" los comandos que el N1MM podría solicitarle (en el propio protocolo CAT del transceptor) no hubo grandes cambios. Siempre me maravilló porque los fabricantes no hicieron un solo protocolo de CAT y ya, pero no, incluso Yaesu usa prácticamente un dialecto (o un lenguaje diferente) para cada transceptor.
Todo bien, muy contento con mi estación y dedicándome a construir las capacidades concurseras en otros aspectos por más de una década.
Cuando mudé mi estación desde Córdoba a Buenos Aires y pasé de ser LU7HZ a ser LU7DID hice una inversión muy importante en renovar equipos, adquirí un Yaesu FT-2000, persiguiendo un deseo de mucho tiempo de poder operar en concursos en modo SO2V en lugar de SO2R, es decir teniendo un equipo con receptor y sub-receptor. Las ventajas son conocidas para quien hace concursos y difíciles de explicar para el que no, pero involucran velocidad de tasa, integridad de equipos y compartir antenas, cosa que no es posible con dos equipos separados. Todo muy bien. No tardé en escribir las extensiones de MM2OR para que entendiera a un FT2000 pero ahí me encontré con un escenario nuevo. N1MM podía fácilmente integrarse, reconocer y usar los dos receptores del FT2000 tirando comandos que apuntaran al VFO A o al VFO B. No fue difícil acomodar la traducción usando MM2OR y OmniRig. Pero ésta vez fue CW-Skimmer (y el resto de la suite) al que no le dió la talla. Simplemente están preparados para trabajar con dos transceivers, pero no con un transceiver con dos VFO. Existe un truco muy sencillo, modificando los archivos de inicialización del OmniRig, para que intercambie los VFO. Es decir que si los comandos son para el VFO A lo tire en realidad al VFO B y viceversa. Eso solucionaba que CW-Skimmer pudiera controlar el VFO B, pero no solucionaba que hablara con un solo VFO. 
Plantee el tema a Alex (VE3NEA) quien no entendió siquiera el problema, recomendándome que alterara los archivos de descripción para justamente intercambiar los VFO. Luego me recomendó que definiera el mismo transceptor en ambos "rig" del OmniRig, solo que uno con la definición "derecha" y el otro con la definición "cruzada". Pero eso falló pues los dos rigs tendrían que compartir el mismo puerto serie, y una vez que uno lo abre no se lo deja abrir al otro. Una falla tan trivial me hizo suponer que Alex ni siquiera le había dedicado tiempo a ponderar mi pregunta antes de contestarme, su respuesta fue demasiado errada para suponer otra cosa.
Hice entonces una primera versión del programa BridgeX, siguiendo en el mismo concepto de integración usado por MM2OR, pero esta vez con OmniRig. Un programa escuchando en un puerto virtual (diferente al físico que estaba conectado en el transceptor) recibe los comandos que están dirigidos a un transceptor FT2000 que en realidad no existe, invierte los VFO y lo manda al otro transceptor via OmniRig. El diagrama (a mano alzada) se puede ver en la figura adjunta. Pero no funciona y no funciona porque el OmniRig tiene un bug. En lugar de mantener separadas las interacciones con los puertos series OmniRig no tiene esa precaución, con lo que cae en un problema llamado "re-entrabilidad y re-usabilidad", es decir intenta usar un puerto serie mientras está "adentro" del código de usar otro. Como resultado la ejecución "pisa" el ejecutable, destruye el stack y produce toda suerte de errores exóticos. Usando éste mismo esquema a mano alzada le pregunté a Alex por el problema y me dijo que si, que podía ser un error, que quizás en algún momento en el futuro lo corregiría o que quizás permitiría que CW-Skimmer seleccionara el VFO con el que operaba, o ambas cosas. Quizás. Algún día.  O nunca, vaya uno a saber. 
El proyecto estuvo dormido por casi dos años con lo que "coexistí" con el problema al que resolví con mantener la sesión "run" del CW-Skimmer sin conexión con el transceiver y hacerlo con la sesión "S&P". Dicho de otra manera, barrer multiplicadores con "point & click" pero mantenerme fijo en el run. De todas formas el N1MM siempre sabe en que frecuencia está cada uno pues, nuevamente, si reconoce sin problemas los dos VFO.
Hasta que preparándome para el CQWW 2000 volví a retomar el proyecto pero con una vuelta. El problema era el bug de OmniRig al tratar de usar dos puertos, uno real y uno virtual (que terminaba intentando pasar comandos al transceiver por el real). Entonces, ¿porque no virtualizar todo...?
El resultado del razonamiento se describe en la figura adjunta. Básicamente replico la estrategia de virtualizar puertos, en éste caso dos puertos distintos COM10 y COM12, donde escucha BridgeX los comandos respectivos. OmniRig envia comandos a esos puertos como si fueran dos transceivers distintos, ambos FT2000 en cuanto a sus comandos CAT. El programa BridgeX recibe los comandos, en el caso de los que recibe por COM10 los pasa físicamente (por COM4) al transceiver mientras que los que recibe por puerto COM12 los pasa, también por COM4, pero invirtiendo VFO A y VFO B. Como resultado CW-Skimmer tiene una instancia sobre el transceiver en rig1 (el FT2000 que toma sus comandos) y otra instancia en rig2 (el FT2000 que invierte VFO). Como resultado ambos CW-Skimmer interactúan cada uno por su lado con distintos VFO. Y se puede hacer S&P en cada VFO por separado. Y se gana bastante en agilidad operativa. De alguna manera vuelvo a tener todas las facilidades que tenía con dos transceivers separados pero ahora con todas las ventajas de uno integrado.
El esquema lo usé en forma prototipo en CQ WW, y luego de algunos ajustes nuevamente en ARRL 10 Meters. Con excelentes resultados en ambos casos. Fue un puente que tardé muchos años en encontrarle la vuelta, y al final como en todo problema que se resuelve, la solución parece muy simple. Al punto que uno se pregunta, ¿porque habré tardado tanto tiempo en encontrarla?. La conclusión es que no hay cosas "imposibles" en materia de software, solo mas o menos ganas de hacerlas.