El PixiePi de LU7DID

 En entradas anteriores de éste blog he referido al proyecto en curso al que denominé "PixiePi" (contracción de Pixie y Raspberry Pi), del que he dado algunos avances de proyecto en éste blog (link). Siempre me fascinó el diseño llamado Pixie (que significá duendecito en inglés, para los cinéfilos también es el nombre de la compañerita alada de Peter Pan). Muchas entradas de mi blog anterior en LU7HZ también refirieron a variantes de éste diseño, tanto propias como ajenas. El principio de funcionamiento es sorprendentemente simple, un oscilador a cristal al que sigue un amplificador de RF, el amplificador en recepción se lo priva de corriente por lo que se comporta como un detector, la señal detectada se amplifica en audio con un integrado LM386. Al manipular la salida es capaz de aumentar la corriente manejada y se transforma en un emisor de telegrafía de potencia QRP, de acuerdo al diseño puede ir desde algunos centenares del milliwatts hasta un par de watts según el diseño.

El diseño es tanto elogiado por su simplicidad como denostado por sus limitaciones, que son muchas. En la práctica uno lo construye, hace un contacto de prueba (normalmente acordado previamente con algún amigo) para ver como anda, recibe un reporte sorprendente para la simplicidad y luego solo lo usa en ocasiones especiales (demostraciones, cursos y contactos muy esporádicos) porque casi todas las referencias a las dificultades en su uso son correctas. Gil (F4WBY) hace un review en su canal bastante ajustado a lo que refiero antes (link).  Por eso, y desde hace algún tiempo fui desarrollando un prototipo mediante el cual mediante el uso de la librería librpitx construí un programa para la placa Raspberry capaz de proveer una serie de funciones propias de un transceiver de gama mucho mas alta. Entre otras funciones están no solo capacidad de sintonía en toda una banda sino también VFO dual, operación dual, RIT, offset variable, Keyer directo o íambico, distintos modos de potencia y varios modos de operación. Todas esas funciones no cambian que no importa que sofisticado sea la generación de señales, no deja de estar seguido de un amplificador simple de RF y un filtro pasabajos relativamente ancho. Las funciones son relativamente simples, no hay procesamiento de señales ni demodulación involucrada, solo generar señales en una frecuencia fija (que se va cambiando según el modo de operación). El diseño empezó con una placa Arduino Nano controlando un DDS basado en el AD9850 y posteriormente el muy versátil Si5351. Llegué con el proyecto a terminar un "frankentipo" funcional que me permitiera desarrollar el microcódigo y con el que incluso llegué a hacer algunos (pocos) contactos. El desarrollo de sistemas embebidos es muy divertido porque el hardware no hace nada sin el software, pero el software no se puede desarrollar sin el hardware, asi que se establece un progreso "iterativo". El proyecto, sin embargo, empezó a mostrar algunas limitaciones. Mover un DDS con una placa Arduino y agregar algunas pocas funciones por decirlo de alguna forma "sobra". Es un excelente modo, por ejemplo, de convertir viejos BLU de bandas comerciales a bandas de aficionado. Programar un DDS, variar su frecuencia, incluso agregar unos pocos "chiches" como VFO múltiple, split y hasta un manipulador es muy facil. Pero mi proyecto era un poco mas ambicioso, incluía poder hacer una una baliza en varios modos, PSK31, RTTY, modos digitales como WSPR o FT8, e incluso algunas funciones de procesamiento digital de señales. Y esas funciones por un lado quedan cortas en un procesador relativamente chico y lento como el ATMega328 en la, relativamente pequeña también memoria de trabajo, la que rápidamente se mostró demasiado pequeña para el tipo de proyecto que tenía en mente. La arquitectura además requiere o hacer un programa que tenga todas las funciones o reprogramar el Arduino "flasheandolo" con cada microcódigo especializado que se necesite. Luego de darle muchas vueltas al problema con soluciones parciales terminé tomando una ruta un tanto drástica. Desde hace ya algún tiempo muchos de mis experimentos y desarrollos los vengo haciendo en la plataforma Raspberry Pi, y la diferencia es de órdenes de magnitud en potencia de procesamiento, memoria, versatilidad y herramientas disponibles. La diferencia en costo existe, pero no es tanta para una escala de pocos proyectos personales "únicos". Asi que di el salto y migré casi la totalidad de mis experimentos a Raspberry Pi. Y para proyectos de éste tipo a una Raspberry Pi Zero W. Finalmente el desarrollo terminó su evolución y completé un prototipo funcional al que denominé como expliqué antes PixiePi. El proyecto completo está en el sitio GitHub de LU7DID (link). El proyecto termina siendo un pequeño "ecosistema" tecnológico que incluye el prototipo de hardware, el software, las modificaciones a un kit simple que se adquiere en proveedores chinos y hasta la caja para ser impresa mediante una printer 3D. Cada uno de esos puntos requieren muchas horas de desarrollo, "debugging" y documentación. El proyecto medró por bastante tiempo a un ritmo muy lento en base a las (pocas) horas que le podía dedicar en tiempos normales, pero el contexto de la pandemia global y la cuarentena muy larga y rígida que tiene lugar en Argentina aportó algunas horas adicionales aunque mas no sea por falta de alternativas en los horarios que no trabajo. Como resultado pude darle al proyecto un "pulso" de horas que lo sacó adelante. Entre las funciones que la mayor potencia de procesamiento me permite pude incluir un control CAT (Computer Aided Tuning) emulando los comandos del Yaesu FT817 (lo que parece ser el standard en todos los diseños de aparatos no comerciales que implementan CAT). Encontré que la performance del transceptor es bastante buena además de en CW en la recepción de otros modos digitales (es, también, bastante ancho como para recibir en buena forma señales de fonía). Pude así desarrollar o adaptar programas para PSK31, RTTY o SSTV. Incluso algunas pruebas en SSB muestran que a pesar de ser un amplificador clase C el control de envolvente dá una señal legible, comparable a la distorsión que introduce un compresor. En particular WSPR y FT8. El recibir me llevó a pensar sobre la posibilidad de también transmitir en esos modos, lo que no resulta difícil pues he experimentado bastante con balizas de esos modos. Y efectivamente funciona muy bien (dentro de los límites del receptor y transmisor). La construcción y exitoso uso, en un proyecto no relacionado, del kit D4D de CRKits, cuya performance me sorprendió muy gratamente (entrada en el blog comentando el proyecto aqui). O sea que uno lleva una PC para correr WSJT-X, el transceiver D4D con alguna antena pequeña y puede operar en FT8 en la banda de 20 metros con una huella portátil muy pequeña. La huella del PixiePi es mas grande que la del D4D, pero eso es porque el prototipo tiene espacios generosos para poder trabajar con comodidad, un display LCD y otros controles. Si se prescinde de todos esos aspectos de interfaz y se gestiona igual que el D4D, con alguna versatilidad mayor, via el CAT el tamaño posiblemente podría ser aproximadamente el mismo. El principal limitante para el proyecto es que para recibir con WSJT-X no hay que hacer nada, pero para transmitir se necesita tomar una señal de audio y manipular su banda base para emitirla en la frecuencia de trabajo. Ese proyecto terminó siendo muy interesante y dió como resultado al programa Pi4D (también disponible en GitHub). Tuve que desarrollar y adaptar un procesamiento de señales optimizado para que fuera viable en una Raspberry Pi Zero, ya de por si exigida para generar la señal de RF, pero finalmente el resultado fue exitoso, mostrando el potencial de la plataforma para experimentar.

El Pixie no deja de ser sorprendente, en cualquiera de sus encarnaciones, por su potencial de experimentación.