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.