Pixie+Arduino es Pixino

El "ecosistema" uSDX, término que vengo usando para denotar familias de diseños similares que derivan unos de otros a partir de adaptaciones menores, es muy rico. Dispone de una gama muy amplia de opciones para quien desee utilizarlos como parte de su experimentación que van desde las ideas y conceptos como para que se hagan con ellos armados experimentales, kits de distinto grado de calidad y prestaciones, placas armadas y finalmente equipos comerciales. Y sobre éstos distintos modelos con una gama muy diversa de costos y calidades constructivas que van desde muy baratos a razonables en precio y desde horriblemente construidos a razonablemente bien ensamblados, curiosamente no siempre correlaciona el precio con la calidad. Hay ofertas muy económicas de construcción razonable y al mismo tiempo hay equipos ofrecidos en la gama mas alta del precio (que ronda el rango de los USD $150-200) que muestran deficiencias muy marcadas tanto de construcción como de control de calidad. En algunos casos hay reportes de mala calidad de componentes que provocan un funcionamiento peor al esperado. En la práctica los problemas que han tenido los equipos comprados me las arreglé para superarlos, quizás porque al haber armado varios previamente tenía un conocimiento mas detallado del funcionamiento. En todas sus alternativas es una plataforma muy linda para poder despuntar el vicio de experimentar a distintos niveles de experiencia. Por mi parte, y según puede seguirse en éste blog, el concepto me interesa lo suficiente como para tener varios dispositivos. El primero fue un kit QCX modificado para correr el firmware QCX-SSB de Guido (PE1NNZ) el cual usa un procesador ATMega328P funcionando a 20MHz, lo siguió la placa diseñada por Pablo (EA2EHC) que es una versión simplificada que anda con una placa Arduino Nano también basada en el procesador ATMega328P pero corriendo a 16MHz. Pablo hizo las modificaciones del firmware QCX-SSB en aquellos aspectos dependientes del clock del procesador (timers, velocidades de bus, muestreos, etc.). Adquirí posteriormente dos modelos comerciales, el uSDR (el que ha recibido comentarios muy variados en cuanto a sus prestaciones y calidad de construcción, link) y el micro uSDX (link); ambos reportados en entradas anteriores. Es posible que en algún futuro cercano me haga de un ejemplar de la variante impulsada por Manuel (DL2MAN) en respuesta a los "clones" hechos en China y que tiene el nombre (tru)SDX.

Simultáneamente aproveché la familiaridad que obtuve con el el firmware QCX-SSB, en particular la versión modificada por Pablo, para encarar mi propio proyecto. Use para ese propósito los aprendizajes de un proyecto previo llamado PixiePi donde implementé un transceptor digital utilizando una placa Raspberry Pi Zero (link). Claramente la potencia del procesador del RBPi Z es ordenes de magnitud superior que el de una placa Arduino, pero parte de los algoritmos DSP involucrados son similares. En aquel proyecto como plataforma de RF usé un kit económico Pixie, que se puede adquirir fácilmente y que tiene un rendimiento razonable para lo fácil que es construirlo. El resultado fue sorprendentemente bueno, especial en modos digitales de baja señal (WSPR, FT8 o JS8Call). 

Al diseño lo he llamado Pixino (juntando Pixie con Arduino) y los progresos de su implementación pueden ser seguidos en el sitio del proyecto en GitHub. 

Por ahora el prototipo está construido sobre una placa perforada genérica donde se distribuyen la placa Arduino Nano, el módulo DDS Si5351, la placa LCD 16x2, el encoder y la placa Pixie asi como otros componentes de integración, el cableado por ahora es punto a punto. Quizás en algún futuro progrese a generar una placa PCB pues el diseño está dibujado con KiCAD y es por lo tanto posible integrarlo con el módulo de diseño de circuitos impresos.

¿Porque hacer una versión híbrida del uSDX que usara como plataforma de RF directamente un Pixie? Claramente el enfoque tiene pros y contras. En los pros el ya mencionado que hay un diseño simple, razonablemente económico que puede ser adaptado. Hay varias contras, claramente. La primera es que el receptor del diseño uSDX es un diseño SDR mientras que el Pixie es un receptor de conversión directa (mas ruidoso, mas ancho, menos sensible, etc). En segundo lugar el proceso de mezcla es mas primitivo, en el caso del uSDX es un detector Tayloe de bajo ruido y en el caso del Pixie un mezclador precario y ruidoso hecho con un transistor de juntura. El receptor de conversión directa tiene además una tendencia a tomar ruido de fuente, en particular de 50/100 Hz. Por su parte el Pixie usa un amplificador final clase C que es mucho menos eficiente que el clase E que tiene el uSDX, eso implica mayor consumo de potencia lo que perjudica una potencial operación portátil, pero esto no es una consideración de diseño pues no es mi intención primaria usarlo en forma portátil. Pero una consideración mas importante es que en FT8, y mas aún en WSPR, la etapa de salida está sometida a una emisión continua por 15 segundos a 2 minutos. El kit original Pixie de origen chino no sobrevive a ese requerimiento cuando es alimentado desde +12V y solo lo tolera (calentando mucho el transistor de salida) cuando es alimentado desde +9V pero a expensas de una potencia bastante menor, así que hay que agregarle un disipador generoso para que pueda operar de esa forma obteniendo la mejor potencia posible.

La modificación del firmware QCX-SSB implica eliminar todo aquello que no se usa. La técnica para hacerlo es lograr que activado una directiva especial de compilación (#define PIXINO 1) todas las instrucciones que deben ser removidas o agregadas lo sean, y sin la directiva el firmware sea el que corre en la placa EA2EHC. Las modificaciones cosméticas son varias, pero las esenciales son dos. Por un lado que tanto en recepción como en transmisión la linea CLK2 quede funcionando de manera de proveer el oscilador local a la placa Pixie, en el firmware original el CLK2 opera en transmisión mientras que el CLK0/CLK1 (en cuadratura) lo hacen en recepción. También la modificación incluye operar en todas las opciones de configuración del firmware para que aquellas que no le hagan sentido estén forzada a valores que las anulen, por ejemplo todas aquellas funciones relacionadas con el receptor del estilo de filtros, AGC, NR, ATT, etc. El receptor no es controlado por el firmware, solo se le provee un oscilador local y se toma el audio resultante sin procesamiento alguno.

En transmisión el diseño se puede usar en CW, donde opera como un Pixie con OFV básicamente, o en USB que en realidad no lo es pues el Pixie no tiene forma de dejar controlar la amplitud de la señal, pero que se utiliza en modos digitales de baja señal que son mayormente variantes de modulación PSK. La diferencia entre USB/LSB y CW consiste básicamente en el desplazamiento de la portadora piloto para operar en frecuencia o desplazado para dar el tono de CW de 600-700 Hz.

El diseño se completa con un gestor del PTT del Pixie que permita ponerlo en transmisión en el modo USB o transmitir en el modo CW, el cual se implementa con un JFET. El resto del diseño, filtros de audio, encoder rotativo, switches y display LCD 16x2 son los del diseño uSDX original. 

Hay una modificación adicional en la que es útil detenerse. El uSDX utiliza un enfoque de procesamiento de señales magistralmente implementado por Guido que logra que un procesador tan limitado como el ATMega328P pueda procesar una señal y extraer la información de amplitud y fase necesaria para generar la modulación en los distintos modos que soporta el firmware. Pero también tenía al comienzo del proyecto interés en experimentar por el enfoque propiciado por Hans Summers (G0UPL) en el kit QDX. Es decir en lugar de un procesamiento tan exigente como para comportarse como un transceptor genérico de SSB, asumir que se tratará de una señal digital, modulada en PSK y sin información de amplitud. Mas aún, que lo que tiene que hacer el algoritmo de manejo de señales es programar el DDS Si5351 de manera que "traslade" la frecuencia de audio a una banda de RF, le sume la frecuencia de audio a una frecuencia base por ejemplo en la banda de 7MHz. Como las variaciones de frecuencia son relativamente lentas en FT8/JS8 y mas aún en WSPR el procesamiento necesario en la señal no es tan exigente, en una entrada anterior (link) compartí como se encara en ese kit la medición de frecuencia. O sea que empecé el proyecto con la idea general de poder hacer funcionar al transceptor en la forma convencional uSDX y con el algoritmo QDX. 

Mientras tanto un muy prolífico experimentador, Barbaros (WB2CBA), autor de una muy interesante variante  denominada uSDX-MoNo (por MoNo band) que implementa un transceptor muy compacto, apareció con un diseño extremadamente minimalista de transceptor de modos digitales al que denomina ADX (Arduino Digital Xceiver), donde se pueden ver su descripción (link) y detalles constructivos (link), el que permite emitir en una cantidad discreta de bandas y modos pero que no tiene capacidad de sintonía, ni display, ni CAT ni nada. La sencillez misma. En recepción utiliza un chip de consumo masivo para fabricar radios de AM/FM, el CD 2003GP que se utiliza para implementar un receptor de conversión directa en la gama de HF, al igual que en mi uso del Pixie el firmware no hace mucho mas por la cadena de recepción que aportarle un oscilador local de la frecuencia apropiada. Pero lo que es interesante es el algoritmo que usa para procesar la señal de audio en transmisión. Utiliza una facilidad del procesador ATMega328P denominada Analog Compare que es capaz de muestrear una señal básicamente a la velocidad del clock del procesador y determinar diferencias entre dos entradas denominadas AIN0 y AIN1 (Analog Input 0 y 1), un algoritmo muy sencillo escrito por Burkhard Kainka (DK7JD) (link) permite medir la frecuencia de una señal de entrada mediante el expediente de detectar sus cruces por cero. Basado en ese algoritmo Barbaros implementa un firmware muy sencillo para gestionar el modo recepción y transmisión, controlar el DDS y tomar la entrada para determinar a que frecuencia colocar la salida. El algoritmo opera mediante un control VOX (si detecta señal de audio emite y caso contrario recibe). 

Me pareció una experimentación interesante lograr que el diseño fuera "compatible" con éste algoritmo de manera que se le pudiera cargar el firmware QCX-SSB o el  correspondiente al ADX indistintamente, quizás éste último con alguna mejora para poder usar un display LCD, switches y rotary encoder que están de todas formas disponibles. Para lograrlo hay que introducir una pequeña modificación en la placa. En el diseño original QCX (heredada luego por el uSDX) el encoder rotativo utiliza las líneas D6 y D7 (PD6 y PD7) que se corresponden con las entradas AIN0 y AIN1 respectivamente, por lo que pueden interferir. Para eso se relocalizan éstas líneas al D5 (PD5, no usada en el uSDX) y D8 (PB0, usada en el uSDX pero no en el Pixino pues controla el receptor en el primero y no es necesario en el segundo. Con los cambios, siempre condicionales, del caso en el firmware el encoder sigue funcionando normalmente, pero el audio puede ser alimentado tanto por la entrada analógica A2 donde el muestreado por el algoritmo del QCX-SSB y por las D6/7 donde son procesadas por el comparador.

No tiene mucho sentido incorporar ambos algoritmos en el firmware QCX-SSB pero si poder correr ambos. El firmware del ADX es tan simple que es incluso concebible pensar en correrlo en una placa mas chica (y barata) tal como el Arduino Mini, o incluso el ATmel Tiny85, mucha tela para cortar hasta encontrar que tan chico es chico.

Como sea el resultado, con la implementación del firmware QCX-SSB aún incompleta, con algunas cosas que no funcionan bien aún, fue suficiente como para hacer el QSO de bautismo (Maiden QSO), el cual anduvo sorprendentemente bien para un transmisor no muy ajustado a la antena de solo 500 mW. Se puede ver en el gráfico del sitio PSKReporter.info que el alcance fue sorprendentemente bueno, recibiendo reportes de mas de 1500 Km a una hora donde la propagación no estaba muy abierta, y de hecho pudiendo completar un QSO con una estación a 700 Km, para mi me parece sorprendente la relación entre simplicidad y resultados. Quedan aún algunas cosas que corregir y otras que agregar, como por ejemplo la posibilidad de controlar por CAT la placa o poder utilizar los algoritmos de medición de señal en recepción para proveer alguna indicación del nivel de señal o del nivel de inyección en transmisión. Es una linda plataforma para entretenerse con modificaciones tanto de hardware como de software. Respecto al firmware del ADX la implementación disponible es muy preliminar, quizás si logro alguna mejora no descarto ofrecerle a Barbaros hacer un merge a su versión, el tiempo dirá. Mientras tanto no habrá mas remedio que seguir divirtiéndose con la experimentación.