viernes, 17 de febrero de 2023

ARRL DX CW 2023

 

Se viene en éste fin de semana el concurso internacional ARRL DX CW edición 2023 organizado por la ARRL. Éste concurso es uno de los mas importantes en el año, tanto por significado histórico, por nivel de convocatoria y también por otorgar puntaje para un número de eventos, entre ellos el WRTC.

Como siempre que hay un concurso cada uno se prepara como mas le gusta o le ha dado resultado.

A mi me ha dado resultado tratar de hacer pronósticos, siquiera aproximados, de la propagación con los que planear en que banda voy a participar. Una vez hecha esa elección el pronóstico me dá una idea de como planear los momentos de actividad, las paradas y los descansos.

Siendo un concurso de 48 horas, cuyo objetivo es comunicar con la mayor cantidad de estaciones de USA y Canadá, su duración está fuera de mis posibilidades reales de una participación completa en modo "single operator" por lo que seguramente hará una elección de "single band", ésto hace que se pueda aspirar a un resultado competitivo con una cantidad menor de horas de participación.

Para quienes participen en "multiband" o estén planeando una participación "multioperador" el pronóstico puede ayudar a planear los cambios de banda y la cantidad de operadores que deben estar disponibles.

El pronóstico es realizado con el método de analizar la frecuencia relativa de los spots en DX-Cluster como un predictor de nivel de actividad y por lo tanto de propagación, ambas cosas no son lo mismo pero es una necesaria aproximación.

El método lo he utilizado en los últimos 10 años por lo que puedo evaluar que pronostica con razonable aproximación el comportamiento de las bandas como para ser una herramienta útil de planeamiento, el resultado en el concurso mismo es por supuesto otra historia que depende de muchos factores. Sin embargo siempre es necesario hacer la aclaración que muchos operadores simplemente encienden su radio y participan "leyendo" la propagación tal como la encuentran.

La propagación es un fenómeno aleatorio que involucra energías de escala cósmica y cuyos mecanismos son comprendidos solo en forma superficial, por eso es probable que cualquier pronóstico esté equivocado, aún así algunos serán útiles y espero que éste lo sea.

La lectura es sencilla, las frecuencias se calculan relativas a cada banda con la actividad en la misma dentro de las 24 horas consideradas lo que dá la frecuencia denominada "mejor hora para la banda", ésta indicación será de interés a quienes participen en "single band", los colores en la gama del verde implican buenas condiciones de apertura mientras que la migración al rojo indican ausencias de propagación, siendo los amarillos y ocres estados intermedios.

Para los que participen en modo "multibanda" el cuadro que seguramente representará mas interés es el denominado "mejor banda para la hora", la frecuencia se calcula en éste caso entre todos los contactos de una determinada hora entre todas las bandas, obteniendo la que tiene mayor intensidad en esa hora. La representación de colores es la misma que en el caso anterior.

Para calcular las frecuencias se usa una mezcla entre los spots del Reverse Beacon Network y los del cluster manual el que en mi caso es el de Rick (LU9DA) (proporción 70-30%) usando reportes en éste caso hechos o indicando estaciones LU-CX con K-VE.

El pronóstico tiene sesgos importantes que deben ser comprendidos. El primero y principal es que, como se dijo, la propagación es un fenómeno aleatorio. Pero mas alla de eso también pueden ocurrir diferencias entre distintas semanas (éstos datos reflejan spots colectados el 11 y 12 de Febrero) respecto a las zonas solares con perturbaciones geoactivas. Finalmente, el componente social de la propagación, puede haber condiciones electromagnéticas pero ocurrir en horarios en que no hay operadores para aprovecharlas. Esto último es menos probable que pase en un concurso grande como el que nos ocupa, por lo que el pronóstico tiende a ser mas confiable en bandas altas (diurnas) que en bandas bajas (nocturnas).  

El concurso es una actividad de radio, en el que la gente participa para entretenerse o divertirse, ojalá que sea divertido para todos y que todos los que participen alcancen sus objetivos, cualesquiera que éstos sean.

martes, 7 de febrero de 2023

Proyecto ADX-rp2040


En la entrada anterior compartí la historia inicial del proyecto ADX-rp2040, naciendo como una evolución de mejoras para el firmware ADX original, el darse cuenta que la arquitectura Arduino no permite grandes agregados, la búsqueda de un reemplazo utilizando el Raspberry Pi Pico (rp2040) con ese propósito y los esfuerzos para generar una versión común para ambos.
El esfuerzo resultó esteril en cuanto a resultados por lo que terminé con cierta frustración luego de varios meses de trabajo. 
Pero a poco de pensar sobre la cuestión me di cuenta que era solo una cuestión táctica sobre el camino elegido (que resultó incorrecto) y no estratégica (utilizar un procesador rp2040).
En efecto, la plataforma rp2040 que mueve la placa Raspberry Pi Pico es un orden de magnitud mas poderosa que la plataforma Atmel328p que mueve la Arduino; carece entonces de sentido hablar en términos de agregar funciones que no entran bien en una placa (o directamente no entran) y tener que restringirse en las dos placas con una implementación híbrida cuyoo único propósito es mantener compatibilidad.
La esencia del proyecto es contar con un transceiver "simple" para HF que sea capaz de operar en FT8 (u otros modos digitales de baja señal) siendo alimentado por el audio generado por el programa WSJT-X (u otro similar) corriendo en una PC convencional.
Como comenté en la entrada anterior la portabilidad del código se logra adoptando las librerías de Earle Philhower (ver entrada anterior) denominado tambien "Arduino pico core" por lo que el firmware de ADX compila con modificaciones muy menores para el procesador rp2040.
Hay solo dos modificaciones significativas, ambas devienen de diferencias en la arquitectura de hardware. Una, la ausencia de EEPROM en el rp2040, tiene una solución mas o menos a mano, las librerías del Arduino pico core preveen formas de emular memoria EEPROM en memoria Flash (con algunas limitaciones) de tal manera que las instrucciones relacionadas con EEPROM compilen y operen correctamente. La segunda diferencia, mucho mas significativa, es la ausencia de una interrupción que permita contar cruces por cero de una señal analógica en el rp2040.
Eso afortunadamente estaba resuelto desde el "fallido" proyecto PDX, y de cuatro formas diferentes, por lo que solo era cuestión de elegir.
Y en efecto, como parte de una filosofía diferente en el cual muchas opciones eran alternativamente incluidas o excluidas mediante configuración, esta implementación hace estrictamente lo que hace el firmware original del ADX (tomando como base el correspondiente a ADX_UnO_1.1) sin alternativas u opciones de ningún tipo, con la excepción de aquellas partes del código que debían cambiarse por diferencias de arquitectura. La razón para tomar la versión de firmware ADX_UnO_1.1 en lugar de la previamente adoptada ADX_QUAD_V1.1 es que el primero tiene menos dependencias de hardware al no tener que soportar la placa QUAD (multibanda) e implementandose en un diseño monobanda, el cual es mas simple. Eso lleva a un código extremadamente simple, tan conciso como el original de ADX. Se sigue requiriendo adaptar el método de conteo de frecuencia, central al funcionamiento del firmware, para lo cual se toma ventaja de una característica única de la arquitectura rp2040 que consiste en disponer además del procesador principal (de dos nucleos) de 16 procesadores RISC independientes (PIO) capaces de almacenar programas cortos (firmware) pero potentes especializados en operaciones de I/O. Ese firmware se "carga" automáticamente a poco de arrancar el procesador mediante una serie de instrucciones especiales. Esos procesadores a traves de ciertos recursos de comunicación entre procesos pueden interactuar con el código principal De esa forma un procesador PIO (Peripherical I/O) se encarga de medir el tiempo entre pulsos consecutivos en la entrada para que luego el programa principal con una cuenta simple pueda calcular la frecuencia y con ello operar las etapas de RF para lograr la síntesis directa de la señal PSK.
El código resultante lo denominé ADX-rp2040 (sitio Github) y mi compromiso es mantener al mismo con funcionalidades similares al ADX de base operando en la plataforma Arduino, pero sin funciones adicionales (bueno, no muchas mas al menos). 
La única diferencia a ese criterio es que  el firmware ADX tiene una función de "calibración" del DDS (Si5351) que permite con la ayuda de instrumentos establecer cual es la corrección que debe realizarse en un chip en particular para que su frecuencia se exacta, la diferencia puede ser de unas pocas decenas de Hz. El ADX logra eso colocando una salida del Si5351 (CLK2) no utilizada con otro propósito en 1 MHz, y luego ir manualmente variando lentamente la frecuencia hasta que externamente se detecte que la frecuencia es realmente 1 MHz, a la corrección necesaria para lograr esa condición se la graba en EEPROM y se la aplica cada vez que arranca el código. En ADX-rp2040 es mucho mas facil directamente medir la frecuencia del CLK2 con el procesador rp2040 (dada su mayor potencia) por lo que no son necesarios instrumentos externos, simplemente en modo calibración el firmware puede hacer toda la operación e ir realizando las correcciones de manera que el error sea +/-2 Hz en forma automática.
Ahora bien, el firmware es todo lo parecido al original de ADX que es materialmente posible, pero el hardware tiene que ser modificado respecto a una placa ADX para funcionar correctamente.
La principal diferencia es obviamente que el Atmel328p y el rp2040 no son compatibles pin por pin, por lo que hay hacer un ruteo general de puertos. La segunda diferencia es que la placa Arduino se alimenta con +12Vcc y un regulador interno provee los +5Vcc para que opere el procesador, esa misma tensión es aprovechada para que el resto de la lógica de la placa funcione pues su consumo es suficientemente bajo para que eso sea posible. El rp2040 funciona con +3.3Vcc y debe ser alimentado por +5Vcc por lo que es necesario un regulador de tensión externo para bajar de +12Vcc a +5Vcc y de alli alimentar al procesador. Finalmente, los puertos de I/O requieren lógica de +3.3Vcc y no de +5Vcc, por lo que hay que tomar medidas para que no lleguen tensiones incorrectas, afortunadamente los tres botones push que tiene la placa ADX pueden ser alimentados con "pull-up" interno con lo que con solo no poblar las resistencia externas de pull-up. Finalmente, la forma de contar frecuencia se beneficia mucho con disponer de pulsos mas netos (mas "cuadrados") que la señal de audio senoidal, de esta forma pasado un umbral se hace innecesario la calibración de los niveles de medición y para ello por lo que se utiliza un comparador con ese propósito de forma que la señal sea encendido o apagado en forma neta. En realidad se usan dos, seleccionables, uno simple basado en MOSFET y otro mas sofisticado basado en comparador. Ambos funcionan muy bien.
Finalmente está la tarea de construir el transceiver. Obviamente que puede encararse como un proyecto de complejidad media simplemente cableando las conexiones de todo el circuito; pero uno de los grandes atractivos del proyecto ADX es su simplicidad, la que en buena medida se basa en disponer de una placa de circuito impreso relativamente económica que se puede mandar a fabricar para luego simplemente poblar unos cuantos componentes mas o menos simples y tener un circuito que salvo errores mayores sale andando siempre. Está también la cuestión de contemplar a quien ya tiene una placa ADX, realmente no tiene gran incentivo para construir una placa como la necesaria para operar el firmware ADX-rp2040 para hacer mas o menos lo mismo que puede hacer con el ADX. Obviamente que la solución de fondo es hacer una placa completamente nueva que evolucione desde la ADX original con los cambios necesarios. Pero al mismo tiempo al ADX-rp2040 es un primer paso en un proyecto mas ambicioso y por lo tanto es probable que vaya mutando con el tiempo. Resultó una idea interesante hacer una "placa-hija" (daughterboard) como la mostrada en la foto, donde toda la circuitería adicional se solucione en ella y que presente un pinout idéntico al del Arduino Nano. Por lo que es posible enchufar la misma en una placa ADX estandar y operar el firmware ADX-rp2040. Es decir una forma de acceder al nuevo procesador y eventualmente a su camino de evolución protegiendo el trabajo hecho hasta el momento con la placa ADX. El diseño de esa placa lo realizó Barb (WB2CBA) y los archivos de diseño para su construcción (Gerber) se encuentran disponibles en el sitio GitHub del proyecto ADX-rp2040.  Si luego, en el tiempo, el diseño prospera y se estabiliza quizás exista una masa crítica de interesados en una placa que sea nativa del rp2040, lo que implica sacar el diseño circuital del Arduino Nano y agregar lo que tiene la placa original del daughterboard (¿ADX+?).
El proyecto empieza a tomar forma, lo suficiente para poner manos a la obra y comenzar la siguiente fase, el RDX.




lunes, 6 de febrero de 2023

Habíase una vez .... El comienzo del ADX-rp2040

 

En entradas anteriores comenté distintas alternativas del proyecto ADX cuyo autor es Barb (WB2CBA), empezando por su estudio e implementación iniciales, luego modificaciones a su firmware para finalmente explorar los límites de la placa en frecuencias superiores a las originalmente concebidas por su autor. Es un proyecto muy interesante con el cual tuve la oportunidad de hacer varios experimentos, los que oportunamente fueron documentados en entradas previas de éste blog.
Al introducir nuevas funciones o modificaciones de las anteriores en el firmware fui también modificando el "estilo" base en el que está escrito, simplemente por una cuestión de experiencia sobre que constituye código robusto y que no lo es. Al mismo tiempo fui agregando funciones que objetivamente creía conveniente realizar. Aplicando prácticas mas o menos establecidas de evolución de productos e integración de funciones tuve la precaución de codificar las modificaciones con una técnica llamada "control de configuración" donde el código puede modificar su comportamiento en función de directivas externas en tiempo de compilación. De esa manera incluyendo una directiva del estilo de "#define CAT 1" puedo hacer que todos los segmentos de código relacionados con la implementación del CAT sean incluidos o excluidos. Haciendolo con todas las modificaciones es posible ir agregando las distintas funciones una por una y en cualquier orden sin que interaccionaran entre si, condición que técnicamente recibe el nombre de "alta cohesión y bajo acoplamiento" de funciones. El resultado es un código mas extenso y mas complejo, no solo porque hace mas cosas sino porque también existe una infraestructura de código para gestionar las alternativas de configuración. Habiendo puesto el código resultante en el dominio público (como ADX_QUAD_V1.5) encontré rápidamente que había un inconveniente fundamental. Hay demasiadas versiones de firmware independientes entre sí, sin la mas minima coordinación entre sí; situación que rápidamente hace que las funciones sean incompatibles entre si y que no se sepa cual hay que tomar de base para agregar alguna función. Al mismo tiempo, y casi completamente en dirección opuesta, los usuarios habituales de la plataforma ADX no apoyaban el incremento de complejidad y preferían claramente un código relativamente escaso en funciones pero pequeño tal como el original de ADX. Llegué entonces a la conclusión que no valía la pena el esfuerzo de trabajar en una versión mas grande y compleja, que agregaba funciones que no siempre eran entendidas para que (pues el firmware original no las tiene) y que además no era tenida en cuenta como base para agregar nuevas funciones, debido a ésto último no justifica el esfuerzo de trabajar en una cosa así. 
En realidad esa versión se trataba de una función de referencia no ya para que fuera utilizada por toda la comunidad ADX existente sino que además era la plataforma para plantear la migración a un procesador mas potente.  El procesador elegido es el ARM rp2040, corazón de la placa Raspberry Pi Pico. 
Siendo que se trata de un procesador casi un orden de magnitud mas potente que el original del Arduino
En efecto, al agregar unas pocas funciones al firmware original ADX rápidamente se llega al límite de memoria que puede manejar un procesador Atmel328p, corazón del Arduino Nano, por lo que es dificultoso agregar mayor complejidad (mayor cantidad de código). Por lo que por mas que las funciones se agreguen incrementalmente deja de tener sentido una base común si lo fundamental solo funciona en una plataforma. Es una manera de limitar o restringir, artificialmente, ambas.
Se intentó hacer un esfuerzo mancomunado para "portar" el código de referencia ADX_QUAD_V1.5 a uno nuevo, denominado PDX (Pico Digital Transceiver) el cual esencialmente requiere una placa igual a la ADX pero con una placa Raspberry Pi Pico en lugar de una Arduino Nano, todo el resto idéntico.
El esfuerzo, significativo, implicaba no solo lograr que el firmware ADX pudiera funcionar en un procesador distinto, con una arquitectura distinta sino que en su esencia se mantuviera un solo código para ambas placas (ADX y PDX).
El firmware ADX está desarrollado utilizando el Arduino IDE (Integrated Development Environment) mientas que el ambiente de desarrollo para Raspberry Pi Pico está basado en el IDE Eclipse utilizando un conjunto de librería llamados el Pico-SDK (Software Development Kit), ambos incompatibles como habría de suponerse.
Eso se superó parcialmente gracias al enorme trabajo de Earle Philhower III, quien creo una serie de librerías (link) que una vez instaladas en un Arduino IDE (instrucciones) permite compilar indistintamente para un Arduino a para una multitud de placas basadas en el procesador rp2040. 
El nivel de implementación es excelente, la mayor parte de la librerías que funcionan en Arduino también lo hacen bajo éste ambiente, aunque hay algunas variantes en aquellas caracteristicas que son diferentes entre un Atmel328p y un rp2040 a nivel de hardware.
Una diferencia en particular es que la forma de medir la frecuencia en el firmware ADX utiliza interrupciones y comparadores en hardware que el rp2040 no tiene, por lo que no es directamente portable.
La solución fue bastante trabajosa e implicó desarrollar en forma independiente cuatro diferentes formas de realizar la medición de forma de medir cual es la mejor; siguiendo con las caracteristicas de configuración mencionadas los cuatro métodos podían ser configurados independientemente.
Este enfoque de trabajo implica una coordinación muy precisa pues cualquier modificación para una arquitectura tiene que ser propagada para la otra, y teniendo en cuenta que un firmware está difundido y el otro está en desarrollo implica en ocasiones liberar en forma desbalanceada (incluir una modificación selectivamente en una plataforma y no en la otra). El esfuerzo para hacer eso es enorme.
Por su parte todas las nuevas funciones que se agreguen en la nueva plataforma (PDX) requiere un cierto grado de "retrocompatibilidad" a las correspondientes en el firmware "base" (ADX). Por ejemplo, rápidamente surgió para que ponerle LED o "push button" toda vez que la nueva placa probablemente tuviera un LCD TFT display, sin embargo sin ellos el ADX no funciona.
El proyecto entró en un circulo vicioso, por un lado la comunidad existente ADX no convergía a utilizar al versión 1.5 del firmware para ninguna actividad y la comunidad desarrollando el PDX no veía la
necesidad (y el esfuerzo adicional) de mantenerse compatible con ADX, generandose continuamente segmentos de código en violación a esa condición, completaba el escenario cierta disfuncionalidad en los acuerdos de metodología de trabajo entre el grupo de desarrolladores.
La situación se hizo insostenible, y luego de no pocas frustraciones anuncié entonces que retiraba del dominio público a la versión ADX_QUAD_V1.5, cosa que hice efectivamente y también discontinué todo el código desarrollado para PDX hasta ese momento (el cual mayormente tenía contribuciones mias).
Pero, el proyecto era demasiado lindo para terminar así, y había invertido una cantidad enorme de tiempo para llegar a ese punto. Juntando los pedazos nació el proyecto ADX-rp2040, pero eso es historia para la próxima entrada.