sábado, 24 de agosto de 2019

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..."!



martes, 20 de agosto de 2019

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.




lunes, 12 de agosto de 2019

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.

sábado, 6 de julio de 2019

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ó.



viernes, 28 de junio de 2019

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?.


lunes, 24 de junio de 2019

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. 

domingo, 23 de junio de 2019

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!

viernes, 24 de mayo de 2019

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.

domingo, 21 de abril de 2019

"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.



domingo, 14 de abril de 2019

Baliza WSPR de 28 MHz usando filtro pasabajos de QRPLabs

Hace algún tiempo compré por correo un kit de filtro pasabajos para 10 metros (28 MHz) en QRPLabs. La idea entonces era hacer una baliza WSPR basado en un Arduino Nano, para lo que éste kit es un "sombrero" (hat).
Como era de esperarse cuando llegó, y luego de una muy desagradable cola de casi 7 horas (¡7 horas!) en el centro de distribución internacional del Correo Argentino en la calle Estonia (CABA) me hice de el, lo guardé prolijamente en la caja de "proyectos futuros" y allí durmió una siesta de varios meses, como  muchos otros proyectos donde las realidades del tiempo disponible se juntan con las buenas (y a veces no tan buenas) ideas para proyectos de construcción.
En el medio empecé, y desde hace varios meses estoy trabajando, con desarrollos de bajas señales (WSPR, FT8, etc.) sobre la plataforma Raspberry Pi mayormente usando el modelo 3B, algunas entradas recientes dan cuenta de esos proyectos y otras futuras continuarán haciéndolo; ese proyecto fue una aspiradora de tiempo libre y ningún otro proyecto avanzó mientras me dediqué a el.
En general las balizas, que gracias a la flexibilidad de una plataforma Linux, pueden implementarse fácilmente en varios "idiomas" (WSPR, FT8, CW, RTTY, PSK31 e incluso SSTV) está funcionando en forma estable en WSPR y FT8 desde hace varios meses. Simultáneamente con ese desarrollo integré a mi "cluster" de máquinas una Raspberry Pi Zero y una Raspberry Pi Zero W para evaluarlas y entenderlas un poco mejor, la principal diferencia entre ellas es que la primera no tiene WiFi ni Bluetooth incorporado mientras que la segunda si. 
La conclusión que saqué de ambas placas es que si bien la Raspberry Pi Zero es mas económica en la práctica termina saliendo mas cara al tener que comprarle un "dongle" WiFi o un adaptador Ethernet porque no se puede usar "headless" (sin monitor ni teclado ni mouse); carece de sentido práctico, al menos para mi, tener que usar un teclado, un monitor y un hub USB para poder operarla en forma permanente. La Raspberry Pi Zero W (la W es por "wireless"), en cambio, una vez configurada se puede "tirar" en cualquier lado donde tenga señal WiFi y operarla "headless" desde otra máquina. Ambas máquinas son bastante limitadas en cuanto a potencia de procesamiento, operan con una CPU de un (1) núcleo, comparado con la Raspberry Pi Modelo 3 que opera con cuatro (4) núcleos. Esta última es bastante potente por cierto, y se puede usar hasta incluso como una "desktop" de uso (muy) liviano, cosa que claramente la versión Zero no le dá. 
En las mediciones que deja reflejado en el log puedo ver que la baliza ocupa aproximadamente un 15% de CPU promedio en una Raspberry Pi Modelo 3 en el pico de procesamiento (cuando emite) o sea que en una Rapberry Pi Zero debería ocupar 4 veces mas (la cuenta no es tan lineal, solo es una aproximación), o sea un 60% de CPU en el peor caso; lo que es razonable para una placa dedicada que no hace otra cosa. No es razonable emitir constantemente, por mas que no sea una placa de "monitor" (que reciba y reporte lo que escuche, además de emitir) no es conveniente saturar la frecuencia y para eso la cadencia de emisión es cada unos 10 minutos aproximadamente, en realidad transmite cada 5 ciclos WSPR (2 minutos cada uno) pero a continuación de la baliza WSPR emite durante dos minutos 4 frames FT8 (15 segundos de emisión y 15 segundos de escucha, alternadamente durante 2 minutos), pasados los cuales la baliza esté en reposo durante 6 minutos.
La baliza es muy sencilla de construir, una Raspberry Pi Zero W y un filtro pasabajos para 10 metros, ambos muy pequeños, lo suficiente para volver a utilizar la cajita metálica de pastillas "Altoids" como gabinete. Buena oportunidad para usar el kit de QRPLabs para lo que en definitiva era su uso original, solo que con otra configuración de proyecto. El kit es muy sencillo pero muy bien armado (la placa sobre todo) y los materiales de muy buena calidad; creo que vale la pena comprarlo por mas que sea muy sencillo de armar con piezas sueltas. El manual tiene los componentes para todas las bandas de HF, lo que es interesante para tener registrado porque es un circuito útil para casi cualquier proyecto que implique emitir RF.
El software para la baliza es el mismo que vengo usando en 14 MHz, solo que mínimamente configurado para la nueva frecuencia. A diferencia de la baliza de 14 MHz esta sale nativa desde el puerto GPIO a la antena con la mínima aislación de un capacitor en serie para evitar cortocircuitos desagradables y el filtro pasa bajos; eso es unos 10 mW de potencia de RF, que ya he probado en 20 metros que es mas que suficiente para alcances regionales (hasta 5000 Km) y ocasionalmente DX a mas distancias (10000 a 12000 Km); creo que 10 metros mostrará aperturas de esporádica E (continuamente reportadas en WSPR en Europa) y ocasionalmente en el punto mas bajo del ciclo solar en propagación ionosférica por capa F1/F2.
Lindo proyecto para una tarde de otoño, seguramente tendré que dedicarle horas para ponerla en un régimen estable, y posiblemente le encuentre un hogar fuera de mi shack una vez que esté estable para evitar interacciones con la otra baliza.





sábado, 6 de abril de 2019

Transceptor de señales débiles, bit a bit (Parte 8)

Para terminar de comentar sobre los diferentes modos que implementé en la baliza, aunque no todos ellos quedaron programados en forma permanente por razones prácticas fuera de la experimentación en si describo ahora la implementación de RTTY.
El viejo modo de "radioteletipo" pese que ha sido objetivamente superado técnicamente sigue estando vigente, hay bastante actividad con quienes lo practican, en especial en concursos del modo.
En realidad se trata de un modo de modulación en frecuencia, toda vez que los dos simbolos binarios con que se lo representa se les asigna dos frecuencias. La separación entre las dos frecuencias se denomina "desplazamiento" (shift) y en emisiones de radioaficionado es, por convención, de 170 Hz.
Las frecuencias de los tonos serán entonces 1350 Hz y 1520 Hz. Al equipo de SSB convencional se lo puede alimentar tanto como una señal de audio (AFSK) como mediante un desplazamiento (FSK). En un ambiente virtualizado es mas conveniente el primer método. El RTTY utiliza 5 bits para emitir cada caracter utilizando una codificación denominada BAUDOT, como 5 bits alcanzan para codificar solo 32 caracteres y eso es insuficiente hasta para un código ASCII muy restringido se soluciona enviando un caracter de "escape" denominado LETRAS o FIGURAS con lo cual se indica que los caracters que siguen pertenecen a dos conjuntos diferentes, cada uno de 32 caracteres. Aun así no es tan rico como el conjunto ASCII pero sirve para transmitir casi cualquier texto, no sirve para transmitir textos complicados como pueden ser programas de computación pues le faltan algunos caracteres; hace muchisimo tiempo, con las primeras computadoras y cuando las impresoras eran muy caras, se usaban máquinas de teletipo como impresoras, aunque no servían para imprimir programas normalmente por esa misma razón.
Buscando en Internet encontré un programa denominado rpi_rtty creado hace algún tiempo por Mike Adams (G3ZLO), el que permitía dado un texto generar los tonos con el que emitirlo en RTTY para a continuación grabarlo en un formato especial del programa rpitx denominado "frecuencia-tiempo" (.ft). En ese archivo se especifican pares de "frecuencia" junto al tiempo que el tono dura. Un archivo en ese formato puede ser procesado por el "viejo" (V1) programa rpitx usando la opción "-m RF". Para mi sorpresa esa función no está mas soportada en el "nuevo" (V2) programa rpitx, el cual existe y acepta la opción pero no funciona como tal. Chequeado con Evariste (F5OEO) me confirmó que efectivamente la función no estaba implementada aún, parece que todos tenemos el mismo problemita de tiempo con nuestros proyectos :-) .
Sin embargo el programa pisstv del paquete rpitx, que sirve para emitir en SSTV y veremos a continuación, internamente genera una estructura de datos similar a la que se utiliza para el formato .ft.
Asi que fue solo cuestión de poner manos a la obra, hice un "fork" del programa pisstv, una mezcla (merge) entre el programa rpi_rtty en lo que hace a la manipulación de textos y generación de tonos junto con el programa pisstv para emitirlos, fue necesario un poco de código propio para pegotear ambos programas para que funcionaran juntos. También para adecuar el hecho que rpi_rtty es un programa escrito en C mientras que pisstv está escrito en C++. Existe la creencia que ambos lenguajes son iguales, o al menos compatibles entre si, pero no siempre es el caso. Y este no fue el caso ciertamente. Para que funcionara tuve que cambiar la forma en que internamente el programa manipulaba los punteros a las áreas de memoria, trabajo simple pero tedioso.
Como sea que fuera completé y puse en github el programa pirtty que es justo para balizas, recibe un texto como argumento y lo emite en RTTY en la frecuencia que se le indique.
Para instalar pirtty se ejecutan los siguientes comandos:

cd ~
git clone http://www.github.com/lu7did/pirtty
cd ./pirtty/src
make
sudo make install

Para ejecutarlo se lo llama con

sudo pirtty  14097000 "   RYRY CQ LU7DID/B LU7DID/B GF05TE 20 K  " 170 45.5

Esto hará que en la frecuencia de 14.097 MHz se emita el mensaje con RTTY shift de 170 Hz y 
velocidad 45.5 bauds.
Aprovechando la mención  también se puede comentar como transmitir SSTV en forma automática.
El estandar que usa pisstv (rpitx) para transmitir SSTV es el denominado MARTIN1, que tarda algo menos de 2 minutos para transmitir una imagen a color.  SSTV emite una señal de variación analógica de frecuencia para transmitir la distinta información de luminancia (intensidad) y crominancia (color), utilizando frecuencias extremas del segmento de audio para representar los sincronismos horizontal y vertical.
El programa toma una imagen en formato "RGB" (formato crudo) y lo emite en la frecuencia indicada; como el formato RGB no es la forma mas común de almacenar archivos se debe primero convertir la imagen desde otro formato, por ejemplo .JPG, para su emisión. El script que hace eso viene en el paquete rpitx y se denomina testsstv.sh su contenido es:

#!/bin/sh
convert -depth 8 BBC.jpg picture.rgb
sudo ./pisstv picture.rgb "$1"

Aqui el archivo BBC.jpg es el emitido y lo hace en la frecuencia que indica el argumento con el que es llamado el script, por ejemplo:

/home/pi/rpitx/testsstv 14235000

El funcionamiento es excelente, pero probablemente SSTV no es un modo práctico para una baliza de solo 100 mW excepto quizás en un entorno local o quizás como parte de un experimento en bandas de VHF o UHF; es un modo relativamente sensible a la relación señal al ruido deteriorada. Adicionalmente una figura tarda casi dos minutos en emitirse, y se difícil encontrar una secuencia de emisión que no "empuje" la relación transmisión-recepción de la estación monitora y la proporción entre los distintos modos fuera de valores razonables. Nada impide no tener en cuenta esta facilidad para algún proyecto futuro (¿globo?¿satélite?¿baliza dedicada?). ¡Quien sabe!

sábado, 30 de marzo de 2019

Transceptor de señales débiles, bit a bit (Parte 7)

La estrategia utilizada hasta ahora para ir implementando las distintas piezas es mas o menos repetitiva. Para la cadena receptora se comienza con las muestras que entrega un dongle RTL-SDR, el cual abarca un ancho de banda de mas o menos 600 KHz (podría hacerselo mas grande de ser necesario) y con distintos trucos para manipular la señal con bloques SDR se vá por un lado recortando el ancho de banda a unos pocos cientos de Hz o unos pocos KHz por un lado y se vá de modulando la señal que nos interesa. No tenemos por ahora una implementación tan general como es un receptor, pero estamos haciendo los distintos pedazos para que eventualmente podamos operar en cualquier modo, en cualquier frecuencia. Una vez que tenemos el equivalente a una señal de audio digitalizada la podemos mandar a un auricular (y escucharla) o mediante un cable virtual a otro programa (y decodificarla). Para los modos digitales en general se hará lo último. Para los modos digitales de baja señal en general se utilizará el programa WSJT-X y para los modos digitales mas convencionales el FLDIGI; pero nada impide con las adaptaciones del caso utilizar cualquier programa que pueda ser alimentado con la salida de una placa de sonido, como lo haríamos con un transceiver convencional. En ocasiones pienso que tener los distintos modos sueltos e irlos conectando para distintas implementaciones no es muy diferente a cuando construimos un transceiver físico, módulo por módulo y trabajándolo sobre la mesa de trabajo para asegurarnos que anda y poder hacer mediciones fáciles. Normalmente pasa bastante tiempo ante que ponemos todo en una caja bonita (o no tanto, depende de la habilidad de cada cual) y por supuesto nos olvidamos completamente del proyecto pues ya estamos en otro igual o mas divertido.
Para la cadena transmisora hacemos algo parecido, solo que recorremos la cadena en sentido opuesto; empezamos con algo que genera audio (o, siendo mas general, una señal a modular) digitalizado, lo capturamos con un cable virtual en otro programa y lo vamos tratando con distintos procesamientos de la señal hasta que tenemos una "banda base" modulada y la aplicamos entonces al programa rpitx.
Hasta ahora de la salida de rpitx se puede optar por salir directamente a la antena con un filtro pasabajos simple (10 mW aprox.), poner un filtrado mas robusto y algo de amplificador (100 mW aprox) o ya a partir de alli tratar de alimentar una cadena de transmisión mas potente. Como en todo proyecto interesante es casi imposible evitar que a cada paso que damos se abran ramas diferentes que son igualmente interesantes y que estamos seguros nos darían un enorme placer experimentar. Solo algunas para concretar el punto, estas técnicas básicas con muy pocas modificaciones pueden usarse para hacer un repetidor de FM, o un transponder lineal como el que utilizan los satélites, o balizas para globos, o emisores de TV analógica y digital, o trabajar en packet APRS, o ... bueno, creo que se entiende. Por otra parte la integración de hardware, tema que no tiene tanto interés para mi pues estoy mas inclinado a la experimentación basada en software; por ejemplo con una sola placa pequeña (una Raspberry Pi Zero, por ejemplo) se puede potenciar un emisor de FM o uno de SSB canalero para transformarlo en uno multimodo, multibanda, por ejemplo.
Como quiera que sea hasta ahora he mostrado como implementar una baliza WSPR, una baliza FT8 y una baliza en CW; le ha llegado el turno a otros modos. Empezando por PSK31.
Este modo es bastante popular, su comportamiento con señales bajas no supera al CW, pero si lo hace con el SSB por lo que a iguales potencias se puede comunicar mejor con igual propagación, su complejidad técnica para implementarlo es baja y puede hacerse con virtualmente cualquier transceiver de SSB con una PC relativamente modesta. Hay bastantes programas para generarlo pero los mas habituales son MixW, MMVARI y FLDIGI para el mundo Windows y en el mundo Linux FLDIGI tiene una implementación muy potente (que eventualmente sirve para Packet).
Este último puede construirse para la placa Raspberry Pi, como siempre la secuencia es larga y es necesario hacerla con cuidado y sin olvidarse nada por lo que es útil usar scripts para eso; en éste caso para los pre-requisitos, la bajada y la construcción propiamente dicha. Los pasos son:

Bajar los paquetes e instalar los pre-requisitos (link).
Construir fldigi (link)
Construir flrig (link).
Construir flxmlrpc (link).

Antes que nada hay que revisar si en el primer script se están bajando los paquetes del último nivel disponible pues cambian continuamente, si se detectan cambios hay que hacer los ajustes de nombres en los subsiguientes paquetes.
La ejecución puede hacerse con  la misma técnica utilizada hasta aquí para WSJT-X, es decir alimentarlo con un cable virtual, extraer su modulación con otro cable virtual y procesar ambas cadenas con bloques constructivos SDR. Detalles de implementación de lado las cadenas SDR a utilizar son idénticas a las ya vistas.
Esta configuración con FLDIGI es suficientemente robusta como para hacer QSO con ella; sin embargo no es práctico generar una señal de baliza utilizandola. Primero porque es pesado levantar y bajar la aplicación cada vez que se lo hace, en segundo lugar porque requiere una placa mas grande sin ningún propósito útil y finalmente por no es completamente sencillo automatizar todo el proceso. Una baliza lo que necesita es una forma simple de enviar un texto fijo, o al menos un texto que se pueda construir dinámicamente como se mostró en la entrada anterior para el caso de FT8 o CW.
Para lograrlo empezamos con un "transceiver de ssb genérico" virtualizado mediante el siguiente script ssb.sh (link).

arecord -c1 -r48000 -D default -fS16_LE - | csdr convert_i16_f \
  | csdr fir_interpolate_cc 2 | csdr dsb_fc \
  | csdr bandpass_fir_fft_cc 0.002 0.06 0.01 | csdr fastagc_ff \
  | sudo /home/pi/rpitx/sendiq -i /dev/stdin -s 96000 -f "$1" -t float

Esta cadena ya se usó y explicó en entradas anteriores, pero básicamente se comienza por una señal de audio digitalizada y se la vá procesando para generar una señal de SSB por el método de rotación de fase para finalmente cuando están disponibles las señales I/Q respectivas emitirlas mediante rpitx. Nótese que éste script requiere ser ejecutado indicando la frecuencia en Hz de emisión (ej. ./ssb.sh 14097000").
Para generar la "banda base" con la señal de PSK31 ya modulada volvemos a recurrir al utilitario para SDR csdr quien tiene todas las funciones necesarias para hacerlo; el script correspondiente es PSK.sh (link).

#!/bin/sh
#*-----------------------------------------------------------------*
#* tx_PSK31
#* Experimental PSK31/SSB generator
#*
#* tx_PSK31.sh FREQ [in Hz] "MESSAGE"
#*-----------------------------------------------------------------*
#f="14097000"
echo "***********************************************"
echo "* PSK Generator                               "*
echo "***********************************************"
echo "Freq=$1 Message=$2"
f="$1"
echo "Starting SSB Generator at $f"
mkfifo pskfork || exit
/home/pi/whisper/ssb.sh $f 2> pskfork &
pid1=$!
while read line; do
  case $line in
    *high_cut*) echo "$line"; echo "found KEY=high_cut"; break;;
    *) echo "$line";;
  esac
done < pskfork

echo "Removing FIFO buffer"
rm -f pskfork  2>&1 > /dev/null

m="$2"
echo "Sending message frame($m)"

echo $(echo -n "$m") |
csdr psk31_varicode_encoder_u8_u8 | \
csdr differential_encoder_u8_u8 | \
csdr psk_modulator_u8_c 2 | \
csdr gain_ff 0.25 | \
csdr psk31_interpolate_sine_cc 256 | \
csdr shift_addition_cc 0.125 | \
csdr realpart_cf | \
csdr convert_f_s16 | \
mplayer -cache 1024 -quiet \
     -rawaudio samplesize=2:channels=1:rate=8000 -demuxer rawaudio - & 

echo "Waiting for termination"
sleep 20

echo "cleaning up processes"
sudo killall mplayer 2>&1 > /dev/null
sudo kill $pid1  2>&1 > /dev/null
sudo killall csdr  2>&1 > /dev/null
#sudo killall arecord  2>&1 > /dev/null
#sudo killall sendiq  2>&1 > /dev/null

exit 0

El script hace varias cosas y puede lucir confuso por lo que lo explico en partes; el segmento que genera PSK31 es el siguiente:

...
echo $(echo -n "$m") |
csdr psk31_varicode_encoder_u8_u8 | \
csdr differential_encoder_u8_u8 | \
csdr psk_modulator_u8_c 2 | \
csdr gain_ff 0.25 | \
csdr psk31_interpolate_sine_cc 256 | \
csdr shift_addition_cc 0.125 | \
csdr realpart_cf | \
csdr convert_f_s16 | \
mplayer -cache 1024 -quiet \
     -rawaudio samplesize=2:channels=1:rate=8000 -demuxer rawaudio - & 
...

El segmento empieza con la presentación de un texto a ser emitido el cual se entrega a una función de csdr llamada psk31_varicode_encoder_u8_u8 que como su nombre lo indica genera el patrón de bits a ser modulado, seguido de una función que hace la codificación diferencial (differential_encoder_u8_u8) y finalmente la modulación PSK propiamente dicha (psk_modulator_u8_c) que transforma la señal desde una codificación digital de 8 bits a una compleja de punto flotante ya modulada. El resto de los pasos se corresponden con el tratamiento de la señal en términos de su ganancia, las transiciones de potencia y la conversión al formato y tasa de muestreo final que requiere mplayer para generar el "sonido" final.
Notese que este segmento comienza con el texto y emite los sonidos "a la nada", estará de nuestra parte luego mediante pavucontrol conectar la salida del programa mplayer a uno de los extremos de un cable virtual (por ej. Virtual0) tal como, me repito, se hacía en WSJT-X en entregas anteriores.
Hay que hacer algunos trucos adicionales porque en los casos anteriores se conectaba la salida de un script con otra aplicación que estaba corriendo por separado y aquí, ambas aplicaciones parecen correr juntas... Eso es un poco la función del resto del script.
Al comenzar se llama al script ssb.sh y se lo ejecuta en el trasfondo (background), pero no es posible comenzar con la parte moduladora si el transmisor no está andando, basta una fracción de segundo de diferencia para que uno de los dos no funcione bien. Por eso el script genera un pipe (pskfork) donde se pone la salida que va emitiendo ssb.sh y mediante un loop redireccionado de ese pipe (a continuación) se controla que aparezca alguno de los mensajes que podemos esperar cuando ya está listo, tras lo cual borra el pipe y continúa invocando al segmento que genera PSK31.
Para que funcionen correctamente ambos pedazos (el transceptor y el generador PSK31) son lanzados como procesos en el background, por lo que a continuación el script se queda esperando un tiempo suficiente para que el mensaje sea emitido correctamente en PSK31, pasado el cual se eliminan todos los scripts que están corriendo antes de terminar. El tiempo de espera es suficiente para un texto cualquier de aproximadamente medio renglón, si fuera mas corto o mas largo puede reducirse o aumentarse en forma correspondiente el retardo.