Guido (PE1NNZ) sigue sorprendiendo.... ¿porque no sorprende?

El kit OCX de Qrp-labs, diseñado por Hans Summers (G0UPL) es posiblemente una de las herramientas de experimentación mas completas y mejor logradas disponibles para radioaficionados hoy, para fundamentar un poco esa afirmación es necesario una disgresión primero.

Hace muchos años que la disyuntiva que enfrenta quien tiene gusto por la radio es u operar equipos comerciales muy completos (y costosos) cuya reproducción con herramientas y habilidades constructivas "normales" es virtualmente imposible. O su alternativa, hacer equipos funcionales pero con muchas menos capacidades, siempre que se dispongan de herramientas, instrumental y habilidad. Hay casos aislados de diseños que alcanzan complejidades del orden de las comerciales, pero requieren habilidades e instrumental inalcanzables para la mayoría, por no mencionar acceso a los componentes lo que no es facil tampoco en cantidades de menudeo. Y aún así casi nunca se alcanza el nivel de integración, tamaño y funcionalidad completa de un equipo comercial. Eso está cambiando, con la disponibilidad de sub-sistemas completos es posible armar equipos de cierta complejidad ensamblando sub-sistemas. Sigue siendo divertido, sigue siendo una tarea profunda y deliciosamente técnica, pero es mucho mas accesible con conocimientos e instrumental mas de terrestres. A eso hay que agregarle otra tendencia simultanea que es mover funciones de hardware a software, entonces muchas de las funciones pasan de realizarlas componentes dificiles de conseguir y calibrar a ... lineas de código. En proyectos anteriores de éste blog (como el PixiePi o el Pi4D) puede verse como un kit de transceiver QRPp de muy baja gama de complejidad puede aumentarse enormemente en sus prestaciones trasladando muchas de sus funciones a software y apalancando en procesadores modernos de mucha potencia y velocidad (como la Raspberry Pi Zero en éste caso) o proyectos donde todo el hardware es la placa misma, como el OrangeThunder también en éste blog. Pero la tendencia es visible por todas partes, no solo en los proyectos de éste blog, ni por cerca. Hay muchos proyectos donde a un transceptor, usualmente comercial, a todas luces obsoleto por ser de canales fijos en HF, se lo puede traer a la vida nuevamente con el agregado de una simple placa DDS y unas pocas modificaciones menores (algo de eso hay en la cocina, pero no he podido dedicarle tiempo al proyecto todavía). Toda ésta disgresión viene a cuento que la tecnología moderna permite volver a poner en las manos de los experimentadores el realizar aparatos útiles, funcionales, potentes y muy entretenidos para construir, modificar y operar. Incluso, con enormes posibilidades de experimentar mediante su modificación, con habilidades e instrumental razonable. Hay "eco sistemas" de construcción que están lentamente cambiando eso, un ejemplo claro es el proyecto BitX.

Esto nos trae de vuelta al kit QCX. Recientemente me referí a la delicia que fue construir su versión mas actualizada, el QCX-Mini. Pero me estoy refiriendo al kit original. Un kit es una experiencia muy linda porque permite construir, experimentar, aprender y operar con varios problemas (que al menos a mi no me dan placer) solucionados, tales como conseguir componentes, generar una PCB impresa o resolver problemas mecánicos. No conozco nadie que me haya dado un reporte malo de ese kit, tanto en la construcción como el uso. Y en el aire suena muy bien, he contactado con varios en el aire y son una maravilla. Se puede argumentar que es un kit monobanda y que es para CW, cosa que es cierta aunque en la práctica no lo veo tanto como una limitación. El agregar capacidad multibanda suele agregar muchas dificultades constructivas y hay veces que es preferible tener mas de un equipo. Tampoco es que todo el mundo sale en todas las bandas. Mis propias preferencias de operación confinan la mayor parte de mi actividad a tres bandas, 40, 20 y 10 metros. Para la comunicación ocasional incluso menos, 40 y 20 pues 10 metros es mas bien una banda concursera para mi. Por supuesto que algo en otras bandas, 30 metros la exploro siempre que puedo en FT8 por ejemplo. Pero es muy raro que salga en 12, 17 o 60 metros. Casi nunca lo hago en 80 o 160 metros pues tengo antena muy pobre o no tengo antena respectivamente. El kit es también un "sistema", es decir es un todo. Para llegar al transceiver andando hay que empezar por tener un diseño bueno (que no dé dolores de cabeza para arrancar y ajustar), tener todos los componentes, tener un sistema de armado muy logrado con detalles como secuencia de inserción para que un componente no sobrecaliente o moleste a otro, y por supuesto métodos de calibración. El QCX tiene todo eso.

Pero, .... es solo CW, insisten...... Bueno, para mi eso no es un problema, es mas bien una ventaja, mi operación en radio en HF es CW y FT8 mayormente, solo muy ocasionalmente hago fonía (distinto es VHF/UHF donde casi todo lo que hago es fonía aunque recientemente he hecho muchas pruebas en CW en 2mts y 70 cm con Alejandro (LW8DRU). Pero es solo CW, ... siguen insistiendo.

Entonces vino Guido (PE1NNZ), y pateó el tablero. Guido es un viejo conocido y experimentador holandés que nos viene sorprendiendo con pensamiento e implementaciones innovadoras, lo que hizo con el QCX y ahora voy a comentar con mas detalle lo viene avisando desde hace casi una década (!¡), pueden ver mi entrada en el viejo blog LU7HZ donde comentaba su muy innovadora propuesta de generar SSB mediante modulación de un PLL y su implementación, por entonces, en una placa Raspberry Pi.

Lo que hizo Guido es innovador y creativo, pero también revolucionario. El tomo el kit QCX como base, eliminó mas de la mitad de las funciones implementadas en hardware (hay mas de 80 componentes del kit que no es necesario insertar) y movió sus funciones equivalentes al firmware del kit. No solo hizo eso, sino que implementó su método de generación de SSB en el firmware de un ATMega328P (el procesador del QCX), de manera que en una muestra de exquisita destreza en programación logró que un procesador chico funcionara como procesador de señales, muestreara una señal de audio, aplicara las transformaciones necesarias para generar las fases I/Q de las señales y generó las señales para que el chip DDS que utiliza el QCX (un conocido SI5351) fuera modulado en frecuencia enviando las señales por el protocolo I2C a 800 KBps, simple, ¿no?. 

Entonces el QCX ahora no solo transmite en CW, también lo hace en SSB (USB/LSB), y ya que estamos porque solo es cuestión ahora de hacer las cuentas un poco diferentes lo hace en AM y FM. Por supuesto que al transmitir en SSB también lo puede hacer en modos digitales (PSK/FT8/RTTY). Y ya que estamos, pues es solo materia de controlar el DDS a la frecuencia correcta de paso lo libera de ser monobanda y puede salir en cualquier banda entre 80 y 10 metros. El OCX queda fuertemente "destripado" y es necesario hacerle algunos "jumpers" para lograr el resultado (ver fotos). Pero aún así la complejidad de la modificación es mucho menor que la parte del kit que no se construye. El firmware del QCX es reemplazado completamente,  el mismo está en el dominio público en el sitio de Guido en GitHub (link). Si bien es posible "pisar" el firmware del QCX con éste, para lo que hay que "hamacarse" un poco aunque no exageradamente mucho lo mas recomendable es comprar un ATMega328P vacío y grabarle el firmware virgen preservando el que vino con el QCX en primer lugar. Para grabar un ATMega328P hay muchas formas dependiendo de si el mismo tiene un bootloader o no (cuando uno lo compra virgen no tiene bootloader alguno), pero se puede generar un grabador de boot y del firmware por métodos simples teniendo dos placas Arduino, una placa Arduino y el QCX mismo o una placa Arduino y un circuito "ad-hoc". También se puede comprar un grabador especial, pero salvo que se quiera grabar muchos probablemente no se justifique. Este video del canal de Manuel Klaerig (DL2MAN) (link) muestra como es una posible forma de grabar el firmware usando una placa Arduino Uno como auxiliar. En realidad el lo hace para una placa llamada USDX creada por Barbaros Asoroglu (WB2CBA), pero esa pequeña sorpresa es básicamente una placa OCX reformulada de manera tal que los componentes del kit que no se usan no estén, y por lo tanto es mucho mas pequeña, pero es lo mismo funcionalmente que una OCX y de hecho el firmware de Guido es el mismo, es por lo tanto un transceiver multimodo y multibanda basado en un Arduino. Pero eso, eso es otra historia que les contaré cuando me lleguen las placas que pedí a China para construirlo. ¡La diversión hay que administrala después de todo!

El mini máximo de QRP Labs (QCX Mini)

 

En el aire solo se escuchan elogios y buenas señales del transceiver QCX, diseñado por Hans Summers (G0UPL) y el cual es comercializado en forma de kit por Qrp-Labs. Se trata de un transceiver para CW, mono banda, que puede configurarse en cualquier banda de HF que uno elija. El transceiver tiene un muy buen soporte en el foro correspondiente de QRPLabs@groups.io y se recibe respuesta con una velocidad que envidiarían mas de un soporte a clientes. 

El transceptor posee sintonía continua de toda la banda de telegrafía (de toda la banda, en realidad), dos VFO, keyer automático (con modo entrenamiento incluido), memorias, decodificador de CW, tiene la capacidad de funcionar como baliza de CW y WSPR. Completa la lista de facilidades el tener CAT (Computer Aided Tuning), poder conectarse a un GPS. El kit tiene un impresionante listado de agregados, accesorios y modificaciones; solo enThingiverse hay al menos media docena (ejemplo) de cajas para imprimir entre otros agregados. Hay incluso una modificación experimental para hacerlo funcionar en SSB-AM y FM (link) por medio de técnicas de SDR. 

Al mismo tiempo es un transceptor de buena performance, no es un diseño QRP de compromiso, utiliza técnicas de SDR para el procesamiento de la señal tanto para demodular como para filtrar la señal. Tiene por lo tanto muy buena selectividad y no funciona como un conversión directa como típicamente ocurre con los dispositivos QRP mas sencillos. 

 Todas éstas bondades mejoraron con el reciente lanzamiento del modelo QCX-Mini. Funcionalmente es igual a su antecesor (o hermano mayor pues no se ha discontinuado) pero aplica técnicas de construcción mas avanzadas para lograr un aparato de dimensiones muy reducidas, aproximadamente dos teléfonos celulares apilados. El resto de la funcionalidad es igual.

Para lograr semejante reducción y al mismo tiempo que sea un kit accesible la placa de circuito impreso ya viene pre-poblada con un importante número de componentes SMT (resistencias, capacitores e integrados).

Se empieza por construir el transformador toroidal principal, y luego la excelente guía de armado va progresivamente conduciendo la construcción en forma metódica gasta concluirlo. El kit completo consta de una placa principal y dos placas subsidiarias, una para el armado del control de sintonía/volumen y el otro para montar el visor LCD 16X2. 

El proceso de construcción termina con el ensamble de las tres placas y su fijación estructural. Una facilidad fantástica que tiene el kit es que incluye en su firmware las facilidades para sintonizar y ajustar el equipo, no necesita instrumental, la placa misma tiene todo lo necesario. Debido a eso el ajuste es muy rápido. Siempre me gustaron los kits, me permiten concentrarme en la parte que me gusta (la electrónica, el software, la operación) y me resuelve la parte que no me gusta tanto (el juntar componentes en ocasiones dificiles de conseguir sueltos, el armado mecánico, etc); tengo por lo tanto bastante experiencia práctica en ellos. Siempre falta algún componente, hay alguna instrucción poco clara o erronea, siempre hay algún defecto o algo que uno hace mal y siempre uno se da cuenta cuando lo termina que se olvidó de algo. Para que ninguna de esas cosas ocurran, o al menos sea menos probable que ocurran, el kit tiene que ser soberbio. Y éste kit lo es. El manual de armado tiene mas de 100 páginas, paso por paso, con diagramas, con fotos (usualmente en más de un ángulo), con "tips", con "ayudas" y con toda la explicación detallada de funcionamiento para que no solo se arme en forma "mecanicista" mediante una serie de pasos sino con detalladas explicaciones del circuito y módulos. Una belleza.

Al finalizar hice algunas pruebas, para ello lo conecté al manipulador lateral, a la fuente de 12V regulada de la estación, usé un parlante USB (no tiene parlante propio) y empecé a sintonizar. Justo estaba el CQ Russian Contest  asi que tenía muchas estaciones para sintonizar y alguna que otra para comunicar. Justo pude sintonizar a Osvaldo (LU3MAM) quien estaba participando en el concurso, muy bien tomado.

Un concurso es una buena forma de probar un receptor porque se pone en juego que tan bueno es en cuanto a su selectividad y capacidad de manejar un buen rango dinámico, por supuesto que el FT2000 con todos sus filtros avanzados y una antena direccional tomaba mas... ¡mas vale! Pero el chiquitín se defendía muy pero muy bien.

Quedan algunas cosas por repasar, quizás un ajuste mas exacto para extraerle todo el jugo, hacerle un keyer para la computadora, un par de conectores, quizás un par de accesorios con la printer 3D pero ya está. Muy conforme con la compra, deleitado con la construcción y satisfecho con la performance resultante!

El dragoncito habla nuevas lenguas

Hace bastante tiempo, en 2013 en mi antiguo blog lu7hz.blogspot.com, que he referido utilizar un transceptor Dragon SS301 en salidas portátiles. Se trata de un handy de 5W pep para banda ciudadana que es comercializado bajo varias marcas (Albretch, Magnum, Dragon, etc.);  también opera en AM/FM/SSB en banda de 28 MHz (10 metros) y con una modificación sencilla, pero que requiere soldado en el motherboard,  funciona en 24 MHz (12 metros). Es un diseño simple y su funcionamiento es referido en las redes sociales como "soberbio" o "una porquería" (link) casi con igual frecuencia. En mi uso práctico me ha dado prestaciones satisfactorias una vez que se tiene en cuenta sus ventajas, las que ayudan a compensar sus debilidades. Básicamente es un transceptor mediocre en performance en casi cualquier aspecto que se desee considerar, pero tiene el factor de forma y peso de un handy, por lo que es muy facil transportarlo. Y de hecho ese es el uso primario que le he dado y para el que me resulta satisfactorio, equipo portatil de muy baja huella de espacio y peso para llevar en viajes, con un tiempo de puesta en marcha muy rápido. La antena con la que viene provisto no sirve para mucho, excepto en rangos muy cortos. Pero he obtenido buenos resultados con una antena igualmente pequeña, la MFJ-1810, la que es una antena que luce cara (como, en mi opinión, todos los productos MFJ) pero que es muy robusta, plegada tiene dimensiones muy pequeñas y es muy adecuada para el funcionamiento portátil, sea que al transceptor se lo use en una posición "fija" como que se lo utilice en su original naturaleza de "handy". Entre los problemas que tiene se cuentan que no tiene una forma directa (sin modificaciones en el motherboard) de trabajarlo en CW, que tiende a tener cierto "tironeo" en la frecuencia con el nivel de modulación y que su mecanismo de sintonía apesta pues es práctico para establecer una frecuencia de operación pero no para sintonizar la banda. Lo he llevado en viajes tanto al interior como al exterior y su performance siempre invitó a volver a usarlo. Sin embargo, hace bastante tiempo que no lo uso. En principio porque no viajo tanto como antes, y ciertamente nada desde que estamos en pandemia, pero además porque la propagación en 10 metros es virtualmente inexistente. Hay aperturas de propagación que pueden aprovecharse con buenas antenas en SSB, pero la operación en portátil es con antenas pobres. 

Tampoco se puede usar en CW que es mucho mejor en esas condiciones. Se puede usar en CW por el método de generar la señal como audio. Tanto FLDIGI como MixW tienen esa capacidad, y es un formato básico quizás pero el problema del "tironeo" de frecuencia con el nivel de audio hace que para que la señal sea limpia deba tener muy poco nivel de audio, y eso se traduce en unos pocos cientos de mW (solo pude hacer muy pocos contactos de esa forma, y siempre locales). Pero pensé que se le puede dar una vuelta de tuerca a éste equipo usandolo en FT8, con un ajuste cuidadoso de los niveles de audio si se puede sacar entre 500 mW y 1W la experiencia me dice que acoplado a una buena antena debería lograrse una buena performance. Y una buena antena es una antena de media onda alimentada al extremo (EFHW) como las que estuve probando recientemente con tan buen resultado en otros equipos. Una antena de ese tipo para 10 metros solo tiene 5 metros de longitud y es incluso compatible con desplegarla en una habitación o colgarla desde un balcón cualquiera. Con esa posibilidad en mente puse en funcionamiento la portátil con éste transceptor. A mi me pasa, y no sé si es algo que me pasa solo a mi o es generalizado, que tengo las distintas configuraciones de portátil en sus respectivos "bolsos" para un despliegue rápido. Y eso incluye todos los cables, arneses, conectores y otros misceláneos necesarios para la configuración. Pero, por razones de costo, hay componentes que no tengo uno por cada configuración de portátil, por ejemplo la batería de gel de 12V@7AH. Otros componentes en cambio son víctimas de rápidos saqueos cuando necesito configurar otra cosa rápido y encuentro algún cable o conector que me es útil, y por supuesto no repongo. No es completamente fuera de la cuestión que otros miembros de la familia también se sirvan, en particular dispositivos no tan asociados a la radio como cables USB, hub, soundcard, etc. Como quiera que sea, cuando quiero utilizar una determinada configuración portátil no anda nada, me faltan varias cosas y termino necesitando trabajar un poco para ponerla en funcionamiento. En éste caso, además, es obvio que todos los elementos muestran el trajín de muchos uso y las condiciones de conexiones no es la mejor, asi que no vino mal repasarlo. Por lo demás, conceptualmente, la misma interface que usaba para modos digitales y CW, se reutiliza para FT8. El transceptor no tiene VOX, por lo que hay que hacerle PTT mediante un puerto serie (ver diagrama de interfase). Por lo demás, luego de renegar un poco con algunos falsos contactos salió andando. Al sintonizar en 28074 KHz (frecuencia de FT8 para la banda) inmediatamente escuché las clásicas señales de FT8, no solo indicando que andaba sino que además había bastante actividad. 

Muy rápidamente el WSJT-X confirmó que así era, se toman con comodidad estaciones de alcance regional, todos los países limítrofes que mostraban actividad. Configurando la parte transmisora pude contactar sin ninguna dificultad a todas las estaciones que intenté y que llegaban a un nivel SNR -8 dB o mejor, con lo que pude hacer contactos con PY, CE, varios LU e incluso FG5 (Guyana Francesa).Muy gratamente sorprendido. Luego de llamar CQ varias veces también tuve respuestas de PY y CE. Con el correr de las horas pude hacer QSO con Centro y Norte América, y mas tarde para mi sorpresa incluso Japón. Observando el mapa de reportes en pskreporter.info muestra que la señal es escuchada en buena forma en forma global, mucho mas que aceptable para una configuración modesta de tipo portátil con algo mas de 2W y una antena sencilla. El consumo monitoreado sobre la batería de gel fue de 170mA en recepción y 750mA en transmisión, por lo que aún en un ciclo continuo de llamada y operación en FT8 da algo menos de 0.5A, lo que es mucho menos que lo que consume el FT817 (0.45A/2A respectivamente) y por lo tanto puede operar aproximadamente 14 horas desde la batería de gel. En base a las pruebas con paneles solares también daría una ecuación energética muy favorable usada en conjunto con un computador de bajo consumo como un Raspberry Pi o una tableta Windows sencilla. Definitivamente el uso de FT8 le agrega nueva vida a ésta configuración. Aproveché para probar la configuración con un arrancador portátil USB y con un conversor USB-12V conectado a un pack de recarga. Ambas pruebas fueron exitosas en recepción pero ambas fallaron en transmisión. En el caso del arrancador portátil la calidad de la señal en emisión era pésima, aún bajando prácticamente a la nada misma el nivel de audio (100 mW aproximadamente), mientras que en el caso del conversor USB a 12V directamente al intentar transmitir el handy se reseteaba pues no podía mantener la tensión de funcionamiento, buenas pruebas para saber que ninguno de los dos son opciones válidas para ésta configuración, lástima porque constituyen una solución muy práctica para proveer energía en una operación de poca duración como la que usualmente termina siendo un uso portátil. Solo hay que esperar probar toda ésta configuración en serio en condiciones portátiles.... ¿o no será que en realidad estamos buscando excusas para salir de una vez por todas a tener actividades al aire libre? 

ARRL DX CW 2021

Se viene el ARRL DX International 2021 de CW, y como en otras ocasiones hago en concursos que tengo la intención de participar comparto mi propio análisis de lo que espero como condiciones de propagación. 

La metodología fue explicada en múltiples entradas anteriores y se basa en la actividad en las bandas elegibles para el concurso reportadas por el Reverse Beacon Network en el fin de semana del 13 y 14 de Febrero. 

El método sigue un método estadístico de asimilar las frecuencias de reportes como probabilidad de contacto para una determinada hora y banda. En tal sentido las probabilidades son una estimación estadística, con su correspondiente incertidumbre y variabilidad. 

El hecho que los reportes sean automáticos reduce en algo el sesgo inherente en los reportes manuales reflejados en los clusters, lamentablemente el RBN no reporta contactos monitoreados correspondientes a contactos en FT8 lo que permitiría capturar para el análisis aperturas de propagación mucho mas marginales. 

Existe un pequeño sesgo correspondiente al hecho que el Sol pudo haber variado la configuración geo-efectiva de sus manchas y perturbaciones, pero quizás siendo una parte baja del ciclo las perturbaciones son mas bien pocas.

El análisis tiene entonces la perspectiva de quien participará en "all band" donde lo importante es saber en que banda trabajar en cada hora y (aproximadamente) a que horarios se producirán las transiciones ("mejor banda para la hora"). Mientras que en las participaciones "single band" lo mas importante es saber (aproximadamente) en que horarios la banda estará operativa y con que intensidad relativa ("mejor hora para la banda").

El resultado del análisis se puede ver en el cuadro adjunto, donde se muestra que posiblemente la mejor banda será 20 metros, seguido por 15 y 40 metros. Las bandas de 10, 80 y 160 metros serán mas marginales, con aperturas puntuales y restringidas en el tiempo.

Estamos empezando el repunte de las condiciones del ciclo solar 25 que se pronostica para tener su pico en el 2025.

Ojalá que quienes participen tengan un buen resultado, pero por sobre todo que se diviertan mucho!

 

 

El transformador UNUN de QRPGuys

 

He compartido recientemente un número de entradas con distintos experimentos basados en antenas de hilo, en particular long wire, random wire and end feed half wave  (EFHW) antenas. Ese tipo de antenas son continuamente mencionadas por quienes tienen preferencia por activaciones portátiles, en condiciones de emergencia o de tipo SOTA (Summit on the air). Son antenas livianas, de razonable rendimiento comparadas con sus alternativas y relativamente poco críticas en sus necesidades de instalación. He realizado un número significativo de pruebas con éste tipo de antenas activando mi jardin en el último año; y los resultados son muy buenos operando en FT8, CW y WSPR a nivel regional.

En general estamos hablando de antenas para HF, típicamente para las bandas de 40,30 y 20 metros. Excepcionalmente para bandas mas bajas (80 y 160 metros) donde las antenas son bastante mas grandes en dimensiones y en bandas mas altas donde quizás no son tan atractivas pues antenas de mayor rendimiento (vertical cuarto de onda o dipolo de media onda) tienen dimensiones manejables en una operación portátil de bajo perfil.

En general éste tipo de antena necesita un transformador UNUN (Unbalanced-Unbalanced, opuesto al mas conocido transformador BALUN Balanced-Unbalanced) que adapte las impedancias de algunos centenares de ohms de éste tipo de antena a las algunas decenas de ohms que los transceptores con un sintonizador de antenas pueden sintonizar. El problema práctico que tienen éstas antenas es que el transformador requiere un núcleo toroidal de buena sección, incluso para potencias QRP, y ese tipo de núcleo no es fácil de conseguir. En general es mas sencillo conseguir nucleos pequeños, pero no son adecuados para transmisión o núcleos mas grandes pero cuyos materiales tienen muchas pérdidas en frecuencias de HF. Siempre está la posibilidad de comprar un núcleo por correo, pero el costo de transporte suele ser muy alto. Una alternativa interesante es comprar el kit de qrpguys denominado 40-10m ununtenna . Termina resultando que el costo del kit mas del envío es menor que el de traer un núcleo toroidal equivalente, e incluye una placa que desdobla como carretel para la antena y los anclajes para conectar la antena y el transmisor. El kit está preparado para funcionar con antenas de 29' (8.83m), 35.5' (10.82m) o 41' (12.49m). La antena no debe ser resonante a la frecuencia de trabajo y esas dimensiones permiten trabajar en todas las bandas de 40 a 10m. La antena necesita una "counterpoise" de 1/4 de onda pero se indica que con 35' (10.66m) es un buen compromiso para todas las bandas. La mejor performance es en 20m y el fabricante del kit anticipa que en las bandas extremo (40m y 10m) cae una unidad S (6dB) respecto a 20m.

La calidad del kit es soberbia y su construcción implica unos 15 a 20 minutos de tiempo incluyendo el bobinado del transformador trifilar (9 vueltas).

Si bien la antena es alimentada en el extremo, con lo que eso facilita la instalación y uso, es importante comprender que no sirve para antenas EFHW pues éstas requieren un transformador 49:1 en lugar de 9:1.

En principio pienso utilizarla con el Xiegu X5101 aprovechando su sintonizador automático, pero también puede utilizarse con el FT817, el D4D, el mcHF o incluso con el ya vetusto Dragon SS301 usando el sintonizador de qrpguys que algunas entradas atrás mencionara, y que también anda muy bien.

Todo parece que hay que aprovechar la primer oportunidad posible que la pandemia nos ofrezca para estirar las piernas y hacer una salida portatil, quizás inaugurar la modalidad POTA (Plains On the Air, Llanuras en el Aire) mas acorde a los lugares disponibles en los alrededores.

¡HNY 2021!

 

Y, finalmente, parece que se está por ir el 2020. Y la novedad es que por suerte algunos llegamos vivos para verlo. La desgracia es que muchos, y muy cercanos, no lo han logrado. El año ha sido, si se quiere, terrible no solo a nivel personal sino para la humanidad toda, ... ¡vaya novedad!. 

Cuando era chico me resuenan las palabras de mi abuela contando, con cierta reticencia, los terribles momentos de la pandemia de 1919, la infame gripe española. Aquella gripe en realidad fue mal llamada "española" como ésta es mal llamada "china". Esa pandemia, curiosamente también creada por un coronavirus como la que nos golpeó en éste año que se va, produjo la friolera de 20 millones de muertos en dos años, antes de desaparecer tan misteriosamente como llegó, algunos conjeturan que porque luego de tantos infectados y muertos se alcanzó finalmente lo que se llama "inmunidad de la manada". Dos de ellos de mi familia, los que hubieran sido mis tios Raul y Rosa, los "bebés" como siempre se los conoció en mi familia pues lo eran al momento de ser alcanzados por la pandemia. Un siglo después, con la medicina moderna, con los métodos modernos de diagnóstico, con drogas maravillosas y con el saber humano capaz de producir no solo una vacuna sino de hacerlo en menos de un año el costo en vidas será posiblemente una fracción del de aquel entonces, pero eso es poco consuelo para quienes partieron por su culpa, o mejor dicho, para quienes quedaron y vieron partir a sus seres queridos. He perdido familia, otros también, es una tragedia. Solo queda levantar la vista y ver porque sendero continuar.  Pero, como dijera Friedich Nietzsche "lo que no nos mata nos fortalece". Hemos aprendido, hemos adoptado estrategias de supervivencia, de cuidarnos, de trabajar en forma remota, de interrelacionarnos con cuidado, de ser resilientes en el cuidado de nuestros afectos. Hemos sentido, mas allá de "grietas" tontas, un cierto sentido de comunidad, de entorno, de "no dejaremos a nadie atrás", de "mientras nosotros no caigamos no dejaremos que nadie alrededor nuestro caiga". En alguna forma hemos aprendido a ser mejores, mas solidario, a pesar de la adversidad. Ya no es cuestión de cuidarnos, es cuestión de cuidar al otro también, una dimensión que pocas veces en mi vida he percibido tan claramente. No es general, no es con todo el mundo, es solo con algunos, pero es un comienzo.

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

Pero antes de hacerlo quisiera detenerme a compartir el enorme auxilio que representó para mi en éste año la actividad de radio. Tener en que aplicar el tiempo ocioso (no libre) que de repente todos nos vimos forzados a tener, poder desarrollar proyectos en los que estar ocupado (algunos de ellos documentados en éste blog) para que mi cabeza tuviera herramientas para manejar la enorme ansiedad que implica la incertidumbre, poder participar de actividades que otros tuvieron la gentileza de organizar a modo de distracción para entretenernos mientras esperamos por lo desconocido y, en general, obtener todos los beneficios de un pasatiempo para distraernos no tiene precio, su valor es inconmensurable; el coronavirus tenía lo suyo, pero la ansiedad y angustia que generó también. Espero que algunas contribuciones hechas hayan ayudado a otros, pero ciertamente quiero agradecer las que hicieron otros y ciertamente me ayudaron.

Finalmente, y ahora si, levantemos las copas y pensemos mucho en nuestros planes futuros  mientras lo hacemos, junto a nuestros afectos. No sabemos si tendremos futuro, pero si lo hay... ¡que no nos encuentre sin planes!

¡HNY 2021 DR OM 73 ES DX ES 88 TU BK!

¡Μολὼν λαβέ 2021!

EchoLink para Raspberry PI, SVXLink de SM0SVX

A fuerza de la necesaria honestidad que el comienzo de un nuevo año merece realmente el sistema EchoLink nunca me llamó demasiado la atención. Nacido como un sistema de tecnología VoIP (Voice over IP) desarrollado sobre plataforma Windows y madurado a lo largo casi una década de uso en una respetable red de mas de 6000 nodos y alrededor de 200000 usuarios a nivel mundial.

La propuesta tecnológica es simple y sofisticada al mismo tiempo, los usuarios acceden a un nodo EchoLink que escucha y transmite en un canal de VHF normalmente, ocasionalmente UHF. Lo que el nodo escucha lo retransmite a todas las estaciones que estén conectadas a ese nodo a traves de un cliente EchoLink. Conexión se hace mediante Internet usando tecnología VoIP, no muy diferente a la que usan programas muy usados como Skype, Teams, Zoom o Google Meet, tan en boga durante el necesario trabajo cooperativo remoto durante el confinamiento de la pandemia. Sin embargo, al momento de su lanzamiento no había muchos programas que usaran esa tecnología, algunos ya no existen mas y otros como Skype se han ido modernizando. El sistema tiene un programa servidor, que opera sobre Windows y programas cliente que operan en un número de plataformas, las mas populares Windows y sistemas operativos de telefonía celular, como Android por ejemplo. El nodo es de instalación relativamente simple; en su configuración mas simple opera en, valga la redundancia, simplex. Lo que el servidor escucha lo retransmite por VoIP a todos los conectados y si alguno de los conectados habla se le comparte al resto de los conectados y lo envia por aire también. Eso permite instalar un sistema sencillo, pero relativamente eficaz de uso compartido entre estaciones operando en radio y estaciones operando en Internet. En su variante "duplex" el sistema se adosa a un repetidor existente, de esa manera permite interconectar muchas estaciones en radio con muchas estaciones en Internet. La interfaz para hacer la conexión es muy simple, poco mas que conectar las salidas y entradas de una placa de sonido a un transceptor VHF/UHF, configurar el software y se está en el aire. Los nodos pueden formar parte de configuraciones relativamente complejas con "salas" geográficas, temáticas y por nodo. También es posible formar parte de la red Echolink sin ningún componente de RF, es decir solo con nodos que gestionan tráfico exclusivamente por Internet.

Ventajas y Desventajas 

En lo técnico el sistema es relativamente simple de instalar y configurar si se despliega un servidor y mas simple aún de usar si solo se usa el cliente, lo que es atractivo para quienes tengan una aproximación a la radio mas orientada a la comunicación que a la experimentación. En algunos casos permite hacer algo de actividad de radio, aunque pudiera paradójicamente no incluir ningún componente de radio, cuando por dificultades de antenas, equipos o propagación hubiera sido imposible de otra manera. Permite también la relación de personas que están físicamente muy dispersas, completamente fuera del alcance de un enlace de VHF o incluso de HF, con una precisión de horarios que la propagación no permite alcanzar. Tiene, claramente, muchas ventajas operativas.

Tiene unos cuantos puntos débiles, los que contribuyen a alimentar eternas polémicas sobre si es un uso legal o incluso ético de la radio. En general son discusiones estériles. En lo reglamentario no hay nada que impida su uso y la ética es una colección amorfa y gaseosa de conceptos que cada uno le dá la forma que le conviene para demostrar lo que necesita. Es claro que, discusiones estériles al margen, hay algunos cuestionamientos técnicos que limitan su utilidad. El mas severo es que es un sistema que depende de redes por fuera de la radio, específicamente Internet. Sin Internet no hay EchoLink.

El otro aspecto, y ya es mas opinable, es que técnicamente es una "caja negra" con poco o ningún lugar para la experimentación fuera de algunas interfaces simples entre equipos de radio y computadoras; técnicamente puede ser un medio "aburrido" (tomar en forma muy liviana y opinable éste concepto). Finalmente, desde el punto de vista de seguridad, tiene algunos puntos debatibles. Cualquiera puede obtener una copia del cliente y con el acceder a recursos que pueden implicar el uso de frecuencias de aficionado, y la cadena para demostrar que se tiene licencia para hacerlo es debil, muy debil. Potencialmente puede haber usos no autorizados de enlaces radiales y hay pocos, poquisimos, recursos para impedirlo.

Mis experiencias

Por todos éstos factores en varias oportunidades he instalado sistemas servidores para experimentar un poco con ellos, pero nunca encontré la motivación para hacer de ellos un sistema permanente. Básicamente implica tener una PC y una estación de VHF andando permanentemente, nada que no haya hecho antes como por ejemplo cuando tuve el nodo ABROWN de packet por casi una década, pero en aquella oportunidad fue la base para una inagotable cantidad de actividad experimental la que incluyó el primer gateway Packet-Internet online que funcionó en Argentina. Aquí en cambio, al ser un sistema cerrado las chances de experimentar son bien pocas, por lo que usualmente al cabo de unas pocas pruebas el sistema quedaba apagado o directamente des instalado. 

Del lado del cliente corrió un poco de mejor suerte, casi siempre he tenido un cliente instalado, en especial desde que se hizo común su disponibilidad en teléfonos celulares, en la última década por decir un marco temporal aproximado. Por lo que ocasionalmente lo he utilizado, tanto para contactos pre-establecidos, como atender eventos en "salas" específicas como para alguna prueba casual durante viajes cuando no tenía nada mas a mano. Pero el uso siempre fue mas bien marginal, siempre preferí usar equipos de radio.

Algo cambió... veamos de que se trata

El estado de cosas anterior se mantuvo hasta que Daniel (LU9DPD), conocedor de cierta experiencia en la plataforma debido a otros experimentos que fui haciendo públicos, me preguntó un día si creia que fuera posible desplegar un nodo Echolink usando una Raspberry Pi.

Para que funcione en una Raspberry Pi primero tiene que funcionar en Linux, y EchoLink lo tenía como un sistema tradicionalmente basado en Windows, mundos que parecen destinados a no juntarse como los protagonistas en la película "El Hechizo del Halcón".

No fue necesario buscar mucho, lo encontré rápidamente, el programa SVXLink, creado por Tobías (SM0SVX), el que no solo brinda soporte completo a un sistema servidor EchoLink bajo Linux sino que también ... ¡soporta a la placa Raspberry Pi!.

El programa es un clon funcional, que tiene capacidad de integrarse a la red EchoLink sin restricciones y ser reconocido como uno nodo perteneciente a ella. Provee además una serie de funciones avanzadas que el programa EchoLink original no contiene.

Instalación y configuración

Como casi cualquier proyecto lo primero que hay que hacer es ingresar al sitio svxlink.org y recorrer la documentación disponible. A continuación hay que realizar un paso crecientemente obligado de buscar en YouTube sobre proyectos similares al que se intenta llevar a cabo (por ejemplo éste, entre muchos otros mas antiguos y mas recientes).

Claramente se trata de un proyecto muy popular, muy transitado y con muchos ejemplos.

Empecé entonces con inicializar una placa Raspberry Pi Zero W con un SD card conteniendo una imagen estandard del sistema operativo Raspbian a último nivel, para hacerlo hay que seguir uno de los miles de tutoriales que indican los distintos pasos. Una vez que ese ambiente estuvo disponible comencé la instalación del hardware y software necesario. 

Elegí como transceptor para el experimento un handy Baofeng, aparato noble y resistente si los hay, a quien le construí un arnés simple para realizar la interfaz de audio. En principio y en un primer enfoque simplificado asumí que el PTT se activaría mediante un sistema VOX. En la placa Raspberry adosé una USB soundcard genérica. Intenté instalar SVXLink desde binarios pero claramente no están preparados para la placa Raspberry Pi Zero y dá numerosos errores; al intentar instalar desde sources mediante la carga de pre-requisitos y compilación del aplicativo también obtuve un número muy elevado de errores, probablemente con tiempo y paciencia esos errores eventualmente se pueden superar, pero no me sobraba ninguno de los dos ingredientes asi que tomé por un camino alternativo. Estoy convencido que a la placa le sobra potencia para operar como nodo, después de todo es un procesador ARM con un clock de 1 GHz para procesar señales de un ancho de banda de unos pocos KHz.

El camino alternativo fue comenzar la instalación de vuelta pero sobre una placa Raspberry Pi 3 B disponible en el cluster que tengo.

La instalación anduvo perfectamente, tanto haciendola a partir de sources (link) como de binarios directamente (link).

Configuración

La configuración del programa svxlink una vez instalado es bastante obscura, la documentación no ofrece "escenarios" sino que mezcla parámetros que son necesarios para funciones muy diferentes del servidor, con lo que termina no siendo demasiado claro que parámetros hay que cambiar y cuales hay que dejar como están. Y cuando se los cambia cual debería ser el valor adecuado para un determinado propósito.

La configuración se realiza cambiando el contenido del archivo /etc/svxlink/svxlink.conf donde los parámetros están indicados por su nombre simbólico seguido del signo "=" para a continuación estar el o los valores que se le asignan (ej. CALLSIGN=LU7DID), en general los parámetros no son sensibles a las mayúsculas. El archivo de configuración debe ser editado mediante sudo pues está ubicado en un directorio de acceso escritura solo para root (bueno, si saben Linux ya saben eso, y si no lo saben descubrirán la necesidad de aprender eso y otros temas antes de hacer ésta instalación).

Finalmente, por prueba y error encontré cual es la configuración mínima que es necesaria para configurar un nodo en simplex, que de eso se trataba. Obviamente hay que cambiar referencias a mi localización, frecuencia y licencia por las que se necesiten configurar.

######################################################################                Configuration file for the SvxLink server        

[GLOBAL]

LOGICS=SimplexLogic

CFG_DIR=svxlink.d

TIMESTAMP_FORMAT="%c"

CARD_SAMPLE_RATE=48000

CARD_CHANNELS=1

LOCATION_INFO=LocationInfo

[SimplexLogic]

TYPE=Simplex

RX=Rx1

TX=Tx1

MODULES=ModuleEchoLink

CALLSIGN=LU7DID-L

SYSOPNAME=Pedro

SHORT_IDENT_INTERVAL=60

LONG_IDENT_INTERVAL=60

EVENT_HANDLER=/usr/share/svxlink/events.tcl

DEFAULT_LANG=en_US

RGR_SOUND_DELAY=0

REPORT_CTCSS=136.5

MACROS=Macros

FX_GAIN_NORMAL=0

FX_GAIN_LOW=-12

[Rx1]

TYPE=Local

AUDIO_DEV=alsa:plughw:1

AUDIO_CHANNEL=0

#AUDIO_CHANNEL=1

SQL_DET=VOX

SQL_START_DELAY=0

SQL_DELAY=0

SQL_HANGTIME=2000

VOX_FILTER_DEPTH=20

VOX_THRESH=200

CTCSS_MODE=2

PEAK_METER=1

DTMF_DEC_TYPE=INTERNAL

DTMF_MUTING=1

DTMF_HANGTIME=40

DTMF_SERIAL=/dev/ttyS0

[Tx1]

TYPE=Local

AUDIO_DEV=alsa:plughw:1

#AUDIO_CHANNEL=1

AUDIO_CHANNEL=1

PTT_TYPE=NONE

TIMEOUT=300

TX_DELAY=500

PREEMPHASIS=0

DTMF_TONE_LENGTH=100

DTMF_TONE_SPACING=50

DTMF_DIGIT_PWR=-15

[LocationInfo]

APRS_SERVER_LIST=euro.aprs2.net:14580

STATUS_SERVER_LIST=aprs.echolink.org:5199

LON_POSITION=56.23.00W

LAT_POSITION=34.48.00S

CALLSIGN=EL-LU7DID

FREQUENCY=145.10

TX_POWER=3

ANTENNA_GAIN=0

Finalmente, de todos los servicios posibles (¡muchos!) solo uno se configurará y pondrá operativo en éste esquema básico y es el correspondiente a EchoLink mismo, para ello hay que editar el archivo localizado en /etc/svxlink/svxlink.d/ModuleEchoLink.conf

[ModuleEchoLink]

NAME=EchoLink

ID=2

TIMEOUT=60

ALLOW_IP=192.168.0.0/24

SERVERS=servers.echolink.org

CALLSIGN=LU7DID-L

PASSWORD=password

SYSOPNAME=Pedro

LOCATION=Adrogue,BA (GF05TE)

PROXY_SERVER=elp108.pi9noz.ampr.org

PROXY_PORT=8100

PROXY_PASSWORD=PUBLIC

MAX_QSOS=10

MAX_CONNECTIONS=11

LINK_IDLE_TIMEOUT=300

DESCRIPTION="You have connected to the LU7DID node\n"

            "QTH:     Adrogue,BA, Argentina (GF05TE)\n"

            "QRG:     Simplex link on 145.20 MHz\n"

            "CTCSS:   No Tone\n"

            "Trx:     BaoFeng UV-5RE\n"

            "Antenna: 5/8 at 12 mts\n"

En ésta configuración se establecen algunos parámetros clave para el funcionamiento del sistema y su integración en la red EchoLink global, para el cual debe registrarse la licencia del nodo (LU7DID-L en éste caso). Tal como está configurado se integrará a la red global a traves del servidor servers.echolink.org.

Funcionamiento

Si bien con lo anterior ya configurado es posible levantar la versión local del programa mediante

el comando

sudo -u svxlink svxlink

lo que irá indicando mediante un "trace" las distintas acciones y si hay algún error en la configuración que deba ser reparado.

Son necesarios sin embargo algunos pasos mas para llegar a tener un sistema funcional.

El primero y mas obvio, o quizás no, es tener registrado el nodo en la red EchoLink. Si se tiene registrada la licencia LU7DID (por ejemplo) la configuración anterior no andará, se requiere tener también registrada la licencia LU7DID-L, para el sistema EchoLink son cosas diferentes (y está bien que lo sean para no perder la capacidad de usar el cliente al mismo tiempo que el servidor está andando).

A continuación notaremos que si bien el nodo se conecta exitosamente a la red EchoLink y aparece publicado como activo no se puede llegar a el. Eso ocurre por las caracteristicas que típicamente tiene una conexión de Internet hogareña, donde el router cambia la dirección IP con que se expone a la red mediante una acción llamada NAT (Network Address Translation, traducción de dirección de red). Eso se hace así para por un lado proteger los dispositivos que uno tenga en casa del acceso externo y por el otro para que todos los dispositivos se presenten a la red como provenientes de una única dirección IP, eso es bueno en general para el uso diario pero no lo es tanto cuando quiero acceder desde el exterior a un dispositivo en particular dentro de una red hogareña, en éste caso la máquina que corre el nodo server.

Hay varias soluciones posibles, la mas neta es abrir un puerto en el router lo que involucra un procedimiento técnicamente complejo (simple cuando se sabe lo que se quiere hacer) pero que requiere reconfigurar la red hogareña entera, queda fuera del alcance de ésta entrada explicarlo.

El problema se explica con cierto detalle en el sitio EchoLink (link).

Una solución mas simple es utilizar un nodo "proxy", es decir que reciba las llamadas para nosotros y mediante un esquema de conexión donde nuestro nodo va a buscar la conexión en vez de esperar recibirla es posible sortear el problema de la traducción de direcciones. Después de todo es un problema muy común para el cual le han pensado ésta solución simple. Hay una lista bastante extensa de nodos proxy disponibles (link), en ocasiones esa página dá problemas de seguridad pero son falsas alarmas y pueden ser ignorados. Claramente no es una solución que escale en tráfico e introduce latencias adicionales que pueden ser molestas, pero para una prueba de concepto es perfectamente aceptable. En la configuración el proxy que utilizo es elp108.pi9noz.ampr.org aunque hay muchos otros.

Finalmente, un último obstáculo a superar, con el proxy configurado puedo acceder al nodo local desde un cliente cualquiera EchoLink, pero el audio es inservible y con una fuerte realimentación. Eso se debe a que la mayoría de los handy tienen una conexión de audio "económica" destinada a simplificar y hacer económico el micrófono, pero que no se lleva bien con éste tipo de uso, se crean lazos de masa indeseables que hacen realimentar la salida a la entrada. Para evitarlo es necesario aislar galvánicamente el circuito de micrófono con el de parlante del handy y los correspondientes a la entrada y salida de la placa de sonido. Eso se logra con un transformador de audio como los que se utilizan para, justamente, eliminar lazos de masa en sistemas de audio.

Con ese último agregado el sistema funciona perfectamente, tiene un retardo aproximadamente similar al del resto de los nodos que funcionan en la red y es por lo tanto usable. Acepta conexiones múltiples y se comporta, a todos los efectos prácticos como cualquier otro nodo de la red EchoLink.

El sistema, como tal, es mucho mas abierto y configurable que su contrapartida en EchoLink, sin ir mas lejos se disponen de los fuentes con lo que se pueden introducir modificaciones al código, y sin llegar tan lejos hay media docena de funciones tales como repetidor Echo, enlaces por red, conexión con APRS y otros que vale la pena explorar. Estimo que hay para muchos meses de experimentación para quien quiera ir en ésta dirección, y es posible que sea un proyecto muy interesante.

Estoy convencido, además, que aunque una placa Raspberry Pi 3 sea suficientemente "pequeña" el uso de CPU y otros recursos es tan bajo que el sistema, con tiempo y paciencia, tiene que poder funcionar en una Raspberry Pi Zero. Un proyecto en si mismo.

Muchas de las objeciones que puede tener el EchoLink como sistema son abordadas por las modernas redes digitales (por ejemplo DMR, Yaesu System Fusion, etc.) a las cuales EchoLink también se puede integrar, generando un interesante ecosistema analógico-digital.

¡No digan que no es tema para abordar en el 2021!

MicroSOTA y los microtranceptores QRPp

 

Revisando los canales YouTube habituales hubo un anuncio que fue manejado con bastante anticipación, con lo que genera expectativa. Se trata de la operación "MicroSota" que prometía la operación en SOTA (Summit on the Air) con el transceptor mas pequeño.

Fue anunciada bastantes días antes de ser publicada  con lo que generó alguna legítima expectativa. 

La corriente "SOTA" es un patrón de actividades en radio que premia el contacto con estaciones que operan desde "alturas" (cumbres, summit en inglés). Cada cumbre significativa (creo que la loma de 15 metros de altura donde vivo no cuenta como válida) tiene un código que la designa, cada país tiene su inventario de cumbres válidas y la actividad consiste en distintos formatos de colección de "cumbres". Tiene un esquema similar conceptualmente al de IOTA ("islands on the air") que quizás es un poco mas establecido, aunque su activación es mas costosa por la logística que suele involucrar llegarse a una isla que califique como válida. En el caso de SOTA son actividades mas al alcance de un grupo pequeño, o incluso un individuo, con una logística muy frugal, casi la propia de una excursión de campamento. Es sin duda un motivo de diversión a quienes contactan, pues se arman "pileups" significativos como para el que opera pues implica habilidades operativas similares, aunque de menor escala, que las de un operador DX-pedition. 

Hay un esquema de anuncios de activaciones y registro de planes futuros que, siendo muy organizados, completan la operación de ésta modalidad. En principio, no hay restricciones a las antenas, equipos o potencia con la que opere la estación en la "cumbre", pero en general llegar allí implica travesías a pie literalmente cargando con los equipos, antenas y fuentes de energía. Existe entonces un imperativo práctico para que las estaciones que van a la "cumbre" lleven equipos lo mas pequeños posibles, que utilicen la menor energía posible y las antenas de las menores dimensiones posibles. En ocasiones lo práctico es llevar un handy y operar la cumbre en V/UHF, en ocasiones eso puede dar acceso a una audiencia de centenares de kilómetros a la redonda, sobre todo en las cumbres cuyas faldas dan lugar a valles extensos, algunos con cierta densidad de población. Eso ocurre en casi toda nuestra pre-cordillera andina, en las sierras de Córdoba y San Luis así como en lugares seleccionados de la llanura pampeana (Balcarce, Tandil, Ventana, etc.). Pero, el condimento que siempre se trata de agregar es poder operar en HF, y para ello se debe apelar a transceptores muy pequeños, en ocasiones comerciales y en ocasiones caseros. Operando con potencias QRP (5W o menos) o incluso QRPp (1W o menos), usualmente en CW pero en ocasiones en Fonía o modos digitales. Con antenas usualmente portátiles verticales de dimensiones reducidas o de hilo tipo random wire, long wire o, con mucha frecuencia, antenas tipo EFHW (End Feed Half Wave). La energía es usualmente provista por baterías y ocasionalmente por energía solar, no conozco casos de energía eólica, pero seguramente alguien los habrá utilizados. Sin embargo cualquier modo de generación es típicamente voluminoso y por lo tanto lo que domina la activación es hacerla con la menor potencia posible. Las activaciones, dada la naturaleza del lugar, suele realizarse durante una jornada o fracción.

No he realizado SOTA activamente transmitiendo desde una cumbre, no al menos bajo el marco del programa de premios; si he comunicado en ocasiones con estaciones en cumbre. El desafío es bastante interesante, pues si bien la concurrencia es menor que cuando se contacta una DX-pedición, las capacidades de la estación en cumbre son drásticamente menores, por lo que se necesita una enorme habilidad operativa en el "cumbrero" para realizar éste tipo de operación y que sea divertida para todos.

Sin embargo, en casi 20 años de vivir en Córdoba, operé muchas veces desde las sierras de Córdoba, en condiciones QRP o QRPp y con fuentes de energía "off the grid", mayormente a batería pero ocasionalmente solar. Esas operaciones las hice en su enorme mayoría en CW, pero ocasionalmente en fonía (con buenos resultados dado el muy bajo ruido en esas locaciones) y con toda una gama de antenas portátiles. Muchas de las antenas están plasmadas en éste blog o en su predecesor lu7hz.blogspot.com . Por eso cuando finalmente apareció el video en el canal YouTube de Adam (K6ARK) (ver aqui link) me fue imposible no compartir inmediatamente el entusiasmo que transmite durante su expedición tanto por el lugar desde donde opera como por el equipo con que lo hace.

El equipo, cuyas especificaciones técnicas no indica exceptuando que es un prototipo, lo menciona en un tramo como una variante del legendario Pixie, circuito que he experimentado hasta la nausea en diseños propios y ajenos. Curiosamente Adam se "queja" de lo rústico del transceptor y sus pobres capacidades de selectividad. Todo conocido. Pero, claro, ... ¡2.7 gramos!. No está claro como se llega a eso ni a una potencia de 850 mW pues, nuevamente, no dá detalles técnicos. Refiere a un video anterior donde habla del "mini Pixie" siendo el de ésta oportunidad un "micro Pixie", supuestamente mucho mas pequeño. 

Conociendo el circuito estoy seguro que el par de gramos no incluye batería ni antena, fin de la discusión.

Tampoco, sin certeza pero sin dudas al afirmarlo, incluyen conector alguno o el keyer.

La potencia  indicada es, seguramente, de entrada y no de salida, concordando con los clásicos 400-500 mW típicas de un Pixie, pero me genera cierta curiosidad el manejo de la disipación. El Pixie se le puede extraer 500 mW de RF pero sin disipador bastará una "T" un poco larga o un poco de QRQ para que la etapa final resulte dañada, ni hablar de una antena con pobre adaptación. No, el Pixie es noble, pero las potencias mas seguras están en el entorno de 100 a 250 mW de RF.

Para que el transceiver mismo pese eso es claramente una versión reducida del Pixie, dado que el clásico pesa unos 50 gramos. 

Hay diseños de Pixie que construidos con componentes SMD pueden dar el factor de forma mostrado por el video y el peso, aunque claramente la construcción requiere típicamente una placa impresa especial, no es un diseño minimalista para prototipos. Sin embargo, hay servicios que permiten realizar tiradas de impresos muy pequeñas, algunos incluso individuales, a precios muy bajos, asi que es posible. Claramente, hay que ver los detalles, donde como sabemos el Diablo siempre se esconde.

Mientras reflexionaba sobre posibles enfoques técnicos recordé un proyecto hecho hace ya varios años, un híbrido entre el Curumim de PY2OHH, el Pixie clásico y la evolución de otros diseños propios presentados en mis blogs; ese proyecto lo llamé en su momento Arin y lo publiqué en mi blog anterior (link) en varias entregas, como un sistema de construcción que empieza por la descripción conceptual, continúa con la construcción y finaliza con el diseño del impreso. Por lo que recuerdo el peso del mismo era de unos 10 gramos con componentes convencionales una vez construido y operaba por un tiempo (breve) desde una batería convencional de 9V. Creo que hoy con los packs LiPo de alta capacidad de recarga de celular mas un "cable" conversor de 5V a 12V (creo que no hay de 5V a 9V) tiene que andar muy bien a un costo en términos de prestación vs. peso mas que razonable. Un arrancador de auto portátil basado en batería LiPo es también una opción atractiva en peso, tamaño y costo.

Es un proyecto interesante para aggiornar, ver como con tecnología un poco mas moderna es posible mantener la simplicidad al mismo tiempo que se incrementan las prestaciones (¿un DDS miniatura? ¿medidor de potencia? ¿tono? ¿offset? ¿CAT? ¿modos digitales?), creo que un objetivo razonable sería unos 20 o 30 gramos (sin antenas ni baterías) con un factor de forma de una pulgada cuadrada.

Pero mas allá del solaz y la anticipación de alguna diversión futura encarando ese proyecto como desafío creo que el Arin tal como estaba es un potencial compañero de andanzas de alguien que haga SOTA, así como fue planteado, una década atrás .... ¡por lo menos merece una prueba!

Construyendo puentes, el componente BridgeX

Un poco para ir redondeando el año técnico quería compartir (¿documentar?) un logro técnico que perseguí por mucho tiempo con mi estación concursera y en la que por distintos motivos gasté una enorme cantidad de horas. Para dar contexto me tengo que remontar a casi una década atrás. Luego de unos primeros intentos con software de logging de concursos claramente no apropiados, porque no eran para concursos o porque eran demasiado frágiles, adopté el famoso programa N1MM (por entonces la versión anterior). Esa decisión fue, en perspectiva, mucho mas durable que lo que podría hacer suponer un simple experimento. Con el tiempo probé otros software de concurso como AATest o WinTest, pero volví al N1MM. Los programas para logging de concursos tienen una enorme cantidad de funciones pues deben operar en una enorme variedad de configuraciones, satisfacer una igualmente enorme cantidad de posibles gustos y preferencias y además estar constantemente siendo ajustado a las siempre cambiantes reglas de los concursos alrededor del mundo. Tom (N1MM) y su equipo hacen un magnífico trabajo en lograr posicionar su plataforma, gratuita, como uno de los programas top en la materia y someterlo a constantes actualizaciones (en ocasiones varias por semana) en, por lo menos que me conste, la última década. Posiblemente desde antes. El primer traspié fue que todo el resto de los programas que quería usar no eran compatibles con N1MM pues se basaban en la plataforma OmniRig, que N1MM no le dá soporte. Al principio, inocentemente presumo, crei que era una omisión involuntaria. Por eso en distintos foros de soporte plantee la cuestión y me sorprendí un poco por el tipo de respuesta airada que obtuve de algunos miembros del equipo de desarrollo, no de Tom es bueno decirlo, opinando sobre mis motivaciones equivocadas y arriesgando que era técnicamente "imposible". Con el tiempo y otras interacciones con Alex (VE3NEA), autor del OmniRig y del CW-Skimmer entre otros,  mediante me di cuenta que había algun tema dando vueltas entre ambos equipos y que no podía esperar que ninguno de los dos fuera demasiado cooperativo. La principal razón para necesitar esa integración es que varios programas obtienen información del CAT del transceptor, frecuencia en particular. Y el CW-Skimmer, que a pesar que jamás lo usé como decodificador de CW, que es tan bueno o malo (según se prefiera) como otros decodificadores, tiene uno de los filtros mas potentes que conozca. Filtros Bayesianos. Un tipo de filtro que con el tiempo trabajé bastante en investigación académica y que solo se puede implementar con técnicas DSP. Es cuestión de tiempo que se desarrolle un hábito en el sintonizar las estaciones haciendo "click" en la señal de la misma, desarrollar una técnica para agudizar la coordinación cerebro-oido prestando atención al waterfall del CW-Skimmer y otras facilidades. El CW-Skimmer es el motor atrás del potente Reverse Beacon Network, además. Con el tiempo desarrollé el dispositivo para habilitar la operación SO2R primero y SO3R después. Primero en hardware y luego en software. Nuevamente, cada vez mas dependiente de poder administrar los equipos por fuera del N1MM. Pero el N1MM seguía sin incluir al OmniRig pues "no se podía". En realidad sería muy facil desarrollar el soporte en N1MM para el OmniRig, no es novedoso siquiera pues lo hacen otros programas como AATest o WinTest, simplemente se define un transceiver que sea "OmniRig" y se envian los comandos por alli, dejando que el OmniRig "traduzca" los comandos al transceptor físico que fuera, todos los comandos que usa el N1MM son, por supuesto, soportados por OmniRig. Todo el resto es pelea de pueblo chico pero que no se puede hacer nada sobre ello. No pasó mucho tiempo para que dejara de lado semejante pamplina y desarrollara (hace casi 10 años atrás) un programa denominado MM2OR (n1MM 2 OmniRig) que básicamente es un artefacto típico de integración de sistemas, como los que he construido o sido responsable de construir docenas en mi vida profesional. Utilizar alguna de las interfaces de un software para colocar un traductor que lo haga hablar con otro, sin que naturalmente ninguno de los dos esté pensado para hacerlo. En el caso del N1MM ese punto de apalancamiento fue la comunicación serie con el transceiver. Básicamente el programa MM2OR simula un puerto serie (mediante el programa com0com) y escucha en el. Cada vez que el N1MM envía un comando al transceiver el MM2OR lo intercepta y lo envía al transceiver en su nombre, usando OmniRig. La respuesta, también por OmniRig es enviada a N1MM por el mismo puerto serie virtual. N1MM "piensa" que está hablando con un transceiver. Conceptualmente es simple, prácticamente no lo es tanto. En primer lugar había que entender que comandos usa el N1MM para comandar al transceiver, por prueba y error fui sacando que comandos envía permanentemente (status y frequencia), que comandos espera del transceptor (frecuencia y modo) y que comandos puede tirar ocasionalmente (tipo cambio de VFO, split, modo, banda, etc.). Luego encontré que el N1MM tenía bugs, por ejemplo, enviaba dos comandos juntos al transceiver, ... y esperaba las respuestas juntas (como seguramente lo hacía el transceiver). Sin embargo cuando "parseando" los dos comandos primero se proveía la respuesta a uno y luego a otro el N1MM simplemente quedaba confundido. Como anécdota solo cabe aclarar que comentado el problema con uno de los desarrolladores ni siquiera entendieron de que se trataba y porque era un problema. Como quiera que fuera, con todo éste lio era entonces posible que varios programas Y el N1MM hablaran simultaneamente con un transceiver, y luego con dos (máximo que soporta OmniRig). Nació allí el sistema SO2R que usé por muchos años con distintas combinaciones de radios. Primero con un FT100, luego un FT740 con un FT100, luego el FT100 lo reemplacé por un FT790 y finalmente agregué a la mezcla un IC706 y el FT817. Para operación normal no es necesario pues uso software de teclado y logging (AALog, BandMaster y CWType) que si es compatible con OmniRig. El tema era solo con concursos. Salvo la molestia de tener que modificar el programa MM2OR cada vez que agregaba un nuevo transceptor para "enseñarle" los comandos que el N1MM podría solicitarle (en el propio protocolo CAT del transceptor) no hubo grandes cambios. Siempre me maravilló porque los fabricantes no hicieron un solo protocolo de CAT y ya, pero no, incluso Yaesu usa prácticamente un dialecto (o un lenguaje diferente) para cada transceptor.

Todo bien, muy contento con mi estación y dedicándome a construir las capacidades concurseras en otros aspectos por más de una década.

Cuando mudé mi estación desde Córdoba a Buenos Aires y pasé de ser LU7HZ a ser LU7DID hice una inversión muy importante en renovar equipos, adquirí un Yaesu FT-2000, persiguiendo un deseo de mucho tiempo de poder operar en concursos en modo SO2V en lugar de SO2R, es decir teniendo un equipo con receptor y sub-receptor. Las ventajas son conocidas para quien hace concursos y difíciles de explicar para el que no, pero involucran velocidad de tasa, integridad de equipos y compartir antenas, cosa que no es posible con dos equipos separados. Todo muy bien. No tardé en escribir las extensiones de MM2OR para que entendiera a un FT2000 pero ahí me encontré con un escenario nuevo. N1MM podía fácilmente integrarse, reconocer y usar los dos receptores del FT2000 tirando comandos que apuntaran al VFO A o al VFO B. No fue difícil acomodar la traducción usando MM2OR y OmniRig. Pero ésta vez fue CW-Skimmer (y el resto de la suite) al que no le dió la talla. Simplemente están preparados para trabajar con dos transceivers, pero no con un transceiver con dos VFO. Existe un truco muy sencillo, modificando los archivos de inicialización del OmniRig, para que intercambie los VFO. Es decir que si los comandos son para el VFO A lo tire en realidad al VFO B y viceversa. Eso solucionaba que CW-Skimmer pudiera controlar el VFO B, pero no solucionaba que hablara con un solo VFO. 

Plantee el tema a Alex (VE3NEA) quien no entendió siquiera el problema, recomendándome que alterara los archivos de descripción para justamente intercambiar los VFO. Luego me recomendó que definiera el mismo transceptor en ambos "rig" del OmniRig, solo que uno con la definición "derecha" y el otro con la definición "cruzada". Pero eso falló pues los dos rigs tendrían que compartir el mismo puerto serie, y una vez que uno lo abre no se lo deja abrir al otro. Una falla tan trivial me hizo suponer que Alex ni siquiera le había dedicado tiempo a ponderar mi pregunta antes de contestarme, su respuesta fue demasiado errada para suponer otra cosa.

Hice entonces una primera versión del programa BridgeX, siguiendo en el mismo concepto de integración usado por MM2OR, pero esta vez con OmniRig. Un programa escuchando en un puerto virtual (diferente al físico que estaba conectado en el transceptor) recibe los comandos que están dirigidos a un transceptor FT2000 que en realidad no existe, invierte los VFO y lo manda al otro transceptor via OmniRig. El diagrama (a mano alzada) se puede ver en la figura adjunta. Pero no funciona y no funciona porque el OmniRig tiene un bug. En lugar de mantener separadas las interacciones con los puertos series OmniRig no tiene esa precaución, con lo que cae en un problema llamado "re-entrabilidad y re-usabilidad", es decir intenta usar un puerto serie mientras está "adentro" del código de usar otro. Como resultado la ejecución "pisa" el ejecutable, destruye el stack y produce toda suerte de errores exóticos. Usando éste mismo esquema a mano alzada le pregunté a Alex por el problema y me dijo que si, que podía ser un error, que quizás en algún momento en el futuro lo corregiría o que quizás permitiría que CW-Skimmer seleccionara el VFO con el que operaba, o ambas cosas. Quizás. Algún día.  O nunca, vaya uno a saber. 

El proyecto estuvo dormido por casi dos años con lo que "coexistí" con el problema al que resolví con mantener la sesión "run" del CW-Skimmer sin conexión con el transceiver y hacerlo con la sesión "S&P". Dicho de otra manera, barrer multiplicadores con "point & click" pero mantenerme fijo en el run. De todas formas el N1MM siempre sabe en que frecuencia está cada uno pues, nuevamente, si reconoce sin problemas los dos VFO.

Hasta que preparándome para el CQWW 2000 volví a retomar el proyecto pero con una vuelta. El problema era el bug de OmniRig al tratar de usar dos puertos, uno real y uno virtual (que terminaba intentando pasar comandos al transceiver por el real). Entonces, ¿porque no virtualizar todo...?

El resultado del razonamiento se describe en la figura adjunta. Básicamente replico la estrategia de virtualizar puertos, en éste caso dos puertos distintos COM10 y COM12, donde escucha BridgeX los comandos respectivos. OmniRig envia comandos a esos puertos como si fueran dos transceivers distintos, ambos FT2000 en cuanto a sus comandos CAT. El programa BridgeX recibe los comandos, en el caso de los que recibe por COM10 los pasa físicamente (por COM4) al transceiver mientras que los que recibe por puerto COM12 los pasa, también por COM4, pero invirtiendo VFO A y VFO B. Como resultado CW-Skimmer tiene una instancia sobre el transceiver en rig1 (el FT2000 que toma sus comandos) y otra instancia en rig2 (el FT2000 que invierte VFO). Como resultado ambos CW-Skimmer interactúan cada uno por su lado con distintos VFO. Y se puede hacer S&P en cada VFO por separado. Y se gana bastante en agilidad operativa. De alguna manera vuelvo a tener todas las facilidades que tenía con dos transceivers separados pero ahora con todas las ventajas de uno integrado.

El esquema lo usé en forma prototipo en CQ WW, y luego de algunos ajustes nuevamente en ARRL 10 Meters. Con excelentes resultados en ambos casos. Fue un puente que tardé muchos años en encontrarle la vuelta, y al final como en todo problema que se resuelve, la solución parece muy simple. Al punto que uno se pregunta, ¿porque habré tardado tanto tiempo en encontrarla?. La conclusión es que no hay cosas "imposibles" en materia de software, solo mas o menos ganas de hacerlas.