Un lugarcito caliente para DMR en LU7DID

Y finalmente llegó la placa MMDVM clone para instalar un "lugarcito caliente" (hotspot en inglés) de DMR. En una entrada anterior compartía mis primeros pasos en el mundo de DMR (Digital Mobile Radio), sorprendido en cierta forma por la curva de aprendizaje a pesar de conocer la tecnología básica por haber trabajado profesionalmente en redes TETRA (Motorola) hace ya un tiempo atrás (circa 20 años atrás).
Del uso fui aprendiendo por un lado cual es la mejor forma de configurar el handy Bauofeng DM-5R mediante un codeplug y por el otro los límites que tengo en el sistema en la configuración que tiene la red DMR en Argentina (ver figura).
Básicamente tengo dos formas de integrarme a la red, en UHF a través de la repetidora digital del Avellaneda Radio Club (LU7EO) al cual puedo abrir en forma consistente a pesar de la modesta distancia que me separa con la antena Yagui o en VHF entrando en el repetidor de Marcelo (LU8EB), el cual está ubicado un poco mas cerca y puedo abrirlo con la antena 5/8 en la torre. En ninguno de los casos puedo operarlo directamente con el handy, por lo que a diferencia de como utilizo las repetidoras analógicas de la zona sur (mayormente LU3DY 147.12+) para las cuales basta poner el handy donde esté en la casa para seguir la actividad.

Es ahi donde entra a jugar un "hotspot", que es un dispositivo que opera como un repetidor local en miniatura, se lo accede por radio en UHF (mi modelo, que es uno de los mas simples y económicos) y a traves de una conexión con Internet establecida mediante WiFi se integra a la red DMR que se le configure. Esa vendría a ser la principal razón para pensar en poner un hotspot; la otra, que no me motivó ni explore significativamente por ahora, es la posibilidad de trabajar en otras redes.De esa forma solo basta instalarlo en algún lugar de la casa que tenga buena visibilidad radioeléctrica tanto de la cobertura WiFi como del handy. La potencia que utiliza el hotspot es muy baja, del orden de 10 mW por lo que apriori aparecería como para brindar un servicio doméstico, sin embargo en un par de pruebas rápidas dentro de la manzana puedo activarlo con razonable confiabilidad. Hacer funcionar el hotspot no es un proceso trivial, sobre todo si uno empieza desde cero. Afortunadamente hay bastante material en Internet al respecto y un intenso, y muy productivo, intercambio de información y configuraciones que ayuda mucho cuando hay dificultades. Aún así es importante entender que algunos pasos no son evidentes ni triviales y preguntar puede ahorrar horas de frustración a prueba y error.
La puesta en marcha tiene varias pasos, a saber, puesta en marcha del hardware, instalación del software PiStar creado por Andy (MW0MWZ), configuración del hotspot mismo (local), configuración en el server DMR, modificación del codeplug del equipo que lo use y (finalmente) actualización del firmware del hotspot de ser necesario así como ajustes menores al ambiente Linux en el que corre.

Puesta en marcha del hardware

El primer paso depende muchísimo de cual es la placa específica de hotspot que se está usando; hay un número importante de modelos disponibles con diferente grado de compatibilidad entre ellos. La que yo adquirí es una placa MMDVM clone de origen chino. En lo profundo de lo barato, como para que quede claro. La placa es similar a la que está en la primer foto de ésta entrada. Es la placa misma, que consiste en un HAT (sombrero) para placa Raspberry Pi, el conector SMD de antena, la antena y dos peines de pines para la placa Raspberry. La placa MMDVM tiene el peine hembra, por lo que la placa Raspberry tiene que tener pines macho. No se que tenía en la cabeza el proveedor chino pero solo venía peine para una hilera y me pareció mecánicamente frágil pues queda un tanto "en voladizo". Asi que puse dos hileras de 5 pines en cada extremo. La soldadura de los pines y del conector SMD es razonablemente fácil siempre que se tomen las precauciones para tratar éste tipo de placas respecto a la estática, la potencia del soldador, la bondad de la soldadura, etc.
No hay mucha forma de probarlo hasta que se completan los pasos siguientes, pero al menos con la placa MMDVM puesto sobre la placa Raspberry hay toda una fantasía multicolor de los LEDs de la placa MMDVM que indica que "algo está haciendo", ahhh, y ausencia de humo, lo que es siempre importante.

Instalación del software PiStar

El firmware del hotspot es una distribución de Linux (Raspbian) sumamente recortada y ya configurada para funcionar sin necesidad de estar ni configurando el Linux mismo. El firmware se baja como una imagen (link) tal como habitualmente se lo hace con el Raspbian. Bajado el archivo hay que "flashearlo" sobre una tarjeta SD de al menos 8 GBytes. Para hacerlo yo utilizo Balena Etcher en mi Mac, pero puede usarse la versión de Windows o Linux de ese software también. En el caso de Windows también se puede usar Win32DiskImager. Todos ellos son equivalentes, no hay un notoriamente mejor que el otro, y su propósito es grabar la imagen del sistema operativo en la tarjeta SD.
Una vez finalizado hay una facilidad (link) que permite generar una configuración de la red WiFi que será útil. Los detalles están muy bien explicados en el excelente video de Hernán (LU7EHR) (link)en castellano o en éstos otros (link) o (link). Todos los videos, con matices, cuentan el proceso completo de configuración y no solo la instalación del PiStar. Es importante el paso de copiar el archivo wpa_supplicant.conf (configuración de conectividad wireless en Linux) al directorio boot de la tarjeta, pues es lo que permitirá luego al arrancar la placa Raspberry el que ésta tenga conectividad.

Configuración del Hotspot mismo

La tarjeta SD se coloca en la placa Raspberry, en mi caso utilicé una Raspberry Pi Zero W, la que por tamaño es muy apropiada. Puede usarse una Raspberry Pi 3, 3+, 4 (supongo, no lo probé) pero creo que es excesivo. Por alguna razón la configuración que usé no respondía al nombre "pi-star.local" por mas que estaba en la red, tuve que buscar con el programa nmap una dirección IP que no correspondiera a nada conocido e ingresar a ella (usuario: pi-star, password: raspberry). Uno siempre descubre que tiene mas cosas en la red que las que pensaba cuando hace ésto, así que puede haber un par de direcciones que no responden al intento de conexión. Cuando se puede entrar en la placa se lo debe intentar por una página web, suponiendo que la dirección asignada fuese 192.168.0.166 habría que acceder a la URL http://192.168.0.166  y cuando pida usuario y password indicar pi-star y raspberry respectivamente.
Alli se procede a configurar al hotspot propiamente dicho, seguir las indicaciones del video ya referenciado de Hernán (LU7EHR) que explica cosa por cosa con bastante detalle.
Dos aspectos que son un poco confusos y vale la pena aclarar. El DMR Id del hotspot es propio y diferente del que uno tenga configurado en el equipo DMR, y a diferencia de éste no hay que tramitarlo especialmente, básicamente se utiliza el que uno tenga asignado y se le agregan dígitos.  La red funciona en forma similar (conceptualmente) a como lo hace la red IP, uno obtiene "autorización" por su raiz pero se hace responsable de la gestión de todos los números que le sigan. Por ejemplo, mi DMR Id tramitado (equivalente a mi señal distintiva, y a los efectos prácticos lo es en DMR) es 7220292 , entonces arbitrariamente asigno a mi hotspot por ejemplo 722029201 y así lo configuro, la primera vez que se lo use exitosamente quedará registrado en "My Hotspot" en la página http://brandmeister.network que es la que en mi caso uso de DMR server (aconsejo hacer lo mismo, al menos inicialmente).
El segundo aspecto a considerar es que uno tiene que indicar un "servidor" de entrada, y al buscar "BM_....." con Argentina en la indicación no lo encuentra, bueno, hay que usar cualquier otro, a mi me funcionó bien el correspondiente a Chile, Brasil o Panamá.
Finalmente, hay que establecer una frecuencia en la que acceder al hotspot, en mi caso en la banda de UHF. Hay que tener cuidado que lo que ofrezca como default esté habilitado por nuestra reglamentación y que no esté en sub-banda de satélite.
Al finalizar la configuración habrá que configurar el handy, o el equipo en particular, mediante el codeplug para que permita operar con el hotspot.

Modificación del codeplug

El "codeplug" es un archivo de configuración que editado y cargado con las herramientas apropiadas en el equipo base o el handy permite definir en el mismo los recursos de la red, tanto propios como de otros. Esto es necesario porque en DMR la red se gestiona en base a los "servicios" representados por un DMRId, y éste puede ser uno mismo, una repetidora (duplex o simplex), uno hotspot, talking groups o individuos. Uno podría usar el recurso que quisiera, simplemente tipear el DMR Id correspondiente, en que frecuencia usarlo, que slot, que color y tantos otros parámetros necesarios. Pero no es práctico. Es mas amable tener todo lo que que uno va a usar en términos de red definido en el "codeplug" y cargado en el equipo para seleccionarlo cuando se lo vaya a usar. Típicamente estarán definidos los access points mas comunes (repetidoras simplex, duplex o hotspots), las estaciones que uno puede a querer llamar con cierta frecuencia en forma "privada" (directamente) o los talking groups (TG) que uno quiera participar o al menos monitorear.
La edición del codeplug se hace con un programa específico de cada base y los principales pasos pueden seguirse, para el caso del Baofeng DM-5R que me ocupa hacia la segunda mitad del video ya referenciado (link).

Verificación y ajustes menores

Con los pasos anteriores el hotspot debería estar completamente configurado para funcionar correctamente y el equipo para utilizarlo; de hecho en los distintos pasos de configuración se van haciendo pruebas para asegurar que lo que se va haciendo está correcto.
En el video de Hernán (LU7EHR) se agrega hacia el final un paso muy importante que en general observo no se le dá mucha importancia, y es asegurarse que el firmware está con la configuración mas reciente, vale la pena ver esa parte e implementarla.

Al mismo tiempo el hotspot queda configurado como un Linux embebido en nuestra red WiFi, por lo que si uno, como es mi caso, tiene otras máquinas funcionando y un esquema de red quizás convenga adaptarlo parcialmente para que armonice en esa red. Por ejemplo, asignarle una IP fija en la red, introducirle rutinas de mantenimiento, poner logs que controlen al procesador (temperatura, tensión, espacio en disco, uso de CPU, etc), quizás cambiarle el nombre (el default es PiStar pero en mi red las máquinas Rasbpberry tienen nombres de estrella de cielos del Sur, por lo que resulta renombrada como Theta-Crux o tcrux. Y alguna otra modificación menor. La imagen de PiStar representa un esfuerzo honesto de su autor para hacerlo lo mas masivo posible y que pueda ser desplegado prácticamente sin conocimientos de Linux, o con conocimientos mínimos. Debido a eso una vez desplegado lo más rápido posible se traslada al administrador a una aplicación basada en una página Web donde se configura el hotspot desde el punto de vista DMR. Desde éste punto de vista todo lo que es concebible de hacerse puede hacerse. Pero entrando al Linux con una terminal ssh la historia es otra, es un ambiente extremadamente restringido, con una configuración limitada y con prácticamente ningún paquete habitual disponible o incluso sin permisos para ejecutar cosas muy triviales (como un ping a otra máquina por ejemplo). En lineas generales nada es necesario para poder hacer andar el hotspot, y una Raspberry Pi Zero no tiene tantos recursos sobrantes como para andar compartiéndolos en otras actividades distribuidas de la red. Pero, no pudiendo con el genio, la terminé haciendo parecida a otras máquinas en cuanto a perfil de paquetes disponibles, a tener el software MPI de procesamiento distribuido, a ser parte de las rutinas de backup y restore y otras.
A pesar de todo lo hecho, sigo sintiéndome como con una cucharita parado enfrente del océano, lo cual es muy divertido por cierto.

Reporte WOW en WSPR

No hay día que no me asombre un poco mas sobre la capacidad del sistema WSPR de ser reportado desde distancias asombrosamente grandes y potencias asombrosamente pequeñas.

No me asombra tanto que sea ZL1RS quien reporte en WSPRNet, en éste caso, a mi baliza de WSPR 100 mW en 20 metros. Bob ya ha dado evidencia de lo soberbia que es su recepción reportando al picoglobo de LU1ESY en sus "órbitas" a distancias de varios miles de kilómetros. Pero en éste caso se trata de genuinas antípodas, en 20 metros, con propagación horrible (o quizás no tanto...) y con la antena de la baliza siendo un dipolo rígido apuntando al Norte. Como sea, una maravilla.

Windows On ARM (¡WOA!)

Hace poco menos de un año empezó a aparecer en los forums comentarios sobre un esfuerzo para trasladar Windows 10 a una plataforma Raspberry Pi; faceta visible de un esfuerzo mucho mas estratégico para tratar de mover la plataforma Windows a una arquitectura de procesadores ARM, fuera ya de su tradicional dominio de las plataformas Intel (llamadas, casualmente, "WinTel"). ¿Para que podría quererse correr Windows en una plataforma ARM?... se preguntará mas de uno....

Sin entrar en una segura polémica, donde cada uno tendrá su opinión basado en sus preferencias sobre cual es el "mejor" sistema operativo, lo cierto es que hay aplicaciones donde no hay alternativa a usar Windows. En mi caso me interesé por el WOA (Windows On ARM) intentando hacer funcionar mi nodo de monitor/beacon de WSPR/FT8 conectado con el Reverse Beacon Network. El paquete que lo posibilita se llama aggregator y solo funciona en Windows, y es además resistente a todos los trucos para hacerlo correr bajo Linux (incluso un Linux X86, ni hablar de un Raspbian). Intenté hace unos seis meses atrás esa instalación. Empecé asignando una placa en el cluster para ese fin (lambda-crux), me hice de una tarjeta SD de 32 GBytes (contra los 16 GByes que usualmente tengo) y me largué a seguir lo que me pareció ser las instrucciones mas detalladas para hacerlo. Para hacer un proceso bastante largo y frustrante corto diré que no fue facil, que probé varias conjuntos de instrucciones y que la mayoría de los intentos terminaron en ninguna parte. Por ninguna parte implico que en alguna parte de la secuencia me encontré con errores de sistema infranqueables que no me permitieron seguir. Finalmente conseguí terminar con una instalación y levantar un "Windows", solo para encontrarme con una performance inusable y con enorme dificultad para conectar aún los dispositivos mas básicos, y sin red. En aquel momento solucioné la necesidad utilizando un "PC Stick" Lenovo que corre un Windows 10 nativo (es una máquina X86 muy pequeña), el aggregator funcionó muy bien y pude validar que el Reverse Beacon Network tiene un soporte muy limitado de FT8 y ninguno de WSPR por lo que el proyecto quedó ahi.

Seguí, no obstante, mirando la evolución del proyecto WOA y constatando que seguía el flujo de liberaciones y que los reportes indicaban que paulatinamente los principales problemas se fueron solucionando. Sin una necesidad concreta no abordé volver a intentar instalarlo. Hasta recientemente, donde Daniel (LU9DPD) me consultó sobre alternativas para hacer funcionar un controlador/integrador de repetidor DMR implementado en un programa llamado wires X de Yaesu, el cual tal como el aggregator solo tiene una versión para Windows.

La idea es evitar tener una PC en una función 7x24 no atendida, para el cual una placa embebida es mas apropiada y un PC stick es muy caro.

Asi que apareció una segunda ventana de oportunidad para el WOA. Volviendo a revisar los links sobre el tema encontré que en su enorme mayoría tenían mas de 6 meses de antigüedad y de acuerdo a mis notas los había probado a todos (sin mucho éxito). Me encontré también con éste video en el canal DB Tech de YouTube bastante mas reciente, asi que empecé por el.

El video es muy corto, algo menos de 12 minutos, pero el proceso de instalación que explica dura varias horas y se compone de básicamente tres pasos.

Los primeros dos pasos deben correrse en una máquina Windows 10 nativa, en su momento intentos de correr estos pasos en un Windows 7, en un emulador de Windows 10 o en un Windows 10 embebido no fueron exitosos, debe ser una desktop o una laptop corriendo Windows 10. En mi caso fue una laptop:

• Crear un script (.CMD) yendo a un sitio (link) que construya una imagen ISO a ser instalada, bajando e integrando los paquetes necesarios. Para ello se seleccionan varias opciones sobre las características del WOA a crear con el siguiente mecanismo:

• Seleccionar "Windows (Final Version)".
• Seleccionar "W10 1903 versión arm64 2019-04.
• Seleccionar lenguaje "en-us" (English Americano), debería andar español.
• Seleccionar "Windows 10 Professional".
• Seleccionar "ISO Compiler".
• Al link "creatingISO..." darle "guardar link" con click derecho y salvarlo en la máquina local.

• Ejecutar el archivo .CMD bajado en el paso anterior, hacerlo como "Administrador" (click derecho "Ejecutar como Administrador") es muy posible que el anti virus proteste que no es seguro correrlo, pero es un falso positivo, hay que dar excepción para que permita correrlo. La ejecución tarda varias horas (no los 20 minutos que dice el video). Afortunadamente se lo ve funcionando al script todo el tiempo por lo que se sabe que va progresando. Eventualmente termina.
• Bajar el software "desplegador" o deployer (link) del WOA, el que básicamente baja la última versión de los drivers disponibles. Lo que baja es un archivo comprimido.
• Descomprimir el archivo bajado en el caso anterior, lo que generará una estructura de carpetas y archivos.
• "Montar" el archivo ISO creado por la corrida anterior.
• Correr el archivo ejecutable del desplegador.
• Al comenzar a ejecutar hay que indicar donde se deplegará el resultante (una SD Card). Cuidado, entre los posibles ofrece el disco de la máquina donde está corriendo, no elegirlo.
• Indicar que se quiere correr (sources/install).
• Al poco de lanzar (o al poco de ejecutar) aparece una pantalla de aceptación de términos de la licencia de los drivers, la que habrá que aceptar para poder correr
• El paso anterior correrá también por una hora larga, al finalizar quedará todo lo necesario en la tarjeta SD que se indicó.

El siguiente paso ya se ejecuta directamente en la placa Raspberry Pi, al cual se le coloca la tarjeta SD creada previamente. Debe ser una placa Raspberry Pi 3 o 3B o 3B+ (no encontré referencias a Raspberry Pi 4), creo fuera de posibilidad que WOA funcione en Raspberry anteriores o en la versión Zero habiendo visto la clase de consumo de recursos que utiliza es baja.

El WOA es bastante demandante del procesador, al que adicionalmente se coloca al máximo clock, por lo que es posible que sin un soplador empiece a dar marcas de estar a temperatura elevada (pequeño ícono de termómetro); la temperatura no alcanza valores críticos si eso pasa (si lo hiciera se apagaría el procesador), pero si es posible que el BIOS ponga la placa en "throttle" y le baje el clock con lo que la performance será m-i-s-e-r-a-b-l-e. Una consideración similar ocurre con la fuente de alimentación, al menos de +5V@2.5A, si fuera de mas capacidad mejor.

Antes de empezar, y esto es crítico, debe conectarse la placa mediante Ethernet a un router que pueda proveerle conexión a Internet (mediante DHCP), el WOA no tiene drivers para hacerle funcionar ni el Wifi ni el Bluetooth de la placa Raspberry y el soporte de "dongle" USB externos es muy limitado (no tuve suerte con ninguno de los que probé). El proceso de instalación se hace con monitor y teclado (y si es posible mouse), no está soportado una forma de hacerlo "headless" ( es decir, a través de red, como usualmente se configuran las placas).

Los pasos son:

• Arrancar la Raspberry Pi, comenzar a presionar repetidamente "Esc" para que traiga el menú de BIOS. Seleccionar:
• Procesador a clock "MAX".
• Seleccionar que haga boot desde tarjeta SD y no desde UEFI (queda en 2do lugar).
• Lanzar el boot.
• Al dar boot aparecerá el logo de Windows y comenzará un proceso de configuración automático que durará un tiempo algo cercano a la hora (depende de la placa que se use, la velocidad de Internet y otros factores). Durante esta fase puede emitir algún mensaje de error, pero siempre que dé la alternativa de seguir hacerlo.
• Al finalizar nos pedirá el usuario y password propio de Windows 10 (usualmente la cuenta de Outlook/Live/Hotmail) y aparecerá el desktop de Windows 10. Sorprendentemente con nuestra configuración habitual de Windows (con nuestra foto, por ejemplo)
• Luego hay que hacer la configuración habitual en cualquier máquina Windows.
• Nombre de la máquina.
• Configuración detallada de red (por ej. asignarle una IP fija si eso hiciéramos).
• Wallpaper.
• Configuración de teclado para no tener que adivinar las teclas.

Como comenté antes el WOA ahora anda (¡!) y el progreso ha sido gigantesco y es un milagro que ande, pero aún hay mucho por recorrer.

El WOA corre aplicaciones standard de Windows 10 aunque con la limitación que sean de 32 bits.

En la configuración recién instalada me reconoció al tiro el teclado USB y el mouse inalámbrico (2.4 GHz, no Bluetooth), pero no el teclado compañero del mouse. No me reconoció el adaptador Wifi USB y no encontré drivers. Como necesitaba un puerto serie tenía la alternativa de usar el UART nativo del Raspberry Pi (¡cuidado, sus niveles son +0V/+3.3V y no RS-232!) o intentar hacer funcionar un puerto serie USB tipo Prolific, el WOA tal como fue instalado no lo soportaba pero luego de varios intentos (y probando con varios dispositivos) logré que reconociera uno de ellos. 

El monitor convencional VGA con puerto HDMI lo reconoció de una, sin problemas.

El software que tenía como objetivo tratar de hacer andar parece funcionar correctamente. En el uso habitual la performance es muy lenta, hay que tenerle paciencia para usar las funciones gráficas. El procesador anda normalmente entre 70-100% de capacidad con un uso normal, pero baja a 25-50% con menor uso, por ejemplo una corrida batch. Como browser se utiliza el infame "Edge", que lento pero funciona. Intenté instalar y utilizar Chrome y aparentemente la performance no es suficientemente buena para usarlo.

Vale la pena la experimentación, por ahora la conclusión es que hay que esperarlo un poco mas para que se estabilicen los drivers existentes y aparezcan mas; posiblemente que se pueda utilizar en una Raspberry Pi 4 para mejor performance. Pero mientras tanto si hay alguna aplicación que necesita Windows 10 y una Raspberry Pi es suficientemente usable para intentarlo. "... con paciencia y con saliva..... el elefante....".

SDR... mas lento no se puede...

Siempre fui un profundo admirador de René Lavand (Héctor René Lavandera 1928-2015) mago e ilusionista argentino, quien con una deficiencia física (manco) hacía trucos de cartas increíbles. No solo eso, los repetía en "cámara lenta" para darle chances a su audiencia a que descubriera el truco, cosa que no ocurría nunca por supuesto. Luego con una semisonrisa cómplice decía "... mas lento no se puede" como para patentizar la insuficiencia de nuestros sentidos para poder detectar la grandeza de su arte. Un grande.

Esto viene a cuento que hice, con el tiempo, como propia la expresión "mas lento no se puede" para indicar pedagógicamente  una situación donde las cosas están tan simples y tan claras que el que explica no puede hacer nada más para ayudar a quien escucha a entenderlo, todo el resto le queda a él.

En esa línea se inscribe un repost , cuyo circuito repito, hecho en Facebook por Alejandro Wankiewicz (LW8DRU) en el grupo Radio Telegrafistas del Sur sobre otro post hecho por Osvaldo Nolla (LU1JY) sobre una interfaz simple para SDR en 40 metros. En rigor se trata de un receptor doble conversión, la sencillez misma, pero suficiente para con el concurso de un programa SDR (él recomienda el M0KGK) poder hacer las primeras armas en SDR al mismo tiempo que entrarle a un circuito simple, económico y por cierto mas que razonable para los primeros pasos. Este tipo de receptor fueron los que hacía cuando era chico en mis comienzos en radio, y si bien tiene la dificultad de tener la doble recepción (recibe la señal por arriba y por debajo del valor del oscilador sin distinguirlas) hay toda una serie de trucos que hacen que en la práctica no sea tan molesto. Por ejemplo, si pongo el oscilador en 7000 KHz prácticamente todo lo que reciba será USB en banda de aficionados. Si lo pongo en 7070 KHz todo lo que sea telegrafía será para abajo, y así sucesivamente. Por cierto que para recibir modos de señales débiles (WSPR, FT8, etc) es inmaterial el tema de la doble banda lateral. En resumen, un lindo proyecto para despuntar el vicio un ratito. ¡Felicitaciones al autor y al difusor! Y para los potenciales constructores.... "... mas lento no se puede..."!

Proyecto PixiePi, primeros resultados

Hace algún tiempo he compartido tanto por éste blog como en forums en redes sociales un proyecto en el que he estado trabajando como prueba de concepto de manera de integrar un procesador embebido de bajo costo (Raspberry Pi Zero), un transceptor QRPp minimalista (Pixie) para 7 MHz, algo de hardware de interfaz, las facilidades para transformar una Raspberry Pi en un DDS de bajo costo aportadas por la librería librpitx de Evariste (F5OEO). No estoy inventando nada que no esté inventado ya, pero si realizando una integración de componentes accesibles tecnológica y económicamente para implementar un dispositivo de radio que, aún siendo básico, permita comunicar. Esto lo hago con los modos de bajas señales, especialmente WSPR y FT8, que permiten contactos con potencias ridículamente bajas tal como lo he experimentado hasta el cansancio con los reportes que obtiene mi beacon de WSPR Y FT8 en 20 metros transmitiendo con solo 20 dBm (100 mW)!

El proyecto pasó por interminables bosquejos que nunca salieron del papel, con distintas configuraciones, seguidos de varios prototipos basados en Arduino utilizando como DDS un AD9850 primero y un Si5351, los que en general llegaban a funcionar pero no me convencía la solución de software. Por la naturaleza de la arquitectura Arduino el firmware es uno solo, y si quería poner todos los modos a implementar mas todas las facilidades de soporte me iba muy rápidamente de la capacidad de una placa Arduino Nano o Arduino Uno, que eran mis objetivos. Así que hace ya algún tiempo migré mi experimentación casi exclusivamente a la plataforma Raspberry Pi. Pequeña maravilla de costo razonable la he utilizado en muchos proyectos, me encuentro muy a mis anchas con Linux y un gigantesco ecosistema de librerías disponibles para casi cualquier cosa.

Con esas facilidades cambié la arquitectura del proyecto para utilizar programas específicos para cada modo construidos con librerías separadas para las distintas funciones que se le adjuntan en el momento de compilarlos y eventualmente librerías o programas con los que interactúa en tiempo de ejecución. El ecosistema resultante es un poco intrincado pero termina siendo de una complejidad razonable como para operar en forma confiable. Voy implementando entonces un programa gestor del transceptor mismo (pixie), un emisor de WSPR (PiWSPR), un programa DDS genérico (DDSPi), un emisor de RTT (PiRTTY), puede usarse sin modificaciones la mayor parte del suite de programas rpitx también de autoría de Evariste. Seguramente habrá otros programas en el futuro en la medida que vaya desarrollando y experimentando. SSTV, PSK31, Packet,... y por que no SSB.

La mayor parte del material está en el repositorio GitHub lu7did/PixiePi que alberga el proyecto, este repositorio es estrictamente hablando solo para código y documentación, pero a falta de tiempo lo estoy usando como repositorio de todo el proyecto.

El transceptor Pixie es bien básico, mientras actúa como receptor la etapa de salida es alimentada en baja señal y actúa como mezclador, el resultado de la mezcla es filtrado en forma muy primitiva para separar el audio del RF y amplificado (mucho!) por un integrado LM386. En transmisión la etapa de salida opera en alta señal y amplifica hasta una potencia de salida de entre 100 y 300 mW dependiendo de la antena. Con mayor excitación y ajustes menores se puede llegar a sacar hasta 500 mW del kit, pero no es recomendable. De hecho aún operando a 200 mW en emisión en CW la temperatura del transistor de salida aumenta rápidamente desde temperatura casi ambiente hasta unos 70 C. Operando el transceptor en modos que requieren tiempos prolongados de encendido tales como FT8 o WSPR el transistor de salida se arruina rápidamente si no se le pone un disipador. En mi caso bastó una plancha delgada de aluminio de 1"x0.5" y una pestaña para ajustar al transistor de salida, colocando luego abundante pasta de conducción de calor para mejorar la transferencia térmica. Con éste fix el equipo lo he probado encendido en transmisión permanente por mas de una hora (en realidad no fue una prueba sino un accidente, pero sobrevivió).

Hay una serie de modificaciones detalladas en el portal GitHub que deben ser tenidas en cuenta para construir el kit de manera que sirva para éste proyecto. Es muy importante que, dado que se construye sin cristal, el kit Pixie no emita por si solo, ni aún presionando el manipulador; esa condición indicaría auto-oscilación y debe ser eliminada.

Luego de construir el kit se dispone de una placa Raspberry Pi, en rigor cualquiera, pero en el espíritu minimalista del proyecto utilicé la mas pequeña disponible, la Raspberry Pi Zero W. Es importante que sea la "W" porque indica "Wireless" o sea que tiene WiFi incorporado, dado que el equipo se usará en modo "headless" (mas de eso luego) es importante poder conectarlo por medio de la red, aunque hay una forma de usar una conexión "local" (mas de eso luego también) que permite conectar una Raspberry Pi Zero a una computadora mediante el puerto USB evitándose la conexión inalámbrica.

La salida designada para RF es la GPIO4, aunque puede usarse la GPIO20 con el mismo propósito y se conecta a la placa Pixie mediante una interfaz sencilla (indicada como MODS en la documentación). Adicionalmente hay que articular el PTT, implementado con un transistor 2N7000 excitado por la salida GPIO12 y la posibilidad de un subtono (por ahora muy horrible) generado mediante PWM usando la salida GPIO19.

Con las funciones de la librería librpitx se genera una señal de RF en cualquier frecuencia entre 1 MHz y 1 GHz, el proceso es maravilloso y simple al mismo tiempo, fue explicado en entradas anteriores. Para las pruebas iniciales no es necesario construir ningún programa del paquete, el programa tune del paquete rpitx tiene lo necesario para las pruebas iniciales, básicamente cuando se lo llama emite una señal de rf de la frecuencia indicada por el puerto GPIO4, y lo hace hasta que se lo interrumpe con ctl+C. Sin embargo, para operar la placa Pixie como transceptor es necesario implementar algunas funciones adicionales de las que carece el programa tune aunque para un uso básico al manipular la linea KEY de la placa Pixie bastaría para ponerlo en transmisión y emitir.

Pero para cualquier uso práctico al activar  la linea KEY (colocándola a masa) de la placa Pixie hay que al mismo tiempo correr la frecuencia del VFO en 600-700 Hz como shift del tono de telegrafía, caso contrario el corresponsal nos tomaría con una frecuencia de VFO similar y estaríamos corridos. Al mismo tiempo, es necesario generar alguna señal auditiva que se está emitiendo para tener el necesario "feedback" auditivo de lo que uno está transmitiendo. Ambas cosas son deficiencias básicas del diseño Pixie solo tolerables a cambio de su simplicidad. Para generar el feedback auditivo se genera un tono mediante PWM usando la linea GPIO19 que se alimenta al pin 7 del LM386 que opera como amplificador del Pixie, todavía es una solución que tiene que mejorar pues el tono dista de ser bueno.

Con estas funciones bastaría para hacer comunicados tal como se los haría con el Pixie sin necesidad de un procesador. Pero el software implementa muchas otras funciones que ya exceden largamente las posibilidades de una placa sencilla de transceptor. Cambio de frecuencia, doble VFO, split, RIT, distintos modos, tono shift variable, break-in, potencia variable, manipulación electrónica y muchas otras. Todas esas son funciones implementadas en el programa pixie del paquete PixiePi. Hay funciones que estoy experimentandolas aún
, tal como solo prender el DDS cuando se transmite de forma de poder usar un receptor externo (¿un RTL-SDR dongle, quizás?). La versatilidad es gigantesca.

Para operar el transceiver se adapta una interfaz de usuario compuesta por un display LCD 16x2 y un rotary encoder con "push", con el auxilio de los cuales se dispone de un dispositivo totalmente autónomo, aunque eso es relativo. La librería rpitx corrige la estabilidad de la frecuencia mediante el uso del protocolo NTP, por lo que una conexión a Internet no es imprescindible para operar en CW pero prácticamente es mandatoria para sincronizar la hora de los modos digitales de bajas señales. Con un esquema restringido el "dial" sirve tanto para sintonizar como para elegir las funciones una vez puesto en modo "comando", incluso he diseñado una caja modelandola para impresora "3D" para implementar la base y el frente, todavía hay que ajustarla bastante porque tiene varios defectos de diseño y no imprime bien en 3D pero es un punto de partida.

Una de las funciones mas potentes del diseño es la posibilidad de incorporarle CAT (Computer Aided Tuning), para lo cual implemento el protocolo CAT del Yaesu FT-817, protocolo con el que estoy muy familiarizado de otros proyectos y que es suficientemente potente. Para utilizarlo se simula una linea serie "virtual" mediante un "pipe" utilizando el programa socat, de tal manera otros proflrig o la de modo texto del programa rigctl del paquete Hamlib; en lineas generales la GUI de flrig es mas bonita y funcional pero consume muchos recursos para una Raspberry Pi Zero, mientras que rigctl es mas frugal pero prácticamente no consume recursos.

De esa manera programas como flrig o la librería Hamlib "creen" estar hablando con un transceptor Yaesu, pero solo lo hacen con el programa. De esa forma es posible trabajar en modo "headless", es decir sin un teclado y monitor físicamente asociado a la placa Raspberry ni con un display LCD y controles físicos. Simplemente se corre el programa y se lo acceder en modo terminal mediante SSH, para manipular los comandos CAT para controlar su funcionamiento se utiliza la interfaz gráfica dada por el programa.
Luego de trabajar algunos problemas de estabilidad intermitentes (cierta tendencia a colgarse de la placa Raspberry, requiriendo un hard reboot) y de algunos comunicados locales de rigor continué trabajando con la implementación WSPR y FT8. Con QRPp a nivel de 200-300 mW se pueden hacer, con una buena antena, contactos de compromiso en CW (¡algunas veces sorprendentemente buenos!) pero el potencial real está en los modos de baja señal.

En recepción las primeras pruebas las hice alimentando la señal de audio (PHONE) de la placa Pixie a la placa de sonido de la PC de mi estación corriendo WSJT-X, primero en WSPR y luego en FT8, como para evaluar el rendimiento de un receptor tan simple, y el resultado me sorprendió (muy) gratamente. A poco de andar ambos modos registraron reportes de estaciones operando en la frecuencia, en el caso de WSPR señales de mas de 500 millas (PY-3). Un resultado equivalente, pero mas local, lo obtuve también con FT8. Superó mis expectativas ¡Realmente sorprendido!
Para emitir en ambos modos implementé un programa (PiWSPR) que es una baliza, emite un frame WSPR y termina. El Pixie no tiene problemas en emitir éste tipo de señales pues se tratan de variantes de modulación en Fase/Frecuencia donde la amplitud es constante. Nuevamente, tanto en WSPR como en FT8 al poco de hacer andar ambos en modo baliza comencé a recibir reportes automáticos tanto de WSPRNet como de PSKReporter (para WSPR y FT8 respectivamente) con distancias sorprendentemente grandes para la potencia involucrada.
En resumen, en una etapa muy preliminar del proyecto y aún con mucho por desarrollar tanto en el hardware como en el software me he tropezado con una implementación que pone en juego un gran número de tecnologías, por lo que el aprendizaje es formidable, pero el mismo tiempo la "receta" para duplicarlo es increíblemente simple de manera que puede quedar al alcance de un principiante con ganas de sacar lustre al teclado o chamuscarse un poco los dedos, o ambas cosas.
Queda por delante varias posibles rutas y el tiempo disponible dirá cual puedo seguir y con que intensidad; por lo pronto todos los modos de "amplitud constante" tales como RTTY, PSK31 y SSTV están a tiro de implementarse solo desarrollando el programa respectivo, del cual tengo ya prototipos con las cadenas DSP necesarias funcionando (publicados en entradas anteriores). Luego vendrá el desafío de hacer andar esta placa, siquiera en forma mínimamente aceptable, en SSB. Parece a priori un desafío imposible dada la naturaleza de la amplificación en un Pixie, pero confío que experimentando con la modulación PWM sugerida por PE1NNZ que comenté previamente puede abordarse una solución que no sea una "puñalada" a los oídos. Las modificaciones a la placa Pixie serían realmente muy pequeñas y el grueso de la "magia" estaría en software, aunque hay que validar si para el procesamiento intensivo DSP necesario alcanza una Raspberry Pi Zero o es ya necesario alguno de sus hermanos mayores (3,3B y porque no 4! fantástica excusa para conseguirme una). Esta misma implementación puede ademas utilizarse para otros modos como packet AX.25 o APRS, pero eso es ya materia de experimentación mas diversificada. Finalmente, y si bien estoy mas que conforme con la performance del receptor simple de la placa Pixie, quiero probar que pasa si uso la cadena solo para transmitir y un dongle SDR-RTL para recibir. Como siempre digo, muchos proyectos y poco tiempo.

DMR en LU7DID, el nuevo BAOFENG DM-5R

Luego de darle algunas vueltas al asunto terminé sucumbiendo a la tentación de explorar el modo DMR . Hace algunos años tuve un cierto involucramiento profesional con la tecnología a partir del despliegue de redes de comunicaciones basadas en la tecnología TETRA implementada por Motorola para redes de servicio público. Asi que pude pasar rápidamente por la parte donde se explica la base de como funciona (como funcional el TDMA, el concepto de tier, etc.). En aquel entonces (una buena década y media atrás) no había redes de éste tipo para uso de aficionados, al menos en Argentina, al menos que conozca. Pero recientemente comencé a leer y me fui adentrando en la implementación para radio aficionados, porque una cosa es la tecnología básica, pero si no se conoce la topología de la red, su configuración y los recursos de "talking groups" (TG) uno no tiene ni por donde empezar.

Hay muchas formas de comenzar, y elegí una simple, adquirí un handy Baofeng DM-5R. Son esas compras que uno las hace y luego revisa en profundidad encontrando que los comentarios no son tan buenos como a uno le gustaría. Desde cierta dificultad de uso hasta que directamente no soportaba partes esenciales del protocolo (capacidad de conectar en Tier 2, es decir, de usar repetidoras). Tengo un Baofeng UV-5R, versión analógica de éste mismo handy, con el que realmente estoy muy satisfecho. Al recibirlo pensé que familiarizado con esa versión y con conocimientos de la tecnología bastaba para empezar a salir, haciendo corta una historia larga el primer set con el handy fue un contundente 0-6 a favor del handy, no lo pude hacer andar bien ni en modo analógico. El manual, el manual es horrible, mal organizado, mal traducido y muy poco útil en general. Así que, guardé y volví a modo lectura, pidiendo ayuda además en el reflector de WhatsApp del RC.Avellaneda (LU7EO). Ahí me dí cuenta que la mayor parte de los vídeos que reflejaban problemas eran relativamente viejos, dos o tres años de antigüedad, siendo que en general los vídeos mas nuevos referían que la mayor parte de los problemas habían sido mayormente solucionados. Dos videos cortos y útiles fueron éste para una descripción general y éste para los aspectos de programación. El segundo round fue mucho mas productivo, luego de haber leído el manual y revisado como era la navegación de los menúes de configuración (bien diferentes al UV-5R) pude en poco tiempo hacer funcionar el handy con la repetidora local de LU3DY (147.12+600 100Hz). Luego de renegar un poco pude hacer funcionar el programador de codeplug  y la configuración para la zona AMBA para los recursos en que me pasó Daniel (LU9DPD) y alli pude, si, hacer bastantes pruebas sobre la repe LU7EO y los varios recursos (Talking Group, TG) disponibles. Como en general operan los modos digitales la comunicación es cristalina, vástamente superior a su equivalente en fonía analógica, hasta el punto donde los errores son tantos que deja de haber señal. Es decir la señal tiene la inteligibilidad de una señal local o nada. Pude probar una cucharadita de té de éste océano imponente de posibilidades, será cuestión de ir profundizando.

Estudio de propagación en 14 MHz basada en WSPR

Revisando los reportes reflejados en WSPRNet para mi baliza WSPR busqué una forma de representar gráficamente esa información de manera que pudiera visualizarse el patrón de propagación que representa. Encontré útil hacer un pequeño programa en Python con uso extensivo de la librería Matplotlib para generación de mapas. En realidad dibujar mapas con cualquier proyección necesaria (e imaginable, diría) es bastante sencillo con esa librería.

Lamentablemente la base de datos de WSPRNet no tiene una forma ágil de exportar datos de los reportes, solo provee la posibilidad de bajar de a mes entero, el archivo respectivo se va actualizando diariamente o sea que su tamaño es incremental a medida que pasa el mes. Hacia el final del mes es un archivo de casi 1 GByte comprimido y de casi 7 GBytes expandido. Para hacer un proceso recurrente (¿diario?) que realice el análisis hay que ver alguna forma de bajar y digerir esos datos, pero para una prueba simplemente hice una consulta a la base para los reportes a mi estación durante la última semana (con un límite de 1000 reportes, que no se alcanzaron). Y esa información la bajé en formato CSV (Comma Separated Values), tal como se corta y pega desde la página Web no son datos separados por comas sino por "Tab" (\t en Python, 0x09 en Hex) pero que pueden ser procesados con facilidad mediante la librería Python CSVReader. Una vez procesados y "parseados" los datos de cada spot se tiene la fecha, hora, estación reportada (indicativo, locator, potencia) y estación reportante (indicativo, locator) además de otros datos como la relación señal a ruido, el error de tiempo y la frecuencia del spot. Para el análisis solo uso por ahora la existencia o no de contacto por lo que solo utilizo la hora (UTC) y los QTH locators de origen y destino. Supongo que se puede hacer un análisis mas fino en tiempo y alguna forma de representar la potencia o la intensidad del reporte (cuantas veces una estación es reportada por otra), pero ese es un análisis que queda para otro momento.

Una vez disponible el spot solo queda traducir los QTH locators (maidenhead) a su equivalente en Latitud y Longitud. Finalmente dibujar un trazo que una ambas locaciones (lo que nuevamente es representado con facilidad usando funciones de la librería Matplotlib.

El resto es simplemente acumular los spots por hora, e ir generando un gráfico con todos los reportes a una hora dada. La sucesión de gráficos representa como cambia la propagación según la hora. Para hacerlo un solo archivo "GIF" animado uso la librería imageio, el cual dada una sucesión de archivos gráficos permite generar un archivo GIF animado (como el que se muestra mas arriba. La librería permite aparte generar mapas con distintas perspectivas, por ejemplo el primer mapa utiliza el denominado dataset NASA bluemarble (mármol azul) mientras que el segundo se denomina "shaded relief" (relieve con sombras), que equivalen groseramente a una vista "símil satélite" o de mapa "geodésico", hay otras variantes y simplemente es una cuestión de gusto cual se utiliza.

Se ve que la propagación a larga distancia es mayoritariamente dominante durante el mediodia y el atardecer, siendo durante el resto del día mayormente regional (con alguna excepción); es raro no tener reporte de estaciones de USA los que son habituales al anochecer, pero se nota que la propagación en el período medido no lo permitió.

Interesante método para generación de SSB (de PE1NNZ)

Guido (PE1NNZ) es un experimentador cuyas propuestas para el tratamiento de señales ya fueron comentadas previamente, en particular su interesante concepto para generar una señal de SSB que, sacrificando perfección, es creativo a la hora de intentar una implementación eficiente y sencilla. El concepto se ancla en concebir a la señal de SSB como formada por una señal modulada en fase y amplitud simultáneamente, concepto poco novedoso siempre que es la representación vectorial (fasor) de una señal modulada. Por lo tanto la modulación se logra por un lado modulando una señal portadora en fase y luego controlando su amplitud.

El método no es nada novedoso, se ha utilizado por años para realizar la compresión de señales en SSB (primariamente para HF), el detalle de como se hace la compresión puede verse en varias fuentes (link), pero en resumen se trata de limitar la amplitud de una señal SSB preservando su fase, de esa manera la potencia media de la señal tiende a incrementarse (que es el efecto que se quiere lograr).

Guido propuso ya hace algunos años utilizar una variante de ese método para generar SSB (link)  y mas recientemente ha propuesto modificaciones al popular transceptor de CW llamado  QCX para implementarlo (link).  Toda vez que las modificaciones en el hardware son pequeñas y no afectan el funcionamiento en CW es un proyecto muy económico y atractivo. El transceptor QCX tiene muy buenas críticas en las redes sociales y su costo es muy a tiro de experimentar con el. Básicamente las modificaciones de hardware están relacionadas con eliminar el filtro de CW (cuando se lo opera en SSB) y agregar el control mediante PWM de la potencia del amplificador de salida.El grueso de las modificaciones son en el firmware, basado en forma muy general en la plataforma Arduino, para que haga el muestreo de la señal de audio, module la fase (frecuencia) del DDS con ella y genere la señal PWM para controlar al amplificador de salida. 

El proyecto es interesante así como lo plantea Guido y también es interesante para probar con variantes en otras placas, incluso mas sencillas como puede ser un transceptor Pixie o 49er o, incluso porque no, el curumim de PY2OHH.  Por otra parte la plataforma Arduino+DDS que propone Guido es una variante económica, pero también es concebible utilizar directamente una placa Raspberry Pi a modo de DDS integrado usando la librería librpitx. Al mismo tiempo se puede experimentar en que pasa si no se controla la amplitud directamente, suena un poco drástico y seguramente tendrá bastante distorsión, pero es posible que sea suficientemente inteligible y de una enorme simplicidad. Loco como suena (y lejos estoy de recomendarlo) había un transmisor muy utilizado hace muchos años en 50 MHz al que operaba directamente en clase C y se lo denominaba, con bastante justicia, "la puñalada". Pero la modificación por PWM es suficientemente simple como para que no valga la pena ahorrarsela de todas formas. Un transceiver the SSB de unos pocos transistores, o incuso de un solo transistor, (mas los millones que tiene la placa Raspberry Pi) suena interesante como experimentación, ¿no?.

Reportes de propagación baliza WSPR 14 MHz

He compartido en varias oportunidades mi admiración sobre la característica de los modos de bajas señales para proveer capacidades de comunicación inauditas en términos de la potencia utilizada, las antenas disponibles y las distancias que se logran. 

Mi baliza emite un mensaje WSPR cada 10 minutos a partir del primer minuto par desde que es encendida, luego continúa con 4 llamadas FT-8 para finalmente estar en silencio durante los siguientes 6 minutos. La pausa es para, por un lado, no generar excesiva actividad en la sub-banda y por el otro para darle la oportunidad a la porción receptora del beacon de producir sus propios reportes.
La baliza emite con una potencia de 100 mW y utiliza una antena dipolo rígido multibanda, en principio está encendida 7x24 y logra operar con buena disponibilidad.
Es posible tomar los reportes desde el sitio WSPRNet tanto de quienes reportan mi estación (reporte "WSPR Beacon Report") como de quienes reporto como escuchados (reporte "WSPR Monitoring Reports") sobre el período de casi un mes.
La masa de datos, varios centenares de spots y muchos de ellos repetidos, es un poco áspera de descifrar directamente desde los datos, por lo que trabajar con alguna representación gráfica será mas aceptable.  Para solucionar eso extraigo, en forma un tanto artesanal aunque podría automatizarse desde un archivo de spots en formato CSV disponible en el sitio WSPRNet, los spots en uno y otro sentido.
Con el auxilio de un código relativamente simple en lenguaje Python y usando la potente librería para dibujo de mapas denominada "basemap" es posible "pintar" los trazos entre mi ubicación y la del corresponsal que me reporta en un caso y contra el corresponsal que reporto en el otro. El resultado da un panorama de cual es la cobertura geográfica a nivel global. Las estaciones que reporto trabajan en general con potencias entre 100 mW y 5W, aunque hay un par que reportan 50 y 100W los que quizás tienen un problema de configuración en su transmisor pero de no tenerlo no entienden muy bien de que se trata esto de "señales bajas".
Lo curioso es que esas estaciones "tan potentes" no son reportadas significativamente por encima de otras de la misma zona al mismo tiempo que indican potencias mucho menores, un buen argumento para razonar que en realidad transmiten con baja potencia solo que configuraron mal su baliza (y si no lo han hecho, quizás tienen un problema en sus antenas). La respuesta es similar entre quienes me reportan y a quienes reporto; hay una marcada cobertura de estaciones europeas y americanas. Durante el período reportado no hubo estaciones de Asia y Oceanía aunque si tuve registros en el pasado. Hay diferencias sutiles, por ejemplo típicamente me reportan estaciones de Islandia mientras que no parece haber estaciones de esa procedencia emitiendo. Hay buena propagación regional la mayor parte del día y eso incluye estaciones PY, ZP y LU de distintas zonas. También la base antártica Neumeyer (DP0GVN) que reporta estaciones escuchadas en todas las bandas, calculo que deben tener una propagación insuperable. Al respecto solo puedo imaginar lo fácil que sería poner una baliza en LU-Z, mi baliza es la prueba que los equipos necesarios son la nada misma y la antena necesaria es prácticamente nada también. Hacerla un poco mas sofisticada (todas las bandas) sería un trabajo muy simple. En general he tenido respuestas muy reactivas y recelosas cada vez que he intentado explorar posibilidades de operar en algo relacionado con Antártida, pero de hecho los LU tenemos una larguísima tradición de operación desde el continente blanco. Que se yo... ideas solamente.  Volviendo al tema de ésta entrada, solo una confirmación sobre el modo y sus posibilidades. Si bien WSPR no es una forma de hacer contactos de "2 vías" es una herramienta muy poderosa para estudiar la propagación y para probar antenas en el caso de FT-8 si es para hacer contactos y tiene una performance respecto a la relación señal-ruido similar (solo 5-10 dB menos en teoría),   algo así como una unidad S para hacerla fácil. Respecto a las herramientas de visualización las facilidades de la librería "basemap" son tan poderosas que creo que sería un buen proyecto ir tomando los spots a medida que ocurren y hacer un "gif" animado de como van ocurriendo según la hora, una forma de mostrar visualmente como se comporta la propagación. Como siempre mas ideas que tiempo, pero no parece difícil que la baliza misma baje los archivos necesarios y haga el cálculo, le sobra CPU por cierto. 

Plato el día: Pin frito

Buscando la razón por la que la baliza WSPR/FT8 de 28 MHz no aparecía reportada pude finalmente dedicar tiempo a investigar que pasó. Y pasó que el pin GPIO4 de donde se extrae la señal de RF estaba muerto, frito, inutilizado. Esta baliza opera solo con un filtro pasabajos antes de la antena, no tiene un amplificador ni protecciones especiales. No es ninguna sorpresa que haya quedado inutilizado por alguna descarga. Para revisar encontré muy util los utilitarios contenidos en el paquete pigpio y en particular el paquete gpiotest que es un programa en Python que permite evaluar el estado de un puerto GPIO, de su pull-up y la reacción a comandos. Confirmado, el pin GPIO4 no es capaz de modificar su estado ni de levantar el pull-up, frito. Quedaban varias alternativas, una es rotar el mismo nucleo a otra placa, hay una que ya tiene salida de antena para desarrollo aunque no el filtro pasabajos para 28 MHz. Otra era ver de utilizar otro pin. El beacon usa el paquete WsprryPi para el beacon de WSPR, pift8 para el de FT-8 y eventualmente (aunque no activado corrientemente) el programa iqsend y el pirtty. El último de ellos lo hice yo aunque igual que los pertenecientes al paquete rpitx está basado en los servicios de la librería librpitx. Investigando el código fuente pude detectar que la salida por el pin GPIO4 está "cableada" por software y no es un parámetro configurable. Sin embargo es posible alterar el pin desde donde sale el clock con una instrucción para habilitarlo y otra para deshabilitarlo. Habían dos alternativas, o modificar la librería librpitx para que fuera un parámetro opcional lo que potencialmente invalidaría todos los programas que la usan; o en cambio también puede hacerse el "hack" en los programas que usan la librería para hacer opcional la salida por otro pin. Elegí el segundo camino. La variedad de posibles pin no es muy grande, puede usarse GPIO4 y GPIO20 solamente. GPIO4 es el problema o sea que la alternativa es por GPIO20. Para entender un poco mas es interesante entender como puede generarse RF directamente desde la placa hasta frecuencias tan altas (mas de 1 GHz) que son comparables con el clock mismo de la máquina. Generar señales con el procesador es mas viejo que la injusticia, ya lo hacía en procesadores tipo Z80 para generar señales de audio. La técnica mas rudimentaria, y sencilla, es simplemente poner alternativamente en alto o bajo un puerto de salida digital, esperando un retardo controlable en su duración entre uno y otro "perdiendo tiempo" con un loop de software, básicamente contar al vicio un número suficientemente grande de veces. Con eso se saca una señal cuadrada cuya fundamental está dada por el período de alternancia y por lo tanto controlada por el programa. Una onda cuadrada es también rica en armónicos impares (3f, 5f, 7f, etc.).  Por eso se debe agregar un filtro pasabajos con corte por encima de la fundamental, normalmente aún el filtro mas simple (uno tipo RC) bastará para un resultado aceptable debido a la diferencia de frecuencia al primer armónico (espurea). Este método tiene dos problemas; uno es que se tiene que elegir entre que el procesador haga algo ademas de generar la señal o mantener la estabilidad de frecuencia de la señal generada, mejorar uno deteriora el otro. Normalmente se pueden conseguir resultados aceptables para frecuencias muy por debajo del clock del procesador por ésta vía (0.1 a 1%), con semejante margen pequeñas actividades adicionales cuidadosamente balanceadas (normalmente en lenguaje Assembler) permitían hacer algo mas que generar una señal de una frecuencia dada. En la medida que las placas embebidas incorporaron funciones de Timer manipulables con interrupciones se hizo posible generar señales con mucha precisión a frecuencias bastante mas altas; básicamente el atiempamiento está dada por el clock del procesador y no por un retardo de software al mismo tiempo que la sobrecarga para cambiar el estado en un sentido u otro es realmente mínimo y se realiza durante el servicio de la interrupción; normalmente el timer se opera a nivel mayormente hardware una vez programado por lo que los ciclos de CPU se pueden usar para cualquier otra cosa. El único límite a la frecuencia a generar es la resolución el timer y el tiempo de servicio de las interrupciones, por lo que se pueden alcanzar frecuencias de hasta un 5-20% del clock del procesador, un poco mas en algunas arquitecturas. Pero el enfoque que usa la librería rpitx (y todas las que la precedieron y de las que deriva) opera con un principio de funcionamiento diferente. Programa un gestor de DMA disponible en el chip BCM de la Raspberry y lo conecta directamente a un pin de salida; una vez hecha esa programación básica el procesador no tiene que intervenir mas para generar la señal (excepto para modificar su configuración, si está prendido u apagado, la frecuencia, etc.). Por lo que se puede seguir trabajando normalmente con el procesador con una mínima sobrecarga y generando señales de hasta 1 GHz (casi de la misma escala que el clock del procesador). El problema es que solo se puede programar esa conexión directa entre DMA y pines GPIO para un número limitado de pines; en éste caso solo son útiles el GPIO4 o GPIO20 pues no tienen otra asignación. Utilizar otros pines interferiría con servicios básicos como Ethernet o Wifi.

De vuelta a mi materia planteo el problema en el foro groups.io de soporte para rpitx y el consejo que me dá el autor Evariste (F5OEO) es básicamente que haga fork de los paquetes y haga la modificación yo mismo en una copia local. Desistido de modificar librpitx hice fork del paquete rpitx en mi espacio github [link]  e hice modificaciones en los paquetes tune, sendiq y pift8 que son los tres que necesito para la baliza en 28 MHz, el resto puedo vivir por ahora con usar GPIO4 pues son usados en otras placas que no tienen problemas. En todos los casos introduje la modificación para que sin cambiar el default GPIO4 pudiera alterarse con un argumento al llamado que usara otro pin como salida. En el mismo sentido modifiqué todos los paquetes que desarrollé o estoy desarrollando yo.

Pero queda el problema de WSPR para el cual uso un programa que no se basa en librpitx, sino que utiliza la gestión artesanal de DMA explicada antes originaria en los paquetes antecesores a rpitx. No es facil cambiar en ese caso que pin usa como salida porque hay que operar a nivel de registros del procesador (es posible, solo que lleva mas tiempo comprender bien que tocar y mucho mas probarlo). Por lo que tomé otra ruta. Hace algún tiempo había desarrollado una baliza WSPR para una placa Arduino asumiendo utilizar un DDS tipo AD9850 o un Si570, el proyecto nunca pasó de la etapa de boceto (uno de muchos otros tantos que terminan su trayectoria como garabatos en mi libreta). Pero tenía la carpeta con todos los antecedentes y algunas partes de código ya escritas. Una baliza de WSPR es muy simple, básicamente hay que transmitir 162 caracteres, cada uno pudiendo ser uno de 4 símbolos, cada símbolo está separado del anterior por un poco mas de 1 Hz y cada símbolo tarda un poco menos de 1 segundo; el total debe emitirse a partir del segundo 0 de los minutos pares y dura en total algo mas de 1' 45" en emitirse (para dar 15" a las estaciones receptoras para que decodifiquen antes del nuevo ciclo). Los 162 bytes codifican en forma redundantes tres datos, la característica (ej. LU7DID), el locator (ej. GF05) y la potencia en dBm. Teniendo la posibilidad de establecer la frecuencia de un DDS es trivial implementar la transmisión, mucho mas en un ambiente cuya hora está sincronizada por internet mediante el paquete ntp. La creación de los 162 bytes del mensaje son un poco mas ásperos. Antiguamente había un programa (wspr0) en el paquete WSJT-X que dado los valores de licencia, locator y potencia como argumentos los generaba, pero no lo encontré en las distribuciones mas recientes. Asi que busqué como hace el programa WSJT-X mismo para codificar ese mensaje, y durante la búsqueda encontré que otros ya había hecho lo mismo Alex  (OE5TKM) en el paquete wspr-beacon que si bien está diseñado para usar un DDS por hardware tiene todas las rutinas para dado un mensaje obtener su codificación en WSPR, tomé esos segmentos de código y escribí un programa llamado PiWSPR que está integrado a un proyecto mas grande y ambicioso llamado PixiePi (muy en sus comienzos aún) destinado a implementar un transceiver "Pixie" mayormente por software. Incidentalmente un transceiver Pixie es, en teoría, perfectamente capaz de transmitir no solo en WSPR sino también en FT8 provisto que su frecuencia pueda ser controlada en forma externa, algo que obviamente no se puede en la versión tradicional controlada a cristal pero que está muy a tiro si se reemplaza el cristal por un DDS implementado en hardware o software.

Como sea, pude volver a poner la baliza en el aire, emitiendo ahora con su salida desde el puerto GPIO20 (ligera corrección del cableado) en 28 MHz y ya empezaron a fluir los reportes tanto en WSPR como en FT8. Estos modos son maravillosos, la baliza emite con 10 mW solamente (!!) y es escuchada a miles de kilómetros aún con la banda de 10 metros en lo peor del ciclo solar completamente cerrada, que no se podrá hacer con ella en el máximo del ciclo solar. Bueno, será cuestión de probar entonces!

Pronóstico de Propagación CQ WPX CW 2019

Se viene el CQ WPX CW Edición 2019, llevará ya empezado de hecho un par de horas al horario de aparición de ésta entrada. Las condiciones lucen horribles para casi todas las bandas de HF, con un SFI de 66 y un SN=0 (proyectando un SSN= - 22 !!) no es de esperar casi nada de las bandas altas excepto propagación de alcance regional en ventanas horarias pequeñas y condiciones breves e inestables en larga distancia. Probablemente las mejores bandas sean las bajas, y si el ruido acompaña probablemente se logren contactos muy interesantes. Como siempre 20 metros presentará probablemente un estado intermedio.

Como lo he venido haciendo en los últimos pronósticos he utilizado los reportes de mi beacon WSPR en 14 MHz durante las últimas dos semanas para tratar de anticipar probables horarios e intensidades de las aperturas, el pronóstico es entonces para 20 metros pero el método puede ser replicado en forma sencilla tomando datos de otras balizas WSPR en las demás bandas. El método de cálculo fue explicado muchas veces en entradas anteriores pero en forma resumida cuento los "spots" (reportes) de mi estación para cada hora desde distintos continentes (mayormente NA,EU y SA puesto que no he tenido spots de AS u OC recientemente). La proporción de spots de cada locación respecto del total se asimila, aproximadamente, a la probabilidad de contacto con esa locación respecto al total de las 24 horas. La performance respecto a la relación señal a ruido de WSPR es apróximadamente 20 dB mejor que CW, y con 100 W de potencia tendré 30 dB mas potencia que el beacon a igual antena, por lo que si escuchan al beacon WSPR deberían escuchar mi señal en CW  unos 10 dB mejor que al beacon. 

La aproximación es realmente grosera y mas cualitativa que otra cosa, pero la idea es aproximar en que horarios puede ponerse intensa la propagación y no un pronóstico preciso (el que es, por otra parte, imposible). 

El resultado del análisis puede verse en el cuadro adjunto, el que muestra que aproximadamente el 80% de la probabilidad de contacto se concentra entre 1300Z y 2100Z (10am a 6pm hora LU). Es probable que las condiciones sean cercanas a nulas entre 0200Z y 1000Z. Entre 1400Z y 2100Z debería estar la masa del 75% de contactos, si es que se apunta a una participación mas restringida en horario. La mejor propagación será de tipo regional (SA) con aperturas a EU alrededor de 2000-2100Z mientras que con aperturas significativas a NA entre 0000-0100Z.  Eso último no parece estarse cumpliendo en los primeros minutos del concurso.

En todo caso que sea divertido y que nos vaya bien a todos los que participemos.

"Hello World" telegráfico en Raspberry Pi Zero

Hace algo menos de 40 años atrás escribía en la entonces recientemente salida revista K64 mi primer artículo, se trataba de emitir código Morse con una revolucionaria para la época computadora Sinclair ZX81.  El artículo causó bastante furor por entonces y fue seguido por muchos mas en una colaboración que duró varios años y produjo un par de docenas de artículos. Hace mucho que la revista dejó de salir pero yo sigo usando los dibujos pues me gustan mucho y me transportan brevemente a una época muy linda. Hay un proyecto que trata de compilar imágenes de las ediciones, así que quien tenga números en papel quizás quiera contribuir.  El dibujo que hicieron para ese artículo lo usé muchas veces en éste blog, pues aquel no fue ni el primer ni el último manipulador electrónico que diseñé, ni para la ZX81 (o TS1000 como se la conocía por aquí) ni para muchas otras plataformas que le siguieron. Esta introducción es para tratar de explicar porque tantas veces he realizado éste tipo de proyectos. En realidad cuando uno incursiona en una nueva plataforma enfrenta una curva de aprendizaje, que es bastante áspera al comienzo pues se tiene que aprender muchas cosas de golpe. 

Es una estrategia muy útil para enfrentarla hacer un "Hello World", que no es mas que un pequeño programita que hace solo eso, genera el texto "Hello World" y lo presenta por cualquiera sea el dispositivo disponible. Parece una soberana tontería, pero no lo es. Para poder lograr que un programa tan simple funcione hay que tener muy configurado el ambiente, haber entendido todas las opciones necesarias, encontrar que editor hay disponible y como usarlo, enfrentarse con problemas en casa uno de esos pasos anteriores y encontrar como solucionarlos. No es nada trivial. Y es una manera de hacer "algo" sin que la complejidad de ese "algo" sea fuente de ningún problema; es como salir con trapito rojo a "torear" a los problemas para que aparezcan ya así eliminarlos de a uno. Pero en realidad el Hello World no ayuda a mas que saber que la configuración anda, pero no permite explorar mucho del resto del ambiente, así que en mi caso usualmente hago un segundo proyecto corto, pero mas complejo, con el cual terminar de familiarizarme. Es un proyecto que conozco mucho, que no me es difícil, pero para el cual tengo que poner en juego algunas técnicas de programación y entender como funciona la entrada-salida de la plataforma "nueva", ese proyecto es y ha sido siempre un manipulador de telegrafía. Explico todo ésto para intentar compartir cuando, inevitablemente, me comenten que se puede hacer lo mismo con un integrado LM555 que no, no es lo mismo.

En este caso le tocó a la Raspberry Pi. En realidad no es el primer proyecto que hago con ésta placa, hace ya algunos años que hago cosas con ellas, pero últimamente casi todos mis proyectos están basados en ese plataforma. Contribuye que tengo que practicar CW "a mano" (habilidad que en la que me he endurecido bastante luego de usar un teclado por mas de una década) y que cuando fui a buscar mi keyer basado en un PIC 12F675 encontré que no funcionaba (vaya uno a saber porque). Las alternativas eran buscar porque no andaba y repararlo, o hacer uno nuevo. Por supuesto que es mas divertido hacer uno nuevo, y eso hice, porque de eso se trata un hobby, de divertirse.

Como he comentado varias veces he construido un cluster de placas Rasbpberry Pi que las uso para experimentación de distinto tipo, balizas multimodo, monitor de WSPR, el nodo SatNOGS y un par que están libres para otros usos y desarrollos. Tengo también dos placas Raspberry Pi Zero, una tipo W (con Wifi) y la otra sin el. La que tiene Wifi (lambda crux) la transformé en un beacon WSPR/FT8 explicado en una entrada anterior. La otra placa (delta crux) me resulta un poco difícil encontrarle un uso permanente, es pequeña y no es fácil acomodarla en la "torre" donde está el cluster, además como adquiere Wifi mediante un "dongle" externo no siempre lo hace bien, y en ocasiones para encontrar donde está en la red tengo que "buscarla" con el utilitario nmap o incluso conectarla a un monitor/teclado cuando se niega a conectarse, un fastidio. Así que nada mejor para ella que un uso que no requiera red salvo ocasionalmente. Un manipulador (keyer) cumple esa condición, es necesario conectarse a la red para construirlo y quizás para configurarlo, o mejorarle el nivel del software o acaso hacer algún mantenimiento, pero en el uso diario es completamente independiente ("standalone" lo que en inglés significa "que se para solo"). Pero en vez de escribirlo desde cero simplemente exploré en GitHub un poco que había al respecto y me encontré con el paquete denominado iambic-keyer de Rick (N1GP), que cumplía con casi la totalidad de lo que necesitaba. El "casi" lo solucioné haciendo "fork" del paquete en mi propio espacio GitHub y haciendo una nueva versión donde hice los agregados que necesitaba (http://www.github.com/lu7did/iambic-keyer). El programa tiene una arquitectura simple, la lógica del keyer está en el módulo iambic.c (https://github.com/lu7did/iambic-keyer/blob/master/iambic.c) (el que modifiqué) mientras que la generación de tonos está en keyed_tone.c (el que no modifiqué); según el help el programa originalmente estaba implementado en una FPGA en Verilog por Phil (VK6PH).

Esas modificaciones fueron muy simples, cambiar un poco los mensajes, acomodar los puertos de salida a lo que necesitaba y agregar una función para poder cambiar la velocidad sin tener que re-lanzar el programa mediante la lectura del estado del puerto GPIO 19. Esta última trabaja de manera que si detecta la paleta en "punto" con el pulsador de velocidad a masa va disminuyendo la velocidad hasta 5 ppm y en caso de ser "raya" la incrementa progresivamente hasta 50 ppm. El circuito es realmente mínimo, todas las salidas se configuran para tener su resistencia interna de pull-up activadas por lo que solo hay que conectarlas a masa para producir un "0" mientras que la lectura en reposo dá un "1" (recordar que estos pines manejan 3.3V y muy baja capacidad de corriente). El manipulador va entre GPIO13 y GPIO15, la salida para "manipular" es GPIO12, se usa un transistor PNP para manipular poniendo a masa la base. Si se es temeroso sobre a que se conecta siempre se puede utilizar un optoaislador en lugar de un transistor. La electrónica es suficientemente simple, pero nunca está de mas utilizar un diagrama para dejar las cosas claras.

El armado he vuelto a utilizar las latitas de pastillas "Altoids" que tan prácticas son para circuitos simples, primero se ponen todos los conectores directamente en montaje "auto soportado" (araña) y luego con unos pilares pequeños de metal la placa misma; hay que cavar agujeros para los dos conectores USB (alimentación y expansión).
El programa tiene la opción de generar su propio "zumbador" utilizando un puerto GPIO de salida o de hacerlo mediante una placa de sonido. La Raspberry Pi Zero no tiene salida de audio (como si lo tienen sus primas mayores, los modelos "normales"). No encontré incómodo usar un pequeño hub USB para conectar al mismo tiempo un "dongle" Wifi y una placa de sonido USB. Para manejar el sonido se usa un paquete llamado jack el cual debe ser instalado. Para su construcción el programa utiliza la librería de manejo del GPIO denominada wiringPi, ¡muy conveniente!

En ejecución hay que realizar una serie de pasos para que todo ejecute correctamente, por lo que en esos casos es siempre útil hacer un pequeño script bash que impida los errores, al efecto hice el script keyer que es parte del paquete y que se opera con la misma interfaz que un servicio (sudo ./keyer start o sudo ./keyer stop), el programa debe ser ejecutado con sudo por el tipo de operaciones que hace para manipular el hardware. Para que el funcionamiento sea completamente "standalone" es necesario arrancar el programa cada vez que se da boot a la placa. Tuve algunas dificultades para que funcionara bien como servicio o arrancándolo como parte de la secuencia init.d del Linux por lo que usé el método de fuerza bruta, puse en el cron la sentencia de llamada a continuación de la macro "@reboot" de forma que se ejecute al boot de la placa.
Anda lindo y por cierto que ya estoy practicando mis muy oxidadas habilidades de enviar CW manualmente, cosa que el Rafa Panoni (LU3HAZ) me enseñó muy bien, pero que la comodidad del teclado hace perder, de manera que vuelvan a hacer juego con las muy afiladas de tomar CW a oido. Y si todavía alguien propone un manipulador con un 555 o integrados CMOS le concederé inmediatamente que es mas barato, le discutiré un poco que sea mas fácil y definitivamente cerraré la discusión con la invitación  a que use el manipulador para escuchar música.