HNY 2023!

Este ha sido un año muy especial, en el que han ocurrido grandes cambios en mi vida personal. Cambios algunos que acompañan la vida misma, otros que son las respuestas que todos encontramos para mantenernos en movimiento. Y eso me ha mantenido alejado de tener una frecuencia de escritura en éste blog con un gran número de proyectos interesantes en los que estuve involucrado y actividades de radio que he podido realizar.

He participado en concursos, he realizado investigaciones, he desarrollado proyectos de hardware y software y muchas otras actividades interesantes.

Pero es un poco tarde para intentar ponerme al dia justo ahora, el último dia del año. Ya el 2023 con un poco de suerte, y algo de disciplina para tomarme el tiempo de generar documentación de lo hecho, lograré volcar en éste medio resumenes de las actividades que voy realizando. 

Desde hace mas de 20 años (primero en lu7hz, luego aquí como lu7did y ahora como lu7dz) solo resta a esta altura celebrar, todo lo relevante para éste blog se ha dicho en el año que se está yendo, y lo que no se pudo decir se dirá en el próximo.

Finalmente, y ahora si,  cuando termine el dia de hoy en el lugar que cada uno de nosotros esté levantemos las copas y pensemos mucho en nuestros planes futuros  mientras lo hacemos, junto a nuestros afectos. No sabemos si tendremos futuro, pero si lo hay... ¡que no nos encuentre sin planes!

El ADX no pregunta cuantas bandas son, ¡sino que vayan viniendo! ... ¡ahora 10 metros!

 

El Arduino Digital Transceiver (ADX, Transceptor Digital basado en Arduino), diseño originalmente de Barb (WB2CBA) ha sido en el último par de meses el objeto de mi tiempo de experimentación, tal como se da cuenta en entradas anteriores de éste blog.

No es para menos, se trata de un diseño muy sencillo, fácilmente reproducible, flexible, que anda muy bien y da muy buenos resultados.

Aprovechando que la tirada mínima de placas era de cinco (5) hice hasta ahora varios, uno de ellos para desarrollar el firmware, otro para operar en la estación y un tercero para llevar a cabo el experimento que comento en ésta entrada.

He trabajado bastante en desarrollar una versión experimental del firmware que soporta una serie de funciones que en el software original no están contempladas, tales como un watchdog de transmisión, manejo optimizado de la memoria EEPROM, soporte de CAT (TS480 e IC746), posibilidad de operar en CW, capacidad de tener una terminal de configuración y otras funciones. El firmware original  está configurado para soportar cuatro bandas, a saber 40,30,20 y 17 metros. La placa en si es monobanda, pues depende de un filtro pasa bajos que permite la operación en clase E de alta eficiencia y el mismo es óptimo para solo una banda. 

Sin embargo la idea es que se puedan enchufar varios filtros según la banda que se opere. Es un juego un poco peligroso porque si bien la placa tiene protección para impedir emitir sin el filtro (los +12V de la etapa de salida se canalizan por el filtro, por lo que si no está la misma no recibe alimentación). No hay sin embargo control que el filtro enchufado sea consistente con la banda que se está operando, cuestión que está recibiendo cierto grado de discusión entre quienes estamos participando en el desarrollo y mejoras del firmware. Otro participante del esfuerzo de desarrollo, Alan (AG7XS) está por su parte trabajando en filtros multibanda. Barb, por su parte está llevando adelante una "daughter-board" llamada QUAD que funciona como un filtro seleccionable de 4 bandas que puede ser controlado por software. Mientras tanto la frecuencia máxima a la que se supone opera el ADX es 17 metros (18 MHz), dejando fuera las bandas de 15,10 y ... ¿6 metros?. No hay, aparte del filtro, ningún limitante en la cadena de transmisión con la posible excepción del integrado 244, tanto el módulo Si5351 que se utiliza como DDS como los transistores de salida BS170 pueden operar perfectamente en bandas mas altas. 

Sin embargo, en recepción el integrado CD2003GP es dudoso que pueda trabajar a frecuencias tan altas, después de todo es un receptor AM de bajo costo utilizado como receptor de conversión directa. La hoja de datos exhibe mediciones en 1 MHz, infiriendo que sea ésta la frecuencia típica de uso. Sin embargo, mi razonamiento es que ese chip es también un receptor de FM (88-110 MHz) por lo que es improbable que los receptores de AM y FM tengan parámetros de chip tan diferentes. Así que me lancé a construir una versión para 10 metros. El primer punto fue diseñar un filtro adecuado a esa frecuencia. Partí de valores aproximados que me compartió Barb pero les pegué un retoque con el programa de cálculo de filtros de salida para amplificadores clase E (link), los valores son muy parecidos.  

Al ponerlo a funcionar inmediatamente se iluminó la recepción con muy buena captura de señales (comparando con WSJT-X corriendo en una PC grande y una antena Yagui), primer conclusión, al CD2003GP le da el cuero para operar en 10m (y por transitiva en 15m), muy buena noticia porque eso significa que el transceiver puede (en recepción) cubrir toda la gama de bandas de HF. En transmisión, luego de una falla provocada por uno de los transistores de salida en corto, con algo menos de excitación proveniente del 244 aún así se puede operar con 1 a 2W de potencia de salida. Mas que muy suficiente para tener una cobertura y operación global. De hecho, en el primer día de operación pude hacer con comodidad con esa potencia baja estaciones de EU y NA, quizás mas a la noche si la propagación acompaña algo de JA.

Queda picando ahora comprobar si también llega a 6 metros, no tengo duda alguna que la cadena receptora andará bien. Tengo, si, mis duda con la transmisora por el comportamiento del 244 como excitador. Supongo que eso puede ser compensado por los menores requerimientos de potencia que tiene la "banda mágica" cuando se abre. ¡No queda mas remedio que probarlo!

FT8 Radio y (tr)uSDX, ¡un duo dinàmico!

Hace algún tiempo, en entradas anteriores, comenté el curioso derrotero que siguió el diseño (tr)uSDX de Manuel (DL2MAN) como evolución del transceptor "open source" uSDX, el cual a su vez deriva del diseño QCX-SSB de Guido (PE1NNZ), el cual se basa en el transceptor archifamoso QCX de Hans Summers (G0UPL).

El proyecto en si tiene pros y cons, por un lado es un refinamiento del diseño "sandwich" previo de Manuel, al cual se lo ha miniaturizado aún mas para incorporar increíbles 5 bandas en un diseño poco mas grande que un mazo de cartas.

El mismo proporciona alrededor de 3W de potencia, al menos en 40 metros pues no lo probé en el resto de las bandas, y sigue la interfaz clásica del QCX-SSB con dos botones y un dial/pulsador. En teoría puede operar en USB/LSB/CW/AM/FM y  da soporte a CAT (Kenwood TS480) por medio de un puerto serie-USB. Su gran "con" es que se trata de un proyecto no necesariamente con fines de lucro, pues se puede obtener en kit por un costo nominal, pero si cerrado pues su firmware no es público. Si bien el transceiver viene ya programado con un firmware actualizado las actualizaciones subsecuentes hay que hacerlas recurriendo a una clave provista con el aparato (que hay que enviar a Guido, para que el retorne una clave de activación). Todo muy alambicado y posiblemente inútil.

Pero bueno, para probarlo se me ocurrió hacerlo en FT8, modo en el cual estoy dedicando la mayor parte de mi tiempo de experimentación para construir el firmware experimental del transceptor ADX (ver entradas anteriores sobre ese proyecto).

Pero en lugar de conectarlo a la placa Raspberry Pi que utilizo como controlador de mi estación digital para generar FT8 a partir del programa WSJT-X quise seguir los pasos de Adam (K6ARK), un entusiasta de las operaciones tipo SOTA, quien en un reciente video en su canal de YouTube (link) utilizó al transceptor (tr)uSDX junto a una aplicación para el teléfono celular (Android) denominada FT8 Radio desarrollada por Dhiru Kholia (VU3CER).

La misma es capaz de procesar las señales de audio FT8 proveniente del transceiver y de generarlo, con lo que puede operarse FT8 sin otro recurso, como es altamente probable que uno tenga que llevar un teléfono celular de todas formas baja drásticamente lo necesario para operar portátil.

El programa tiene un registro de llamadas algo rústico, pero creo que suficiente pues permite exportar a formato ADIF para procesarlo en otro lugar. La interfaz de manejo es intuitiva aun que un poco engorrosa, pero suficientemente ágil como para permitir operar FT8 sin problemas.

El aplicativo soporta algunos protocolos CAT, entre ellos (aparentemente) el del TS480 pues dice funcionar con el transceptor uSDX, pero no he logrado que funcione aún. No obstante se puede operar perfectamente utilizando el transceptor activado por VOX. Completa la configuración un adaptador "Y" de plug 3.5" para celular de 5 polos a dos jack de audio 3.5" stereo.

Como todo diseño que se precie el "maiden QSO" lo hice con la estación de Juan (LU5MBB) quien llamaba general en el momento de la prueba, a pesar de una banda concurrida, una antena dipolo rígido y solo 1W de potencia pudimos hacer rápidamente QSO con un sustentable -4 dB de reporte.

La intención última es poder hacer funcionar éste programa con el transceiver ADX, pero por el momento el control VOX "zapatea" un poco y el teléfono celular parece no poder entregar suficiente señal por lo que seguramente la clave estará en operarlo por CAT, resta alguna experimentación.

¡Realmente es una combinación fantástica y muy facil de usar!

Y dale con el ADX.....

 

El desarrollo de proyectos lleva su tiempo, y el transceptor ADX diseñado por Barb (WB2CBA) no es una excepción. La concepción y funcionamiento del proyecto fue ya descripto en entradas anteriores con cierto detalle, pero a modo de resumen se trata de un transceptor mono banda que permite operar en modos digitales en general, y en los modos digitales de baja señal (FT4,FT8,JS8 y WSPR) en particular. Su firmware, la esencia de su funcionamiento, es abierto y permite un grado considerable de experimentación al basarse en la plataforma Arduino.

La experimentación tiene algo de repetición, se va entendiendo cual es la mejor solución para un determinado problema intentando muchas veces diferentes alternativas. En ocasiones luego de varios intentos se logra una alternativa que funciona bien. Algunas veces incluso ninguna alternativa funciona.

La primer prueba de concepto fue adaptar el firmware para funcionar con una placa que es esencialmente otro transceptor, el uSDX o mi variante experimental el Pixino. Luego hice una versión con cableado punto a punto hasta que finalmente llegaron las placas que mandé a hacer en China. Ya con ellas construí una primer versión para 40 metros, que luego de algunos experimentos me las arreglé para dañar severamente y que hoy utilizo como placa de desarrollo. Seguida de otra placa para 40 metros que es la que hoy utilizo en la estación para operar FT8 en la banda de 40 metros con excelentes resultados. Mientras tanto le puse esfuerzo al proyecto mas allá de la construcción de transceptores en tres áreas, las que tienen un grado de desarrollo diferente. 

La que mas esfuerzo recibió y mas avance tiene es las mejoras de firmware (microcódigo, el software que controla la placa), el que es un programa para placa Arduino Nano. La placa tiene una interfaz muy simple, básicamente 4 LED que indican normalmente el "modo", en realidad como la placa no define el modo indican la frecuencia dentro de la banda en la que transmiten (que es distinta para cada modo) y tres switches tipo "botón" normalmente abierto. Uno para subir (UP), otro para bajar (DOWN) y el tercero para poner la placa en transmisión (TX) manualmente. Un quinto LED indica cuando la placa está en modo transmisión. La placa opera mediante un control VOX por lo que cuando detecta que hay señal de audio se pone en modo transmisión y cesa cuando no hay mas señal de audio. De esa forma la transmisión es controlada por el programa que realmente genera la señal del modo, normalmente WSJT-X corriendo en otra computadora. En realidad se puede usar cualquier programa que genere la señal a transmitir y la haga disponible por la placa de sonido. En mi estación uso una Raspberry Pi Modelo 3B con ese propósito, y la opero desde cualquier otra máquina de la casa o celular mediante el programa Real VNC Viewer. Muy práctico y conveniente, de hecho he podido desplegar una estación completamente remota en Mar del Plata con ésta configuración, lo que me permite hacer muchos experimentos de propagación. Sin embargo, a poco de experimentar con la placa resulta evidente que la misma se puede beneficiar, sobre todo en las condiciones que la uso, mediante un control CAT. Si bien la placa está diseñada para soportar 4 bandas y el firmware permite configurar 4 juegos de frecuencias diferentes en forma correspondiente en la realidad la placa es mono banda, pues solo permite un filtro de salida y es mecánicamente enchufable. Si bien no hay inconveniente en tener diferentes "filtros enchufables" para distintas bandas no es una configuración viable para la operación remota. Aun así sería conveniente poder cambiar de "modo" o frecuencia dentro de la banda correspondiente al filtro disponible, y para eso es necesario dar soporte a algún protocolo CAT. Al mismo tiempo surgen rápidamente otras mejoras que se hacen evidentes al operar la placa con el firmware original. Una de ellas de índole práctica es cambiar la estrategia de grabación de EEPROM, pues ante cualquier cambio se graba toda la configuración. Eso no es necesariamente incorrecto, la interfaz de botonera no invita a muchos cambios. Pero al colocar una interfaz CAT por cada cambio que se haga en algún parámetro, incluyendo la frecuencia, generaría una grabación de EEPROM. Las placas Arduino tienen un chip de EEPROM que soporta varias decenas de miles de ciclos de escritura, pero se agotan con sorprendente rapidez si se está permanentemente grabando sobre ella. Por eso le agregué un algoritmo que la configuración es bajada a EEPROM luego de varios segundos que se hizo el último cambio. También, para una placa que en algunas aplicaciones funciona sin atención (por ejemplo en recepción, como monitor de banda) es importante que si tiene algún problema que "cuelgue" al firmware ésto no implica que la placa queda en un estado inestable o impredecible; para evitar eso es necesario utilizar servicios de "watch dog timer (WDT)" que tiene por hardware el procesador ATMega328P. Al hacer ambas modificaciones aproveché para que el código en su conjunto fuera mas genérico y pudiera programarse con facilidad para cualquier banda de HF. El conjunto de las modificaciones las liberé como un firmware 1.2e (con "e" de experimental, link). En principio el CAT emula a un Kenwood TS480, es una versión adaptada del existente en el firmware del uSDX, y tuve algunos problemas de atiempamiento para que funcionara correctamente con WSJT-X, sin embargo funciona correctamente con FLRig y éste puede ser utilizado como un servidor para que WSJT-X utilice el protocolo CAT correspondiente. Es decir, las modificaciones en FLRig  provenientes del transceptor se reflejan en WSJT-X y viceversa. EL disponer de una interfaz CAT no solo tiene la ventaja de cambiar la frecuencia, sino también eventualmente el modo (para el soporte de CW) y hasta encender o apagar el transmisor sin depender de un control VOX. Adicionalmente ésta versión de firmware explora otros modos digitales. Si bien el método de generación de señal utilizado por el transceptor ADX es una traslación lineal de frecuencia en respuesta a una señal de audio (se mide la frecuencia de audio y se desplaza una portadora piloto en dicha frecuencia) la misma no modula amplitud y por lo tanto no puede utilizarse para fonía (SSB), o se puede utilizar con una distorsión inaceptablemente severa (suena como una señal de SSB muy comprimida y con muchos "splatters"). Si, en cambio, debería poder ser utilizada para transmitir en cualquier modo digital donde la amplitud no sea relevante, por ejemplo CW, RTTY, PSK31 e incluso SSTV (sin audio). Esto tiene dos vertientes, por un lado que el firmware acomode la generación desde el punto de vista interfaz de usuario del modo y la otra es el modo mismo. Para implementar CW tomé un camino simplista, el manipulador vertical en paralelo con el botón TX y cuando se encuentra en ese modo la portadora es desplazada 600 Hz para dar el "shift" propio de una señal de CW, revirtiendo el desplazamiento al pasar a recepción. En principio la interfaz permite un manipulador vertical solamente y el desplazamiento puede ser cambiado pero al momento de compilar el firmware por lo que es fijo durante su operación. El grueso del trabajo se insume en definir una elaborada interfaz que permite transmitir alguna idea a quien opera la placa sobre en que frecuencia está (arriba o abajo relativo a la frecuencia QRP de cada banda).

Para implementar todas esas funciones aproveché e hice cambios en la modularidad del código para que las distintas funciones fueran mas estructuradas y permitieran cambios con mayor facilidad (cada cambio o función se hace en una sola parte del código). La versión experimental con todos éstos cambios implementados puede encontrarse como 1.2e en el siguiente link. Este enfoque de implementación es aún incompleto pues el CW se genera con un ataque y decaimiento brusco y genera algunos "clicks" que hay que eliminar en versiones futuras. Hay varias alternativas en discusión, una es un pequeño circuito adicional y la otra utilizar PWM para moderar el crecimiento del frente con cada manipulación.

Posteriormente, trabajando en equipo con Barb (WB2CBA) y Alan (AG7XS) desarrollé una versión nueva del código denominada 1.3e (link) donde se agregan tres funciones, mejoras en la implementación de CAT que permiten al programa WSJT-X configurarse como utilizando directamente un Kenwood TS480, disponibilidad de un pulso (preliminarmente en la linea D5) para activar un ATU al cambiar de banda y la posibilidad de soportar una placa QUAD con filtros finales para 4 bandas de manera que se selecciones el filtro adecuado para cada banda.

Finalmente una versión adicional denominada 1.4e (link) se agrega en forma opcional el formato CAT correspondiente al ICOM 746, el cual es mas veloz y eficiente para una plataforma pequeña. El mismo es mutuamente exclusivo con el correspondiente al TS480, al momento de compilar el firmware se elige uno u el otro.

Semejante nivel de modificaciones en el firmware se llevaron casi todo el tiempo disponible, pero aún así hay otras dos áreas de progreso.

Una es relacionado con la caja, es conveniente que una vez que se concluye la placa y se la empieza a utilizar en la estación como un equipo mas tenga alguna forma de cubierta; el diseño básico del ADX provee archivos Gerber (placas impresas) para la tapa y el fondo de manera de cubrir la placa propiamente dicha; pero tontamente no las pedí al hacerlo con las placas originales. Pero en forma cruda es posible pasar un formato Gerber (placa) a un formato STL (printer 3D) y es lo que hice para ambas tapas, el proyecto todavía preliminar puede obtenerse en Thingiverse (link).

La otra área de modificación consiste en explorar el uso de la placa original en la banda de 10 metros. Originalmente el firmware del ADX viene programado para las bandas de 40,30,20 y 17 metros. La hipótesis subyacente es que quizás el chip receptor (CD2003GP) no sea adecuado para frecuencias mas altas. Después de todo es, en esencia, un receptor de AM para banda media de bajo costo y su especificación solo habla de su comportamiento en 1 MHz. Sin embargo, ese chip es al mismo tiempo un receptor de FM comercial, por lo tanto su tecnología constructiva es difícil que tenga muchas diferencias entre una función y otra. De ser eso posible el ADX podrá ser utilizado en 15,12 y 10 metros, quizás incluso habría que probar en 6 metros aunque no sé que tanta actividad en FT8 hay en esa banda. Para eso construí una placa de filtro para 10 metros e hice algunos experimentos en 10 metros, los que resultaron satisfactorios en cuando a la sensibilidad. No es una gran sorpresa, incluso con un deterioro debido a la frecuencia el menor ruido de 10 metros y el margen de señal-ruido que tiene el modo FT8 deben ser suficientes para obtener una performance aceptable; queda todavía bastante por probar y todo empieza por construir una placa especializada en 10 metros de forma de probarla en forma continua.

Muchas cosas interesantes, poco tiempo para dedicarles.

"Antípodas, pibe..."

Muchas veces conecto situaciones técnicas, operativas e incluso vivenciales con momentos y enseñanzas que pasé con quienes fueron mis mentores en la radio.

 He referido en muchas oportunidades que quizás ahora me es relativamente sencillo hilvanar conceptos técnicos relativamente complejos, pero una cosa es hacerlo ahora con mas de 45 años de experiencia profesional y otros tantos de formación académica superior. Una historia muy diferente era cuando empezaba en radio, tenía 12 años y no sabía absolutamente nada del tema, quizás con la excepción que si sabía que me gustaba. La mayor parte de mis maestros y mentores de entonces han fallecido y no puedo repetirle las gracias, pero al menos puedo a partir del reconocimiento intentar proveer aunque sea un poco de lo que ellos me dieron con entradas como ésta, que ojalá inspire a otros que estén empezando (o no tanto) como en su momento me inspiraron a mi.

Cuando empecé en radio tenía un equipo valvular de AM de unos 25W, que funcionaba en 80 metros (3.5 MHz) adosado a una antena algo precaria por limitaciones de espacio; por entonces mi actividad era mayormente local (50 Km o menos) con, ocasionalmente contactos en el rango de 500 a 1000 Km en días de muy buena propagación.

Leía revistas de radio donde hacían pronósticos de propagación donde las coberturas globales ocurrían en bandas a las que no tenía licencia (ni equipo) para acceder como 20 o 15 metros; ocasionalmente había pronósticos de propagación de alguna distancia (Sudamérica, Sud-Africa) para la banda de 40m donde mi equipo si podía operar con algunas modificaciones que con el tiempo hice aunque la licencia me permitió operar allí bastante tiempo después. En ningún caso escuché estaciones de las distancias pronosticadas ni en 80 metros ni en 40 metros. Pasarían varios años antes que pudiera tener un equipo se SSB, empezara a hacer telegrafía y pudiera tener una antena decente.

Con el tiempo, las mejoras de equipo, el pulido de habilidades operativas y  el creciente dominio de CW pude disfrutar de alcances como los que antaño en mi niñez indicaban los pronósticos, hoy es rutinario tener abundantes contactos con Japón, Corea, China y Rusia Asiática en CW, incluso con baja potencia. Con el tiempo he podido completar no uno sino varios DXCC en distintas modalidades, e incluso completar mas de 100 países en un solo fin de semana durante un CQ WW en el "peak" de propagación pasado.

Volviendo a mi niñez cuando le preguntaba a Don Ernesto Stellini (LU5EZ,SK) cual era el mejor logro que se podía lograr en radio el me decía "Antípodas, pibe...". El había sido recordman sudamericano en la banda de pre-guerra de 56 MHz, antecesora de la hoy banda de 50 MHz, en su contacto con Nueva Zelanda. Antípodas en términos geográficos es el "opuesto" geográfico, es decir donde llegaríamos si caváramos un imaginario túnel desde donde estamos saliendo en el lado opuesto de la Tierra. Para los americanos Australia o Nueva Zelandia es antípodas, pero para nosotros si hiciéramos ese túnel imaginario emergeríamos en algún lugar de China. Pero, detalles geográficos al margen, antípodas tiene el significado general de ser el complementario a 180 en longitud de donde estamos. Y ciertamente allí si caen Australia, Nueva Zelandia y Lejano Oriente.

Para mi, desde esos ecos lejanos cada vez que trabajo países en las "antípodas" tiene un sabor especial, es un logro especial. Hay veces que es mas difícil que otros, de hecho en mi experiencia siempre ha sido mas difícil contactar países en la franja de longitudes que incluye Asia Central, India y Océano Indico que se extiende hasta la península arábiga y Medio Oriente. Un poco por cuestiones de población pues hay muchos paises en esa región donde hay muy pocos aficionados pero también por propagación, no hay camino solar en en 10m y no hay camino obscuro bandas mas bajas. Los contactos siempre son en alguna ventana en 20 o 15 metros, breves ventanas en las que hay que estar muy atentos o en ocasiones de camino largo sobre el polo Norte. Tal es así que operé por primera vez en mi vida paises como Bangla Desh, Sri Lanka y Nepal cuando operé años atrás como estación VU en uno de mis viajes a la India.

Nuevamente, los ecos de los recuerdos no saben de dificultades técnicas y "antípodas" siempre tiene un sabor especial. 

Lo experimento en la tradicional apertura en 40 metros CW con JA de nuestro amanecer en otoño y primavera, o en el atardecer tardío o primera noche en 10 metros CW también con JA también en CW; a pesar de las horas extrañas que implican siempre hago un momento para disfrutar esas ventanas, siempre breves.

La exploración de los reportes de señales en FT8 tanto en 40 metros como en 10 metros cuenta también una historia de aperturas mas largas que en CW, sobre todo con JA, VK y ZL donde he tenido la oportunidad de contactar muchas veces recientemente en 40 metros FT8.

Al poner en funcionamiento el transceiver ADX (comentado en otra entrada) en 40 metros tenía expectativas de poder cubrir con el a nivel pais y regional, 2000 Km o menos, tiene, después de todo un receptor muy sencillo y lo he ajustado para una potencia de salida de algo menos de 2W. Para mi sorpresa cuando se produce la apertura he tenido oportunidad de trabajar Nueva Zelandia, cuando pude contactar con Andy (ZL1VAH), poco después de las 4am hora local (0713Z). No se con que potencia transmite Andy, pero su reporte de -18 dB SNR para mi señal implica que tendría que haber usado +24 dB mas de potencia para poder sostener el mismo contacto en SSB, ésto es debería haber utilizado 2 KW de potencia o 1 KW y una antena direccional (a tiro de mi estación en éste momento), mientras que en CW podría haberlo hecho con 100W (mucho mas a tiro de mi estación).

Como sea cuando se completó el contacto, con un transceiver fruto de intensa experimentación que construí con mis manos, de solo 2W de potencia sobre una antena dipolo rígido, con firmware adaptado por mi me transporté 50 años al pasado y sentí la misma sensación que entonces, solo faltaba Don Ernesto diciendo "Antípodas, pibe..." y tenía razón, la sensación de logro es enorme.

 

Il vero ADX ...Transceptor minimalista para señales débiles en HF

El proyecto ADX es una iniciativa que está, creo, destinada a causar una huella en los proyectos que gustan a los experimentadores.  El ADX (Arduino Digital Transceiver) diseñado por Barb (WB2CBA), prolífico autor para diseños derivados del concepto uSDX (link) en particular el denominado MoNo, tiene atractivos que rayan con lo imposible de evitar. En palabras de su autor como un diseño simple de adquirir sus partes, simple de construir y simple de calibrar y que sea muy económico. Demasiado bueno para ser cierto. Pero ésta vez lo es. El proyecto es discutido en cierto detalle en sitio GitHub (link), en el blog de Barb (link) y en un artículo en QRZ News (link). El diseño es realmente muy simple, la cadena receptora gira alrededor de un chip CD2003GP que es un integrado pensado para realizar radios de AM y FM económicas, al cual se le utiliza el segmento de AM para implementar un receptor de conversión directa. Como oscilador local se utiliza una de las salidas de un módulo DDS implementado alrededor del chip Si5351. Como parte del concepto de simplificación en vez de usar el chip Si5351, el cual tiene un formato SMD y requiere cierto acondicionamiento de señales, se utiliza directamente un módulo comercial el cual básicamente hay que proveerle alimentación (+5V/GND), dos señales I2C de control (SDA/SCL) y extraerle la señal de RF a partir de una de tres entradas (CLK0/1/2). Para poder controlar al chip se utiliza una placa Arduino Nano el cual configura al DDS para que emita una señal de oscilador local por su puerto CLK1. En éstas condiciones la cadena receptora toma las señales, las demodula y el resultado se entrega en el puerto de audio de salida. Es un receptor muy simple, un poco mas sofisticado que el de un Pixie donde la conversión directa se logra en el mismo transistor de salida operandolo en baja señal y mas simple que un chip de propósito general como el Si4732.

En transmisión el controlador programa al DDS para que la señal del oscilador sea emitida por el puerto CLK0 (apagando CLK1 y el receptor), la señal es amplificada por un buffer 74HC244 (en algún momento en el pasado experimenté con un transmisor de CW basado en ese concepto, link), pero para obtener una potencia un poco mas alta se recurre a tres transistores BS170 en paralelo, con lo que puede obtenerse una potencia del orden de los 3-5W dependiendo del ajuste y la antena.

Este tipo de diseño de salida se está transformando en standard, se utilizan muchos transistores económicos tipo MOSFET de los que usualmente se utilizan para baja señal (podría utilizarse también el 2N7000 que es mas fácil de conseguir, al menos para bandas bajas de HF dada su capacidad de entrada). Los transistores MOSFET funcionan mejor en paralelo que los correspondientes bipolares y no requieren de realimentación negativa para compensar sus diferencias. Se operan, además, en clase E de alta eficiencia, tan alta eficiencia que no es necesario ni siquiera poner un disipador a los transistores (aunque eso requiere que siempre tengan una carga apropiada pues su capacidad de disipar potencia en exceso es limitada). Para operar en clase E es necesario construir un tanque de salida que además del consabido funcionamiento como filtro pasa bajos ofrezca los valores correctos de impedancia reflejada. Terry (WA0ITP) provee un calculador para éste tipo de circuitos (link). No me imagino que salvo para equipos extremadamente simples utilicemos otro tipo de amplificador que no sea de éste tipo, algunos recursos de como funciona (link1, link2). Este tipo de amplificador sirve para señales que no tengan información de amplitud, sin embargo tal como se utiliza en el diseño uSDX se puede subsanar eso con una modulación simultanea de la amplitud.

El diseño de Barb solo utiliza el tanque de salida como único circuito sintonizado de todo el transceptor, y si bien no ofrece mecanismos de conmutación entre diferentes tanques para diferentes bandas utiliza un sistema de filtros "enchufables" de manera que se tenga que enchufar el correcto para cada banda; eso lo hace muy simple pero también bastante peligroso, hay una protección para evitar que el equipo se ponga en modo transmisión sin el filtro enchufado, la alimentación de +12V le llega a la etapa de salida a través del filtro por lo que si no está no hay potencia de salida. Sin embargo es mucho mas facil emitir con el filtro de la banda equivocada, y dependiendo de la ROE que tenga en esa banda el resultado puede no ser bueno para la etapa final. Lo realmente novedoso de éste diseño, optimizado para modos digitales de baja señal como FT8, FT4, JS8Call y WSPR, es como genera la señal. 

Generar una señal de, por ejemplo, FT8 es realmente simple y requiere muy poca potencia de procesamiento, básicamente se tiene un mensaje a transmitir, se lo codifica con el algoritmo redundante para generar el mensaje y se lo emite cambiando periódicamente la frecuencia de acuerdo al símbolo a transmitir. Las variaciones entre símbolos son suficientemente lentas para que cualquier procesador, por pequeño que sea, no tenga dificultades en programar los cambios de frecuencia en un DDS. Hay múltiples diseños disponibles de emisores WSPR usando tanto el AD9850 como el Si5351 con ésta técnica. Sin embargo, para transmitir en FT8, con mensajes cambiantes, hay dos alternativas. O se genera un programa capaz de codificar completamente el mensaje (como hago en el proyecto OrangeThunder) o se procesa de alguna manera la señal de audio proveniente de una PC o una Raspberry Pi corriendo el programa WSJT-X. El enfoque utilizado por el transceiver uSDX es procesar la señal de audio en forma digital de forma de extraer las componentes de fase y amplitud de la misma y utilizar una técnica muy ingeniosa para modificar la frecuencia del DDS Si5351 y la amplitud de la señal de salida de manera de tener una emisión lineal, capaz de generar cualquier modo (SSB, CW, FM, etc). Como el uSDX también utiliza un procesador Arduino Nano hacer semejante procesamiento en un procesador de 16 MHz de clock (20 MHz en el uSDX) requiere exprimirlo al máximo, cosa que Guido (PE1NNZ) consiguió.

Sin embargo, ya en el kit QDX de QRPLabs (Hans Summers, G0UPL), el enfoque para un transceptor especializado en modos digitales es otro, en vez de procesar digitalmente la señal de entrada para obtener su fase y su amplitud se puede descartar lo segundo pues no es necesario en modos digitales. La fase y la frecuencia son magnitudes "hermanas", teniendo la una se obtiene la otra por integración o diferenciación según de cual se trate. Entonces puedo medir la frecuencia de la señal de audio de entrada, la cual estoy razonablemente seguro en modos digitales que es un tono puro y no una señal compleja, y con el resultado de la medición cambiar la frecuencia del DDS por encima de una frecuencia base (por ejemplo 7.074 MHz para FT8 en 40m). A éste modo de generar la señal se lo denomina síntesis directa de SSB.

A pesar que el mensaje es corto (menos de 15 segundos) ésta forma de medición es muy eficiente computacionalmente y el procesador puede, utilizando interrupciones por nivel y los Timer disponibles, realizar muchas mediciones por cada segundo, de hecho millones de ellas. De hecho puede obtener unas 10 mediciones por cada microsegundo, lo que mas que dá un buen margen para muestrear una señal cuyo ancho de banda máximo es de 3 KHz (según el teorema del muestreo deberían obtenerse mas de 6000 muestras por segundo, en la práctica se obtienen muchas mas).

Hans comparte el algoritmo en el manual del transceptor QDX (link pag 57), sin embargo Barb extrae el algoritmo de una publicación de Burkhard Kainka (DK7JD) en su blog titulado Geführte FSK-Modulation mit Timer1 Caption" (Modulación FSK utilizando el Timer1) el cual incluye el algoritmo para utilizando el TIMER1 del procesador ATMega382p medir con mucha precisión la frecuencia del tono de entrada. Básicamente se configura que ocurra una interrupción cada vez que la señal tiene un cruce por cero y se utiliza el timer en su modo mas veloz (16 MHz) para contar cuantos pulsos de clock hubo entre interrupciones sucesivas, al hacerlo de ésta manera se puede conocer la frecuencia con resolución de fracciones de Hz, más que suficientes para operar FT8. Burkhard encuentra necesario utilizar un filtro pasabajos para justamente evitar que ruidos que pudieran estar presentes en la salida de audio del PC por encima de la frecuencia de corte generen aliases. El transceptor funciona muy simplemente, ni siquiera utiliza alguna forma de PTT, básicamente si detecta que hay un todo de audio se pone en modo transmisión, opera con un sistema VOX bien simple. El circuito es un transceptor solamente, por si mismo es incapaz de generar las señales de audio en modos FT8 u otros, tampoco de decodificarlas, para eso hay que usar una PC corriendo el programa WSJT-X y alguna placa de sonido para recibir y emitir las señales de audio necesarias. He probado tanto con una PC de escritorio, como una tableta como una placa Raspberry Pi, anduvo excelente con todas como era de esperar.

El resto de la implementación hace juego con la simplicidad conceptual, el transceptor asume que puede trabajar en 4 modos (FT8,FT4,JS8 y WSPR) en cada banda y pueden programarsele hasta 4 bandas; el firmware original viene configurado para 40,30,20 y 17 metros. Barb dice en la documentación que el cree que el chip CD2003GP puede ser limitado para funcionar en bandas mas altas, pero creo que eso hay que probarlo aceptando que habrá una degradación de funcionamiento pero evaluando si aún así la performance no es buena. En transmisión con el filtro de salida adecuado la cadena transmisora no tiene limitante alguno, en recepción habrá que ver hasta donde llega el chip receptor sin degradarse profundamente. El chip está especificado para AM para operar en el entorno de 1 MHz, será cuestión de probar. Para operar el transceptor se disponen de 4 leds que se multiplican para indicar el modo y la banda. Al comenzar parpadea el correspondiente a la banda en que se encuentra y al completar la inicialización queda prendido en el modo en que se encuentra. Dos pulsadores permiten cambiar el modo en forma cíclica, y mediante una combinación poner al transceptor en modo "cambio de banda". Completa la austera interfaz de usuario un led y un pulsador para poner e indicar modo transmisor manual.  

La construcción es simple, aunque no es tan simple como si fuera un kit, pues todas los componentes deben ser comprados y en algunos casos adaptados respecto a lo que se consigue. El elemento mas crítico es la placa de circuito impreso, que si bien no es muy complicada requiere un fabricante. En éste caso la envie a JLCPCB donde luego de subir los archivos Gerber correspondientes (disponibles en el sitio GitHub de WB2ADX) los mismos son validados y enviados a producir. El costo es muy bajo, al punto que el envio es mas caro (o comparable) a la construcción. Los módulos e integrados se consiguen por correo en los portales de compras y toda la minutería en casas de electrónica bien surtidas. Tuve, curiosamente, alguna dificultad en los conectores de audio pero terminé consiguiéndolos en una casa del centro de Buenos Aires. Ansioso como estaba de construir el transceptor, de experimentar su algoritmo de emisión mas que nada, hice pruebas adaptando el firmware a una placa del proyecto Pixino, el cual básicamente se trata de un módulo generador uSDX utilizando una placa Pixie como cadena de RF (discutido en una entrada anterior de éste blog en Pixino y su adaptación para ADX).

La modificación del firmware terminó resultando mas grande que lo que esperaba, pero me dio la oportunidad de familiarizarme con el código, adaptarlo un poco a mis preferencias de estilo (concepto vago e indefinible que todos los que desarrollamos software tenemos pero fallamos en explicar) y agregar algunas funciones que creo son de utilidad. De ese esfuerzo quedó una versión propia del firmware que fue la que terminé de adaptar cuando construi la placa real ADX.

La construcción empieza como en cualquier kit, inventariando los componentes y midiéndolos uno por uno para asegurar que tengan valores correctos, tengan la continuidad (o discontinuidad) que deban tener y que son adecuados para la placa.

Luego es una cuestión mayormente de preferencias, las que en mi caso implican soldar primero resistencias y capacitores, midiendo cada uno antes de soldarlo, asegurando que las conexiones sean buenas (si, una por una, demasiadas horas buscando fallas por soldaduras frias me lo enseñaron de la peor forma que eso es lo que se debe hacer). Luego los transistores y diodos. Luego los zócalos, módulos, leds, pulsadores y conectores. Finalmente las bobinas.

Aqui debo decir que cometí un error de juicio cuando mandé a hacer las placas pues omití mandar a fabricar las correspondientes al filtro de salida (el cual es una pequeña placa "daughter board"), su costo es insignificante y construirlas sobre una placa de impreso universal asegurando buenas conexiones, evitando acoples indeseados y con buena masa es mas complicado de lo que parece. De hecho el tiempo para el "debug" inicial el grueso del tiempo se lo llevó problemas en éste módulo, donde además de purito milagro no quemé los transistores de salida. Al respecto creo útil aportar que el problema de quemar los transistores de salida no es el costo, son realmente económicos aunque no tan fáciles de encontrar al menos en Argentina en éstos dias. El problema es reemplazarlos, porque justamente instalarlos bien implica soldarlos bien, que fluya la soldadura y sea firme. Bueno, una vez que se consigue una buena soldadura no es facil revertirla, en todo caso la placa no aguantaría creo demasiados ciclos de soldar y des-soldar. Asi que, hay que evitar equivocarse mucho.

Una vez terminado hice algunas mediciones básicas, tensiones mayormente, que dieron correctas y le hice un flash del firmware al Arduino Nano. Primera sorpresa, el Arduino quedaba bloqueado en el arranque. Error de firmware con la implementación propia del "watchdog", solucionado. Luego no prendían los led en la secuencia correcta, nuevamente problema de firmware en su implementación propia (en la de WB2CBA andaba bien). Luego encontré que parecía funcionar pero no recibía ni transmitía, error del firmware nuevamente en como se configuraba el clock del Si5351. En cada uno de éstos defectos el proceso era observar si en el firmware original también ocurría y si no lo hacía era obvio que se trataba de algún problema en la implementación propia.

Esto se debe a que utilicé una técnica de configuración que preserva el código original, de tal manera que el mismo sea (potencialmente) posible de consolidarse con el firmware original. Consiste en "eliminar" los segmentos de código que no se desean o agregar los que si se desea con condicionales de compilación (#define/#ifdef/#ifndef) de tal manera que el agregado o quita de una función "#define" agrega o quita segmentos de código enteros al momento de la compilación. La misma técnica la utilizo para configurar no utilizar los LED, agregar el CAT, utilizar o no la EEPROM, activar el watchdog y asi sucesivamente. El progreso de éste proyecto puede seguirse en el "fork" del proyecto original en mi sitio GitHub (link) el cual por ahora es independiente del mantenido por Barb, aunque está sincronizado con él de tal manera de posibilitar, en algún futuro y si las circunstancias así lo permiten, hacer un "merge" en un único sitio open source.

Obviamente al utilizar la técnica se cometen errores, sea eliminando o agregando partes que no se deben (o fallar al hacerlo) con lo que al compilar el código pueden aparecer "novedades" (bugs). Una vez despulgado el firmware de éste tipo de problemas pude evaluar que funcionalmente andaba bien, haciendo un contacto con la estación de María (LU2EIC), que es mi estación, al hacerlo compruebo que la señal de FT8 anda bien. Solo que no tiene potencia. Revisando con un osciloscopio la cadena de emisión identifico el problema de potencia es por una mala soldadura en el filtro tanque de salida, al corregirla sale andando todo muy bien y puedo hacer el "maiden QSO" (el QSO inaugural de todo proyecto), al igual que en los barcos todo un acontecimiento.

Queda mucho por experimentar, porque de eso se trata una plataforma tan sencilla y maleable, el grueso de lo cual es a traves de versiones del firmware. Primero viene habilitar todas las funciones adicionales que ya incluí en la prueba con la placa Pixino (EEPROM, watchdog y CAT) de a una para validar que funcionan bien. La principal función y la que todo el mundo está esperando es poder operar éste transceptor con CAT. Luego hay algunas modificaciones que creo importante hacer respecto a poder limitar los cambios de banda por firmware (con algún pin por hardware) e implementar la capacidad de CW. Para ésto último es necesario poder sintonizar, para lo cual los comandos no son ágiles con la interfaz actual ni es posible saber en que frecuencia se encuentra el transceptor. Obviamente agregar hardware tipo un rotary encoder o un display OLED es posible aunque agregaría complejidad a un diseño cuyo principal encanto es su simplicidad. Sin embargo el transceptor Pixie es funcional sin ninguna de las dos cosas, o sea que básicamente algo que permita subir o bajar la frecuencia en pasos de 100 Hz con alguna indicación de donde está (por ejemplo usando los cuatro leds) puede ser suficiente. El manipulador es posible adaptarlo con modificaciones muy simples a la placa. El resto es todo firmware.

Luego vendrá hacerle con la impresora 3D alguna clase de "casa" para no estar utilizando la placa directamente; el proyecto viene con unas placas impresas para usar a modo de "tapas" por encima y debajo de la placa propiamente dicha, pero no me terminan de convencer como solución. En resumen, un fantástico proyecto que no dudo en recomendar para experimentadores de toda la gama de experiencia que quieran pasar un buen rato.

Pixino con cariño es ADX

 

En una entrada anterior comenté sobre el proyecto Pixino, básicamente un diseño uSDX pero que como etapas de RF utiliza, en recepción y transmisión, un kit Pixie de bajo costo. La larga lista de ventajas y desventajas que tiene éste enfoque fue discutida en ese artículo, pero baste decir que es un proyecto que requiere mucho ajuste y experimentación, sobre todo del firmware QCX-SSB, por lo que es muy divertido.

En ese artículo referí al pasar sobre el proyecto ADX de Barb (WB2CBA), que es una variante diferente pero en el mismo sentido. Es decir, un transceiver de modos digitales usando una estrategia similar a la utilizada por el transceptor QDX de QRPLabs creado por Hans Summers (G0UPL). La principal similitud consiste en la generación de la señal PSK de FT8 (y otros modos digitales) no por el mecanismo convencional de SDR sino por la combinación de conteo con síntesis de frecuencia. El receptor de QDX es un supeheterodino compacto mientras que Barb utiliza un chip CD2003GP (chip receptor de AM/FM de bajo costo) el cual permite implementar un receptor de conversión directa. Se puede generar FT8 de muchas formas, con un transceptor convencional de SSB, con un transceptor simple de DSB (D4D de CRKits), por técnicas de SDR (uSDX) y por síntesis directa (QDX, ADX, entro otros).  

La estrategia de Barb es minimalista, el transceptor es tan de propósito específico que ni siquiera tiene otra forma de visualizar su funcionamiento que no sea con tres leds y como todo control tiene tres pulsadores que permiten seleccionar banda y modo; asignándole una frecuencia fija a cada uno de los modos FT8, FT4, JS8 y WSPR. El resultado es un transceptor super sencillo pero aún así muy potente, en un video demostración en YouTube Barb trabaja antípodas (circuito W-VK) en 20 metros desde su auto con uno de ellos. En su versión actual la implementación carece de cualquier otra facilidad (CAT, otros modos, etc) aunque Barb admite que podría incluirlos en versiones futuras del software.

Es un proyecto tan simple que entusiasma hacerlo, tanto la documentación de armado, como los circuitos y el firmware están disponibles. De hecho, en una revisión rápida pude verificar que los componentes, con excepción de la placa, los tengo o puedo conseguirlos con cierta facilidad localmente. La placa, para la cual están disponible los archivos Gerber para reproducirla, puede ser enviada a cualquier fabricante con esa información. Y por cuestiones de costo ese fabricante suele ser de China (por ejemplo JLCPCB). No obstante, y exceptuando que se quiera pagar USD $65.- de flete por 5 placas de USD $1 cada una hay que esperar bastante para que lleguen, en el entorno de 60-70 dias usualmente (muchos de los cuales se consumen en la aduana y correo locales, misterios de la logística global).

Asi que mi primer impulso fue construir el proyecto pero sobre una placa experimental de propósito general, soldando "cablecitos" a la vieja usanza. La ventaja es que al no tener ni visor LCD16X2, ni encoder rotativo la cantidad de lineas necesarias es muy pequeña, por lo que es relativamente facil de armar.

Mientras consideraba entrarle de esa forma me di cuenta que para poder usar directamente el transceiver Pixino en realidad necesitaba hacerle una sola modificación; re-localizar el pin de la placa Arduino Nano donde se conecta el encoder rotativo, pues es a esos pines los que el ADX usa para ingresar y procesar el audio. Por lo que decidí ordenar las placas y mientras llegan dar los primeros pasos con el firmware usando Pixino. Y alli fue.

Es interesante entender como funciona el transceiver. En receptor el firmware comanda al módulo DDS Si5351 para que provea la señal de oscilador local a un receptor de conversión directa; como no tiene forma de cambiar la frecuencia ni sintonizar solo basta un botón para que ciclicamente vaya cambiando las cuatro frecuencias de las bandas base de FT8, FT4, JS8 y WSPR. La placa ADX es realmente monobanda, pero prevee la posibilidad de enchufar diferentes filtros pasa-bajos. Al mismo tiempo se prevee en el firmware configurar hasta 4 bandas, sin modificaciones estas son 40,30,20 y 15 metros. O sea que la operación es trabajar en una banda definida y poder cambiarla a otras tres, pero en cada cambio hay que manualmente cambiar el filtro de salida. La recepción en si la hace un chip CD2003GP del cual se utiliza la etapa de RF y el mezclador para obtener un receptor de conversión directa. Es chip es extremadamente económico, pero los reportes indican que funciona muy bien. Barb indica que ese rendimiento decae por encima de los 21 MHz por lo que el transceiver, en principio, no se puede usar en 17, 10 y 6 metros, o al menos se pierde sensibilidad al hacerlo. No hay nada en el firmware que con los ajustes del caso no permita probar, solo hay que hacer el filtro pasa-bajos correspondiente a la salida para cada banda (y configurarla como parte del esquema cíclico de cambio). En que banda está el transceiver y en que modo lo indica mediante sendos LED a modo de interfaz de usuario, el firmware prevee hasta 4 bandas.

En recepción es ingenioso pero no es demasiado diferente de un Pixie, ambos son conversión directa. Sin modificaciones adicionales el kit Pixie está pensado para 40 metros y es bastante menos agil en banda desde el punto de vista filtro pasa bajos de salida.

En transmisión la técnica empleada está descripta en el transceptor QDX como se dijo, pero es implementada en la placa Arduino en forma bastante sencilla. A diferencia del transceptor uSDX no se hacen procesamientos de señal sofisticados para detectar amplitud y fase que luego puedan ser empleados para modificar en tiempo real la fase del DDS (operando en el límite del procesador y el DDS para hacerlo, realmente Guido (PE1NNZ) logró algo cercano a lo imposible). En éste enfoque, en cambio, lo que se hace es medir la frecuencia de entrada de la señal de audio por un método relativamente simple de cruce por cero, y una vez detectada esa frecuencia desplazar la frecuencia del DDS en la misma magnitud. Para un receptor de SSB es inmaterial si la señal se generó mediante un proceso de modulación "convencional" de SSB, por técnicas de SDR  o por éste método; observa una señal que varía en frecuencia al ritmo de una señal de audio que recupera y entrega a un programa como el WSJT-X para demodular. La medición de frecuencia es suficientemente "lenta" para no requerir recursos de procesamiento especiales. Básicamente se configura el Timer1 de la placa Arduino de tal manera que sea alimentado por el clock del procesador (16 MHz) y contar cuantos "ticks" ocurrieron entre dos cruces sucesivos por cero de la señal de entrada; parece algo muy "rápido" pero aún para un procesador tan lento es una lentitud glacial. Cada "tick" del reloj insume 1/16 microsegundos, mucho menos que la velocidad necesaria mínima de 1 microsegundo. La medición de frecuencia resulta entonces con una precisión mejor que 1 Hz lo que es mas que lo necesario para modular correctamente una señal FT8 (y mas aún WSPR). Una vez detectada la frecuencia de la señal de entrada simplemente se altera la frecuencia del DDS Si5351. por encima de la frecuencia base que requiera un dado modo. Por lo demás la señal del DDS se amplifica primero con una serie de compuertas digitales 74HC244 y finalmente con una salida en clase E lograda por 3 transistores BS170 de bajo costo operando en clase E. Nuevamente, el transceptor Pixie, aunque menos eficiente por operar en clase C no es muy diferente, la señal del DDS se alimenta al transistor que es el oscilador en el kit, y que deja de serlo al no instalar el cristal y conectar con el DDS en cambio, para luego resultar amplificado. En el caso del Pixie es necesario utilizar una señal PTT para que fisicamente pase la etapa de salida de funcionar como un mezclador a hacerlo como un amplificador de salida de potencia (dando 1W con suerte).

Dado que las diferencias no son tantas me largué entonces a hacer el proyecto. Me encontré con cierta dificultad en reemplazar los tres "switches" físicos que tiene el ADX por un tres switches virtuales que operan en realidad como niveles analógicos sobre un solo puerto. Hay operaciones como presionar dos switches simultaneamente que no son tan triviales de lograr. Pero usando el "pulsado largo" en reemplazo del "pulsado simultaneo" lo pude ajustar. El firmware ADX es tan simple que solo prevee operar con VOX, no tiene ningún circuito físico para encendido del transmisor. Si hay audio transmite y si no lo hay recibe, bien simple.

Con la idea general de hacerle algunos agregados al firmware original también aproveché a cambiar ligeramente la estructura del código para hacerlo mas facil. Implementé también algunas funciones que Barb había indicado que podían ser útiles en el futuro tales como mas bandas y CAT. También un "watchdog" siempre útil en los transmisores que exigen mucho la etapa de salida para el caso que algún problema en el software deje "clavado" el transmisor en encendido.

Hice todas las modificaciones en un branch público pero derivado del original del firmware ADX (técnicamente lo llama "fork") por lo que quizás en un futuro pueda integrarse con el código original (técnicamente se llama "merge" a ésta acción).

Todavía hay algunas funciones que requieren desarrollo, pero con la ansiedad propia de todos los proyectos en cuanto tuvo en funcionamiento lo básico lo puse a comunicar. Y para mi sorpresa rápidamente hizo los "maiden QSO" (equivalente al "maiden voyage" de los barcos, su viaje inaugural) en forma exitosa, cubriendo 600 Km de distancia a media tarde en 40 metros. Nada mal para 300 mW (ver el log WSJT-X adjunto).

Ahora resta completar el firmware y esperar la placa para armar una versión mas robusta, lo que tengo ahora es una placa experimental para desarrollar a modo de prototipo con pocas chances de sobrevivir ser puesta en un móvil.

Dos proyectos al precio de uno, nada mal.

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.

El (micro)uSDX en LU7DZ

 

En un entrada anterior hice una descripción mas o menos detallada del "ecosistema" de transceptores uSDX. Está siendo bastante común el concepto de "ecosistema" partiendo de un diseño generado y compartido por alguien, el cual va recibiendo sucesivas mejoras, y con el tiempo generando "familias" de aparatos similares que han recibido alguna modificación especializada para un propósito en particular. En entradas anteriores he compartido distintos miembros de esta "familia" y algo de su historia.

La saga de clones chinos continúa, hay muchos modelos ofertados desde distintos fabricantes. El "azul", el "punta roja", el "uSDR", etc. Incluso hay un "clon" de los "clones", pues Manuel (DL2MAN) ha sacado su propia versión llamada (tr)uSDR que se vende en portales chinos tanto en formato kit como dispositivo armado.

Personalmente me fascina el concepto, lo encuentro muy versatil y habiendome familiarizado con el el firmware tiene el potencial para un número de proyectos afines.

Mientras tanto me tropecé buscando otra cosa con una versión extremadamente compacta, no tiene un nombre en particular por lo que lo llamo el (micro)uSDX. ¿Que tan pequeño?... muy pequeño... bastante mas pequeño que un handy de VHF/UHF Baofeng.

Luego de la compra, que coincidió con el año nuevo chino y cierto desbarajuste de las logísticas globales por la invasión de Ucrania finalmente lo recibí.

El resultado de las pruebas me indica que todo depende de que expectativas uno se genera, en función de que tan alto las ponga es mas o menos probable quedar decepcionado.

El precio es imbatible, mucho menos que cualquier modelo armado de uSDX. La especificación mas o menos la habitual para éste diseño aunque con muy poca información constructiva (circuito, manual, etc.). El portal Aliexpress donde lo compré indicaba que es para 40-20-15 mts con potencias de 0.1 a 5W.

Al recibirlo el paquete es la frugalidad misma, básicamente el transceptor sin ningún accesorio (ninguno) y con un papel que dice "consulte la reseña en el artículo del producto"... y no hay reseña alguna... (con excepción del conexionado de la entrada PTT/MIC y la salida SPKR).

Pero bueno, muy familiarizado con el diseño navegué con los menues standard del firmware QCX-SSB y encontré que los valores de fábrica son relativamente inusables, hay que modificarlos para que el aparto cobre vida (NR,AGC,ATT, ATT,ATT2,VOX,NOISE GATE en particular).

El sonido es el esperable en un parlante tan pequeño, tiene micrófono incorporado pero no tiene agujero para el mismo por lo que la voz suena un poco "apagada", Dafydd (Dav) Walters (M0WDV) me sugirió en el sitio de soporte para ucx groups.io (donde se discuten cuestiones de todos los modelos y variantes) que hiciera un pequeño agujero en la carcaza a la altura del micrófono, la idea tiene méritos si se lo va a usar en fonía (que no es mi caso). El PTT externo funciona bien (uno de los switches) tal como es estandar en el diseño uSDX.

Pero primer problema, al intentar usarlo en FT8 el PTT por entrada no funciona. Pude hacerlo andar en el modo configurando el control VOX (el que está inactivado de fábrica), hay que tener cuidado de subir el valor de NOISE GATE a 6 o 7 antes de activar el VOX, caso contrario con el valor de fábrica (2) el VOX se activa con el ruido de fondo y queda permanentemente activado. El firmware QCX-SSB no permite cambiar configuración en transmisión asi que se entra en un loop (queda en transmisión, al apagarlo está grabada la configuración por lo que al encenderlo vuelve a ponerse en transmisor, entonces no arranca ..). Superado el loop macabro y logrando que se haga un "reset" de parámetros a valores de fábrica logré hacerlo andar bastante bien en FT8.

Me llama la atención que el firmware deja seleccionar cualquier banda entre 160 y 6 metros, pero resulta que los filtros son solo para 40,20 y 15 por lo que en cualquier otra banda las espurias son monumentales y es riesgoso poner al equipo en transmisión.

Finalmente desarmé el aparato exponiendo su interior, son dos placas en sandwich muy pegadas entre si y a su vez muy pegadas a las tapas de la carcasa. La construcción parece muy deficiente y desprolija. Los toroides están flojos, los switches tenían un falso contacto y tuve que repasar las soldaduras y lo mismo con el conector de 12V pues al moverlos tenían comportamiento errático. Finalmente solucioné la falta de PTT tirando un cable desde el switch de PTT (que si anda) al pin correspondiente del jack MIC/PTT con lo que quedó andando muy bien (tanto en VOX como en PTT externo).

Tuve que armar un pequeño arnés para combinar la señal de PTT/Manipulador externo con la de MIC, agregar un cable 3.5 mm stereo macho-macho y una fuente 12V@4A que uso para éstas pruebas. También tuve que agregar un acoplador SMA(m)-BNC(m) para poder acoplar a las antenas. El conector de antena luce fragil y su soldado interno lo es mas aún, es aconsejable conectarle la antena con un cable bien flexible que no aplique torque sobre el conector.

Para mas seguridad agregué cinta aislante bajo los pines de la placa que pudieran estar en riesgo de hacer corto contra ella, en particular los de RF de salida y los de alimentación de 12V.

Internamente tiene los conectores para programarle otras versiones de microcódigo pero sin pines, es posible que buscando con el suficiente empeño se encuentre como entrarle con una linea CAT a nivel TTL. No tiene batería ni espacio para ponerla dentro de la carcaza.

No hice aún contactos en CW pero si hice varios en FT8. La potencia de salida (todavía no le ajusto los parámetros del firmware) está en el orden de 300-400 mW sobre una antena dipolo rígido, es una potencia adecuada para un trabajo casual en FT8 y local en CW. Es un tema que hay que seguir investigando, pero no me quedaron muchas ganas de aumentarsela porque los transistores de salida no tienen disipador, mucha eficiencia de clase D/E, pero sin disipador no creo que sea sensato tratar de sacarle mucho mas de 1W a 4 transistores FET de baja señal como el BS170.

Todavía queda bastante para experimentar pero la primer impresión, como dije antes, depende de lo que uno esperaba. Conociendo el diseño en hardware y software e incluso conociendo lo comprometido del diseño del QCX-Mini para entrar en una forma mucho mas pequeña (y siendo éste MAS pequeño que un QCX-Mini) sabía que seguramente habían tenido que realizar muchos compromisos. No tener batería, probablemente cuidado con la potencia. La construcción pésima y el control de calidad peor no lo contaba, en parte se explica por el precio.

En resumen, creo que no es un aparato para iniciados o quien no tenga ganas de abrirlo para reparar y experimentar, aún así bajo esas condiciones de bajas expectativas su precio bajo y su factor de forma miniatura lo hace atractivo.