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.
.jpeg)
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.
.jpeg)
