martes, 25 de agosto de 2020

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


No hay comentarios:

Publicar un comentario