¡73 ES TU 2019 !..... ¡FB HNY 2020!

En minutos se apagará no solo un año, sino toda una década!. Si tomo en cuenta la vieja casa digital (lu7hz.blogspot.com) llevo mas de una década  con ésta iniciativa.

Este es un blog que tiene mas de anotador personal que de medio de difusión y en el mismo comparto mis ideas, algunas reflexiones, logros y en ocasiones también fracasos en los temas técnicos que me interesan. Las estadísticas indican que eso parece ser del agrado de un número no muy grande pero muy consistente de seguidores.

Este blog está relacionado con un aspecto de mi vida donde prima el placer únicamente, que es el dedicarme a las cosas que me gustan mucho. 

Es muy difícil en la vida alcanzar un estadio permanente de felicidad, mas bien se logran hebras de ella durante las vivencias de algunos momentos, la idea es que se los disfrute y si fuera posible que éstos sean mas que su necesaria contrapartida no tan felices.

El año que se está a punto de ir ha tenido un balance positivo para mi; en lo familiar primero viendo con mi familia se va consolidando en sus  proyectos de vida y como la nueva generación que se ha sumado empieza a tomar forma. En lo profesional y académico he podido tener logros interesantes que espero poder igualar o superar en los años que vienen. En radio, finalmente, ha sido un año donde pude alcanzar muchas metas que me había propuesto, y las que no pude simplemente disfrutando de la anticipación de tratar de alcanzarlas mas adelante.... Solo resta levantar las copas en ese infinitesimal tiempo en que el viejo año se vá borrando sus problemas y pendientes para dar paso al nuevo, con su propia carga de esperanzas e ilusiones, con los buenos deseos para todos los que están y el recuerdo para todos los que se fueron. Tiempos mágicos que permiten compartir un abrazo para aquellos que tenemos en nuestros pensamientos pero solo podemos alcanzarlos por éste medio. ¡HNY 2020! 

Antena de hilo arbitrario alimentada al extremo

Pocas cosas se persiguen tanto como una antena que sea razonablemente eficaz (ni siquiera eficiente, que rara vez lo son) y que no implique dimensiones enormes y que pueda ser instalada en espacios reducidos, además de transportadas con facilidad.

Pero, por mas que uno le dé vueltas al tema cada esfuerzo se comprueba el postulado que dice "todas las antenas que no sean un dipolo o una vertical son una porquería, algunas son útiles".

En efecto, es fácil medir la "eficiencia" de una antena; en definitiva hay que solo encontrar una forma de medir la potencia que se le entrega y cuanto de ella se transforma en energía radiada; y muy pocas antenas son altamente  "eficientes" por cierto, y ninguna lo es al 100%. Medir la "eficacia", es decir la habilidad de conseguir un objetivo con ella, es otra historia pues básicamente depende de lo que se quiera conseguir. Si se consigue el objetivo que se perseguía la antena es eficaz, si no se lo consigue entonces no lo será. Una antena eficaz para DX probablemente tenga que ser la mejor disponible y no será posible utilizar "eficazmente" algo de compromiso. Pero si las expectativas son tener una cobertura razonable a nivel local o incluso regional se pueden aceptar grados decrecientes de "eficiencia" pues es suficiente la "eficacia". Recientemente se agregó el aliciente de poder aceptar márgenes mayores de baja "eficiencia" manteniendo aún así una "eficacia" razonable mediante la utilización de modos de baja señal como WSPR o, sobre todo para comunicar FT8 quienes con márgenes asombrosos de -25 dB de relación señal a ruido permiten contactos con potencias efectivas irradiadas extremadamente bajas. El compromiso en ocasiones consiste en usar lo que se puede instalar o no hacer radio, en tal caso la eficacia consiste en "lo que se pueda hacer con eso que se puede instalar". En oportunidades eso es parte de un desafío técnico y en otras pura necesidad. En tal sentido he usado mayormente como configuración portátil antenas de tipo vertical acortada, distintas variantes de "látigo" (whip). Las que usualmente consisten en un látigo pequeño respecto a la longitud de onda, el que usualmente ofrece reactancia capacitiva, con un inductor para compensar, como componente adicional esas antenas se usan mayormente con potencias bajas (QRP o QRPp). Dos antenas me han dado un rendimiento aceptable en el tiempo, la Yaesu ATAS-1 y la MFJ-1799 una con bobina en centro y otra con bobina en base; ambas ajustan a ROE reducida en las distintas bandas y con ambas he comunicado en condiciones de portátil con restricciones de espacio y peso. La Yaesu ATAS-1 tiene un pequeño bono que consiste en que en el irradiante por debajo de la bobina de carga  se desdobla como antena de VHF/UHF.  Adicionalmente, he tenido muy buenas experiencias con la antena miniWhip originalmente diseñada por PA0RDT, pero solo sirve para recepción, y cuando es lo único que se quiere hacer es probablemente la mejor alternativa.

Ambas antenas necesitan un "counterpoise" para funcionar adecuadamente, lo que usualmente es un cable que anda viboreando cerca del piso y que cumple con tal papel.

Pero nunca había experimentado con antenas de hilo, en particular las variantes de hilo largo (long wire) y las de longitud random (random wire o arbitraria) alimentadas al extremo, en realidad eso creía, volveré sobre el punto hacia el final.

Las antenas de hilo largo son por definición aquellas cuya longitud es grande comparada con la longitud de onda, es decir al menos superiores a media onda o incluso de media onda. Cuando están alimentadas al extremo tienen ciertas ventajas eléctricas y de montaje comparadas con el dipolo de media onda convencional y algunas dificultades derivadas, justamente, de su alimentación al extremo (alta impedancia vs. baja impedancia de las primeras) que requieren un dispositivo transformador de impedancia. Por lo demás son antenas mas bien largas.

La antena de hilo de longitud arbitraria por su parte tiene similares ventajas de configuración física y algunas dimensiones posibles son cortas comparadas con la longitud de onda. Para empezar la antena "random" (que deriva de tener una longitud "arbitraria"", al "azar") no lo es tanto, tiene que alejarse de resonar con cualquiera de las bandas en las que se las quiere usar o de alguno de sus múltiplos pares; las cuentas al hilar fino dan un número de posibilidades no demasiado extenso si se quiere tener una antena medianamente multibanda. Algunos cálculos muestran que los valores recomendables son (en pies) 8, 14, 16, 24, 25, 41, 46, 77, pueden verse algunos cálculos adicionales aqui. Dado que un pié es aproximadamente 1/3 metro puede verse que se obtienen algún resultado con hilos de algo mas de dos metros para bandas de HF. Por supuesto que cuanto mas corta sea la antena respecto a la longitud de onda menos eficiente será, y no hay milagro alguno en emitir en 80 metros con una antena de 2 metros de longitud, ciertamente es improbable que funcione, pero quizás funcione bien en 6 o 10 metros, incluso en 15 metros. Un buen compromiso es el de antenas entre 17 y 22 metros de longitud, los que deberían funcionar con distintas consideraciones y eficiencia para las bandas de HF entre 80 y 10 metros.

La antena es muy flexible en su ubicación y disposición, puede plegarse incluso para sortear problemas de espacio (aunque por supuesto, con alguna penalidad en eficiencia al hacerlo). Pero, alimentada en el extremo una antena de éste tipo tendrá una impedancia de varios centenares de ohms, difícil de operar eficientemente con un transceiver que opera con 50 Ohms de salida. Es entonces necesario utilizar un adaptador de impedancias, el que usualmente es un autotransformador desbalanceado-desbalanceado (unbalanced-unbalanced o UNUN) que suelen por convención construirse para una relación de 9:1 por lo cual una impedancia entre 300 y 600 Ohms reflejará al transceiver en el otro extremo entre 33 y 100 Ohm, lo que permitirá una operación directa con ROE relativamente baja o poder ser corregida con cierta facilidad con un sintonizador, incluso simple. Hay muchos kits y proyectos disponibles en Internet, uno que me gusta es el provisto por el Emergency Amateur Radio Club of Hawaii (EARCHI), en el canal de Youtube de OM0ET también se analizan varios proyectos. Un sintonizador particularmente apropiado me parece es el ofrecido por qrpguys.

Estas antenas requieren un "counterpoise" (sistema de masa artificial) para poder operar correctamente, mucha literatura dice que no es estrictamente necesaria, pero una configuración con aproximadamente 5 metros de longitud de cable o mas mejora la distribución de corrientes. En la figura inicial muestro la construcción que estuve experimentando. Alli puede verse la entrada coaxial y las conexiones apropiadas para uso en campo del hilo de antena y de "counterpoise".

Se trata en esencia de un auto-transformador toroidal con relación de espiras 1:3 lo que da una transformación de impedancias de 1:9. En la foto tomada del kit de EARCHI mencionado se ve que el transformador es de construcción simple, basado en un devanado de 5 a 7 espiras trifilar (verde-negro-rojo), el verde es masa de coaxial y counterpoise, el verde/negro es vivo de coaxial y el rojo es el hilo, hay una conexión no visible negro/rojo que completa el circuito.

El núcleo a ser utilizado requiere cierta experimentación, idealmente hay que usar uno tipo T106-2 o superior. Pero para la mayoría de los experimentadores indicar un tipo concreto de núcleo es igualmente inalcanzable que especificar como parte de los materiales necesarios rocas de la Luna o polvo de estrellas, pues si bien se consiguen toroides en las casas del ramo es muy difícil que sean de una especificación concreta. Experimenté con un núcleo recuperado de la fuente de una PC vieja (el mostrado en la foto) el cual resultó tener pérdidas excesivas, posteriormente con un Amidon T37-61 que tenía de un experimento anterior el cual mostró que no tenía sección suficiente para sostener las corrientes necesarias para trabajar incluso en potencias QRP. Finalmente lo implementé con un núcleo de hierro que pude recuperar de un circuito viejo, el cual da un rendimiento razonable. Constructiva mente el montaje es sencillo, una caja estanca de electricidad pequeña da amplio lugar para las cuatro conexiones necesarias y en principio soporta bien la intemperie, al menos por tiempos reducidos. Es un buen experimento, que dio resultados alentadores en una configuración restringida en mi casa, sobre todo en 20 metros, y que está a la espera de una prueba mas en profundidad en condiciones portátiles. A todo ésto, por si no quedó claro, si pueden utilizar un dipolo de media onda alimentado al centro o una antena vertical para la banda úsenla, pero si no pueden ésta puede ser una alternativa a explorar.

A todo ésto comentaba al comenzar que creía no haber trabajado con éste tipo de antenas previamente, pero recapitulando me llegó un mensaje del pasado sobre que si, después de todo sí las había usado. No hay mensajes ocultos ni parapsicología involucrada; solo un niño de 12 años empezando a tratar de hacer cosas de radio sin saber realmente nada de electrónica,  estrictamente nada.

Guiado por su entonces mentor en la materia abordó el poner como solución a severas restricciones de espacio, de disponibilidad de ofertas comerciales y de dinero,  una antena que fuera "eficaz" en cuanto a permitirle dar los primeros pasos para hacer radio en  80 metros con una configuración que consistía en una antena hilo de cobre con 1/4 de onda para 80 metros (20 metros de largo) alimentada en un extremo con cable cinta de TV de 300 Ohms, el mismo mentor se la terminó construyendo, pues el niño no sabía soldar siquiera. Ese tipo de cable, muy poco común hoy, lo era bastante por entonces pues se usaba para las bajadas de antenas de TV abierta (por entonces la única disponible), y era muy económico; mucho mas que el inalcanzable coaxial. Por supuesto que no era claro como era que funcionaba esa antena, solo que era posible comunicar en 80 metros a nivel local y de noche cuando abría la propagación podía hacerlo en alcances regionales cortos, 500 Km y excepcional mente hasta 1000 Km como máximo. Operaba por entonces un equipo a válvulas para AM de 25 W de potencia, curiosamente equivalente a cuando hoy se usa (por elección) potencias QRP (25W en AM se corresponden aproximadamente a 5W en SSB), solo que entonces operar QRP no era algo que estuviera de moda o que se conociera el término incluso. Ese niño era yo, y ese mentor era Don Ernesto Stellini (LU5EZ,SK). Me llevó más de una década a continuación adquirir los conocimientos para poder entender como funcionaba esa antena, pero tampoco es que los apliqué inmediatamente pues ya para ese entonces trabajaba con antenas mucho mas elaboradas, operaba equipos bastante mas complicados y el tema quedó apilado allí, en la memoria. Hasta que el otro día al montar la random wire y observarla por la ventana de mi oficina en casa el patrón apareció de repente de entre las tinieblas y vi instalada en el jardín de mi casa, como novedad experimental, la misma antena que Don Ernesto había hecho para mi mas de 50 años atrás, y que me permitió dar mis primeros pasos en radio a pesar de las múltiples restricciones que tenía. Ahora es trivial para mi ver, que una antena de 1/4 de onda para 80 metros, sin ser ideal ni multibanda, se comporta como una random wire, alimentada al extremo presenta una impedancia de algunos cientos de Ohms. La salida valvular presenta una impedancia de varios miles de Ohms, y la adaptación mediante circuito link, el que transformaba la alta impedancia de salida de las válvulas a la relativamente baja de la antena mediante un transformador consistente en un inductor y su secundario (el "link"), ambas bobinas articulaban su proximidad para permitir una gama de posibles adaptaciones realmente notables. Algunos equipos realizaban esa adaptación usando un circuito mas moderno, el "pi", pero no era el método más común por entonces, no al menos en el tipo de equipo como el que tenía yo. El transformador "link" era en realidad un transformador de impedancia de, para sorpresa de nadie, relación 10:1. La rama no usada de la cinta de TV (¿para que se conectaba a la nada?) era, nuevamente para sorpresa de nadie, la "counterpoise". A mi me danza el gráfico de Smith en la cabeza para entender como juegan las impedancias, pero a Don Ernesto le llevó unos minutos entender que con las restricciones que tenía esa era una buena solución. A mi me llevó solo 50 años entender lo que hizo y poder apreciar lo mucho que sabía y que me ayudó. Quizás donde sea que esté se ponga contento en saber que al final entendí.

Dipolo para recepción de satélites metereológicos NOAA (137 MHz)

Si, como buen hobbista, tiene un severo problema con la creciente lista de proyectos sin terminar no creo que pueda ayudar mucho con éstas lineas excepto para garantizar que tener una printer 3D empeora la situación. Uno ya no se detiene en proyectos de su área de interés, docenas de circuitos y proyectos que desbordan interés pero que probablemente nunca pasen de esa etapa; sino que además ahora le agrega proyectos complementarios con la impresora 3D y, por si eso fuera poco, toda suerte de "gadgets" con los que uno se tropieza y no puede reprimir el pensamiento sobre que lindo sería tenerlo. Pero, no todo está perdido, de vez en cuando los proyectos si logran superar esa confusa mezcla de barrera inercial de hacer cosas concretas alineado con una ventana de tiempo en la que no se puede hacer otra cosa mejor para concretarse. En realidad hay dos formas, básicamente, para plasmar un proyecto. Una es ir a un repositorio de diseños ya realizados, el mas completo y fascinante que he encontrado al momento es The Thingiverse, traducción medianamente liberal por medio vendría a ser la conjunción de thing (cosa) y universe (universo), o sea universo de cosas. Y ciertamente hay las cosas mas interesantes y las mas raras. También hay un par de grupos en Facebook en la cual se presentan diseños no tan convencionales, aunque rara vez se compartan los archivos de diseño. Estos archivos de diseño, de extensión .stl (Standard Triangle Language) son los que permiten a la impresora (en modo off-line) o al programa conectado a la impresora (en modo on-line) generar las instrucciones de movimiento que terminan traduciendose en la impresión 3D propiamente dicha. El programa que utilizo es el Ultimaker Cura, por ahora en su versión para Windows aunque también hay una versión para Mac y para Linux. Hace años ya que gracias al regalo de mi hija, la Dra. Claudia Colla Machado, disfruto una MacBook Air que es una maravilla, el sistema iOS es por otra parte derivado de Unix (de la encarnación que Steve Jobs creó cuando se abrió de Apple y fundó NeXT) con lo que mas a gusto me encuentro aún. El regalo de mi hijo, el Dr. Pedro Colla Machado, de un teléfono iPhone 6 y el regalo de María (mi esposa) de una iPad lograron completar el ecosistema Apple para todas mis actividades. Pero, disgresiones al margen, hay veces que es mejor trabajar en Windows por lo que tengo instalado en la Mac el programa Parallels corriendo una versión de Windows 10, en la que programas como el Ultimaker Cura corren fantásticamente bien.

Comentaba que había dos formas para hacer proyectos con una printer 3D, una es bajarse el archivo ya hecho, cargarlo en Cura, establecer algunos parámetros (lo mejor que he encontrado ante la vastedad de los posibles parámetros es utilizar todo en los valores "default" o propuestos por el programa) y mandar a imprimir.

Pero, no siempre se encuentra el diseño que uno quiere, y si bien había varios diseños de soportes para antena dipolo para 137 MHz, ninguno me resultaba atractivo. Quería algo bien básico, en un solo bloque y fácil de imprimir. Como en todos los órdenes cuando no se encuentra lo que se busca hay que hacérselo uno. Y es allí donde la impresora 3D se transforma en un agujero negro de tiempo y esfuerzo, el proceso de diseñar un objeto, aún con herramientas rudimentarias de aficionado como las que uso (TinkerCAD), es fascinante y puede absorber totalmente la atención durante horas. Básicamente se pueden manipular figuras geométricas básicas (esfera, cubo, cilindro, pirámide y otros) variando sus dimensiones, posición en el plano y rotación en el espacio. Las figuras se pueden hacer también de material (sólido) y anti-material (vacío), juntando ambos el "anti-material" cava sobre el material y permite crear espacios vacíos. Con esa combinación mas unos pocos comandos de manipulación espacial se puede hacer cualquier pieza. Se agrega la capacidad de importar y exportar otros diseños así como generar una librería propia de partes y componentes. Es muy básico comparado con otros software de diseño 3D industrial, aún así increiblemente potente para usos domésticos o casuales. 

Y con ello traigo a colación el diseño que motiva ésta entrada, el soporte para antena de 137 MHz. En rigor un dipolo en V para cualquier frecuencia mientras que las varillas de aluminio pesen lo suficientemente poco como para que el material lo soporte. Creo que uno para 50 MHz quizás dé brazos muy largos y uno para 1.2 GHz seguramente el material juegue una mala pasada, pero en el medio sospecho que cualquier frecuencia puede ser adecuada. Para 137 MHz las ramas del dipolo tienen que ser de 53.4 cm cada una, asumí usar una varilla o tubo de aluminio de 5 mm de diámetro como buen compromiso entre rigidez y peso. En los extremos se toman unos trozos de cobre que conectan la varilla con el conector PL-259. El conjunto se hace mas rígido mediante unos tornillos que sostienen las varillas en su lugar a presión. El conjunto es muy liviano. Se pasan unos precintos en las ranuras al efecto y luego de colocar la tapa (a presión) el conjunto se ata al poste que opere como mástil. ¡Voilá!

La recepción la hago con el nodo SatNOGS que tengo operando desde hace ya un tiempo, programando la pasada de los satélites meteorológicos con mas prioridad que otros, la foto muestra un ejemplo. A la izq. es la imagen en visible y a la derecha en infrarrojo, el ruido superior e inferior corresponde a la visibilidad de horizonte de la antena en su ubicación actual. Las bandas de ruido intermedias "finitas" son lóbulos de la antena que tendré que trabajar en eliminar (si los quisiera eliminar totalmente tendría que recurrir a un diseño de polarización circular) y las bandas de ruido "gruesas" se trata de la interferencia producida por la baliza WSPR/FT8 que si bien opera en 14 MHz parece afectar lo suficiente la recepción para producir ese efecto, nace así otro proyecto para que con determinadas prioridades la baliza evite emitir si está pasando un satélite de interés, técnicamente desafiante pero también divertido.

La lista de proyectos de radio, y fuera de la radio, es enorme ya. Pero supongo que con tiempo los proyectos mas interesantes verán la luz del día, cuando le llegue su turno!

PixiePi habla lenguas

“I will use strangers who speak unknown languages to talk to my people. They will speak to them in foreign languages," Corinthians 14.

En entradas anteriores comenté sobre progresos tanto en el armado del kit D4D (crkits) como del desarrollo que denomino PixiePi el que integra un desarrollo basado en un kit DIY Pixie y la librería librpitx corriendo en una plataforma Raspberry Pi Zero (W).
Cuando comenté en el foro Facebook Técnica-LU sobre el primero de ellos junto con mi recomendación hice el comentario, mas bien conceptual, que emitir en DSB como lo hace el D4D tiene sus bemoles y que debería poderse hacer en forma mas robusta mediante generación directa de señal con técnicas SDR. Lo que tenía en mente era que el proyecto PixiePi pudiera hacerlo, claro.
En realidad el "salto" no es tan grande, de hecho puede ni siquiera ser necesario un salto. En la página del proyecto figura como recibir y emitir FT8 con el proyecto PixiePi tal como está en éste momento, solo que si bien es funcional no es cómodo. En recepción el enfoque es idéntico al D4D, un receptor de doble conversión, concedo que quizás menos sensible pero suficiente, siendo su oscilador local la librería librpitx operando como DDS. En transmisión, sin embargo, el programa PiFT8 puede emitir todos los mensajes FT8 que sean necesarios, pero es necesario armarlos y coordinarlos completamente a mano, lo que quizás sea práctico para una prueba de concepto (o para un beacon) pero no necesariamente lo es para comunicación corriente. Por otra parte, correr WSJT-X en la Raspberry Pi Zero es técnicamente posible pero la performance es muy marginal (¿lo es?).
En experimentos previos, reflejados en la serie de éste blog denominada "Construyendo un transceptor digital bit a bit" exploré que era necesario para utilizar una plataforma Raspberry Pi para recibir distintos modos a partir de un dongle RTL-SDR y emitirlos basados en la librería librpitx. La mayor parte de la experimentación la hice con una Raspberry Pi 3+, el cual es casi cuatro veces mas poderosa que una Raspberry Pi Zero en términos de CPU. Alli encontré un limitante fundamental, que era que para compensar el retardo en el procesamiento del audio de recepción y retrasar el clock de la máquina para eso, perjudicaba la exactitud de la ventana de transmisión. La conclusión que saqué en ese momento era que debería usar dos placas separadas, una para emitir y otra para recibir (cada una con su compensación de clocks).
Pero hay otro enfoque posible, y es mostrado en la figura adjunta. PixiePi no requiere procesamiento digital de su salida, el receptor Pixie es un doble conversión (bueno, regular o malo, no importa) que puede alimentar directamente un WSJT-X via una placa de sonido cualquiera, una USB es quizás la opción mas conveniente. Por su parte el WSJT-X puede si, mediante un proceso de adecuación digital, alimentar la emisión mediante PixiePi a partir de una cadena de procesamiento digital que transforme los sonidos generados con la modulación FT8 en una señal de modulación I/Q (compleja) con la que poder modular en SSB la portadora generada del DDS. Con esa premisa empecé a trabajar en crear el software necesario para integrar ambas cosas, proveer una señal DDS que opere como oscilador local (LO) en receptor y una señal SSB que emita los tonos provistos por WSJT-X en transmisión.
En realidad el transceptor Pixie es de CW, y por lo tanto su etapa de salida no es lineal pues opera en clase C. Pero ésto no es dificultad toda vez que el filtrado de la señal de salida sea adecuado para evitar espurias excesivas y que la señal FT8 está contenida en la fase de la señal y no en su amplitud, la que resulta uniforme.
La capacidad del Raspberry Pi de generar una señal modulada en amplitud que se emita por un pin digital (GPIO4) es limitada, pero sorprendentemente suficiente puesto que el "nivel" de señal en el pin puede ser controlado programáticamente en hasta 7 niveles diferentes, y eso basta para generar una aproximación de la señal modulante suficientemente buena como para ser inteligible en un grado sorprendente, no peor que una señal de SSB "comprimida".
El despliegue consiste entonces en desplegar WSJT-X en una Raspberry Pi Zero, configurarla para recibir señal desde la linea MIC de una placa de sonido, el cual es alimentado con la salida de Speaker de la placa Pixie y alimentar la señal a emitir mediante un loopback interno para poder con el mismo activar el proceso de modulación SSB. La activación del PTT se realiza mediante comandos CAT aunque no descarto en el futuro poder hacerlo con un sistema VOX tal como opera D4D, aunque no hay cables involucrados en ninguno de ambos casos pues el comando es completamente digital.
De esta forma el procesamiento queda comandado enteramente por la placa Raspberry Pi Zero, aunque aún es necesario tener alguna forma de operar el WSJT-X que alli corre.
La forma mas trivial es, por supuesto hacerlo desde una PC o laptop mediante el uso de la conectividad VNC (escritorio remoto), la operación del WSJT-X es mayormente "point & click" asi que es una interfaz totalmente aceptable; pero en realidad se puede utilizar como alternativa cualquier medio que me permita utilizar el programa VNC Viewer tal como una tableta o un teléfono celular. En cuanto al teclado puede utilizarse un teclado virtual o un teclado bluetooth.

Monitoreo de Propagación de LU9DA

Hace bastante tiempo que Rick (LU9DA) tiene funcionando su DX-Cluster en el que realiza, cada 10 minutos, un resumen gráfico del estado de propagación mediante el recurso de dibujar los "enlaces" dados por los "spots" del cluster en ese período. Lo hace tanto para las bandas tradicionales como para las WARC. Es un recurso que adopté hace mas de una década como parte de mi infraestructura concursera. Le agregué entonces un script en Javascript, muy simple, denominado MonitorProp.htm que lo que hace es tomar los gráficos de todas las bandas y ponerlos en una sola página, el script carga los gráficos cada minuto (aunque los gráficos mismos son actualizados cada diez minutos). Si bien han aparecido recursos de monitoreo de propagación bien sofisticados desde entonces tales como el "mapa de calor" proporcionado por DX Heat (band activity) o incluso el muy sofisticado DX Maps con una enorme cantidad de información desplegada, recursos ambos que también uso durante mi actividad concursera, el que continúo usando como monitor primario y "pantalla de fondo" permanente es el que genera Rick. Contribuyen  a su utilidad el formato frugal, las conclusiones las saca uno de un gráfico simple, pero al mismo tiempo completo en un grado que permite de un vistazo saber donde está la propagación (si es que está) y como está mutando. Datos útiles tanto para participaciones "All Band" para saber cuando es momento de cambiar de banda, como en "Single Band" para saber cuales son los "corredores de propagación" activos. En general he sostenido discusiones sobre si un recurso así debe usarse solamente en modos "asistidos" en concursos que los permiten o puede usarse en cualquier concurso y categorías no asistidas. El tema siempre genera debates acalorados y no pocas veces alrededor de posturas mas bien dogmáticas pero siempre he sostenido la conversación parado en competir en modo asistido por lo que  no quedan dudas, pero también he sostenido que cuando uno lee los reglamentos de los concursos no es difícil concluir que la asistencia consiste en saber estaciones concretas en frecuencias concretas, y claramente el cluster gráfico de Rick no da esa información (si lo hace DX Maps y es inevitable verlo en DX Heat, pero no aquí). Uno solo sabe que hay un enlace entre dos países, pues el mapa gráfica los enlaces entre las capitales de los países, independientemente de donde esté ubicada la estación. He comentado en entradas anteriores de mi blog como LU7HZ este recurso muchas veces, pero a cuento de haber resuelto un "bug" en mi script que ya llevaba una década de edad (la omisión del año en el título) tuve que refrescarlo con la corrección, y eso es un buena excusa para refrescar también la existencia del recurso y repasar su utilidad. Se viene el CQ WW CW 2019, y este es un recurso que soporta muy bien el paso del tiempo, signo seguro de que es útil.

CQWW CW 2019

Y se viene el CQ WW CW 2019, concurso clave del calendario anual para CW; aún en un año con poquisimas participaciones en concursos es una cita obligada.

Como es natural, y como parte de los preparativos de la estación, empecé a pensar sobre las posibles estrategias a seguir a emplear. Creo que de base descarto una participación All Band, requiere un involucramiento y asignación de tiempo mayor que el que me es posible. Asi que Single Band (SB) será. La potencia será LOW y el modo Assisted por preferencias ambos. O sea que queda elegir que banda será. El año pasado participé en 40 metros (SO(A)SB40 Low), y si bien me divertí mucho me quedé con la sensación que me perdí oportunidades de contactos importantes por no estar durante toda la madrugada; pero no daba y no dio. La banda de 80 metros queda descartada pues no tengo antena decente. Participar en 20 metros tiene su atractivo por varias razones, la principal es que creo que conozco bien el patrón de propagación, lo he estudiado durante todo el año gracias al beacon WSPR y FT8, mi estación es razonablemente eficaz en 20 metros también y por cierto tiene la ventaja que los horarios son mas "diurnos". Pero, estudiando la performance de otras estaciones le solicité el log preliminar de la estación de Ricardo "Los Profes" (LU2DX) durante el reciente concurso CQ WW SSB 2019, los que con mucha amabilidad me compartieron. Revisándolo me encuentro con una performance muy buena en la banda de 10 metros, superior a lo esperable. Las aperturas son muy breves y muy "agudas" en tu perfil de tasa, pero por cierto de aprovecharlas se puede articular un buen puntaje. Intrigado realicé un pronóstico de propagación basado en los perfiles que ellos obtuvieron, con la siempre oportuna hipótesis simplificadora que la propagación pasado aproximadamente un mes (parecida configuración solar geoefectiva). 

Me da que, estimación de intensidades o probabilidad de contactos al margen deriva en un pronostico de apróximadamente 6 horas de propagación por día de concurso, con un comienzo en nuestra noche del Viernes (1am GMT) con una apertura corta con Japón, seguida de varias horas de apagón hasta que alrededor del mediodía local son de esperar condiciones moderadas con Europa por un par de horas seguidas con buena probabilidad de tener tasas interesantes de contactos con USA. Tanto SA como AF pueden aportar contactos durante esa ventana. Un poco para validar hice un análisis similar pero utilizando la proyección realizada con el programa VOACAP alimentado con las hórridas condiciones actuales de actividad solar (SSN negativo, SFI en 70 o menor) y, sorprendentemente, da un perfil de contactos tanto en banda horaria como en perfil geográfico de corresponsales similar, se pronostican 6 horas de condiciones por cada día de concurso (12 horas durante todo el fin de semana) en casi total coincidencia con el perfil de LU2DX. Finalmente, bajé datos del Reverse Beacon Network del fin de semana del 25 y 26 de Octubre (aproximadamente un mes antes de lo que estoy proyectando) y el perfil también coincide en forma bastante aproximada aunque menos intensa que en los casos anteriores. Cabe destacar que siempre la participación de estaciones, y por lo tanto la "intensidad" de actividad es muy superior en un concurso respecto a un fin de semana cualquiera, por lo que eso podría explicar en parte la ausencia de datos en la red RBN. Los resultados de las tres comparaciones puede verse en el gráfico adjunto, donde una "X" implica que la probabilidad de hacer contactos en esa hora es media a alta, mientras que un blanco implica probable baja actividad (aunque no se pueden descartar aperturas esporádicas y al azar en cualquier horario). El esfuerzo de participación, en horas, es similar al esperable en 20 metros, y por cierto que 10 metros aún muy cerrada por las pobrísimas condiciones de propagación imperantes es una banda muy atractiva, por lo menos para mi, sobre la cual se puede competir con otros paises mas en pié de igualdad que hacerlo en bandas mas altas. No tengo aún decidido en que banda operaré durante el concurso, pero ciertamente ésta banda está alta en sus posibilidades.

Corriendo la frontera del asombro, distancia record para FT8 en 20 metros

En varias entradas anteriores he compartido mi asombro sobre las capacidades del modo WSPR (Weak Signal Propagation Report) para cubrir distancias inimaginables con potencias absurdamente pequeñas. Este modo tiene una capacidad de identificar señales tan débiles como -30 dB de Relación Señal-Ruido (SNR) en un canal de referencia de fonía (2.5 KHz). Esa referencia es un estandar, pues es obvio que no se necesita tener tanto ancho de banda para decodificar un mensaje simple, pero es la referencia para poder comparar con la eficiencia/eficacia de una señal de fonía. Solo para comparar se estima que la capacidad de CW en ésta materia ronda los -5 dB para copia "automátizada" y alrededor de -10 dB para copia auditiva (algunos estiman que un operador realmente experto empuja ese límite a -15 dB). En el caso de CW esa performance sobre ruido explica la capacidad de equipos de potencia muy baja, QRP o incluso QRPp, pueden realizar contactos muy buenos. Solo para poner perspectiva numérica, en condiciones normales lo que podría hacer con un equipo QRP (5W) en CW podría hacerlo en WSPR con un poco mas de 500 mW. En mi caso hace ya bastante tiempo, próxima a cumplir un año con funcionamiento continuo, tengo una baliza WSPR de 100 mW (+20 dBm) de potencia, la que operando sobre una antena dipolo rígido es rutinariamente reportada desde EU, NA e incluso OC (ayer, Bob ZL1RS a 10531 Km de mi ubicación). Pero WSPR es un modo de reporte de propagación, solo puede ser escuchado pasivamente y reportado, la extensión de la transmisión de información de casi dos minutos lo hace poco viable para comunicar. Y en los dos minutos de extensión de la emisión, junto con los algoritmos sofisticados de codificación, la información estructurada y breve, está el secreto de poder recuperar señales tan débiles. Ahora bien, FT8 (Franken-Taylor PSK 8) es un modo que está a caballito de ambos mundos, por un lado utiliza el tipo de algoritmos que WSPR, pero lo hace con algunos sacrificios y compromisos en un tiempo de emisión de algo menos que 15 segundos sobre "ventanas" sincronizadas con mucha precisión en el segundo 0,15,30 y 45 de cada minuto; de esa manera una llamada en el segundo 0 puede ser contestada por otra estación en la ventana del segundo 15 y la respuesta en el 30 para cerrar el contacto en la ventana del segundo 45 . Como resultado se pueden sostener tasas de contactos (en condiciones ideales) de cierta fluidez. En la práctica, en condiciones normales se tarda un par de minutos por contacto debido a los re-intentos, mas si las condiciones de propagación son marginales. El mensaje que se intercambia es muy escueto pero suficiente para validar el contacto como el famoso "2-way contact" requerido por la tradición (es decir, señal distintiva y nivel de señal con la confirmación de haber recibido correctamente ambas) y las reglas de la mayor parte de las actividades de DX y concursos. Su performance está, dependiendo de la profundidad de la decodificación que se active, lo que depende también de la potencia del procesador que se disponga, entre -15 dB y -25 dB de SNR. La razón de la potencia del procesador estriba en que del ciclo de 15 segundos que dura un "frame" quedan un poco menos de 3 segundos entre que finaliza la transmisión y comienza la ventana de un nuevo ciclo de transmisión, por lo tanto la "recepción" debe ocurrir en esa ventana de tiempo. La diferencia entre distintas "profundidades" de decodificación estriba en el algoritmo de decodificación mismo. La banda pasante es explorada sumariamente en busca de "bins" o segmentos con energía, asumiendo que corresponden a una señal (aunque también pueden ser mero ruido), es posible entonces en función del nivel de energía estimar preliminarmente la probabilidad que haya una buena señal para decodificar. Con todas las señales provenientes de esa pasada (que reitero, pueden tener "falsos positivos" debido a ruido") se hace una tabla donde las señales candidatas preliminarmente están ordenadas de mayor probabilidad de validez a menor. Lo lejos en la lista de señales candidatas que se puede progresar  antes que se quede sin tiempo determinará cuantas posibles señales se decodificaron y cuantas no se llegaron a decodificar. En otras palabras, una señal "fuerte" es decodificada por la configuración mas "rápida" en profundidad pues está primero en la lista de candidatos, mientras una señal extremadamente debil requerirá de mucha potencia de procesamiento para que en solo 3 segundos pueda llegarse a procesarla luego de muchos otros candidatos, incluso cuando fueran "falsos positivos" producidos por ruido, un destello de ruido puede tener una firma de energía superior a una señal válida y por lo tanto ser identificada como de mayor prioridad.. Por eso es facil en FT8 operar a nivel regional con poca potencia y antenas modestas y para ocasionalmente lograr distancias mayores; mientras que para consistentemente poder hacer grandes distancias se requieren mejores antenas y una buena estación de "ambos lados".

En mi caso junto con mi baliza de WSPR, la que emite un frame cada 10 minutos, opera una baliza de FT8, la que luego de los dos minutos de la ventana de WSPR emite cuatro llamadas CQ a razón de dos por minuto durante dos minutos, esas llamadas no inician un QSO automáticamente, por mas que sean contestadas por algún corresponsal siguiendo la tradición no escrita iniciada por el Dr. Taylor de no generar robots capaces de hacer un QSO completo sin ninguna intervención humana en el proceso. La baliza queda a continuación silenciosa por los 6 minutos remanentes hasta el próximo ciclo. Durante ese período opera el monitor de FT8, el cual operó durante mucho tiempo con una Raspberry Pi corriendo WSJT-X y un receptor RTL-SDR y ahora lo hace con la misma Raspberry Pi pero usando el transceiver D4D de CRKits, el cual tiene una sensibilidad extraordinaria. La baliza transmisora controla el acceso a la antena de uno u otro. La baliza FT8 con solo 100 mW es rutinariamente reportada desde Norte y SudAmérica, y ocasionalmente desde AF (ZL-Land) y EU; por su parte la estación monitora reporta rutinariamente todo ese espectro. Pero, corriendo la frontera del asombro ayer la baliza fue reportada, en el límite mismo del modo a -24 dB, por Eiichi (JF7ELG) a sorprendentes 18320 Km (¡!). Hay un viejo comentario de los viejos radioaficionados (categoría en la cual ya también estoy yo) que siempre hay propagación, solo hay que buscarla en el momento correcto. Suena a que es un truco "mágico" de un modo que en definiva es pura matemáticas y que tiene poca conexión con la forma que por ahi percibimos un radioaficionado puede y debe contactar. Yo difiero con ese punto de vista por varias razones, que no vienen al caso enumerar. Pero aún aceptando ese razonamiento se puede argumentar que si a la misma hora y con la misma configuración de antenas en ambos extremos intentáramos lo mismo con CW a 100 W, le estaríamos poniendo 30 dB mas al circuito por lo que la relación SNR debería ser de 4 dB, confortable para un QSO en telegrafía y si hay bajo ruido de banda para uno "ruidoso" en fonía. O sea que los modos de baja señal puede beneficiar al que está de acuerdo con ellos, y al que no. ¡Es solo cuestión de intentarlo!

Impresora 3D en LU7DID

Hacia rato largo que venia considerando la posibilidad de incorporar una impresora 3D a mi shack. Pero los precios muy por arriba de lo que sensatamente puedo invertir en una cosa asi para un uso ocasional y de "entrecasa" combinado con dificultades para identificar un propósito "duro" que lo justificara fueron demorando la decisión. En el medio aprendí a manejar las herramientas de diseño, primero como "nivel principiante" la muy interesante plataforma TinkerCad, a la que referí en alguna entrada anterior debido a su también excelente emulador de Arduino, provee un editor Web sorprendentemente potente para manipular objetos y crear diseños de cierta complejidad incluso. Se obtiene como resultado el archivo con el diseño en formato STL. Dado que se puede también importar diseños externos con ciertas limitaciones, no importantes a nivel principiante, se puede ingresar a repositorios como Thingiverse con miles de modelos en prácticamente cualquier aplicación imaginable, y de allí extraer un diseño para tomar como base y evolucionarlo. Por ejemplo eso es lo que hice para un primer prototipo del gabinete para el proyecto PixiePi donde tomé diseños existentes que usan Raspberry Pi Zero, aplicaciones con LCD 16x2  y kit Pixie para unificarlos en un solo diseño. Mas allá de aprender un campo realmente vasto, lo que de por si es interesante, uno se encuentra rápidamente con el límite físico de no poder plasmar en objetos físicos lo que está diseñando. Intenté con un productor comercial pero la experiencia no fue satisfactoria en resultados y fue extremadamente costosa; aparte de la impresión existe el interés de vender servicios de diseño gráfico con lo que se hace muy difícil una aplicación en tirada corta y sin propósitos comerciales. Supongo que si hubiera un desarrollo comercial quizás justifique esa via, incluso los honorarios del diseñador gráfico, pero no para experimentar y hacer cosas de una vez. Pero empecé a ver en los sitios web chinos ofertas de impresoras 3D de muy bajo costo, hasta que un modelo ingresó volando por debajo de todas las defensas, 150 dólares en una oferta especial que duró un fin de semana. Y allí me compré la ANET A8 3D Printer  , no había mucho tiempo para investigar pero una mirada rápida me mostró una enorme comunidad amateur, bastantes problemas para hacerla funcionar bien pero también otros tantos proporcionando soporte y "atajos" de uso, incluyendo una enorme gama de mejoras hechas con la impresora misma. La adquirí y por los meandros de las compras online tardó muchísimo en llegar, mas de 3 meses, la miraba en el tracking internacional rebotando entre aeropuertos domésticos de China como si el courier estuviera en loop, pero finalmente llegó.

Cuando llegó algo que sabía racionalmente se transformo en conocimiento emocional, la impresora es un kit. Es un kit con centenares de piezas, muchos centenares de piezas; no es nada ni parecido a ensamblar media docena de sub-sistemas. Hay que armar cada sub-sistema. Lo primero que busqué fueron videos en Youtube sobre como armarla, y encontré muchos, de distinta calidad y claridad. Es frustrante en un video de armado que se pierda foco de la imagen justo cuando está mostrando lo que uno debería ver.... Entre todos ellos encontré uno muy bueno en español [link] creado por 3D Maker ES, que consta de 4 partes de aprox. 20 minutos cada una. Si, la explicación de como armar la printer, en el formato acelerado y con espacios recortados de Youtube toma casi una hora y media..... Al ver los videos llegué a la conclusión que jamás podría armarla con la habilidad necesaria para que saliera andando. Afortunadamente vino a pasar unos dias con nosotros el Dr. Marcelo Colla Machado, que además de cirujano de profesión tiene una enorme habilidad manual y una paciencia de monje, y aplicó ambas cosas a lo largo de casi 12 horas para armar la impresora; la cual salió andando de primera intención con solo problemas de armado muy menores. Llama la atención que pese a seguir todos los pasos de los videos sobran piezas, y hay al menos un error que hace que no detecta el fin de carrera en eje Z.

La calibración requiere de videos adicionales, de hecho cuesta bastante calibrarla para que funcione bien, hay un video útil [link] que ayuda en ese proceso.

El resultado es una printer 3D que sin ser robusta o de calidad anda lo suficientemente bien como para poder hacer cosas en escala "hogareña" a costos razonables. Luego de algunos pocos diseños de prueba tales como un llavero o el inevitable extrusor de pasta dentrífica ya lo apliqué a un diseño del shack de radio concreto, el gabinete para el "hotspot" DMR.

Durante los primeros usos comprendí a los golpes que implica los problemas de calibración (y lo dificil que es calibrar la "cama") y lo importante que es poder obtener buena adherencia del objeto sobre la "cama" de impresión (placa donde ocurre la impresión que es movida en dos ejes), en particular en las primeras capas. En muy poco tiempo tuve mi buena dosis de "pastichos" inservibles, pero hasta eso es un aprendizaje, pues rápidamente se aprende a guardar los sobrantes y diseños fallidos para mezclarlos con acetona para hacer una pomada que permita realizar acabados o solucionar imperfecciones.

El bautismo de fuego lo tuve cuando, con Marcelo ya en su casa, se me tapó el extrusor y tuve que desarmarlo para limpiarlo, bastante complejo, pero también hay videos para una guía [link].
Si bien es posible imprimir modelos mediante el copiado del archivo con el diseño (.STL) en una tarjeta SD y leerlo directamente con la impresora, he encontrado mucho mas eficaz y rápido usar un programa de rendering que gestione la impresión misma, pues no solo permite trabajar mas amigablemente (sobre todo al comienzo, donde hay mucha prueba y error) sino que dá facilidades para modificar el diseño, calibrar la impresora, ajustarla y cambiar mas o menos facilmente los parámetros de impresión; seguramente hay muchos programas pero el que encontré mas recomendado, no es pago y es razonablemente fácil de usar es Ultimaker Cura. 

Todavía estoy en los primeros pasos de lo que promete ser una curva de aprendizaje bien empinada, el tema es vasto tanto en lo que hace a las herramientas de diseño, los posibles usos y también el instrumento mismo el que cuenta con docenas (centenares) de posibles mejoras.

El kit D4D de BD6CR

A pesar de tener varios proyectos en progreso, y poco tiempo para terminar de concretarlos, una mención hecha por Fernando sobre su construcción de un equipo QRP específico para FT8 en el grupo WhatsApp del RC.Avellaneda (LU7EO) me entusiasmó lo suficiente para comprar el kit D4D (DSB for Digital) hecho por Adam (BD6CR) ofrecido desde el sitio CRKits entre otras ofertas muy interesantes. El kit tiene un costo muy razonable, al punto que el envío sale casi el 50% del kit mismo; afortunadamente un intercambio con Adam y su respuesta muy razonable permitió reducir muy significativamente el costo de envío a expensa de tener un poco de paciencia en que tardara mas en llegar. Y no fue tanto, en poco mas de un mes luego de haberlo comprado, parte bastante significativa consumida aqui mismo en Argentina en el proceso de Aduana y distribución.

Y finalmente llegó. El kit es muy completo, viene no solo con placa y materiales de muy buena calidad sino con toda la caja y la minutería necesaria para el armado de su caja. El kit tiene todos los materiales necesarios para construirlo en su formato básico e incluso para realizarle algunas modificaciones sugeridas para mejorar la performance.

El soporte, excelente también, es dado por la comunidad de usuarios y por Adam mismo, por medio de un foro habilitado en el grupo Groups.io crkits, con tiempos de respuesta que harían la envidia de otros soportes pagos.

El kit tiene una complejidad intermedia, la parte mas complicada si se quiere es el armado de las tres bobinas; hay algunas oportunidades de error en el hecho que el kit se puede construir para 80,40 y 20 metros (el mio es de 20 metros), por lo que hay algunos componentes que son sensibles a la frecuencia y si no se está muy atento es relativamente fácil de confundirse (cosa que me ocurrió dos veces). 

Aproveché el fin de semana largo para abordar la construcción, la documentación disponible en la red incluye el circuito, las instrucciones muy detalladas de armado y el listado de partes. El armado se propone en 8 pasos sucesivos donde se van construyendo en forma incremental las distintas etapas tales como sistema de energía, vox, receptor, transmisor, filtro pasa bajos y finalmente el armado de la caja. 

Al terminar el armado no funcionaba ni en recepción ni en transmisión. El sintoma visible era que se ponía en transmisión en forma permanente, el transceiver no tiene un circuito de PTT o Key sino que lo hace mediante un control VOX con la señal de audio de la entrada; y se activaba en forma espontánea sin señal. No había antecedentes en el foro. Con el osciloscopio rápidamente pude ver que era una fuente de ruido originada en una masa defectuosa. Luego seguía sin funcionar, pero ésta vez parecía mas serio, tratando de recibir con el programa WSJT-X (que el manual de instrucciones dice como debe configurarse) mostraba solo ruido en la banda pasante.

Terminó siendo que los capacitores de carga del oscilador eran los de 40 metros y no los de 20 metros, por lo tanto debido a la carga no funcionaba el oscilador. 
Solucionado eso empezó a recibir, con un poco de ajuste de los niveles de audio empezó a recibir correctamente toda la actividad en la banda. El transmisor también tuvo problemas por una soldadura fría nuevamente, ésta vez en el transformador bifilar del driver de la etapa final. Se nota que era excesivamente cauteloso al momento de soldar o que el soldador era muy pequeño para las superficies extensas de planos de masa que tiene la placa (muy bien hecha).

En los ajustes finales me llamó la atención que la potencia de salida medida es de 300 mW en vez de 1W o mas que debería tener, a pesar de ello pude comunicar muy buenas distancias (PY1 y PY2) con la banda en condiciones intermedias. 

Al medir la corriente resultó que en recepción toma 22 mA y en transmisión 290 mA desde la fuente de 12V @ 3A de switching que le asigné, esto es unos respetables 3.5W de entrada, a 50% de eficiencia (generosamente para abajo) debería emitir 1.5W de RF, el consumo está en linea con lo recomendado por Adam para la banda. (Nota posterior: Adam me comentó en el foro que la corriente es correcta y que debería esperar entre 0.5 y 1W de potencia de salida, y sugirió que mirando con un osciloscopio debería observar 17 Vpp; hago los calculos y con esa tensión de RF la potencia estimada debería ser (17V * 0.35)]^2 / 50 Ohms=~700 mW).
Todavía no terminé de determinar si se trata de un problema en el wattimetro (un dudoso instrumento de Banda Ciudadana). El tiempo total de armado fue de 4 horas, repartidos en dos días; y la búsqueda, solución de problemas y ajustes un par de horas mas; eso habla poco de habilidad constructiva alguna de mi parte y mucho de lo bien organizado del kit y la secuencia recomendada de construcción.
El transceiver es físicamente muy pequeño, quizás como si fueran tres teléfonos celulares apilados. El consumo invita a operarlo con una batería en un auto o de gel en condiciones portátiles. Las pruebas hasta ahora las hice con una antena direccional, habrá que ver como se comporta con una antena mas de compromiso como es probable que se deba operar en condiciones portátiles, candidatas para pruebas futuras es la vertical reducida Yaesu ATAS-1 con bobina de carga lineal y la antena vertical cuarto de onda para 20 metros (que denomino Small T). 
Hasta ahora como estaciones móviles en HF he llevado el Yaesu FT817, variantes del diseño Pixie y el Dragón SS301, pero el factor limitante siempre es la bondad de la antena que puedo llevar y que siempre termina siendo muy de compromiso. Tengo la expectativa que con una antena muy modesta y un pequeño tamaño éste transceptor será un excelente compañero de viajes. No puedo menos que recomendar la diversión pura que proporciona su construcción y anticipo la diversión futura al operarlo.

Un lugarcito caliente para DMR en LU7DID

Y finalmente llegó la placa MMDVM clone para instalar un "lugarcito caliente" (hotspot en inglés) de DMR. En una entrada anterior compartía mis primeros pasos en el mundo de DMR (Digital Mobile Radio), sorprendido en cierta forma por la curva de aprendizaje a pesar de conocer la tecnología básica por haber trabajado profesionalmente en redes TETRA (Motorola) hace ya un tiempo atrás (circa 20 años atrás).
Del uso fui aprendiendo por un lado cual es la mejor forma de configurar el handy Bauofeng DM-5R mediante un codeplug y por el otro los límites que tengo en el sistema en la configuración que tiene la red DMR en Argentina (ver figura).
Básicamente tengo dos formas de integrarme a la red, en UHF a través de la repetidora digital del Avellaneda Radio Club (LU7EO) al cual puedo abrir en forma consistente a pesar de la modesta distancia que me separa con la antena Yagui o en VHF entrando en el repetidor de Marcelo (LU8EB), el cual está ubicado un poco mas cerca y puedo abrirlo con la antena 5/8 en la torre. En ninguno de los casos puedo operarlo directamente con el handy, por lo que a diferencia de como utilizo las repetidoras analógicas de la zona sur (mayormente LU3DY 147.12+) para las cuales basta poner el handy donde esté en la casa para seguir la actividad.

Es ahi donde entra a jugar un "hotspot", que es un dispositivo que opera como un repetidor local en miniatura, se lo accede por radio en UHF (mi modelo, que es uno de los mas simples y económicos) y a traves de una conexión con Internet establecida mediante WiFi se integra a la red DMR que se le configure. Esa vendría a ser la principal razón para pensar en poner un hotspot; la otra, que no me motivó ni explore significativamente por ahora, es la posibilidad de trabajar en otras redes.De esa forma solo basta instalarlo en algún lugar de la casa que tenga buena visibilidad radioeléctrica tanto de la cobertura WiFi como del handy. La potencia que utiliza el hotspot es muy baja, del orden de 10 mW por lo que apriori aparecería como para brindar un servicio doméstico, sin embargo en un par de pruebas rápidas dentro de la manzana puedo activarlo con razonable confiabilidad. Hacer funcionar el hotspot no es un proceso trivial, sobre todo si uno empieza desde cero. Afortunadamente hay bastante material en Internet al respecto y un intenso, y muy productivo, intercambio de información y configuraciones que ayuda mucho cuando hay dificultades. Aún así es importante entender que algunos pasos no son evidentes ni triviales y preguntar puede ahorrar horas de frustración a prueba y error.
La puesta en marcha tiene varias pasos, a saber, puesta en marcha del hardware, instalación del software PiStar creado por Andy (MW0MWZ), configuración del hotspot mismo (local), configuración en el server DMR, modificación del codeplug del equipo que lo use y (finalmente) actualización del firmware del hotspot de ser necesario así como ajustes menores al ambiente Linux en el que corre.

Puesta en marcha del hardware

El primer paso depende muchísimo de cual es la placa específica de hotspot que se está usando; hay un número importante de modelos disponibles con diferente grado de compatibilidad entre ellos. La que yo adquirí es una placa MMDVM clone de origen chino. En lo profundo de lo barato, como para que quede claro. La placa es similar a la que está en la primer foto de ésta entrada. Es la placa misma, que consiste en un HAT (sombrero) para placa Raspberry Pi, el conector SMD de antena, la antena y dos peines de pines para la placa Raspberry. La placa MMDVM tiene el peine hembra, por lo que la placa Raspberry tiene que tener pines macho. No se que tenía en la cabeza el proveedor chino pero solo venía peine para una hilera y me pareció mecánicamente frágil pues queda un tanto "en voladizo". Asi que puse dos hileras de 5 pines en cada extremo. La soldadura de los pines y del conector SMD es razonablemente fácil siempre que se tomen las precauciones para tratar éste tipo de placas respecto a la estática, la potencia del soldador, la bondad de la soldadura, etc.
No hay mucha forma de probarlo hasta que se completan los pasos siguientes, pero al menos con la placa MMDVM puesto sobre la placa Raspberry hay toda una fantasía multicolor de los LEDs de la placa MMDVM que indica que "algo está haciendo", ahhh, y ausencia de humo, lo que es siempre importante.

Instalación del software PiStar

El firmware del hotspot es una distribución de Linux (Raspbian) sumamente recortada y ya configurada para funcionar sin necesidad de estar ni configurando el Linux mismo. El firmware se baja como una imagen (link) tal como habitualmente se lo hace con el Raspbian. Bajado el archivo hay que "flashearlo" sobre una tarjeta SD de al menos 8 GBytes. Para hacerlo yo utilizo Balena Etcher en mi Mac, pero puede usarse la versión de Windows o Linux de ese software también. En el caso de Windows también se puede usar Win32DiskImager. Todos ellos son equivalentes, no hay un notoriamente mejor que el otro, y su propósito es grabar la imagen del sistema operativo en la tarjeta SD.
Una vez finalizado hay una facilidad (link) que permite generar una configuración de la red WiFi que será útil. Los detalles están muy bien explicados en el excelente video de Hernán (LU7EHR) (link)en castellano o en éstos otros (link) o (link). Todos los videos, con matices, cuentan el proceso completo de configuración y no solo la instalación del PiStar. Es importante el paso de copiar el archivo wpa_supplicant.conf (configuración de conectividad wireless en Linux) al directorio boot de la tarjeta, pues es lo que permitirá luego al arrancar la placa Raspberry el que ésta tenga conectividad.

Configuración del Hotspot mismo

La tarjeta SD se coloca en la placa Raspberry, en mi caso utilicé una Raspberry Pi Zero W, la que por tamaño es muy apropiada. Puede usarse una Raspberry Pi 3, 3+, 4 (supongo, no lo probé) pero creo que es excesivo. Por alguna razón la configuración que usé no respondía al nombre "pi-star.local" por mas que estaba en la red, tuve que buscar con el programa nmap una dirección IP que no correspondiera a nada conocido e ingresar a ella (usuario: pi-star, password: raspberry). Uno siempre descubre que tiene mas cosas en la red que las que pensaba cuando hace ésto, así que puede haber un par de direcciones que no responden al intento de conexión. Cuando se puede entrar en la placa se lo debe intentar por una página web, suponiendo que la dirección asignada fuese 192.168.0.166 habría que acceder a la URL http://192.168.0.166  y cuando pida usuario y password indicar pi-star y raspberry respectivamente.
Alli se procede a configurar al hotspot propiamente dicho, seguir las indicaciones del video ya referenciado de Hernán (LU7EHR) que explica cosa por cosa con bastante detalle.
Dos aspectos que son un poco confusos y vale la pena aclarar. El DMR Id del hotspot es propio y diferente del que uno tenga configurado en el equipo DMR, y a diferencia de éste no hay que tramitarlo especialmente, básicamente se utiliza el que uno tenga asignado y se le agregan dígitos.  La red funciona en forma similar (conceptualmente) a como lo hace la red IP, uno obtiene "autorización" por su raiz pero se hace responsable de la gestión de todos los números que le sigan. Por ejemplo, mi DMR Id tramitado (equivalente a mi señal distintiva, y a los efectos prácticos lo es en DMR) es 7220292 , entonces arbitrariamente asigno a mi hotspot por ejemplo 722029201 y así lo configuro, la primera vez que se lo use exitosamente quedará registrado en "My Hotspot" en la página http://brandmeister.network que es la que en mi caso uso de DMR server (aconsejo hacer lo mismo, al menos inicialmente).
El segundo aspecto a considerar es que uno tiene que indicar un "servidor" de entrada, y al buscar "BM_....." con Argentina en la indicación no lo encuentra, bueno, hay que usar cualquier otro, a mi me funcionó bien el correspondiente a Chile, Brasil o Panamá.
Finalmente, hay que establecer una frecuencia en la que acceder al hotspot, en mi caso en la banda de UHF. Hay que tener cuidado que lo que ofrezca como default esté habilitado por nuestra reglamentación y que no esté en sub-banda de satélite.
Al finalizar la configuración habrá que configurar el handy, o el equipo en particular, mediante el codeplug para que permita operar con el hotspot.

Modificación del codeplug

El "codeplug" es un archivo de configuración que editado y cargado con las herramientas apropiadas en el equipo base o el handy permite definir en el mismo los recursos de la red, tanto propios como de otros. Esto es necesario porque en DMR la red se gestiona en base a los "servicios" representados por un DMRId, y éste puede ser uno mismo, una repetidora (duplex o simplex), uno hotspot, talking groups o individuos. Uno podría usar el recurso que quisiera, simplemente tipear el DMR Id correspondiente, en que frecuencia usarlo, que slot, que color y tantos otros parámetros necesarios. Pero no es práctico. Es mas amable tener todo lo que que uno va a usar en términos de red definido en el "codeplug" y cargado en el equipo para seleccionarlo cuando se lo vaya a usar. Típicamente estarán definidos los access points mas comunes (repetidoras simplex, duplex o hotspots), las estaciones que uno puede a querer llamar con cierta frecuencia en forma "privada" (directamente) o los talking groups (TG) que uno quiera participar o al menos monitorear.
La edición del codeplug se hace con un programa específico de cada base y los principales pasos pueden seguirse, para el caso del Baofeng DM-5R que me ocupa hacia la segunda mitad del video ya referenciado (link).

Verificación y ajustes menores

Con los pasos anteriores el hotspot debería estar completamente configurado para funcionar correctamente y el equipo para utilizarlo; de hecho en los distintos pasos de configuración se van haciendo pruebas para asegurar que lo que se va haciendo está correcto.
En el video de Hernán (LU7EHR) se agrega hacia el final un paso muy importante que en general observo no se le dá mucha importancia, y es asegurarse que el firmware está con la configuración mas reciente, vale la pena ver esa parte e implementarla.

Al mismo tiempo el hotspot queda configurado como un Linux embebido en nuestra red WiFi, por lo que si uno, como es mi caso, tiene otras máquinas funcionando y un esquema de red quizás convenga adaptarlo parcialmente para que armonice en esa red. Por ejemplo, asignarle una IP fija en la red, introducirle rutinas de mantenimiento, poner logs que controlen al procesador (temperatura, tensión, espacio en disco, uso de CPU, etc), quizás cambiarle el nombre (el default es PiStar pero en mi red las máquinas Rasbpberry tienen nombres de estrella de cielos del Sur, por lo que resulta renombrada como Theta-Crux o tcrux. Y alguna otra modificación menor. La imagen de PiStar representa un esfuerzo honesto de su autor para hacerlo lo mas masivo posible y que pueda ser desplegado prácticamente sin conocimientos de Linux, o con conocimientos mínimos. Debido a eso una vez desplegado lo más rápido posible se traslada al administrador a una aplicación basada en una página Web donde se configura el hotspot desde el punto de vista DMR. Desde éste punto de vista todo lo que es concebible de hacerse puede hacerse. Pero entrando al Linux con una terminal ssh la historia es otra, es un ambiente extremadamente restringido, con una configuración limitada y con prácticamente ningún paquete habitual disponible o incluso sin permisos para ejecutar cosas muy triviales (como un ping a otra máquina por ejemplo). En lineas generales nada es necesario para poder hacer andar el hotspot, y una Raspberry Pi Zero no tiene tantos recursos sobrantes como para andar compartiéndolos en otras actividades distribuidas de la red. Pero, no pudiendo con el genio, la terminé haciendo parecida a otras máquinas en cuanto a perfil de paquetes disponibles, a tener el software MPI de procesamiento distribuido, a ser parte de las rutinas de backup y restore y otras.
A pesar de todo lo hecho, sigo sintiéndome como con una cucharita parado enfrente del océano, lo cual es muy divertido por cierto.

Reporte WOW en WSPR

No hay día que no me asombre un poco mas sobre la capacidad del sistema WSPR de ser reportado desde distancias asombrosamente grandes y potencias asombrosamente pequeñas.

No me asombra tanto que sea ZL1RS quien reporte en WSPRNet, en éste caso, a mi baliza de WSPR 100 mW en 20 metros. Bob ya ha dado evidencia de lo soberbia que es su recepción reportando al picoglobo de LU1ESY en sus "órbitas" a distancias de varios miles de kilómetros. Pero en éste caso se trata de genuinas antípodas, en 20 metros, con propagación horrible (o quizás no tanto...) y con la antena de la baliza siendo un dipolo rígido apuntando al Norte. Como sea, una maravilla.

Windows On ARM (¡WOA!)

Hace poco menos de un año empezó a aparecer en los forums comentarios sobre un esfuerzo para trasladar Windows 10 a una plataforma Raspberry Pi; faceta visible de un esfuerzo mucho mas estratégico para tratar de mover la plataforma Windows a una arquitectura de procesadores ARM, fuera ya de su tradicional dominio de las plataformas Intel (llamadas, casualmente, "WinTel"). ¿Para que podría quererse correr Windows en una plataforma ARM?... se preguntará mas de uno....

Sin entrar en una segura polémica, donde cada uno tendrá su opinión basado en sus preferencias sobre cual es el "mejor" sistema operativo, lo cierto es que hay aplicaciones donde no hay alternativa a usar Windows. En mi caso me interesé por el WOA (Windows On ARM) intentando hacer funcionar mi nodo de monitor/beacon de WSPR/FT8 conectado con el Reverse Beacon Network. El paquete que lo posibilita se llama aggregator y solo funciona en Windows, y es además resistente a todos los trucos para hacerlo correr bajo Linux (incluso un Linux X86, ni hablar de un Raspbian). Intenté hace unos seis meses atrás esa instalación. Empecé asignando una placa en el cluster para ese fin (lambda-crux), me hice de una tarjeta SD de 32 GBytes (contra los 16 GByes que usualmente tengo) y me largué a seguir lo que me pareció ser las instrucciones mas detalladas para hacerlo. Para hacer un proceso bastante largo y frustrante corto diré que no fue facil, que probé varias conjuntos de instrucciones y que la mayoría de los intentos terminaron en ninguna parte. Por ninguna parte implico que en alguna parte de la secuencia me encontré con errores de sistema infranqueables que no me permitieron seguir. Finalmente conseguí terminar con una instalación y levantar un "Windows", solo para encontrarme con una performance inusable y con enorme dificultad para conectar aún los dispositivos mas básicos, y sin red. En aquel momento solucioné la necesidad utilizando un "PC Stick" Lenovo que corre un Windows 10 nativo (es una máquina X86 muy pequeña), el aggregator funcionó muy bien y pude validar que el Reverse Beacon Network tiene un soporte muy limitado de FT8 y ninguno de WSPR por lo que el proyecto quedó ahi.

Seguí, no obstante, mirando la evolución del proyecto WOA y constatando que seguía el flujo de liberaciones y que los reportes indicaban que paulatinamente los principales problemas se fueron solucionando. Sin una necesidad concreta no abordé volver a intentar instalarlo. Hasta recientemente, donde Daniel (LU9DPD) me consultó sobre alternativas para hacer funcionar un controlador/integrador de repetidor DMR implementado en un programa llamado wires X de Yaesu, el cual tal como el aggregator solo tiene una versión para Windows.

La idea es evitar tener una PC en una función 7x24 no atendida, para el cual una placa embebida es mas apropiada y un PC stick es muy caro.

Asi que apareció una segunda ventana de oportunidad para el WOA. Volviendo a revisar los links sobre el tema encontré que en su enorme mayoría tenían mas de 6 meses de antigüedad y de acuerdo a mis notas los había probado a todos (sin mucho éxito). Me encontré también con éste video en el canal DB Tech de YouTube bastante mas reciente, asi que empecé por el.

El video es muy corto, algo menos de 12 minutos, pero el proceso de instalación que explica dura varias horas y se compone de básicamente tres pasos.

Los primeros dos pasos deben correrse en una máquina Windows 10 nativa, en su momento intentos de correr estos pasos en un Windows 7, en un emulador de Windows 10 o en un Windows 10 embebido no fueron exitosos, debe ser una desktop o una laptop corriendo Windows 10. En mi caso fue una laptop:

• Crear un script (.CMD) yendo a un sitio (link) que construya una imagen ISO a ser instalada, bajando e integrando los paquetes necesarios. Para ello se seleccionan varias opciones sobre las características del WOA a crear con el siguiente mecanismo:

• Seleccionar "Windows (Final Version)".
• Seleccionar "W10 1903 versión arm64 2019-04.
• Seleccionar lenguaje "en-us" (English Americano), debería andar español.
• Seleccionar "Windows 10 Professional".
• Seleccionar "ISO Compiler".
• Al link "creatingISO..." darle "guardar link" con click derecho y salvarlo en la máquina local.

• Ejecutar el archivo .CMD bajado en el paso anterior, hacerlo como "Administrador" (click derecho "Ejecutar como Administrador") es muy posible que el anti virus proteste que no es seguro correrlo, pero es un falso positivo, hay que dar excepción para que permita correrlo. La ejecución tarda varias horas (no los 20 minutos que dice el video). Afortunadamente se lo ve funcionando al script todo el tiempo por lo que se sabe que va progresando. Eventualmente termina.
• Bajar el software "desplegador" o deployer (link) del WOA, el que básicamente baja la última versión de los drivers disponibles. Lo que baja es un archivo comprimido.
• Descomprimir el archivo bajado en el caso anterior, lo que generará una estructura de carpetas y archivos.
• "Montar" el archivo ISO creado por la corrida anterior.
• Correr el archivo ejecutable del desplegador.
• Al comenzar a ejecutar hay que indicar donde se deplegará el resultante (una SD Card). Cuidado, entre los posibles ofrece el disco de la máquina donde está corriendo, no elegirlo.
• Indicar que se quiere correr (sources/install).
• Al poco de lanzar (o al poco de ejecutar) aparece una pantalla de aceptación de términos de la licencia de los drivers, la que habrá que aceptar para poder correr
• El paso anterior correrá también por una hora larga, al finalizar quedará todo lo necesario en la tarjeta SD que se indicó.

El siguiente paso ya se ejecuta directamente en la placa Raspberry Pi, al cual se le coloca la tarjeta SD creada previamente. Debe ser una placa Raspberry Pi 3 o 3B o 3B+ (no encontré referencias a Raspberry Pi 4), creo fuera de posibilidad que WOA funcione en Raspberry anteriores o en la versión Zero habiendo visto la clase de consumo de recursos que utiliza es baja.

El WOA es bastante demandante del procesador, al que adicionalmente se coloca al máximo clock, por lo que es posible que sin un soplador empiece a dar marcas de estar a temperatura elevada (pequeño ícono de termómetro); la temperatura no alcanza valores críticos si eso pasa (si lo hiciera se apagaría el procesador), pero si es posible que el BIOS ponga la placa en "throttle" y le baje el clock con lo que la performance será m-i-s-e-r-a-b-l-e. Una consideración similar ocurre con la fuente de alimentación, al menos de +5V@2.5A, si fuera de mas capacidad mejor.

Antes de empezar, y esto es crítico, debe conectarse la placa mediante Ethernet a un router que pueda proveerle conexión a Internet (mediante DHCP), el WOA no tiene drivers para hacerle funcionar ni el Wifi ni el Bluetooth de la placa Raspberry y el soporte de "dongle" USB externos es muy limitado (no tuve suerte con ninguno de los que probé). El proceso de instalación se hace con monitor y teclado (y si es posible mouse), no está soportado una forma de hacerlo "headless" ( es decir, a través de red, como usualmente se configuran las placas).

Los pasos son:

• Arrancar la Raspberry Pi, comenzar a presionar repetidamente "Esc" para que traiga el menú de BIOS. Seleccionar:
• Procesador a clock "MAX".
• Seleccionar que haga boot desde tarjeta SD y no desde UEFI (queda en 2do lugar).
• Lanzar el boot.
• Al dar boot aparecerá el logo de Windows y comenzará un proceso de configuración automático que durará un tiempo algo cercano a la hora (depende de la placa que se use, la velocidad de Internet y otros factores). Durante esta fase puede emitir algún mensaje de error, pero siempre que dé la alternativa de seguir hacerlo.
• Al finalizar nos pedirá el usuario y password propio de Windows 10 (usualmente la cuenta de Outlook/Live/Hotmail) y aparecerá el desktop de Windows 10. Sorprendentemente con nuestra configuración habitual de Windows (con nuestra foto, por ejemplo)
• Luego hay que hacer la configuración habitual en cualquier máquina Windows.
• Nombre de la máquina.
• Configuración detallada de red (por ej. asignarle una IP fija si eso hiciéramos).
• Wallpaper.
• Configuración de teclado para no tener que adivinar las teclas.

Como comenté antes el WOA ahora anda (¡!) y el progreso ha sido gigantesco y es un milagro que ande, pero aún hay mucho por recorrer.

El WOA corre aplicaciones standard de Windows 10 aunque con la limitación que sean de 32 bits.

En la configuración recién instalada me reconoció al tiro el teclado USB y el mouse inalámbrico (2.4 GHz, no Bluetooth), pero no el teclado compañero del mouse. No me reconoció el adaptador Wifi USB y no encontré drivers. Como necesitaba un puerto serie tenía la alternativa de usar el UART nativo del Raspberry Pi (¡cuidado, sus niveles son +0V/+3.3V y no RS-232!) o intentar hacer funcionar un puerto serie USB tipo Prolific, el WOA tal como fue instalado no lo soportaba pero luego de varios intentos (y probando con varios dispositivos) logré que reconociera uno de ellos. 

El monitor convencional VGA con puerto HDMI lo reconoció de una, sin problemas.

El software que tenía como objetivo tratar de hacer andar parece funcionar correctamente. En el uso habitual la performance es muy lenta, hay que tenerle paciencia para usar las funciones gráficas. El procesador anda normalmente entre 70-100% de capacidad con un uso normal, pero baja a 25-50% con menor uso, por ejemplo una corrida batch. Como browser se utiliza el infame "Edge", que lento pero funciona. Intenté instalar y utilizar Chrome y aparentemente la performance no es suficientemente buena para usarlo.

Vale la pena la experimentación, por ahora la conclusión es que hay que esperarlo un poco mas para que se estabilicen los drivers existentes y aparezcan mas; posiblemente que se pueda utilizar en una Raspberry Pi 4 para mejor performance. Pero mientras tanto si hay alguna aplicación que necesita Windows 10 y una Raspberry Pi es suficientemente usable para intentarlo. "... con paciencia y con saliva..... el elefante....".