El OrangeThunder de LU7DID

En el pasaje de apuntes y notas a éste blog no siempre sigo el orden cronológico del proyecto, ni lo hago inmediatamente. Soy consciente que si no resguardo cierta información es probable que en un futuro cercano haya perdido suficientes detalles sobre el proyecto como para que me sea difícil retomarlo, supuesto que necesite hacerlo, y muy a menudo ese es el caso. De hecho ese es el propósito original y el (para mi) mas importante de éste blog. Pero al mismo tiempo documentar no es lo primero que uno está tentado de hacer, sobre todo cuando no llegó a algún punto de parada lógica donde haya algo concreto que documentar en lugar de ideas sueltas que no parecen conducir a ninguna parte. Los proyectos toman vida propia, en algunos casos se trata de una idea neta y clara que uno persigue hasta alcanzarla o convencerse que no es el momento de hacerlo. En otros casos es un proceso de aprendizaje que se vá ramificando en formas insospechadas porque lo que se aprende muestra posibilidades que no se conocían y que terminan siendo mas deseables que lo que se perseguía en el punto de partida. Eso es lo que pasó con el proyecto Orange Thunder (Trueno Naranja en inglés), proyecto cuyo nombre se remonta a un auto legendario del Turismo Carretera en Argentina y que siendo niño fue mi portal a la curiosidad por la tecnología. El proyecto en realidad empezó con la idea de construir un transceiver especializado en modos digitales de baja señal y mayoritariamente basado en técnicas de Radio Definida por Software (Software Defined Radio o SDR), tema en el que profesional, académica y personalmente he estado muy involucrado en los últimos 20 años. La plataforma Raspberry Pi es ideal para ese uso, es relativamente accesible, muy poderosa en su capacidad de cómputo, montada sobre una distribución Linux propia lo que debido a mi familiaridad con Linux desde hace mucho tiempo, el acceso a recursos de desarrollo y su flexibilidad prácticamente ilimitados es una plataforma ideal. Un primer planteo estuvo dado por dos proyectos anteriores, que en rigor fueron preliminares de éste. El que denominé "Transceptor de señales débiles, bit a bit" (link) donde en varias entradas sucesivas fui mostrando apuntes para construir las diferentes partes de un transceptor. Un segundo proyecto relacionado fue la baliza WSPR que puse en funcionamiento en 20 metros hace mas de dos años (link), proyecto que dio lugar a muchas entradas posteriores tanto relacionada con ella misma como con sus usos en actividades de estudio de propagación y planeamiento de concursos. Es claro que de alguna manera éste proyecto es parte de un hilo de proyectos en el que llevo ya varios años. El proceso de formación de un proyecto va medrando cambiando su dirección en formas que son muy erráticas, temas que no están conectados entre si de repente lo están y partes de un todo terminan tomando vida propia separándose en proyectos independientes que quizás se vuelvan a juntar en otra oportunidad. Es claro que para crear un transceptor hay varios módulos funcionales o sub-sistemas que deben operar en forma satisfactoria. La generación de señal es claramente dominada por la librería librpitx de Evariste (F5OEO), la cual con muchas horas de estudio he logrado comprender en un grado de detalle que me permite modificarla cuando necesito. Evariste me ha honrado con la autorización para que haga merges sin su inspección con modificaciones que crea convenientes directamente sobre el branch master de GitHub que la contiene, ¡guau!. Con esa librería es posiblemente generar cualquier patrón de modulación en el espectro de RF desde unos pocos cientos de KHz hasta el rango superior de UHF (superior a 1.5 GHz). Por otro lado para el receptor tiene todos los números de la rifa el dongle RTL-SDR, he probado muchos otros, en particular varios tuners de TDA pero a la larga o corta la solución mas efectiva es éste a pesar que su precio es un poco mas elevado.

El trabajo con el proyecto PixiePi (objeto de una entrada reciente) me permitió sortear un obstáculo de mas de un año de antigüedad, como procesar las señales en tiempos que no generaran retardos incompatibles con los modos digitales de baja señal, los cuales son extremadamente sensibles a la sincronización temporal entre transmisor y receptor. De ese proyecto terminé con una librería propia y reusable con un kit de herramientas de procesamiento digital de señales (DSP) para generar filtros, diezmadores, interpoladores, filtros de rotación de cuadratura y otros.

Por otra parte el proyecto de la baliza WSPR me familiarizó con una placa provista por TAPR que actúa como "sombrero" (hat) o "escudo" (shield) de una Raspberry Pi y tomando la salida del GPIO4 realiza el filtrado de la misma y su amplificación hasta un nivel de unos 20 dBm (100 mW), la salida de RF tal como es generada por la librería librpitx es una forma de onda cuadrada, muy rica en armónicos a la cual no se le puede extraer mucho mas que 10 mW, que expone demasiado la placa a problemas de estáticos en la antena y que requiere mucho filtrado; todos problemas solucionados con éste shield.  Todo integrado termina en un ecosistema OrangeThunder  y puede encontrarse todo el ecosistema relacionado en GitHub (link) que incluye un conjunto de programas, el hardware necesario, como se integran los distintos módulos e incluso un diseño 3D para el gabinete. un conjunto de programas. El principal programa comparte en realidad una cantidad de código con el ya mencionado Pi4D. Ese programa  se denomina Orange Thunder for Digital (OT4D) y es capaz de tomar una modulación de señal digital, reproducirla y recorrer el camino inverso. Para lograrlo se utiliza ecosistema de varias placas integradas entre si, una interfaz de sonido gestionada mediante la librería ALSA, una placa Raspberry Pi 3B con la que se genera la señal modulada en RF con una salida de 10 dBm y en recepción se realiza la demodulación, una placa TAPR que aporta en transmisión filtrado y amplificación a 20 dBm y un dongle RTL-SDR como downconverter y unidad de conversión analógica-digital. 

Vale la pena describir como funciona el sistema en su conjunto. En recepción la señal de antena es alimentada por un relay de conmutación a la entrada de antena del dongle RTL-SDR; convenientemente programado en parámetros de muestreo y frecuencia el mismo produce una señal en cuadratura a 1.2 MSamples/seg (o sea mas de un millón de pares de valores). Para éste proceso se usa una librería, la mejor librería para gestionar el dongle es la denominada rtlsdr Osmocom (link), uno de cuyos programas es denominado rtl_fm y es capaz de sintonizar múltiples modulaciones en cualquier frecuencia dentro del rango admisible por el dongle. Para ajustar sus funciones a éste proyecto modifico el programa de manera de controlar en forma externa la frecuencia de operación (sin tener que parar y arrancar el programa) y agregar otras funciones tal como lectura de nivel de señal. Se menciona a menudo que el dongle RTL-SDR funciona por encima de 30 MHz y que para operarlo por debajo requiere un módulo down-converter. Eso es parcialmente cierto. En el rango de HF, por debajo de 30 MHz en todo caso el dongle requiere usar el llamado modo 2 (conversión directa) por lo que en realidad entrega dos señales espejadas a ambos lados del oscilador local, como en cualquier receptor de conversión directa. Pero a mas de un millón de muestras el teorema de Nyquist-Shannon nos indica que el ancho de banda será de unos 600 KHz a cada lado, por lo que es razonablemente fácil discriminar las señales, mas fácil en todo caso que lo que es hacerlo cuando las señales están mucho mas juntas como en el caso de un receptor de conversión directa en el rango de audio. En todo caso colocando la frecuencia a la que se ubica el oscilador local (o LO por Local Oscillator) del dongle ligeramente fuera de banda, nos podemos concentrar que se tomará por arriba de la misma con cierta facilidad. La separación permitirá además el filtrado en forma mas sencilla. En realidad de toda esa banda sintonizada originalmente  mediante filtrado y diezmado se retiene solo un par de KHz alrededor de la frecuencia de sintonía. Una vez que se reduce el ancho de banda carece de sentido seguir procesando millones de muestras por segundo y hay que pasar a solo algunas miles con lo que el resto del tratamiento de la señal es menos demandantes. Entonces la señal es procesada primero por rtl_fm, el resultado por un procesador especial y finalmente el resultado, ya una señal de audio a esa altura, puesta a disposición de los programas mediante el programa aplay, el cual es parte de ALSA. 

La señal de audio puede ser mandada a un par de parlantes o alimentada a otro programa mediante un "virtual cable" provisto por ALSA, snd_aloop en éste caso cumple ese role. Con la configuración apropiada WSJT-X recibe la señal de audio como si estuviera conectado a la salida de un transceptor convencional y puede hacer su propia magia a partir de alli. El transceptor en si no participa en la demodulación de la señal, cualquiera sea ésta, lo hace el programa respectivo. Uno puede ver la señal en la banda pasante, puede manejar el transceptor mediante comandos CAT, lo puede encender o apagar con el test de PTT y todo lo que haría con un transceptor, solo que no hay transceptor. Solo hay software.

Para la transmisión se hace algo similar pero a la inversa. El programa que genera la señal digital, nuevamente WSJT-X por caso, genera la banda base de, digamos FT8, como una señal de audio la cual se hace disponible mediante un "virtual cable" para el programa arecord de ALSA. Su salida es procesada digitalmente por una librería del proyecto que implementa algoritmos de procesamiento digital de señales con muy baja huella de procesamiento con los que se generan señales en cuadratura I/Q para USB, las que son alimentadas a funciones del programa librpitx (una versión modificada del programa sendiq del paquete rpitx en realidad), el cual genera la señal de RF en la frecuencia indicada. La señal de RF es emitida en realidad por el puerto GPIO4 como una onda cuadrada de unos 3.3V pep capaz de entregar unos 10 mW sobre una carga de 50 Ohms. Para que esa señal sea usable, y legal, es amplificada y filtrada extensivamente por una placa TAPR. Esa última limita la banda de operación, en éste prototipo a 20m, pero hay modelos para otras bandas. No es difícil hacer shields para bandas diferentes, no es mucho mas que un amplificador simple a FET y un filtro pasabajos mas o menos agudo. 

¿Que se obtiene con eso? Un transceptor de 100 mW capaz de operar en los distintos modos digitales. ¿Para que sirve en, por ejemplo, FT8? Bueno, depende, con la antena correcta y la propagación correcta para comunicar con cualquier parte del mundo en realidad. 

Mi baliza WSPR/FT8 tiene registros de todos los continentes. Lo usual son reportes locales o regionales (5000 Km o menos), pero con frecuencia se reciben reportes continentales (USA, Canadá) o globales. Nada impide agregar una etapa de amplificación mas para tener una salida de 1W con lo lo que las perspectivas mejoran aún mas.

La antena se conmuta con un relay, el cual es controlado por un pin del GPIO, el cual es activado por el programa cuando pasa de recepción a transmisión. Y eso puede ocurrir por un comando de CAT, por utilizar el sistemas VOX o por un PTT físico (el cual es sensado por el programa).

En la práctica el comportamiento en el aire superó las expectativas, el transceptor digital tiene buena performance de recepción y permite hacer contactos locales prácticamente sin restricciones (con 100 mW). Los contactos regionales dependen, como es de esperar, de una combinación de buenas condiciones, con cierta pericia operativa y con ausencia de otras señales de interferencia; pero ciertamente ocurren y con mas frecuencia que lo que se podría suponer. Se deberían esperar señales reportadas -10 dB respecto a lo reportado con la estación "convencional" de 1W, y realmente la relación se mantiene, por lo que en general podré trabajar estaciones a las que escuche a -10 dB o superior, nada imposible con condiciones promedio.

El proyecto fue complejo (y divertido) de desarrollar, aunque no es complejo de reproducir una vez que se cuenta con los esquemas y el software (incluso hasta la cajita para imprimir en 3D). La experimentación adicional que se puede hacer, tanto en el lado del software como del hardware puede derivar en múltiples direcciones. Con el procesamiento adecuado y pocas modificaciones es posible emitir en SSB (la Raspberry Pi tiene cierta capacidad de modular en amplitud el voltage de los pin GPIO), y por supuesto todos los otros modos digitales.

¿Si me dio gusto terminar el proyecto?..... ¿Quien dijo que el proyecto terminó?

μSDX Das Radio (Parte 1)

 

La historia empieza con un proyecto simple pero revolucionario, el transceptor QCX de QRP-Labs, cuyo propietario Hans Summers (G0UPL) es bien conocido por su talento para desarrollar buenos productos para el mercado de radioaficionados global, mercado dificil si los hay. El transceptor de marras es un kit  para que cada uno se lo arme, su circuito está bien documentado pero tiene aspectos propietarios. En su forma original se trata de un transceptor de CW, aunque nada impide usarlo como receptor de SSB también, que opera en una banda en la gama de HF a elección al momento de comprarlo. En realidad su electrónica es tal que lo que diferencia el funcionamiento de una banda u otra son los filtros. Su potencia de salida está en el entorno de los 3 a 5W dependiendo de varios factores, utiliza una etapa de salida basada en MOSFET baratos operando en clase E lo que aumenta mucho la eficiencia y reduce el tamaño del disipador necesario. Un aspecto fantástico del kit es que el microcódigo contiene la implementación de todos los "instrumentos" necesarios para calibrar la placa ya en funcionamiento. El transceptor usa técnicas SDR (Software Defined Radio) para su funcionamiento, en particular para la cadena receptora. El firmware que controla el funcionamiento de la placa es implementado en un ATMega328P y el firmware que contiene es el encargado de todas las funciones de procesamiento de datos, las de gestión de las distintas funciones de la placa, la interfaz de usuario mediante la cual controlar sus parámetros de funcionamiento y la operación misma del transceiver  y, finalmente, implementar los instrumentación de prueba. La memoria del procesador  ATMega328p viene ya grabada con el microcódigo provisto por QRP-Labs, del que no se dispone source ni es facilmente modificable. El chip suena conocido y lo es, se trata del mismo que contienen las placas Arduino, solo que en vez de operar con un clock de 16 MHz lo hace con uno de 20 MHz. Es por cierto posible explorar un poco ese código con un kit de debugging y un  "disassembler" para recuperar una suerte de "source" que con bastante esfuerzo se puede entender y eventualmente modificar, pero realmente no vale la pena tanto esfuerzo como veremos pues el QCX como transceptor tiene un funcionamiento soberbio y es muy completo. Una función muy interesante en el código original es poder operar como una baliza WSPR autónoma, la que salvo una cierta complejidad para sincronizar el reloj tal como lo requiere ese modo es bastante funcional y útil. Para la operación portatil la utilidad de operar WSPR se desdobla, por un lado se puede evaluar el funcionamiento de la antena y por el otro las condiciones de propagación, ambas monitoreando la red WSPRNet.

El proyecto es muy divertido de ser abordado para la construcción, la placa es densa y compleja, pero el kit está muy bien diseñado y siguiendo estrictamente las indicaciones sale prácticamente en el primer intento.

En el aire se comporta muy bien. Obviamente que quien no se sienta cómodo operando en CW le resultará de uso limitado, aunque para funcionamiento QRP la operación en CW es casi la norma, incluso a velocidades muy modestas. En mi caso disfruto operar en CW y la única limitación seria, si se puede llamar tal es la operación monobanda. 

Con el tiempo he construido dos versiones del kit, el QCX+ para 40 metros y el QCX-Mini para 20 metros, ambos funcionan igualmente bien, aunque el último es un poco mas dificil de construir debido a su tamaño reducido, ambos han sido cubiertos previamente en éste blog.

Entonces aparece Guido (PE1NNZ) con una vieja idea (link) implementada casi una década atrás en las entonces incipientes Raspberry Pi (modelo 1, por entonces) y posteriormente sobre un chip ATTiny45. La idea proviene de un evidente dominio de las técnicas DSP para modular señales, y de algo que casi todos usamos pero muy pocos conocen y es como funciona la "compresión" de voz en SSB.

Sin intentar repetir la teoría, que puede leerse en el ARRL handbook, la modulación humana puede dividirse en dos componentes. Una señal modulada en frecuencia que transporta la gama alta de frecuencias del espectro vocal y que contiene la mayor parte de la información la que es modulada en amplitud por una señal de baja frecuencia que da la entonación. La compresión en SSB consiste justamente en quedarse mayormente con la señal modulada en frecuencia con una amplitud casi constante (no del todo para no generar espurias excesivas), con lo que la potencia media de la señal sube. El resultado es una modulación distorsionada, nasal y sibilante, pero inteligible y con mas "pegada" en condiciones ruidosas pues tiene mas "potencia" (mas potencia media). Mas viejo que la injusticia también, pero efectivo desde siempre como bien lo saben quienes usan el recurso en las condiciones muy exigentes de operación de DX y concursos.

Con técnicas de procesamiento digital de señales se puede entonces capturar el contenido de frecuencia de las señales de audio y modular en fase una señal portadora manteniendo la amplitud casi constante o con poca variación.

La Raspberry Pi permite en sus puertos GPIO manejar hasta 7 niveles de amplitud, por lo cual se puede tener una señal vocal bastante inteligible a pesar de lo discreto de los niveles de modulación. En experimentos reportados en el blog he utilizado ésto en el proyecto Orange Thunder y en particular en el denominado PixiePi. En particular en éste último utilicé un kit de transceptor económico de telegrafía (Pixie) el cual opera su etapa final en clase C, claramente no indicada para señales que requieran amplificación lineal como el SSB. Sin embargo, casi mas útil para la operación QRP que salir en CW lo es salir en los modos digitales de baja señal, en particular FT8, y éstos modos requieren SSB pero la modulación es de amplitud constante. Las pruebas con el hardware PixiePi y el programa Pi4D resultaron una revelación puesto que en definitiva se trataba de un receptor rudimentario de conversión directa, un transmisor de algo menos de 1W y una antena simple random wire alimentada al extremo en 40 metros con el que obtuve alcance regional.

Cuando luego de muchos años de silencio encontré una nueva entrada en el blog de Guido, esta vez refiriendo a su proyecto QCX-SSB no pude menos que estudiarlo con mucha atención. En el mismo cuenta como aplicó el viejo concepto que en su momento exploró a nivel prototipo con una placa Raspberry Pi pero ahora con una placa QCX modificada dotando a la misma la capacidad de operar en ... SSB (!). Desde el punto de vista hardware las modificaciones a la placa no son muchas, despues de todo el QCX es un buen receptor, y como transmisor se elimina el circuito de manipulación y se lo modifica para que permita modular la amplitud usando PWM, con un truco genera una señal modulada en fase para completar la generación. Y vaya truco. Una cosa es realizar el procesamiento de señales necesario en una placa Raspberry Pi, que aún en su versión mas vieja era órdenes de magnitud mas potente en clock de CPU y memoria que el Arduino con reloj "sobrecargado" que es en realidad una placa QCX, en el proyecto PixiePi aprendí que el procesamiento digital necesario tenía lo suyo y también era una placa Raspberry (Zero en éste caso). Como buen mago que es Guido hace sus trucos a la vista de todos, el microcódigo QCX-SSB es abierto y está disponible en GitHub para quien quiera usarlo (y modificarlo). Cuando se lo revisa con cuidado es posible observar que el código tiene tres grandes segmentos, el receptor, la gestión de la placa y el transmisor. Los dos primeros operan mas o menos como lo haría el QCX, ignoro en que medida Hans compartió o liberó parte del microcódigo para que Guido lo usara como base o si éste directamente lo desarrolló desde cero, no hay referencias en el código al copyright respectivo y Hans, que suele ser muy enfático cuando del uso de su material propietario se refiere, participa en el foro de soporte del proyecto y no se ha quejado. Lo cierto es que desde el punto de vista programación de parámetros y operación el QCX-SSB es muy similar al QCX, con menos funciones quizás. Desde el punto de vista de recepción no tiene diferencias significativas.

Desde el punto de vista transmisión en cambio Guido ha realizado una obra de arte de programación para poder procesar las señales de audio con las técnicas SDR adecuadas para obtener la información de fase y amplitud tras lo cual realiza otra obra de arte para programar la frecuencia (fase en realidad) del chip DDS Si5351. No consiste en cambiarle la frecuencia en forma convencional, el chip no reacciona con la suficiente velocidad si se lo hace de esa manera, consiste en manipular muy intrincadamente los registros del chip para lograr que opere con técnicas de acceso DMA de baja latencia, una maravilla para estudiar con detenimiento en una tarde de lluvia, casi como una buena lectura de un gran autor. El sitio GitHub contiene toda la información para modificar el hardware del kit QCX para hacerlo compatible con éste firmware, las modificaciones son simples realmente, sobre todo si se arma el kit desde cero con éste uso en mente puesto que en ese caso se trata de poblar mas o menos la mitad de los componentes y luego realizar media docena de "jumpers" en la placa; las instrucciones de armado hechas por Manuel (DL2MAN) no están tan logradas como sus equivalentes del kit original, pero teniendo cierta experiencia en armado de kits y siendo cuidadoso se llega a buen puerto, los pasos de la construcción fueron en su oportunidad documentados en éste blog (link). La grabación del firmware en el chip ATMega328p requiere de un grabador Arduino ISP (usando otra placa Arduino), el proceso no es terriblemente complejo pero hay que ser prolijo con los pasos pues está lejos del método "plug & play" para grabar una placa Arduino convencional. A diferencia del QCX original el firmware no contiene los instrumentos necesarios para su calibración por lo que hay que recurrir a instrumentos de laboratorio mas convencionales para ajustar un emisor SSB. El comportamiento en el aire es sorprendente, tanto en el uso mas convencional de CW propio del transceptor QCX subyacente como en SSB (!), tanto en operación de voz como en modos digitales (FT8). Los reportes en fonía fueron excelentes, en FT8 la cantidad y calidad de contactos fue totalmente compatible con otros transceivers de 5W o menos en la estación a igual antena. 

Un desafortunado accidente mientras experimentaba derivó en la placa con el Si5351 quemado. Para explorar el firmware con mas detenimiento sin utilizar otro kit QCX construi un prototipo basado en una placa Arduino Uno, un módulo DDS Si5351, un rotary encoder/push y un kit de transceiver Pixie. Tuve que hacer algunas adaptaciones al microcódigo por un lado porque la asignación de puertos no podía ser la misma que en la placa QCX original (especialmente para el display LCD 16x2 y el rotary encoder) y por el otro porque el clock de una placa Arduino es, como comenté antes, de 16 MHz en vez de los 20 MHz que tiene la placa QCX, es por decirlo de alguna forma mas "lento", lo que requiere ajustar un poco el firmware para que le de la talla de hacer el procesamiento que tiene que hacer. Como prueba de concepto funcionó mas que bien, mostrando el potencial del proyecto para continuar desarrollandolo y eventualmente concluir con un transceptor ultra simple como el Pixie para operar modos como FT8 que podrían requerir un transceptor de SSB.

Mientras tanto el proyecto QCX-SSB no se quedó quieto, Manuel (DL2MAN) siguió trabajando sobre el único aspecto criticable del proyecto, la limitación original del QCX de ser monobanda.

Nada en el firmware QCX-SSB lo hace ser monobanda, de hecho es posible configurarlo para cualquier banda, pero para que el nivel de interferencias esté dentro de márgenes tolerables Manuel propuso originalmente un mecanismo para tener filtros "enchufables" para las distintas bandas (si, ¡como en los viejos equipos de AM cuando empezamos!). Pero una vez que el concepto mostró ser viable era necesario llevar el proyecto al siguiente nivel, y ¡Manuel se lo puso al hombro! (Continuará...)