"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.

ARRL International DX 2022

Se viene el ARRL International DX 2022, uno de los torneos de radiosport mas importante del año, tanto en antiguedad como magnitud de concurrencia, típicamente es parte de la clasificación WRTC 2022 también. Por la naturaleza de sus objetivos puede considerarse un "work USA" o un "US Open" si se asimilara a una competencia de tenis, en cuyo caso también sería un torneo de "gran Slam".

He participado muchas veces en diferentes categorías y no termino de encontrar una que me convenza completamente. La categoría que mas me gustaría sería SOSB10(U) QRP o LP, la cual desafortunadamente no existe. Las categorías que segmentan por potencia son todas "All Band" y las categorías "Single Band" mezclan todas las potencias juntas. Es decir termina siendo un equilibrio entre la cantidad de horas a participar y el tipo de competitividad que se tiene. Con una participación "Single Band" se puede tener un resultado competitivo a nivel continental con 8 a 12 horas de participación, el equivalente para "All Band" es fácilmente el doble, quizás mas incluso. Cada uno tiene entonces que definir que es lo que quiere, pero también lo que puede en términos físicos, familiares, sociales o incluso de motivación.

Como muchas veces he compartido en éste blog en el pasado, considero el planeamiento previo al concurso una parte importante de la preparación, y porque no del atractivo, que se obtiene. Es una tarea de evaluación, que tiene mucho de empírica y vivencial, pero que da una pauta de cuales serán las condiciones de propagación que se encontrarán, en que banda o bandas es mejor participar alineado con el deseo de invertir horas de competencia e incluso que estrategia de participación en términos de categoría es la mejor.

Por supuesto que hay operadores que no necesitan tal preparación, simplemente encienden en lo que entienden puede ser el mejor momento y mediante exploración de las bandas interpretan la propagación y actúan en consecuencia.

Con márgenes amplios de variación, pues después de todo se trata de pronosticar un fenómeno que involucra energías de escala cósmica que operan prácticamente al azar, tengo suficiente evidencia que el marco de la investigación previa de no mediar un evento solar significativo dá un pronóstico adecuado de aperturas e intensidades, suficiente para un planeamiento previo. Luego, con ese planeamiento previo se lo confirma durante el concurso.

Hay dos enfoques que he utilizado con bastante buenos resultados, uno es el basado en modelos de predicción de la propagación, VOACAP por ejemplo.

Para un circuito Argentina-USA (tomando Denver,CO) como centro de USA, se observa el pronóstico para las distintas bandas usando antenas direccionales y con 100W de potencia en CW, en general por experiencia se obtiene buenas condiciones cuando la probabilidad es superior al 70-80%. 

Otro enfoque es utilizar datos de comunicados reales en las distintas bandas y mediante el conteo de frecuencia de esos contactos asimilar la existencia (o no) de condiciones y la fortaleza de las mismas, asumiendo que mas contactos implica mejores condiciones. Hay varias fuentes para éste tipo de análisis y con el tiempo he utilizado, con distinto grado de éxito a todos ellos.

Por supuesto la fuente primaria es el tráfico de DX-Clusters, aunque encuentro que los reportes son algo erráticos y depende tanto que el contacto exista como que alguien se tome el trabajo de generar el "spot". Un poco mas ajustado es utilizar el Reverse Beacon Network (RBN) cuyo reporte es automático, aunque sigue dependiendo de dos estaciones haciendo un QSO que sean reportados, dependiendo del horario puede haber buena propagación pero no participantes, propagación social por llamarlo de alguna forma. Finalmente el sistema Weak Signal Propagation Report (WSPR o "whisper", susurro) forma una red global de estaciones "baliza" y "receptoras" completamente automática. Con su inaudita capacidad de tomar señales cuya relación señal-ruido (SNR, Signal-to-Noise-Ratio) cercanas a -30 dB (30 dB por debajo del ruido en un canal de fonía) puede capturar aperturas ínfimas que hasta quizás no son usables en otros modos, con la posible excepción de FT8. Sin embargo es bastante facil "corregir" los reportes sabiendo la potencia de la baliza (que es indicada en el mensaje) y sabiendo que una estación en LP emitirá con al menos 100W (típicamente 20-26 dB mas que la baliza), se completa el ajuste sabiendo que el piso de CW está entre -5 a -10dB de SNR dependiendo de la habilidad del operador, por lo tanto si el reporte WSPR +25dB da -5dB o mas el canal también es válido para CW. Todo con muchos supuestos, muy aproximado, pero funciona.

Entonces tabulando los reportes se sabe cuantos contactos hay por banda en cada horario, cual es su margen de señal y como comparan las bandas entre si, con lo que puede obtenerse la mejor banda para la hora (para orientar a quien opera all band) y la mejor hora para la banda (para orientar a quien opera single band en una banda en particular). En la tabla adjunta se encuentran ambos análisis y el coloreado ayuda visualmente a saber los mejores momentos pronosticados, cuanto mas verde mejor, cuanto mas rojo peor.

Pero todo es preparación, la verdad se dá en el transcurso del concurso, donde hay que ir ajustando de acuerdo a lo que se encuentre, aunque en general es difícil pasar de una participación single band a all band luego de varias horas de participación.

Sea que se elija lo uno o lo otro, hay que pensar en encontrar la mejor forma de divertirse, que cada uno le entre al concurso como mejor le sirva y mas placer le de. Para eso son los concursos. Para eso es la radio.

Keyer 3D para portatil

 

Por mucho tiempo el mini-paddle de CW MFJ-561 ha sido parte de mi estación. Es muy pequeño y práctico, ideal para acompañar una estación portatil. Por cierto que no le dá para grandes velocidades pero cumple su papel.

Con la incorporación de varios equipos portátiles se plantea la utilidad de tener otro keyer por lo que empecé a mirar diseños en Internet y encontré que en YouTube las estaciones que hacen salidas desde exteriores (outdoor, POTA, SOTA, IOTA entre otros) suelen utilizar un diseño de keyer muy pequeño. Siempre he preferido tener keyers grandes y pesados, para que no se mueva mientras transmito ni tener que sostenerlo. Pero observé que la técnica es tomar el keyer en un puño y manipular con la otra mano. Para hacer eso tiene que ser pequeño y liviano.

Encontré varios diseños en The Thingiverse, por ejemplo éste de iambic paddles que me pareció lo suficientemente parecido a lo que necesito y lo suficientemente simple como para intentarlo, no me entusiasman los proyectos con base mecánica por cierto, pero en éste la mayor parte lo hace la impresora 3D.  

Bajados los archivos de diseño gráfico (.stl) imprimí primero las dos paletas y luego la caja, lo hice para poder utilizar colores distintos de hilo plástico. Mi impresora, una ANET A8 es posiblemente la mas básica, y si bien mas que cubre mis necesidades no permite lujos como impresión en mas de un color al mismo tiempo.

En general encuentro que con la calidad de mi impresora puedo hacer diseños que requieran una precisión mayor a 0.1 mm y cuyo acabado no sea crítico. Hay impresoras mas costosas que tienen mejor comportamiento en ambos aspectos, pero no se justifican a mi juicio para un uso hogareño y de proyectos relacionados con un hobby.

Utilizo extensivamente la impresora 3D para usos de aficionado en la construcción de accesorios y gabinetes, mas que cumple su función y es realmente económico darle una finalización muy buena a los proyectos con una fracción del esfuerzo que hubiera significado plantear un gabinete en metal, supuesto que la configuración del aparato en cuestión fuera posible con las herramientas que dispongo (por no hablar de la habilidad). Por ejemplo, toda "ventana" de tipo "cuadrada" en un gabinete es una penuria en gabinetes metálicos mientras que es trivial en un diseño con impresora 3D.

Los diseños que hago son tan básicos que me sobra una herramienta online llamada TinkerCad, originalmente usaba esa herramienta para emular placas Arduino y hacer debug del código; pero ahora que programo poco en Arduino uso bastante el sitio para los diseños 3D. Realmente tiene una interfaz y herramientas intuitivas, varias formas comunes pre-definidas y permite tener una biblioteca de componentes comunes. Mas que adecuado.

Supongo que tengo que trabajar un poco para que la operación sea mas firme, pero en principio quedó andando rápidamente. Como todo proyecto, no se puede considerar completado sin la correspondiente ceremonia de bautismo en el aire, y allí fui!

Portatileando por MDQ

 

Parte por restricciones, parte por precaución y otra parte por sentido común la situación de pandemia provocó la reducción de los viajes y las salidas de fin de semana para activar portátil.

Sin embargo, al mismo tiempo aportó la posibilidad de poder trabajar en el armado de equipos, antenas y accesorios para cuando fuera posible. 

He bromeado bastante con que la pandemia permitía activaciones GOTA (Garden On the Air), émulo hogareño del mas sofisticado IOTA o SOTA.

En un viaje reciente a la ciudad de Mar del Plata, conocida también por sus siglas MDP o por el identificador de su aeropuerto MDQ, me propuse explorar una configuración portátil lo mas minimalista posible para activar desde mi casa, un departamento en piso 10 (unos 35 metros de altura).

Y llevé al efecto varios equipos para probar, mas combinaciones de equipos y antenas que lo que el tiempo disponible permitió operar, como era de esperar.

Y tuve buenos resultados, por lo que quisiera compartir con que poco se puede tener resultados satisfactorios.

Para empezar la energía, no traje la batería recargable, que es pequeña pero pesada y claramente no es cómoda para viajar con ella o cargarla. La reemplacé por una fuente switching de 12V@3A, dado que opero con potencias bajas es mas que suficiente. También utilizo un "peine" de bocas USB que se alimenta desde 220V (12 bocas), toda la estación opera en realidad con 5V con excepción del transceiver.

La antena es una variante "clon" china de la MFJ-1899T (que también tengo) la que tiene la ventaja de ser bastante mas robusta y terminar en un conector PL-259, el que es mas apropiado para sostener la antena de mas de dos metros de altura que el conector BNC que tiene la MFJ. Con la impresora 3D hice un bloque de adaptación muy simple, un formato en "U" acostado que permite poner la antena en el tope y un bulón de sujeción en su piso, el conector donde va la antena se completa con un conector BNC a 90 grados y una toma de tierra para el counterpoise, el conector BNC no hace ningún esfuerzo en ésta configuración. Lo completo con un trípode de fotografía (económico) aunque podría ajustarse a cualquier perfil tipo ventana o mesa con una prensa tipo G mini, la que tiene la ventaja que es mas facil de transportar que un trípode.

El equipo es el uSDX, aparato que he comentado previamente y que tiene una performance mas que aceptable a pesar que sus usuarios se quejan un poco. Creo que básicamente es un problema de expectativas, siendo una fracción muy menor del costo de un equipo convencional su performance es una fracción mayor que la relación de costos. Pero no hay que caer en la ingenuidad de compararlo con equipos robustos de 10X su precio o mas. La performance es aceptable en recepción y la potencia de salida es cercana a los 5W en bandas altas y cae a algo menos de 1W en 10 metros, principal motivo de quejas en los usuarios, en particular del creador original del diseño Manuel (DL2MAN) quien sigue quejandose que lo hicieron sin su permiso y no deja pasar oportunidad de remarcar lo mala que es la copia.

La antena necesita un sintonizador, y en la configuración portatil uso dos, lo que no es del todo recomendable porque cada uno agrega pérdidas. El primero es un sintonizador automático ATU-100 y el segundo un sintonizador manual básico de QRPGuys.com. Con el segundo basta para sintonizar la antena con el medidor de Potencia/ROE incorporado en el uSDX, pero el segundo facilita la sintonía y agrega la eficiencia de carga.

Completa la configuración una Raspberry Pi 4 cargada con todo el software necesario en una estación de radio, la interfaz es un soundcard USB y un keyer de construcción casera con un puerto serie USB y un adaptador hecho en casa con un opto-aislador. Completan el "cablerío" un necesario transformador para aislación galvánica entre la placa de sonido y la entrada/salida de audio de transceptor. Los principales programas que uso son FLDIGI, FLRig y WSJT-X, todos compilados desde fuentes para el Raspberry Pi.

Podría operar en fonía, escuché con buena señal a estaciones de un radio de 500 Km en 40 metros y simplemente con el micrófono podría haberlo intentado, pero me concentré en CW y FT8 tanto en la banda de 20 metros como 10 metros.

Los mejores resultados los obtuve en 10 metros, donde en FT8 hice contactos o fui escuchado en todo el continente americano, África (Canarias) y Japón. En CW escuché y contacté con estaciones de USA con señales reportadas para mi bajas pero suficientes para completar un contacto.

Completa la configuración un handy Baofeng DM-5R y un hotspot basado en una Raspberry Pi Zero corriendo el software pi-star, con la que puedo estar en contacto tanto en VHF/UHF local mediante el uso de una antena simple en el balcón como a nivel global mediante los "Talking Groups" de DMR. La huella de la estación es ínfima, uso un pequeño adaptador de USB a 12V (es decir con un conversor USB obtengo 12V) que es suficiente para activar el cargador del handy. Operar en DMR se hace con potencia muy baja y la operación local depende del corresponsal, pudiendo cubrir por la altura de la ubicación a la mayoría de los corresponsales en directo con baja potencia.

Hay algo de "desperdicio" en tener dos placas Raspberry Pi para correr una estación supuestamente minimalista; con bastante trabajo se puede hacer correr pi-star en una Raspberry Pi 4 "full" pues realmente no consume demasiados recursos, pero la instalación "standard" del paquete pi-star es muy minimalista y "cerrada", pensada para bajar la imagen y que salga andando, para hacerla correr en un ambiente mas grande hay que instalarlo partiendo de fuentes y eso es bastante mas complicado, por ahora no vale la pena, pero es algo para pensar a futuro.

El tiempo de armado y desmontaje de la estación es de aproximadamente una hora desde empezar al primer contacto y cabe un una mochila pequeña no muy cargada. En realidad podría, con un empaquetamiento mejor, caber en cualquier equipaje habitual en un viaje de negocios o placer, ciertamente como parte de una salida de fin de semana. Para una activación mas exigente, como por ejemplo un "outdoors" en algún parque o un SOTA creo que es en general apropiada pues si bien hay que llevar alguna batería el volumen no es demasiado mas grande.

La operación puede hacerse directamente contra la Raspberry Pi 4 usando el TV doméstico como monitor (casi cualquier TV moderno tiene entrada HDMI) y un pequeño teclado plegable BlueTooth; pero encuentro mas práctico acceder desde otra PC o tableta IPad usando SSH y VNC, para FT8 es ideal. Para CW la recepción es a oido, el uSDX tiene un decodificador incorporado herencia de los orígenes como transceptor QCX de su firmware, pero como todo decodificador no sirve de nada y tomar a oido termina siendo la mejor opción. Para emitir se puede usar tanto un pequeño manipulador lateral (MFJ) usando el keyer electrónico que tiene que transceptor o directamente utilizar FLDigi al efecto (lo que es mas potente).

Como en todos los aspectos de la radio la experimentación de usarlo fue muy divertida, pero lo fue mas el prepararlo, pensar que componentes convenía o no incluir así como construir cables y conectores especiales.

Pues de eso se trata, de divertirse.