sábado, 24 de agosto de 2019

SDR... mas lento no se puede...


Siempre fui un profundo admirador de René Lavand (Héctor René Lavandera 1928-2015) mago e ilusionista argentino, quien con una deficiencia física (manco) hacía trucos de cartas increíbles. No solo eso, los repetía en "cámara lenta" para darle chances a su audiencia a que descubriera el truco, cosa que no ocurría nunca por supuesto. Luego con una semisonrisa cómplice decía "... mas lento no se puede" como para patentizar la insuficiencia de nuestros sentidos para poder detectar la grandeza de su arte. Un grande.
Esto viene a cuento que hice, con el tiempo, como propia la expresión "mas lento no se puede" para indicar pedagógicamente  una situación donde las cosas están tan simples y tan claras que el que explica no puede hacer nada más para ayudar a quien escucha a entenderlo, todo el resto le queda a él.

En esa línea se inscribe un repost , cuyo circuito repito, hecho en Facebook por Alejandro Wankiewicz (LW8DRU) en el grupo Radio Telegrafistas del Sur sobre otro post hecho por Osvaldo Nolla (LU1JY) sobre una interfaz simple para SDR en 40 metros. En rigor se trata de un receptor doble conversión, la sencillez misma, pero suficiente para con el concurso de un programa SDR (él recomienda el M0KGK) poder hacer las primeras armas en SDR al mismo tiempo que entrarle a un circuito simple, económico y por cierto mas que razonable para los primeros pasos. Este tipo de receptor fueron los que hacía cuando era chico en mis comienzos en radio, y si bien tiene la dificultad de tener la doble recepción (recibe la señal por arriba y por debajo del valor del oscilador sin distinguirlas) hay toda una serie de trucos que hacen que en la práctica no sea tan molesto. Por ejemplo, si pongo el oscilador en 7000 KHz prácticamente todo lo que reciba será USB en banda de aficionados. Si lo pongo en 7070 KHz todo lo que sea telegrafía será para abajo, y así sucesivamente. Por cierto que para recibir modos de señales débiles (WSPR, FT8, etc) es inmaterial el tema de la doble banda lateral. En resumen, un lindo proyecto para despuntar el vicio un ratito. ¡Felicitaciones al autor y al difusor! Y para los potenciales constructores.... "... mas lento no se puede..."!



martes, 20 de agosto de 2019

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.




lunes, 12 de agosto de 2019

DMR en LU7DID, el nuevo BAOFENG DM-5R

Luego de darle algunas vueltas al asunto terminé sucumbiendo a la tentación de explorar el modo DMR . Hace algunos años tuve un cierto involucramiento profesional con la tecnología a partir del despliegue de redes de comunicaciones basadas en la tecnología TETRA implementada por Motorola para redes de servicio público. Asi que pude pasar rápidamente por la parte donde se explica la base de como funciona (como funcional el TDMA, el concepto de tier, etc.). En aquel entonces (una buena década y media atrás) no había redes de éste tipo para uso de aficionados, al menos en Argentina, al menos que conozca. Pero recientemente comencé a leer y me fui adentrando en la implementación para radio aficionados, porque una cosa es la tecnología básica, pero si no se conoce la topología de la red, su configuración y los recursos de "talking groups" (TG) uno no tiene ni por donde empezar.
Hay muchas formas de comenzar, y elegí una simple, adquirí un handy Baofeng DM-5R. Son esas compras que uno las hace y luego revisa en profundidad encontrando que los comentarios no son tan buenos como a uno le gustaría. Desde cierta dificultad de uso hasta que directamente no soportaba partes esenciales del protocolo (capacidad de conectar en Tier 2, es decir, de usar repetidoras). Tengo un Baofeng UV-5R, versión analógica de éste mismo handy, con el que realmente estoy muy satisfecho. Al recibirlo pensé que familiarizado con esa versión y con conocimientos de la tecnología bastaba para empezar a salir, haciendo corta una historia larga el primer set con el handy fue un contundente 0-6 a favor del handy, no lo pude hacer andar bien ni en modo analógico. El manual, el manual es horrible, mal organizado, mal traducido y muy poco útil en general. Así que, guardé y volví a modo lectura, pidiendo ayuda además en el reflector de WhatsApp del RC.Avellaneda (LU7EO). Ahí me dí cuenta que la mayor parte de los vídeos que reflejaban problemas eran relativamente viejos, dos o tres años de antigüedad, siendo que en general los vídeos mas nuevos referían que la mayor parte de los problemas habían sido mayormente solucionados. Dos videos cortos y útiles fueron éste para una descripción general y éste para los aspectos de programación. El segundo round fue mucho mas productivo, luego de haber leído el manual y revisado como era la navegación de los menúes de configuración (bien diferentes al UV-5R) pude en poco tiempo hacer funcionar el handy con la repetidora local de LU3DY (147.12+600 100Hz). Luego de renegar un poco pude hacer funcionar el programador de codeplug  y la configuración para la zona AMBA para los recursos en que me pasó Daniel (LU9DPD) y alli pude, si, hacer bastantes pruebas sobre la repe LU7EO y los varios recursos (Talking Group, TG) disponibles. Como en general operan los modos digitales la comunicación es cristalina, vástamente superior a su equivalente en fonía analógica, hasta el punto donde los errores son tantos que deja de haber señal. Es decir la señal tiene la inteligibilidad de una señal local o nada. Pude probar una cucharadita de té de éste océano imponente de posibilidades, será cuestión de ir profundizando.