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.


 

viernes, 27 de noviembre de 2020

CQ WW 2020 CW

Hoy comienza a las 0000Z (2100 ART) la fecha mas esperada del calendario anual de concursos en CW, el fantástico CQ World Wide edición 2020. Hay una enorme cantidad de concursos en todo el mundo, durante todo el año. Pero solo una docena son los realmente "top-top", especie de circuito de lo que en tenis serían los torneos de "grand slam". 



Pues bueno, dentro de ese circuito tan selecto éste concurso es, en mi opinión y continuando con la analogía comparativa, Wimbledon mismo. Las condiciones de propagación están empezando a mejorar, después de todo el ciclo solar 25 ha comenzado, pero es justo decir que eso oficialmente ocurrió hace menos de dos meses asi que todavía estamos en un mínimo significativo camino al máximo pronosticado de ocurrir en el 2025. Espero que los eventos y actividad menores del sol permitan empezar a encender las bandas altas, en particular la de 10 metros.

Siempre encontré útil estudiar en forma previa la propagación y en función de eso definir mi estrategia de participación; en particular si lo haría "all band" o "single band", y en ese último caso en que banda, y definido en que banda identificar en que horarios es mas probable que se tenga actividad. El CQ WW tiene el condimento competitivo en cuanto a que es importante, muy importante, no solo apuntar a tener contactos (QSO) sino también multiplicadores (Zonas CQ y Paises, algunas estaciones otorgan ambos), debido a ello es quizás necesario estar llamando sin tasa prácticamente por horas para capturar "ese" multiplicador aislado que no teníamos. En lo personal estoy inclinado en los últimos años a tener participaciones single band, eso dá entre 18 y 24 horas de actividad sobre las 48 del concurso según la propagación. Es un buen equilibrio entre la demanda física y obtener resultados competitivos. Creo que la participación all band a niveles competitivos requiere un esfuerzo que me resultaría complicado aplicar o, quizás, una participación M/S o M/1 o M/2. Pero desafortunadamente no he podido sumarme a iniciativas de ese tipo ni ayudar a organizarlas.

Como sea, cualquier estrategia requiere un pronóstico de la propagación, y cualquier pronóstico de la propagación empieza por recordar que se trata de un fenómeno caótico, de escala cósmica y mayormente abordable con criterios estadísticos. Cuando se utilizan técnicas estadísticas es necesario acostumbrarse a que lo que se obtienen son valores esperados con margenes de confianza sobre su ocurrencia, y los márgenes de confianza pueden ser amplios. Nada reemplaza las decisiones de concurso escuchando la banda o, según el modo de operación elegido, evaluando la información provista por los distintos recursos disponibles (cluster, reverse beacon, WSPRNet, etc.) de lo que realmente está ocurriendo. Algunos operadores me han, con alguna frecuencia, comentado que en realidad las condiciones son tan variables e impredecibles que cualquier intento de pronosticarlas es "futil" (optimistamente inutil). Otros simplemente confían mas en sus instintos y experiencia para saber cuando participar ante que cualquier otra herramienta de pronóstico. Dichas esas salvedades la experiencia en concursos y los resultados que fui obteniendo me llevan a confirmar que el pronóstico es una herramienta útil para planear, que permite tener una idea con una aproximación de una hora, los principales momentos de actividad del concurso en cuanto a "run" y anticipar con cierto criterio "quirúrgico" la persecución de multiplicadores. Y de esa forma poder articular un poco mejor los horarios del concurso, poder descansar apropiadamente y también honrar otras actividades personales.

Dicha la explicación es bueno recordar, brevemente, el algoritmo para realizar el pronóstico. Todo empieza por decidirse por un elemento que sea predictor de la probabilidad de hacer un contacto en una determinada hora comparada con otra del horario de concurso. Se pueden usar múltiples fuentes. Modelos teóricos como HFCap o VOACAP (en realidad el mismo motor subyacente), frecuencias relativas de contactos derivadas de concursos anteriores propios o ajenos o monitores de propagación tipo clusters, reverse network y WSPRNet. He usado en distintos momentos los distintos mecanismos y el uso de los monitores de propagación es el que me ha dado los mejores resultados. Personalmente el que mas me atrae es el basado en WSPR, porque detecta propagación incluso cuando no hay actividad, incluso si es muy marginal. Pero lamentablemente la cobertura de bandas es muy despareja, quizás si tuviera intención de operar solo en 20 o 40 metros sería el ideal, en particular 20 metros pues tengo los datos de mi propia baliza que tiene en cuenta todos los aspectos sobre instalaciones y antenas. El Reverse Beacon Network y la info de los clusters es posiblemente el mejor equilibrio entre exactitud y volumen.

Pronóstico de propagación para CQ WW 2020 CW (datos LU9DA Web Cluster)

Para éste caso estoy usando los datos que baje del DX cluster de Rick (LU9DA) donde figuran los spots en las distintas bandas reportadas para nuestra Zona 13 (zona CQ). Es cuestión luego de calcular las frecuencias relativas de QSO para asimilarlas a probabilidad (Fischer). Hay, al respecto, dos visiones útiles y complementarias. Para quien participa "all band" el interés pasa por tratar de aproximar en que banda en cada momento puede ser el mejor, quizás no para cambiar de banda ciegamente pero si para monitorear con mas cuidado quizás con un segundo receptor si la propagación va cambiando. El cálculo de frecuencias se obtiene calculando el número de spots en cada banda respecto al total de spots en una determinada hora. A ésta visión se la puede denominar "mejor banda para la hora".

Para quien participa "single band" el principal interés es entender en que horas tendrá mas o menos actividad, e incluso a que zona geográfica puede estar orientada cada horario. De esa manera una determinada hora puede ser marginal en cuanto a probabilidad de contacto pero puede ser la mejor o la única para ciertos multiplicadores (¿Oceanía? ¿Asia Central?). Esa probabilidad de puede aproximar desde la frecuencia calculada como cantidad de spots de un determinado horario respecto a cantidad total en un período (por ejemplo 24 horas). A ésta visión se la puede denominar "mejor hora para la banda".

Se asume en ambos casos que siendo promedios los ciclos de probabilidad se repetirán en los dos dias de concurso, todos sabemos que no es lo mismo la participación en el primer que el 2do dia. Pero termina siendo una cuestión de intensidad, habrá mas o menos concursantes, pero la distribución relativa depende en forma última de la propagación.

En la tabla anterior se exponen ambas visiones para todas las bandas, los colores verdes tienden a indicar una frecuencia mayor (mas favorable) tendiendo al rojo (menos favorable) pasando por valores intermedios (amarillos y naranja) para cada una de las horas del concurso para cada ciclo de 24 horas del concurso.

Por ejemplo para una participación "single band" en 15 metros tendría que tomar la tabla de "mejor hora para la banda" y observaría que se pronostica propagación entre las 1000Z y 2300Z con máximos durante la mañana y el atardecer.

Si hubiera que participar en modo "all band" muestra que en cada horario hay alguna banda recomendada, pero la performance individual de cada banda con el cuadro de "mejor hora para la banda" muestra que en algunos casos aún siendo la única banda recomendada para un horario, la frecuencia para esa banda respecto a si misma es muy pobre. Por ejemplo 40 metros se muestra como la mejor banda a las 0400Z pero en ese horario solo el 2% de los contactos de esa banda durante el día; quizás es mejor planear dormir en esa hora.

Comparto ésta información en el entendimiento que es un recurso útil para otros participantes, ojalá que podamos participar en ésta verdadera fiesta de la radio y que por sobre todas las cosas tengamos un necesario momento de diversión en éste año tan complicado que hemos pasado.





lunes, 31 de agosto de 2020

El PicoFM de LU7DID

Cuando empecé en radio, hace mucho tiempo ya, el "novicio" tenía usualmente pocas alternativas para hacerse de sus primeros equipos para, también usualmente, empezar en la banda de 3.5 MHz (80 metros) en AM. Siempre podía adquirir un equipo comercial, la mayoría de nosotros soñaba despierto con los equipos Swan, Collins, Hallicrafters o Yaesu por entonces.  Pero esa era una opción mas bien lejana para la mayoría, como si estuviera en la Luna para mi al menos. La siguiente alternativa era comprar un equipo de segunda mano que algún aficionado que no lo necesitara mas ofreciera. Y finalmente podía construirse uno mismo los equipos, lo que era mucho mas común en aquel entonces que ahora. Los equipos de entonces, usualmente eran construidos con válvulas, eran por lo tanto relativamente simples. 
Los diseños mas comunes tenían 5 o 6 etapas en transmisión, a veces menos y a veces mas, en amplios chasis de 1/4 de metro cuadrado, con amplios espacios para hacer conexiones, robustos, fáciles de seguir y de reparar. Predominaban los circuitos de modulación a grilla pantalla, de algo menor calidad pero sensiblemente mas económicos que aquellos modulados en placa pues éstos requieren un transformador de modulación bastante costoso y difícil de conseguir. Los receptores a válvula eran por otra parte mas complejos, pero siempre se podía armar uno modificando una radio común de onda corta o usar un (relativamente simple) conversor cuya salida en banda de AM Broadcasting nos permitiera sintonizar las bandas de aficionados, al respecto había una gama amplia de conversores desde el legendario "Tramur" hasta los muy simples distribuidos por Daxon por medio de sus "mementos". Los repuestos en su gran mayoría se podían adquirir en casas de TV, excepto quizás las válvulas mas potentes de las etapas de salida que había que ir al "centro" a casa Galli u otras. En mi caso era muy chico y el camino que pude seguir fue que mi papá me comprara un equipo usado, cosa que aún el día de hoy creo fue de infinita sabiduría.
Pero a partir de alli las refacciones y mejoras corrían por mi cuenta como si hubiera construido el equipo. Muchas de las reparaciones iniciales la hizo quien fuera mi mentor en radio Don Ernesto Stellini (LU5EZ, SK) a quien he mencionado muchas veces y ese apoyo fue crucial en que pudiera lanzarme como aficionado. No soy adepto a los futuros contrafácticos pero es dificil especular que hubiera sido en mi vida de no haber empezado por la radio.
Pero aún así dependía de repuestos baratos porque el presupuesto disponible no era demasiado grande, por fortuna mis equipos usaban incluso para las válvulas de salida repuestos de TV blanco y negro a válvula de la época, el TV de casa tenía a tendencia a que su válvula 6DQ6 fallara con mucha frecuencia, el hecho que esa fuera la válvula de salida de mi transmisor era solo pura casualidad sin causalidad alguna como es posible imaginarse.
Todo esto viene a cuento, o introducción si se quiere, que por entonces la mayoría de los aficionados construía o metía mano con mayor o menor tino en sus propios equipos, conocía el circuito que tenía y podía con mayor o menor destreza armarse sus siguientes equipos o accesorios. Por ejemplo, el primer circuito que construí en mi vida fue un "aro de Hertz" con el que sintonizaba la salida de mi transmisor, circuito simple que me costó mis primeras quemaduras con el soldador. Como sea, con el tiempo esa relación del aficionado con sus equipos fue cambiando progresivamente; algunos dicen que para peor y otros para mejor. Por un lado los modos "simples" fueron dejando de lado, el AM fue desechado excepto segmentos muy pequeños de las bandas de 80 y 40 metros. El uso se SSB se difundió pero allí los equipos no eran tan simples de construir ni de ajustar. Por fortuna al mismo tiempo los diseños de estado sólido empezaron a acercar las bandas de VHF y UHF al aficionado común; previamente esas bandas eran para experimentadores muy "experimentados", necesitaban componentes especiales que no se conseguían y había muy poca actividad por lo que uno nunca estaba seguro si no comunicaba porque no  había nadie o porque el equipo no emitía. Rebobinado rápido al presente hoy es rutinario que un radioaficionado empiece comprando un equipo chico de FM para la banda de VHF y UHF; son equipos de exquisita miniaturización, robustos y muy sofisticados en sus funciones; muy pocos, poquísimos, arman sus equipos para operar en bandas de HF. Personalmente creo que sin armar desde cero un equipo para HF, lo que tiene su complejidad para proveer al mismo de funciones comparables con los modelos comerciales, es posible reconvertir con costos y conocimientos técnicos modestos equipos SSB de uso comercial para bandas de aficionado mediante kit de DDS y ajustes menores. Y por supuesto siempre están los kits para usos específicos como el D4D de crkits o alguno de los muchos kits disponibles tal como los ofrecidos por qrpguys o el legendario OCX de qrp-labs.
Quizás mas aficionados tienen a su alcance empezar en radio comprando un equipo de VHF/UHF a pesar de no tener formación técnica, quizás es mas difícil que permanezcan mucho tiempo activos basado en el interés en la experimentación. En éste blog he compartido muchos proyectos de equipos simples, incluso equipos simples pero muy sofisticados para las bandas de HF. Pero creo que hay recursos técnicos para poner en manos de experimentadores también las bandas de VHF/UHF. Hay módulos como el Dorji DRA818V/U que implementan un transceiver completo de VHF o UHF (depende de que módulo se elija) en un módulo de poco menos de 1" cuadrada. Es un proyecto interesante para un novicio porque la dificultad de integración es muy baja, a pesar que los módulos integrados sean muy complejos, básicamente se necesita utilizar un módulo transceiver, alguna forma simple de amplificar el audio, alguna forma de enviar comandos por el puerto serie del módulo para configurarlo y comandarlo y algún nivel de filtrado pasabajos a la salida. A cambio de eso se obtiene un transceptor, usualmente a construir como walkie-talkie aunque no fue eso lo que hice, de 1W de potencia capaz de operar tanto en simplex como por repetidora, con y sin tonos.
La hoja de datos del módulo da los comandos para programarlo, básicamente son secuencias de inicialización como si fuera un modem (secuencias AT) que establecen frecuencia, tonos, filtros, ancho de banda de canales y otros parámetros de funcionamiento. Una vez establecidos no es necesario emitir comandos para operar un comunicado normal, basta poner en bajo o en alto ciertas lineas de comandos para que el módulo emita o reciba. Pero es bueno poder cambiar el volumen, el nivel de squelch, la frecuencia y los sub-tonos a usar (o no) en un canal, y salvo que se opere en una frecuencia fija, lo que también puede tener su atractivo en incontables proyectos, es necesario algo que emita los comandos mediante el puerto serie. Y ese algo es usualmente un controlador o un microprocesador. El controlador es realmente simple, se puede hacer fácilmente con un controlador PIC, incluso uno sencillo, siempre que se acepte tener funcionalidades muy básicas. El enfoque mas común que se observa en proyectos en la red es hacerlo con una placa Arduino, incluso una bien simple como una Arduino mini o una Arduino nano o un ArduinoUno bastará (link). En mi caso, y como hago en otros proyectos, preferí utilizar una placa Raspberry Pi Zero W. Es mucho mas que lo necesario para programar el módulo transceiver, incluyendo un nivel de configuración y definición comparable al de cualquier transceiver comercial. Pero todos mis proyectos son con esa plataforma y también permite mayor flexibilidad de experimentación. El resultado puede verse en las fotos, un pequeño gabinete abierto hecho en la impresora 3D, la placa del módulo SV1AFN que utilicé para éste prototipo la que tenía desde hace algún tiempo por lo que la aproveché podría reemplazarse con cierta facilidad por un amplificador integrado y un filtro pasabajos (¡que no importa lo que diga la hoja de datos del módulo, es necesario!). Completan el proyecto un display LCD tipo I2C y un rotary encoder. El resultado lo puse en GitHub bajo el nombre de proyecto picoFM, en el mismo figura tanto el circuito como el software como otro material complementario del proyecto. Por cierto, el mismo no requiere habilidades constructivas ni equipo de pruebas especial, pero si una moderada capacidad de conectar módulos e interactuar con una placa Raspberry para cargar su imagen de sistema operativo Raspbian. Ayuda tener otro equipo de V/UHF para usar en las pruebas para no depender de otra estación para los reportajes.
Las pruebas en el aire fueron satisfactorias, aún en baja potencia podía utilizarlo en simplex y sobre repetidora (LU3DY, 147.12+600 con sub-tono). Supongo que para llevar en la mochila es mas cómodo un handy, pero comunicar con un equipo que uno acaba de construir siempre tiene un sabor especial,  por mas que sea un poquito mas grande y aunque no genere una difusa iluminación de los filamentos de válvulas como hace muchos años. Un chico de 12 años probablemente saldría corriendo confundido ante la posibilidad de armar un equipo de HF moderno, o quizás no, pero estoy casi seguro que si tuviera inclinaciones técnicas encontraría este tipo de proyecto muy atractivo, quizás con muy poca guía de un mentor o de un Radio Club. 
Para los mas experimentados, quienes quizás no tengan interés en tener "otro" equipo de V/UHF,  el proyecto no solo tiene porque ser la base de un transceptor, puede dar pie a todo tipo de experimentación con estaciones automáticas, digipeaters, repetidores EchoLink, seguidores APRS, globos y toda suerte de proyecto donde se requiera emitir y recibir usando poco espacio, poca energía y poco peso.

miércoles, 26 de agosto de 2020

Escuchando susurros en LU7DID. decode_FT8


Pocos modos han tomado tan por sorpresa y en forma tan vehemente la actividad radial como el coloquialmente denominado "FT8", acrónimo artístico de un nombre mas extenso "Franke-Taylor 8 Frequency Shift Keying". Desde el punto de vista de teoría de comunicaciones el FSK no es novedad, tampoco los modos de modulación de tipo n-FSK (n tonos). ¿Cual es la novedad entonces?. La novedad consisten no tanto en la modulación en si misma como en el protocolo para usarla. ¿Que se emite? ¿En que orden? ¿A que velocidad? ¿Con que diseño de modulación en términos de separación y simbolos? Todo eso hay que definirlo por mas que los "1" y "0" terminen codificandose con un método de modulación FSK, en el gran esquema de las cosas eso último es "facil". Medios de modulación abundan en manos de los aficionados, hay esquemas que llevan décadas de presentados y atraen a nadie. Incluso esquemas muy promisorios, que en papel lucen muy potentes, y tienen poco uso. ¿Que es lo que produce lo uno o lo otro?.
Solo puedo esbozar una opinión, luego de observar algunos hechos, que seguramente será incompleta y que puede o no tener aceptación. Para mi es un combo que incluye excelencia técnica, con facilidad de uso, con resultados prácticos, con infraestructura, con coyuntura de propagación y con suerte.
Empecemos por la excelencia técnica. Como apunté antes el uso de FSK como medio de modulación es tan viejo como la radio misma, aunque solo con el vuelco desde comunicaciones de tipo analógicos a digitales en, digamos, los últimos 30 años se hizo masivo. Prácticamente todas las transmisiones digitales se hacen con alguna variante de FSK (o su prima hermana PSK), nuestro mundo tal como lo conocemos hoy "late" al compás de una música usando PSK. O sea que no hay novedad técnica en su uso. Ahora bien, la comunicación usando modulación PSK se deteriora con la relación señal-ruido algo mas graciosamente que los esquemas basados en modulación de amplitud (SSB, DSB, etc) pero finalmente requieren que la señal esté "por arriba" del piso de ruido para un ancho de banda dado, al final el ruido siempre gana la batalla inyectando desorden y caos en la armonía inteligente de la información que está siendo transmitida. Eso se soluciona, tradicionalmente, aceptando que ocasionalmente algo de la información será destruida por el ruido y generando los mensajes con algo de redundancia, de acuerdo a los parámetros de diseño puede ser para saber si todo un "pedazo" de la información está corrupto y hay que desecharlo pidiendo al otro extremo que lo envíe de vuelta o, en casos mas sofisticados, pudiendo incluso corregir algunos "bits" de información destruida por los mismos bits enviados en forma redundante (algoritmos de corrección). Pero al final, si la relación señal a ruido se deteriora lo suficiente, muy pocos pedazos de información pasan o no alcanzan los bits de corrección para arreglarlo, o las dos cosas. El ruido siempre gana al final del día. Estrategias para abordar esta cuestión hay muchas. La mas obvia e inmediata es aumentar la potencia lo que tiene limites prácticos puestos por la tecnología, la legislación e incluso la preferencia de los operadores. La segunda estrategia es, dado que el ruido es "blanco" y a mas ancho de banda mas energía tiene, reducir el ancho de banda de la señal. Una señal de AM tiene el doble de ancho de banda que una de SSB, a igual información. SSB siguen siendo casi 3 KHz de ancho de banda muy ineficientemente poblados por la voz humana. El modo de voz digital (Digital Voice DV) codifica digitalmente la voz en forma mucho mas eficiente en ocupar aproximadamente 1 KHz, mucho mejor aunque el modo no termina de prender, quizás no tuvo tiempo para despegar o quizás hay varios "codecs" la pieza de software que digitaliza que no son completamente compatibles y ninguno se hizo dominante. Una forma de bajar el ancho de banda, y según lo que pronostica la teoría de la información, es bajar la velocidad a la que se la transmite. La voz hablada transmite información a una tasa de muchas decenas de "bits-por-segundo" equivalentes, podemos aceptar hacerlo a menos y tendremos modos digitales como RTTY (45.5 bauds) o PSK31 (31 bps) que son mas resistentes al ruido, pero mas lentos. Nada parecía superar a la reina de los modos, la telegrafía. Con un ancho de banda teórico de algunas decenas de Hz y práctica de 100 Hz o menos permite comunicaciones relativamente lentas (25 a 30 ppm) pero que requieren menos potencia o que a igual potencia son mas resilientes en malas condiciones. Como telegrafista de cierta experiencia puedo sin dar muchos flancos a la crítica afirmar que las supuestas ventajas del CW devienen solo de su equilibrio entre velocidad (ancho de banda) e información transmitida, todo el resto es cháchara. El CW es bueno porque es lindo, es agradable y es rendidor; no hay que buscarle muchas mas explicaciones técnico-culturales, en general rebuscadas y erroneas. El CW fue desde siempre la frontera minima para poder comunicar en un circuito dado en condiciones dadas, y por cierto que muchas veces la única posible para una potencia dada. No es casual que quienes lo utilizan en condiciones de emergencia, baja potencia o precariedad de antenas lo consideren insustituible; todo estrictamente verdad, nada realmente mágico. ¿Que podemos hacer en realidad en CW? Los comunicados en CW son usualmente muy cortos, sobre todo en condiciones de concurso, DX o pileup. Dejemos de lado el martilleo que a puro gusto hay veces que hacemos con buenas condiciones de propagación a puro deleite "hablando" de distintos temas en las particulares abreviaturas que se usan en CW. Tomemos el caso de un concurso, estamos hablando de entre 4 y 6 contactos por minuto donde se intercambia la señal distintiva y el nivel de señal, quizás con un saludo final como al pasar (mas para cerrar el contacto y habilitar al siguiente que de amables). Esa es la comunicación máxima que damos por válida. Tomemos un caso menos extremo, un contacto normal pero rápido... ¿cuanto tarda? ... ¿un minuto? .. ¿dos?. O sea que aceptamos como contactos válidos aquellos en los que intercambiamos muy poca información y aceptamos invertir un minuto o dos para hacer un contacto. Si juntamos ambas cosas necesitamos menos velocidad de transmisión de información que en el CW. Y eso ya vimos que permite menos ancho de banda, y al tener menos ancho de banda permite o usar menos potencia para igual relación señal-ruido o tener mas margen de relación señal-ruido con igual potencia. Un modo mas eficiente en resumen. Y eso, exactamente eso, es lo que hacen los "modos digitales de baja señal", familia de modos de modulación que incluyen al WSPR o al FT8 entre muchos otros. En ellos el esquema es repetitivo. Un mensaje muy estructurado y conocido de antemano en su formato, se codifica con un algoritmo matemático que asegure redundancia de bits y corrección de errores. El mismo, una vez codificado, se envía "lentamente" por un canal usando modulación FSK. Para agregar menos incertidumbre se agrega un marco de sincronización de tiempo muy estricto, del orden de 1 segundo o menos, que ayuda a que mediante artilugios matemáticas pueda incluso mejorarse las chances de decodificar una señal del otro extremo. ¿Cuando mas lentamente? Bueno, WSPR se toma dos minutos por cambio. Un QSO compuesto de llamada, respuesta, señales, señales, adiós y adiós (5 a 6 cambios) puede durar 12 minutos, demasiado. Por eso el WSPR se usa como monitor de señales, uno escucha la señal al cabo de 2 minutos o no la escucha, si la escucha la reporta y si no la escucha no. FT8 usa un esquema similar, pero menos robusto, lo que permite que cada cambio dure solo 15 segundos. Entonces un contacto entero durará un minuto y fracción, similar a lo que dura un contacto similar en CW sin el frénesi de un pileup o un concurso. El llamado, la respuesta, el intercambio de señales y el adiós está codificado, no es cualquier mensaje, hay pocos datos variables (licencia, ubicación y nivel de señal) pero todo el resto está pre-definido y es rígido. Hay otros modos de comunicación, como JS8CALL, que usan el protocolo de FT8 pero para transmitir cualquier mensaje; siguen siendo muy robustos al ruido, mas que CW incluso, pero menos que FT8. ¿Que significa en números todo ésto? Una señal de SSB se acepta que debe estar para una buena legibilidad una unidad S por encima del ruido en un momento dado, es decir +6 dB. Para hacer las comparaciones entre modos uno sabe que puede reducir el ancho de banda a medida que usa modos que necesitan menos, pero para tener una comparación uniforme se utiliza como referencia la relación señal-ruido con la que el modo puede operar tomando un ancho de banda correspondiente a un canal de fonía. En tal sentido los modos digitales como RTTY o PSK31 puede operar entre 0 dB y -5 dB; CW en teoría unos -5 dB (lo que hizo ilusionar a muchos que el PSK31 podía reemplazar al CW solo que sin aprender Morse. Sin embargo el CW a oido permite al entrar a jugar la formidable combinación oido-cerebro operando como filtro el operar a -10 dB, incluso mas. FT8 puede operar a -20 dB y WSPR a -30 dB. La diferencia son abismales casi 26 dB con fonía y 10 dB con CW. Puedo hacer con 1W en FT8 lo que hago con 10W en CW y casi 500W en fonía, es abismal. Es una forma novedosa de apelar a tecnología que se conoce desde hace mucho, usada muy creativamente y con el auxilio de matemáticas muy avanzadas disponibles en abundancia con los computadores modernos.
Abordemos uno de los aspectos mas espinosos, quizás, y es la facilidad de uso. Es obvio que tecnológicamente FT8 es muy sofisticado, pero la complejidad está encapsulada en el programa que lo implementa y completamente invisible al operador. El operador configura unos pocos parámetros en su programa, define en que banda trabajar y rápidamente se le pueblan las ventanas de un montón de estaciones llamando CQ o teniendo contactos con otras. Un doble-click en cualquiera de las que llaman y el QSO puede completarse automáticamente, sin otra interacción. Suena a cazar patos, con dinamita y con los pobres patos atados a una estaca en la tierra. Demasiado facil, ¿no?. Y eso es cierto visto desde ese punto de vista. "¡Eso no es radio!" reclaman muchos. "¡Es demasiado facil, no implica ningún esfuerzo!" confirman otros. Todo eso es cierto, claro, solo que captura una parte del contexto. También es facil prender un amplificador de 1 KW y comunicar con el vecino de la otra cuadra, con el cual realmente no tenemos mucho para actualizarnos porque comunicamos ayer, y el esfuerzo no es mucho mayor, Solo que es un click en FT8 y varios clicks (en el PTT) en banda lateral. Podría estirar la metáfora indefinidamente sobre lo que es "facil" o lo que es "dificil" en radio. Ciertamente es radio, si usa RF y sale por una antena tengo que tener licencia, equipos y antenas; y cualquiera que los haya puesto en funcionamiento sabe que no se consiguen solos. Después en función el mérito, el esfuerzo y el estudio se comunicará en condiciones muy precarias o muy fáciles, depende de como se divierta mas el operador. Efectivamente con un click en FT8 inicio la secuencia del contacto, y el mismo es trivial si al corresponsal lo recibo a -5 dB, algo de esfuerzo si lo recibo a -10 dB, bastante esfuerzo a -15 dB y me tengo que pelar el alma para contactarlo a -20 dB. Supuesto que sea el único que quiera hacerlo, porque si hay muchos otros va a ser incluso mas dificil (pileup). Y recordemos que toda la actividad mundial de FT8 ocurre en solo 2 KHz de cada banda, es un guiso de gente..... Entonces, dá la casualidad, que las estaciones interesantes (los DX) muy a menudo entran a -20 dB y dan mucho mas trabajo que un "click-click", realmente hay que estudiar la propagación, levantarse temprano, encontrar banda y ventanita de algunos minutos para el contacto, insistir, buscar el hueco entre llamados de la competencia y finalmente, hacer el contacto. El esfuerzo, luego de haber hecho muchos QSO, no es significativamente mas facil que hacer contactos de pileup en CW con manipulador automático o teclado. Es mas facil de usar, pero solo marginalmente y en determinados contextos. En otros no es muy diferente.
Resultados prácticos y coyuntura de propagación van muy de la mano. Estamos en el mínimo del ciclo de manchas solares, por momentos parecía otro mínimo de Maunder (ausencia total de manchas solares) y eso hace que las bandas altas estén muertas la mayor parte del tiempo, excepto quizás a nivel regional. Bandas intermedias como 30,20 y 17 metros tienen aperturas pero mas breves y con mas ruido. Las bandas bajas, 40 metros para arriba, tienen su época de gloria. El ruido baja, la absorción en capas atmosféricas menores (layer D fundamentalmente) se reduce y las distancias se incrementan. Pero las aperturas son por el camino obscuro, en altas horas de la noche y breves. Históricamente los minimos solares representaron un mínimo de actividad de radioaficionados, por lo menos en bandas de HF y no tanto en bandas como VHF o UHF que no son afectadas excepto en raras ocasiones por los mínimos. Y siempre se pudo pilotear los mínimos con potencia hasta cierto punto. Pero usar FT8 es como tener un amplificador de 500 W con un dipolo, o una antena direccional con 100W en fonía. Y entonces cuando las condiciones están "cerradas" aún así se puede comunicar. Entonces muchas estaciones que antes no tenían chances de tener actividad ahora la tienen, incluso actividades de DX, incluso por tiempos prolongados. No es casualidad que mas del 90% del tráfico reportado por los sitios automáticos (clusters, RBN, pskreporter por ejemplo) sean correspondientes a FT8.
Y eso nos lleva a uno de los aspectos restantes, la infraestructura. ¿Que se necesita para hacer FT8? Podríamos decir que una estación normal, mas una antena normal, mas una computadora normal. Nada que ya no esté en la mayoría de las estaciones. No se necesita, en la enorme mayoría de las estaciones nada mas que lo que ya tienen, en realidad pueden hacer "mas" con lo que ya tienen, y ese es un gran atractivo. Pero al mismo tiempo se puede hacer mas en condiciones mas precarias. Si tengo un equipo QRP, con el que alimento una antena long wire a baja altura en condiciones precarias (portátiles por gusto o de emergencia por necesidad), incluso con limitaciones de energía; podría en esas condiciones tener una expectativa de contactar como si tuviera una estación de -10 dB de desventaja, es decir como una estación convencional de 500 mW. Cualquiera que haya jugado con QRPp sabe que con esas potencias se puede contactar, y muchas veces buenos contactos, sobre todo con una buena antena. Y en FT8 equivalen quizás a 50W en fonía sobre una buena antena, por lo que realmente rinde, rinde mucho aún en condiciones muy precarias. Otros proyectos reportados en éste blog muestran el enorme potencial técnico y de uso de contar con solo 100 mW de potencia (¡!) en modos digitales de baja potencia. La "poca" infraestructura necesaria es un enorme atractivo.
Lo que nos lleva al último punto, suerte. ¿Que tiene que ver la suerte con un modo de comunicación, de radioaficionados encima?. Mucho, creo. Tuvimos suerte que un premio Nobel de fìsica fuera radioaficionado (Joe Taylor), que fuera además un radio astrónomo y que se entrenara por años en entender la dinámica de las señales del espacio intergaláctico profundo para estudiar fenómenos desconocidos, descubriendo el fenómeno Pulsar en el camino. Y que se cruzó con otro genio, Steve Franke (K9AN), especialista en protocolos de comunicaciones, para que juntos alumbraran el programa WSJT-X en un espeso uso de la matemática de alto vuelo necesaria para implementar diferentes modos de baja señal (incluso, varios no mencionados en ésta entrada). Si un aficionado tuviera que aprender esa matemática para hacer FT-8 su popularidad sería órdenes de magnitud menor; nada es secreto, cualquier buen ingeniero con su formación completa y un postgrado en procesamiento digital de señales no tendría dificultad en entenderlo e implementarlo, esa sería la audiencia, supuesto que le interese además ser radioaficionado. Suerte. He esbozado éstos conceptos, mi opinión en definitiva, parcialmente en varios ámbitos cuando algunos atacan el modo, y por transitiva a mi juicio tontamente adjetivando a quienes lo usan. Con mucha frecuencia observo que lo hacen telegrafistas, no se si será algún tema de índole gremial o que, pero siendo telegrafista yo mismo me siento capacitado para exponer argumentos sin que facilmente se pueda argumentar que mi "odio" hacia el CW es lo que realmente me impulsa.

decode_FT8

Pero ¿a que viene toda ésta introducción? ¿donde aparece algo llamado "decode_FT8" en ella?
Este programa es un experimento, uno exitoso debo agregar, de desplegar una prueba de concepto.
Usando la plataforma "PixiePi" o "OrangeThunder" pude mostrar en sendas entradas anteriores como distintos experimentos me llevaron a construir un hardware original para modos digitales de baja señal, WSPR y FT8 entre ellos. Pero en ambos casos usaba el programa WSJT-X. Lucia un poco mas dificil que cazar patos atados con dinamita, pero quizás solo un poco. Asi que me pregunté que debería hacer para extender el microcódigo que ya había escrito para implementar los transceptores (en su costado embebido) para que, además, pudiera recibir y transmitir en FT8 sin usar el programa WSJT-X. Eso es una buena prueba (para mi mismo, y por diversión, por cierto) que no solo usaba el modo, sino que lo entendía en forma profunda. Escribir la parte transmisora es trivial, realmente, hace años que uso mi baliza WSPR con esa tecnología, la que no difiere mucho de transmitir en FT8, solo detalles en como de codifica el mensaje y como se controla su longitud. También la máquina de estados finitos para implementarlo es un poco mas complejo en FT8 al tener varios "cambios" comparado con WSPR el cual solo emite. Pero no se puede hacer algo híbrido entre mi programa transmitiendo y WSJT-X recibiendo, porque el programa está diseñado para no poder ser ejecutado automáticamente (una decisión editorial de Steve y Joe para que no se construyan, facilmente al menos, robots con el ). El programa que recibe debe poder controlar también la recepción.
Obviamente la descripción matemática que hay en el sitio del WSJT-X es un sobrevuelo, y la que hay en la documentación también. Es necesario ir a al código para entender la matemática involucrada. Y el código para sorpresa de nadie considerando que fue escrito por un astrónomo está codificado en ... Fortran 90. Ese lenguaje fue uno de los primeros que se usó en computadoras, lenguaje por excelencia en los primeros tiempos de la computación científica y usando el cual se desarrollaron cientos de millones de lineas de código con algoritmos, funciones, fórmulas y procedimientos matemáticos de todo tipo. Desde entonces, y por los últimos 50 años, quienquiera aborde un problema técnico espeso en términos matemáticos es muy probable que enfrente escribir un volumen muy considerable de lineas de código desde cero o use librerías existentes escritas en ... Fortran 90 alguno de sus antecesores tan atrás como Fortran IV o tan recientes como Fortran 2008. Las mismas se usan hoy con y desde cualquier lenguaje, termina siendo inmaterial desde que lenguaje se llama a una función, en sus entrañas mismas se ejecuta en muy veloz código de máquina compilado cuyo archivo fuente reside en alguna parte en ... Fortran IV. Estamos hablando de un lenguaje inventado 20 años antes que el primer experimento usando lenguaje C.... 50 años atrás....
Pero mas alla de las fórmulas matemáticas no hay razón para escribir el resto del programa en Fortran 90, pero si para entenderlo. ¿Como hago para saber Fortran 90?. Bueno, historia larga, pero su versión corta es que fue el primer lenguaje que aprendí cuando empecé a estudiar Ingeniería a mediados de la década del 70, y fue mi sustento como programador durante varios años en una empresa que usaba una computadora que se programaba con el. Uno no se olvida de ciertas cosas, ciertamente no del primer programa en el que alguna vez programó. Asi que, si, pude seguir las rutinas en Fortran 90 del WSJT-X con cierto nostálgico deleite. Una vez entendido era solo cuestión de ver como encaptular las librerías de Fortran 90 involucradas o traducirlas a C. No hacía falta, Karlis Goba (YL3JG) ya lo hizo en su paquete ft8_lib. Alli están todas las manipulaciones necesarias para decodificar FT8. Solo hay que tomar la señal de audio, procesarla digitalmente con algún filtrado, llamar las funciones en el orden necesario, definir los límites y sensibilidades del sistema, manejar los errores y decodificar las señales. Suena simple. No lo es.
Pero luego de un considerable masajeo, en particular en manejar las condiciones de error y las sensibilidades del sistema, finalmente empezaron a aparecer los "frames" decodificados de FT8. El receptor (transceptor en realidad) implementado de ésta forma permite hacer contactos en FT8 completamente sin WSJT-X. Sin embargo, es claro que su "sensibilidad" es menor que la de WSJT-X, escucha menos estaciones, en particular no escucha las mas débiles (¡!). ¿Porque? Rápidamente empezó a ser claro porque. El algoritmo revisa toda la banda pasante (2 KHz) buscando señales "candidatas", las que pueden ser señales reales de una estación emitiendo en FT8 o espurias de distinto tipo o picos de ruido simplemente. Integrando durante los 15 segundos que dura el frame FT8 la persistencia de señales permite ir segregando las que son candidatas a ser válidas o ser ruido, y a su vez que tan sólidas son en términos de su nivel sobre el ruido. Ese análisis se cuenta con solo un par de segundos para hacerlo, desde que termina el ciclo de emisión de todas las señales y que comienza el próximo, en un par de segundos hay que revisar una veintena de señales candidatas (o más) a lo largo de casi 15 segundos de emisión. Para asegurar algo esas señales se enlistan ordenadas de "mas probable a menos probable" usando un indicador de calidad que se deriva del procesamiento digital de las señales para hacer ese ordenamiento. Para las señales candidatas resta todavía hacer la demodulación del frame, tarea matemáticamente intensa por su parte. Como resultado, cuanta mas potencia de procesamiento se dispone mas chances hay de procesar señales mas profundo en la lista. Y las señales cuanto mas débiles mas profundas en la lista se encuentran. Por lo tanto, potencia de procesamiento implica sensibilidad de radio. Relación impensada para la mayoría, pero muy familiar para los radio astrónomos.
En términos prácticos resulta un calce perfecto, disponer de mas potencia de procesamiento implica escuchar señales mas débiles. Pero con 100 mW de potencia es limitada la posible clientela de posibles candidatos que nos puedan escuchar, estaremos por nuestra parte lejos del tope en sus listas de decodificación. Por lo tanto hay un equilibrio muy bueno entre lo que el algoritmo escucha y lo que el transceptor puede comunicar con solo 100 mW.
Con orgullo agrego a mis comentarios favorables al FT8 "soy un telegrafista y he escrito mis propios programas para FT8", nadie puede argumentar sólidamente que rechazo el CW ni que me atrae lo facil del FT8.