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

SDR... mas lento no se puede...

Siempre fui un profundo admirador de René Lavand (Héctor René Lavandera 1928-2015) mago e ilusionista argentino, quien con una deficiencia física (manco) hacía trucos de cartas increíbles. No solo eso, los repetía en "cámara lenta" para darle chances a su audiencia a que descubriera el truco, cosa que no ocurría nunca por supuesto. Luego con una semisonrisa cómplice decía "... mas lento no se puede" como para patentizar la insuficiencia de nuestros sentidos para poder detectar la grandeza de su arte. Un grande.

Esto viene a cuento que hice, con el tiempo, como propia la expresión "mas lento no se puede" para indicar pedagógicamente  una situación donde las cosas están tan simples y tan claras que el que explica no puede hacer nada más para ayudar a quien escucha a entenderlo, todo el resto le queda a él.

En esa línea se inscribe un repost , cuyo circuito repito, hecho en Facebook por Alejandro Wankiewicz (LW8DRU) en el grupo Radio Telegrafistas del Sur sobre otro post hecho por Osvaldo Nolla (LU1JY) sobre una interfaz simple para SDR en 40 metros. En rigor se trata de un receptor doble conversión, la sencillez misma, pero suficiente para con el concurso de un programa SDR (él recomienda el M0KGK) poder hacer las primeras armas en SDR al mismo tiempo que entrarle a un circuito simple, económico y por cierto mas que razonable para los primeros pasos. Este tipo de receptor fueron los que hacía cuando era chico en mis comienzos en radio, y si bien tiene la dificultad de tener la doble recepción (recibe la señal por arriba y por debajo del valor del oscilador sin distinguirlas) hay toda una serie de trucos que hacen que en la práctica no sea tan molesto. Por ejemplo, si pongo el oscilador en 7000 KHz prácticamente todo lo que reciba será USB en banda de aficionados. Si lo pongo en 7070 KHz todo lo que sea telegrafía será para abajo, y así sucesivamente. Por cierto que para recibir modos de señales débiles (WSPR, FT8, etc) es inmaterial el tema de la doble banda lateral. En resumen, un lindo proyecto para despuntar el vicio un ratito. ¡Felicitaciones al autor y al difusor! Y para los potenciales constructores.... "... mas lento no se puede..."!

Proyecto PixiePi, primeros resultados

Hace algún tiempo he compartido tanto por éste blog como en forums en redes sociales un proyecto en el que he estado trabajando como prueba de concepto de manera de integrar un procesador embebido de bajo costo (Raspberry Pi Zero), un transceptor QRPp minimalista (Pixie) para 7 MHz, algo de hardware de interfaz, las facilidades para transformar una Raspberry Pi en un DDS de bajo costo aportadas por la librería librpitx de Evariste (F5OEO). No estoy inventando nada que no esté inventado ya, pero si realizando una integración de componentes accesibles tecnológica y económicamente para implementar un dispositivo de radio que, aún siendo básico, permita comunicar. Esto lo hago con los modos de bajas señales, especialmente WSPR y FT8, que permiten contactos con potencias ridículamente bajas tal como lo he experimentado hasta el cansancio con los reportes que obtiene mi beacon de WSPR Y FT8 en 20 metros transmitiendo con solo 20 dBm (100 mW)!

El proyecto pasó por interminables bosquejos que nunca salieron del papel, con distintas configuraciones, seguidos de varios prototipos basados en Arduino utilizando como DDS un AD9850 primero y un Si5351, los que en general llegaban a funcionar pero no me convencía la solución de software. Por la naturaleza de la arquitectura Arduino el firmware es uno solo, y si quería poner todos los modos a implementar mas todas las facilidades de soporte me iba muy rápidamente de la capacidad de una placa Arduino Nano o Arduino Uno, que eran mis objetivos. Así que hace ya algún tiempo migré mi experimentación casi exclusivamente a la plataforma Raspberry Pi. Pequeña maravilla de costo razonable la he utilizado en muchos proyectos, me encuentro muy a mis anchas con Linux y un gigantesco ecosistema de librerías disponibles para casi cualquier cosa.

Con esas facilidades cambié la arquitectura del proyecto para utilizar programas específicos para cada modo construidos con librerías separadas para las distintas funciones que se le adjuntan en el momento de compilarlos y eventualmente librerías o programas con los que interactúa en tiempo de ejecución. El ecosistema resultante es un poco intrincado pero termina siendo de una complejidad razonable como para operar en forma confiable. Voy implementando entonces un programa gestor del transceptor mismo (pixie), un emisor de WSPR (PiWSPR), un programa DDS genérico (DDSPi), un emisor de RTT (PiRTTY), puede usarse sin modificaciones la mayor parte del suite de programas rpitx también de autoría de Evariste. Seguramente habrá otros programas en el futuro en la medida que vaya desarrollando y experimentando. SSTV, PSK31, Packet,... y por que no SSB.

La mayor parte del material está en el repositorio GitHub lu7did/PixiePi que alberga el proyecto, este repositorio es estrictamente hablando solo para código y documentación, pero a falta de tiempo lo estoy usando como repositorio de todo el proyecto.

El transceptor Pixie es bien básico, mientras actúa como receptor la etapa de salida es alimentada en baja señal y actúa como mezclador, el resultado de la mezcla es filtrado en forma muy primitiva para separar el audio del RF y amplificado (mucho!) por un integrado LM386. En transmisión la etapa de salida opera en alta señal y amplifica hasta una potencia de salida de entre 100 y 300 mW dependiendo de la antena. Con mayor excitación y ajustes menores se puede llegar a sacar hasta 500 mW del kit, pero no es recomendable. De hecho aún operando a 200 mW en emisión en CW la temperatura del transistor de salida aumenta rápidamente desde temperatura casi ambiente hasta unos 70 C. Operando el transceptor en modos que requieren tiempos prolongados de encendido tales como FT8 o WSPR el transistor de salida se arruina rápidamente si no se le pone un disipador. En mi caso bastó una plancha delgada de aluminio de 1"x0.5" y una pestaña para ajustar al transistor de salida, colocando luego abundante pasta de conducción de calor para mejorar la transferencia térmica. Con éste fix el equipo lo he probado encendido en transmisión permanente por mas de una hora (en realidad no fue una prueba sino un accidente, pero sobrevivió).

Hay una serie de modificaciones detalladas en el portal GitHub que deben ser tenidas en cuenta para construir el kit de manera que sirva para éste proyecto. Es muy importante que, dado que se construye sin cristal, el kit Pixie no emita por si solo, ni aún presionando el manipulador; esa condición indicaría auto-oscilación y debe ser eliminada.

Luego de construir el kit se dispone de una placa Raspberry Pi, en rigor cualquiera, pero en el espíritu minimalista del proyecto utilicé la mas pequeña disponible, la Raspberry Pi Zero W. Es importante que sea la "W" porque indica "Wireless" o sea que tiene WiFi incorporado, dado que el equipo se usará en modo "headless" (mas de eso luego) es importante poder conectarlo por medio de la red, aunque hay una forma de usar una conexión "local" (mas de eso luego también) que permite conectar una Raspberry Pi Zero a una computadora mediante el puerto USB evitándose la conexión inalámbrica.

La salida designada para RF es la GPIO4, aunque puede usarse la GPIO20 con el mismo propósito y se conecta a la placa Pixie mediante una interfaz sencilla (indicada como MODS en la documentación). Adicionalmente hay que articular el PTT, implementado con un transistor 2N7000 excitado por la salida GPIO12 y la posibilidad de un subtono (por ahora muy horrible) generado mediante PWM usando la salida GPIO19.

Con las funciones de la librería librpitx se genera una señal de RF en cualquier frecuencia entre 1 MHz y 1 GHz, el proceso es maravilloso y simple al mismo tiempo, fue explicado en entradas anteriores. Para las pruebas iniciales no es necesario construir ningún programa del paquete, el programa tune del paquete rpitx tiene lo necesario para las pruebas iniciales, básicamente cuando se lo llama emite una señal de rf de la frecuencia indicada por el puerto GPIO4, y lo hace hasta que se lo interrumpe con ctl+C. Sin embargo, para operar la placa Pixie como transceptor es necesario implementar algunas funciones adicionales de las que carece el programa tune aunque para un uso básico al manipular la linea KEY de la placa Pixie bastaría para ponerlo en transmisión y emitir.

Pero para cualquier uso práctico al activar  la linea KEY (colocándola a masa) de la placa Pixie hay que al mismo tiempo correr la frecuencia del VFO en 600-700 Hz como shift del tono de telegrafía, caso contrario el corresponsal nos tomaría con una frecuencia de VFO similar y estaríamos corridos. Al mismo tiempo, es necesario generar alguna señal auditiva que se está emitiendo para tener el necesario "feedback" auditivo de lo que uno está transmitiendo. Ambas cosas son deficiencias básicas del diseño Pixie solo tolerables a cambio de su simplicidad. Para generar el feedback auditivo se genera un tono mediante PWM usando la linea GPIO19 que se alimenta al pin 7 del LM386 que opera como amplificador del Pixie, todavía es una solución que tiene que mejorar pues el tono dista de ser bueno.

Con estas funciones bastaría para hacer comunicados tal como se los haría con el Pixie sin necesidad de un procesador. Pero el software implementa muchas otras funciones que ya exceden largamente las posibilidades de una placa sencilla de transceptor. Cambio de frecuencia, doble VFO, split, RIT, distintos modos, tono shift variable, break-in, potencia variable, manipulación electrónica y muchas otras. Todas esas son funciones implementadas en el programa pixie del paquete PixiePi. Hay funciones que estoy experimentandolas aún
, tal como solo prender el DDS cuando se transmite de forma de poder usar un receptor externo (¿un RTL-SDR dongle, quizás?). La versatilidad es gigantesca.

Para operar el transceiver se adapta una interfaz de usuario compuesta por un display LCD 16x2 y un rotary encoder con "push", con el auxilio de los cuales se dispone de un dispositivo totalmente autónomo, aunque eso es relativo. La librería rpitx corrige la estabilidad de la frecuencia mediante el uso del protocolo NTP, por lo que una conexión a Internet no es imprescindible para operar en CW pero prácticamente es mandatoria para sincronizar la hora de los modos digitales de bajas señales. Con un esquema restringido el "dial" sirve tanto para sintonizar como para elegir las funciones una vez puesto en modo "comando", incluso he diseñado una caja modelandola para impresora "3D" para implementar la base y el frente, todavía hay que ajustarla bastante porque tiene varios defectos de diseño y no imprime bien en 3D pero es un punto de partida.

Una de las funciones mas potentes del diseño es la posibilidad de incorporarle CAT (Computer Aided Tuning), para lo cual implemento el protocolo CAT del Yaesu FT-817, protocolo con el que estoy muy familiarizado de otros proyectos y que es suficientemente potente. Para utilizarlo se simula una linea serie "virtual" mediante un "pipe" utilizando el programa socat, de tal manera otros proflrig o la de modo texto del programa rigctl del paquete Hamlib; en lineas generales la GUI de flrig es mas bonita y funcional pero consume muchos recursos para una Raspberry Pi Zero, mientras que rigctl es mas frugal pero prácticamente no consume recursos.

De esa manera programas como flrig o la librería Hamlib "creen" estar hablando con un transceptor Yaesu, pero solo lo hacen con el programa. De esa forma es posible trabajar en modo "headless", es decir sin un teclado y monitor físicamente asociado a la placa Raspberry ni con un display LCD y controles físicos. Simplemente se corre el programa y se lo acceder en modo terminal mediante SSH, para manipular los comandos CAT para controlar su funcionamiento se utiliza la interfaz gráfica dada por el programa.
Luego de trabajar algunos problemas de estabilidad intermitentes (cierta tendencia a colgarse de la placa Raspberry, requiriendo un hard reboot) y de algunos comunicados locales de rigor continué trabajando con la implementación WSPR y FT8. Con QRPp a nivel de 200-300 mW se pueden hacer, con una buena antena, contactos de compromiso en CW (¡algunas veces sorprendentemente buenos!) pero el potencial real está en los modos de baja señal.

En recepción las primeras pruebas las hice alimentando la señal de audio (PHONE) de la placa Pixie a la placa de sonido de la PC de mi estación corriendo WSJT-X, primero en WSPR y luego en FT8, como para evaluar el rendimiento de un receptor tan simple, y el resultado me sorprendió (muy) gratamente. A poco de andar ambos modos registraron reportes de estaciones operando en la frecuencia, en el caso de WSPR señales de mas de 500 millas (PY-3). Un resultado equivalente, pero mas local, lo obtuve también con FT8. Superó mis expectativas ¡Realmente sorprendido!
Para emitir en ambos modos implementé un programa (PiWSPR) que es una baliza, emite un frame WSPR y termina. El Pixie no tiene problemas en emitir éste tipo de señales pues se tratan de variantes de modulación en Fase/Frecuencia donde la amplitud es constante. Nuevamente, tanto en WSPR como en FT8 al poco de hacer andar ambos en modo baliza comencé a recibir reportes automáticos tanto de WSPRNet como de PSKReporter (para WSPR y FT8 respectivamente) con distancias sorprendentemente grandes para la potencia involucrada.
En resumen, en una etapa muy preliminar del proyecto y aún con mucho por desarrollar tanto en el hardware como en el software me he tropezado con una implementación que pone en juego un gran número de tecnologías, por lo que el aprendizaje es formidable, pero el mismo tiempo la "receta" para duplicarlo es increíblemente simple de manera que puede quedar al alcance de un principiante con ganas de sacar lustre al teclado o chamuscarse un poco los dedos, o ambas cosas.
Queda por delante varias posibles rutas y el tiempo disponible dirá cual puedo seguir y con que intensidad; por lo pronto todos los modos de "amplitud constante" tales como RTTY, PSK31 y SSTV están a tiro de implementarse solo desarrollando el programa respectivo, del cual tengo ya prototipos con las cadenas DSP necesarias funcionando (publicados en entradas anteriores). Luego vendrá el desafío de hacer andar esta placa, siquiera en forma mínimamente aceptable, en SSB. Parece a priori un desafío imposible dada la naturaleza de la amplificación en un Pixie, pero confío que experimentando con la modulación PWM sugerida por PE1NNZ que comenté previamente puede abordarse una solución que no sea una "puñalada" a los oídos. Las modificaciones a la placa Pixie serían realmente muy pequeñas y el grueso de la "magia" estaría en software, aunque hay que validar si para el procesamiento intensivo DSP necesario alcanza una Raspberry Pi Zero o es ya necesario alguno de sus hermanos mayores (3,3B y porque no 4! fantástica excusa para conseguirme una). Esta misma implementación puede ademas utilizarse para otros modos como packet AX.25 o APRS, pero eso es ya materia de experimentación mas diversificada. Finalmente, y si bien estoy mas que conforme con la performance del receptor simple de la placa Pixie, quiero probar que pasa si uso la cadena solo para transmitir y un dongle SDR-RTL para recibir. Como siempre digo, muchos proyectos y poco tiempo.

DMR en LU7DID, el nuevo BAOFENG DM-5R

Luego de darle algunas vueltas al asunto terminé sucumbiendo a la tentación de explorar el modo DMR . Hace algunos años tuve un cierto involucramiento profesional con la tecnología a partir del despliegue de redes de comunicaciones basadas en la tecnología TETRA implementada por Motorola para redes de servicio público. Asi que pude pasar rápidamente por la parte donde se explica la base de como funciona (como funcional el TDMA, el concepto de tier, etc.). En aquel entonces (una buena década y media atrás) no había redes de éste tipo para uso de aficionados, al menos en Argentina, al menos que conozca. Pero recientemente comencé a leer y me fui adentrando en la implementación para radio aficionados, porque una cosa es la tecnología básica, pero si no se conoce la topología de la red, su configuración y los recursos de "talking groups" (TG) uno no tiene ni por donde empezar.

Hay muchas formas de comenzar, y elegí una simple, adquirí un handy Baofeng DM-5R. Son esas compras que uno las hace y luego revisa en profundidad encontrando que los comentarios no son tan buenos como a uno le gustaría. Desde cierta dificultad de uso hasta que directamente no soportaba partes esenciales del protocolo (capacidad de conectar en Tier 2, es decir, de usar repetidoras). Tengo un Baofeng UV-5R, versión analógica de éste mismo handy, con el que realmente estoy muy satisfecho. Al recibirlo pensé que familiarizado con esa versión y con conocimientos de la tecnología bastaba para empezar a salir, haciendo corta una historia larga el primer set con el handy fue un contundente 0-6 a favor del handy, no lo pude hacer andar bien ni en modo analógico. El manual, el manual es horrible, mal organizado, mal traducido y muy poco útil en general. Así que, guardé y volví a modo lectura, pidiendo ayuda además en el reflector de WhatsApp del RC.Avellaneda (LU7EO). Ahí me dí cuenta que la mayor parte de los vídeos que reflejaban problemas eran relativamente viejos, dos o tres años de antigüedad, siendo que en general los vídeos mas nuevos referían que la mayor parte de los problemas habían sido mayormente solucionados. Dos videos cortos y útiles fueron éste para una descripción general y éste para los aspectos de programación. El segundo round fue mucho mas productivo, luego de haber leído el manual y revisado como era la navegación de los menúes de configuración (bien diferentes al UV-5R) pude en poco tiempo hacer funcionar el handy con la repetidora local de LU3DY (147.12+600 100Hz). Luego de renegar un poco pude hacer funcionar el programador de codeplug  y la configuración para la zona AMBA para los recursos en que me pasó Daniel (LU9DPD) y alli pude, si, hacer bastantes pruebas sobre la repe LU7EO y los varios recursos (Talking Group, TG) disponibles. Como en general operan los modos digitales la comunicación es cristalina, vástamente superior a su equivalente en fonía analógica, hasta el punto donde los errores son tantos que deja de haber señal. Es decir la señal tiene la inteligibilidad de una señal local o nada. Pude probar una cucharadita de té de éste océano imponente de posibilidades, será cuestión de ir profundizando.