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!