Transceptor de señales débiles, bit a bit (Parte 4)

A poco de operar wsjtx con la configuración que se viene discutiendo se hacen obvios algunos

problemas. El primero es que la "ganancia" del receptor implementado con rtl_fm no parece ser mucha, el segundo es que no se ha implementado una forma de transmitir con wsjtx y al intentar hacerlo con la baliza basada en WsprryPi que se discutiera previamente aparecen problemas prácticos y de protocolo.
Un truco útil a ésta altura es poder probar si el dongle RTL-SDR es correctamente reconocido por la placa, normalmente podemos ver cuando todo está funcionando un patrón de recepción de señales bien distintivo en el "waterfall" de wsjt-x, pero como en todo sistema que tiene muchos componentes es bueno tener alguna forma de ir partiendo el problema en pedazos manejables, aqui se puede usar el comando "rtl_test" el cual revisa que el dongle funciona correctamente, es bueno hacerlo antes de seguir experimentando.

Usando rtl_sdr (método #2)

El método recomendado por el artículo ya referenciado "Tutorial: Setting up a Low Cost QRP (FT8, JT9, WSPR etc) Monitoring Station with an RTL-SDR V3 and Raspberry Pi 3" [link] usa un método de recepción diferente, usando diferentes programas, y uno empieza a sospechar que quizás hay algún motivo por el cual lo hace así.
Este método involucra varios programas nuevos que la configuración anterior no usaba, ncat ("network cat") y en particular una pequeña joya llamada csdr.
El enfoque es un poco diferente, empieza por otro programa disponible en el paquete rtl-sdr (no hay que bajar ni compilar el paquete de vuelta) que se llama rtl_sdr justamente (notar que es con guion bajo "_" en lugar de alto "-") y opera en forma mas primitiva si se quiere que rtl_fm, de hecho no realiza ningún intento de demodular la señal. Básicamente entrega las muestras "crudas" tal como salen del dongle RTL-SDR, las que tienen que ser procesadas para que, finalmente, puedan ser digeridas por wsjtx. Entonces todo lo que antes "rtl_fm" hacía por dentro hay que hacerlo por fuera.
Los scripts, son dos ahora y  lucen asi:

El "receptor" propiamente dicho

#!/bin/sh
rtl_sdr -s 1200000 -f 14100000 -D 2 - \
    | csdr convert_u8_f  \
    | ncat -4l 4952 -k --send-only --allow 127.0.0.1  &

El decodificador SSB será:

#!/bin/sh
FX=$(python -c "print float(14100000-14095600)/1200000")
ncat -v 127.0.0.1 4952 \
     | csdr shift_addition_cc $FX \
     | csdr fir_decimate_cc 25 0.05 HAMMING \
     | csdr bandpass_fir_fft_cc 0 0.5 0.05 \
     | csdr realpart_cf \
     | csdr agc_ff \
     | csdr limit_ff \
     |csdr convert_f_s16 \
    | mplayer -nocache -rawaudio samplesize=2:channels=1:rate=48000 -demuxer rawaudio - &

exit 0

Es interesante entender la estructura de éstos dos scripts y su rol en la operación como receptor.
Hay que empezar diciendo que el paquete csdr es un procesador DSP simplificado (pero extremadamente potente) escrito Andras Retzler (HA7ILM) como parte de su tesis de grado/maestría [link] donde cada operación puede ser implementada por conversiones simples donde el "flujo" de entrada viene por "standard input", la operación a realizar indicada por el argumento con que se llama a csdr y el resultado puesto en "standard output". De esa manera opera con una filosofía similar a la de los procesadores DSP nativos, donde el flujo de señal digitalizada fluye en forma continua y es sometida a distintos procesamientos en respectivas colas de entrada/salida.
El primer script "lee" desde el dongle con una tasa de muestreo de 1200000 muestras/segundo y los entrega al siguiente paso donde csdr convierte las muestras I/Q (en formato 8 bits unsigned) a punto flotante para poder aplicar sobre los mismos algoritmos de procesamiento digital, a continuación coloca el resultado en una cola implementada con un socket TCP/IP por medio del utilitario ncat. La especificación dada a ncat hace que éste sea en una dirección y puerto de modo que solo otro proceso en la misma máquina pueda leerlo. El símbolo "&" al final del comando comanda que el mismo quede ejecutando en el background en forma permanente.
En otro script separado ocurre el resto del procesamiento, como se dijo, debe correr en la misma placa (dirección IP 127.0.0.1). Primero se lee la corriente de datos de punto flotante generados en el paso anterior, lo que vuelve a hacer el programa ncat. Luego la señal es sujeta a varias manipulaciones, que para cualquier familiarizado con el proceso digital de señales rápidamente identifica como los necesarios para demodular SSB por el método de la rotación de fase. La señal es desplazada, diezmada, filtrada, limitada en su amplitud por un sistema AGC y finalmente convertida de vuelta desde formato de punto flotante a 16 bits con signo, que es como los "stream" de audio son representados.
Al final del proceso, y como se hacía en el script anterior, es el reproductor multimedia mplayer el encargado de reproducir el audio demodulado. Como en el caso anterior el comando se lanza a ejecutar en el "background" mediante la indicación "&".
Hay algunos elementos a considerar. El primero es que la recepción no se hace en la frecuencia que deseo escuchar sino un poco desplazado (en éste caso 14.100 MHz), eso es para que la señal que queremos escuchar no caiga justo en el "cero" del cálculo digital, en el demulador se corrige ese efecto por la diferencia entre el primero y la frecuencia que se desea escuchar (14.0956 MHz en el ejemplo, frecuencia de WSPR). Para tomar en otra frecuencia (dentro de +/- 24 KHz del oscilador local del RTL-SDR) solo hay que alterar el 2do script. En el script están marcados con distintos colores los números que están relacionados y deben cambiarse en forma conjunta.
Hay varias otras particularidades que vale la pena detenerse. La primera es porque canalizar todo el flujo de datos por un socket mediante ncat, en definitiva se graba y lee en la misma máquina, porque no hacer "ducto" (piping) desde un procesamiento de csdr al otro sin pasar por ncat, y hacerlo todo en un solo script. Hay buenas razones para hacerlo así; he encontrado al menos dos, y es posible que existan mas.
La primera es que, como expliqué en el caso de mplayer, hay una acción de "buffer" que suaviza el flujo de multimedia y lo hace mas parejo. El segundo, mas importante, es que para que los algoritmos de la segunda parte funcionen necesitan datos. Y el programa "rtl_sdr" tarda un par de segundos (una eternidad) en comenzar a funcionar, de esa forma el segundo script termina "anormalmente" por "broken pipe" (ducto roto) por no tener datos si se lo arranca demasiado rápido. La forma de trabajar es lanzar el primer script y luego que éste comenzó a operar hacerlo con el segundo.
Si bien ambos script tienen "&" al final y se lanzan el el background para las pruebas es quizás útil arrancarlos y detenerlos, o que es muy facil con Ctl-C si están en una sesión normal pero que requiere un par de comandos para hacerlo si están en el background como por ejemplo sudo pkill o "pgrep | kill".  Por eso mientras se prueba puede ser conveniente abrir sendas ventanas de un procesador bash (terminal) y lanzar cada script en la suya.
Esta sincronización en el arranque, trivial de hacer a mano pero que no es tan trivial hacerla en forma automática puede automatizarse mediante un script receiver  el que usa un truco mediante una pipe para lanzar el primer script y quedarse observando su salida hasta que aparece en ella un texto que indica que completó su arranque para solo entonces lanzar el segundo.
Una vez lanzados ambos script puede observarse en el panel de pavucontrol que está disponible mplayer como fuente de una corriente (stream) de datos multimedia, el cual, como en el caso anterior, se puede asociar a un extremo del cable virtual, pudiendo asociar el otro extremo a wsjt-x.
Integración feliz, sistema estable. consumo de CPU y memoria es muy modesto, en un RBPi de 4 núcleos típicamente habrá uno de ellos usado al 25-35% en la máquina que corre wsjt-x. Es necesario monitorear la temperatura y quizás sea conveniente disponer de un pequeño ventilador, el conjunto entre el procesador haciendo cálculos continuamente y el calor mismo del dongle RTL-SDR hace que la temperatura de la placa RBPi opere entre 65 y 75 °C, dentro de limites seguros, pero si la temperatura ambiente no coopera puede fácilmente superar los 80-85 °C que si ya representan un problema.La configuración es estable, efectiva, se mantiene operando si no existen inconvenientes con buena disponibilidad y el consumo de CPU es modesto tanto en recepción como en transmisión. Es posible automatizar el lanzamiento de todo el conjunto cuando se arranca la máquina de forma que cada vez que se lance el GUI también se lance el script "receiver" y al programa wsjtx.

Voila!! wsjtx estará recibiendo señales WSPR! O en FT8 cambiando donde dice 14095600 por 14074000.

Transceptor de señales débiles, bit a bit [Parte 3]

Siguiendo con la linea de tiempo del proyecto la baliza estuvo operando durante varios meses donde progresivamente fui trabajando en su estabilidad y confiabilidad haciendo muchas pruebas, la mayor parte sin resultados significativos como para compartirlos. Pero lo cierto es que  llegó el momento de querer experimentar con promover la baliza a una estación de monitoreo de WSPR, es decir que pudiera operar como baliza (y ser reportada) y como estación receptora (y reportar). Una elección inicial obvia fue buscar la respuesta en el programa wsjt-x trabajando con alguno de los transceptores de la estación, pero a poco de pensarlo me quedó claro que no era ese el propósito de la experimentación.

Es claro que para operar como receptor el RBPi necesita hardware adicional. Para eso es ideal utilizar un dongle RTL-SDR, el cual representa un buen compromiso entre funcionalidad y costo. Este dispositivo puede ser configurado como un procesador SDR capaz de sintonizar en el rango nominal de 28 MHz a 1.5 GHz proveyendo una gama de posibilidades en su tasa de muestreo (y por lo tanto la anchura de la banda base). En una cuenta rápida, si la tasa de muestreo es 1200000 muestras/seg el teorema de Nyquist nos ayuda a comprender que se pueden sintonizar segmentos de algo menos de 600 KHz por vez, y el RTL-SDR puede manejar el doble de eso (cómodamente) e incluso llegar a anchos banda de hasta 4 MHz (ver especificación). En realidad se necesita muchisimo menos que eso, el máximo ancho de banda que se requiere para modos digitales de señales débiles es el de un transceptor de SSB en fonía, es decir 2.5 KHz, la enorme cantidad de muestras puede hasta ser una molestia innecesaria, aunque termina agregando "resolución espectral" al proceso de demodulación que es muy útil. El dongle trabaja en un rango de frecuencias muy interesante pero que comienza en el HF lejano (28 MHz) y se extiende bien dentro del rango de VHF y UHF. Sin embargo mi principal interés es operar señales débiles en el rango de bandas bajas de HF. Para extender el rango del dongle lo recomendado es utilizar un "upconverter" que convierta las frecuencias "hacia arriba" desde HF a alguna banda dentro del rango de funcionamiento del RTL-SDR, hay dispositivos comerciales (caros...) o puede hacerse uno casero pues son relativamente simples [link]. Sin embargo los modelos mas recientes del RTL-SDR tienen una función que se denomina "direct sampling" (muestreo directo), que si bien degrada un poco la performance [link]; si bien no experimenté con upconverter (el cual objetivamente es una mejor solución técnica) los resultados con muestreo directo fueron suficientemente buenos como para adoptarlos. En algunos modelos antiguos de RTL-SDR hay que realizar una modificación de hardware para habilitar el muestreo directo, lo que es confuso y luce limitante, pero en los modelos mas recientes es una función que se habilita por software y soportado por la versión actualizada de los drivers.

Para poder un utilizar dongle RTL-SDR  en una RBPi hay que instalar drivers adecuados, uno de los cuales es la librerías denominada librtlsdr. Para evitarnos tener que desarrollar la aplicación que implemente las funciones de la librería es útil recurrir a programas ya hechos, y uno de los más útiles que encontré fue el paquete rtl-sdr

Hay varias versiones ("branches") en desarrollo, algunas mas estables que otras, y otras de naturaleza mas experimental. La que utilizo es una experimental porque tiene algunas funciones que me son útiles. Para instalar ambas librerías:

#!/bin/sh
#*----- Install librtlsdr

sudo apt-get update
sudo apt-get install git build-essential cmake libfftw3-dev pulseaudio pavucontrol mplayer
sudo apt-get install  libusb-1.0-0-dev curl libcurl4-gnutls-dev ntp
sudo git clone https://github.com/steve-m/librtlsdr 
cd /home/pi/librtlsdr
sudo mkdir build
cd build/
sudo cmake ../
sudo make
sudo make install
sudo ldconfig

Y para instalar el paquete rtl-sdr

#!/bin/sh
git clone https://github.com/keenerd/rtl-sdr
cd rtl-sdr/
mkdir build
cd build
cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
make
sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
sudo ldconfig

sudo reboot

Este paquete permite explorar distintas alternativas para construir una cadena receptora completa.

Usando rtl_fm (método #1)

Como parte del paquete está el programa rtl_fm, originalmente concebido para poder demodular señales de FM de banda ancha (comercial) y posteriormente expandido para recibir prácticamente todos los modos. Es parte de los programas compilados al construir el paquete rtl-sdr y su funcionamiento consiste en leer muestras desde el dongle, filtrarlas de acuerdo al modo que se esté demodulando, diezmarlas (decimarlas) para retener solo un número de muestras consistentes con el ancho de banda del modo que se está demodulando (desde centenares de KHz a un par de ellos) y producir una señal "cruda"  de audio digital que puede ser reproducida por un reproductor multimedia como aplay o mplayer. El primero está normalmente instalado por defecto en la distribución Raspbian, mientras que el segundo fue instalado como parte de los paquetes desplegados en el paso previo.
El script típico de ejecución será usando mplayer:

rtl_fm -M usb -g 29 -s 1200000 -f 14095600 -r 48k -l 0 -E direct \
    | mplayer -nocache -rawaudio samplesize=2:channels=1:rate=48000 -demuxer rawaudio -

Usando aplay hay que cambiar la segunda parte de la cadena poniendo parámetros similares correspondientes. En sucesivos experimentos he tenido mejores resultados (mas continuos, menos interrupciones) con mplayer, probablemente debido a que mplayer prioriza la continuidad de la reproducción y por lo tanto establece buffers para asegurarla. El precio es que tiene un retardo de entre 2 y 3 segundos en su ejecución, lo que en modos digitales de baja señal terminan siendo críticos y deben ser compensados, veremos como mas tarde.
Desafortunadamente, el programa rtl_fm opera en modo direct sampling con el canal 1 (I) y para éste uso se debe habilitar el canal 2 (Q), la modificación es simple, hay que editar

nano /home/pi/rtl-sdr/rtl_fm.c

Y cambiar

if (strcmp("direct",  optarg) == 0) {
dongle.direct_sampling = 1;}

por

if (strcmp("direct",  optarg) == 0) {
dongle.direct_sampling = 2;}

Luego del cambio hay que salvar el fuente y construir nuevamente el paquete para lo cual hay que ejecutar

cd /home/pi/build
cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
make
sudo make install
sudo cp ../rtl-sdr.rules /etc/udev/rules.d/
sudo ldconfig
sudo reboot

Si ejecutamos el script y abrimos el diálogo de pavucontrol veremos que hay una instancia de mplayer operando como "fuente", si asociamos a ella la salida de auricular de la RBPi o una placa de sonido USB y conectamos auriculares a ella "escucharemos" el receptor tal como lo haríamos en un transceptor común.
Podremos por supuesto cambiar la frecuencia y utilizar esta misma configuración con frecuencias de FT8 (14074.0 KHz), o CW, o SSB, o RTTY o PSK o SSTV, es un receptor SSB (USB) como cualquier otro. El único detalle es que tendremos que cancelar el script (con Ctl-C) para editar la frecuencia en cada caso, no muy ágil para "ruletear" la banda, pero mas que adecuado para "escuchar" un segmento cualquiera haciendo pruebas.
Parece muy poco cómodo pero si uno empieza a pensar un poco con criterio Linux empezará a ver los problemas como una sucesión de pequeños módulos que se conectan unos con otros para lograr un propósito, en esa dirección no sería descabellado inventar un programa que actuando de "pantalla" permita manejar los controles de un transceptor (receptor por ahora) en cuanto a frecuencia, modo, ganancia y otros para, una vez especificados, actuar en la "trastienda" deteniendo el script y lanzándolo nuevamente con los nuevos argumentos. Pero no hace falta inventar eso, ya está inventado, es el programa qtcsdr, solo que usa otras formas de implementar el transceptor (nada impide cambiarselas a éstas, pero eso, eso es otro proyecto).

Hay un buen número de cuestiones prácticas que resolver para integrar un "transceptor" virtual implementado a partir del dongle RTL-SDR (u otro similar) con wsjt-x de forma de utilizarlo en modos de señales débiles, primariamente WSPR y FT8.

Mucho de lo que viene a continuación toma ideas originalmente expuestas en un artículo fantástico denominado "TUTORIAL: SETTING UP A LOW COST QRP (FT8, JT9, WSPR ETC) MONITORING STATION WITH AN RTL-SDR V3 AND RASPBERRY PI 3" [link] cuya lectura es altamente recomendable.
El primero es como lograr que el "audio" generado por el transceptor pueda ser utilizado por wsjt-x.

No es difícil pensar en una solución mas bien de fuerza bruta, con pavucontrol (previamente instalado) conectar la ejecución de mplayer a la salida de una placa USB de sonido, conectar con un cable la salida a la entrada de MIC, configurar wsjt-x para que tome como su entrada a esa y ajustar los niveles de audio para que no haya distorsión. Todo lo que no tiene de elegante el método lo tiene de efectivo, por cierto que anda.
Pero es cierto también que hay formas mas elegantes de hacer lo mismo, y sin necesidad de una placa física USB, el procesamiento de ese audio por esa placa dista de ser gratis en términos de CPU y en la RBPi la CPU no sobra....

Para salvar esta situación se recurre a un "virtual cable" o cualquiera de los nombre con que se lo encuentra; se trata de un programa que tiene la habilidad de comportarse como una placa de sonido (virtual) que opera como un "cable", todo lo que se le coloca en una entrada (virtual) sale por la otra (virtual también). La carga de CPU es enormemente menor, en realidad los datos casi no sea procesan, solo se mueven punteros en memoria muy rápida y eficientemente.

Hay al menos dos formas de implementarlo en forma mas o menos sencilla, una es usando snd-loop y la otra pulseaudio. Ambos son "cables virtuales", el primero viene ya en la distribución RSBPi pero hay que activarlo, al segundo hay que instalarlo.

Para activar y configurar snd-loop hay que seguir los siguientes pasos:

[activar snd-loop]

[configurar  snd-loop]

Para instalar y configurar pulseaudio hay que seguir los siguientes pasos (hechos parcialmente en pasos anteriores pero que no daña repetir):

#!/bin/sh

sudo apt-get update

sudo apt-get pulseaudio pavucontrol

Hay que editar el archivo de configuración

sudo nano /etc/pulse/default.pa

y agregar las siguientes lineas al final del archivo

load-module module-null-sink sink_name=Virtual0 sink_properties=device.description="Virtual0"

load-module module-null-sink sink_name=Virtual1 sink_properties=device.description="Virtual1"

Finalmente hay que optimizar el funcionamiento del pulseaudio limitando el logging que hace, hay que editar el archivo daemon.conf

sudo nano /etc/pulse/daemon.conf

Buscar "log-level" (con Ctl-W) y cambiar a "log-level = error" y remover el comentario para que quede como:

; log-target = auto

log-level = error

; log-meta = no

Salvando el archivo hay que relanzar pulseaudio, lo que se puede hacer con un reboot (sudo reboot) o con "pulseaudio -k".

Si hicimos las cosas bien veremos que en pavucontrol podemos asociar un dispositivo "Virtual0" o "Virtual1" a mplayer. Asignemos "Virtual0". Ejecutando wsjtx tenemos que ir a configuración y designar como dispositivo de entrada "Virtual0.monitor" (el otro extremo del cable virtual), con lo que veremos que el medidor de sonido se "enciende". Hay que trabajar un poco con los controles de nivel para asegurar que el mismo está entre 50 y 70 dB, en todo caso en color "verde".

Es probable que si bien wsjtx en apariencia funcione bien aún así no decodifique correctamente señales, lo haga en forma errática o tenga muchos errores; puede ser que algo de todo lo anterior no anda del todo bien. Pero la causa mas habitual en mi experiencia con ésta configuración es que simplemente hay un problema de sincronismo en el tiempo.
Previamente se dijo que los modos de señales débiles requieren una sincronización de tiempo muy estricta, en incluso se instaló un paquete denominado ntp para asegurar que el reloj esté correcto. Sin embargo el procesamiento de la señal no es instantáneo, tarda entre 2 y 3 segundos, eso significa que cuando la señal es decodificada por wsjtx está "corrida" respecto a la ventana en esa magnitud, muy pequeña pero suficientemente crítica. Para evitar ese problema hay que "correr" las sincronización para que la hora del RBPi "atrase" un par de segundos respecto a la sincronización perfecta; ntp no permite hacer eso, pero un paquete similar llamado "chrony" si.
Para instalarlo

sudo apt-get update
sudo apt-get install chrony

Chrony cuando se instala desinstala automáticamente a ntp, al que reemplaza completamente. Editar el archivo de configuración chrony.conf

sudo nano /etc/chrony/chrony.conf

Y agregar

pool 2.debian.pool.ntp.org iburst offset -2.5

Luego reciclar chrony con

sudo invoke-rc.d chrony restart

Se podrá percibir que el reloj de la máquina ahora atrasa aproximadamente 2 segundos; esto a su debido tiempo generará sus propios problemas, pero por ahora ayudará a que todo funcione.
El programa wsjtx podrá recibir (sintonizando en las frecuencias y modos correctos) recibir señales y decodificarlas normalmente. Recordar que no hay conexión alguna entre la frecuencia que wsjtx asume que está y la que realmente está "escuchando" el transceptor, asegurarse que son las mismas (error común olvidarse de verificar que lo sean).

Maravilla de maravillas, ¡la frambuesita tiene oidos ahora!

Transceptor de señales débiles, bit a bit [Parte 2]

En realidad, y como aclaré al comienzo, la historia contada en ésta serie de entradas no transcurrió en la misma linea de tiempo que la estoy contando; en mi caso el paso de instalar una baliza WSPR fue el primero, y el experimento consistió en ver si podría lograrse con solo una placa RBPi y ... ¡nada mas! (spoiler: ¡si, se puede!).

He realizado algunas entradas por fuera de ésta serie comentando algunos detalles de la implementación técnica de la baliza, el cual se hace con el programa wspr del paquete WsprryPi [link], el cual deriva de una larga trayectoria de programas que exploran la capacidad de una RBPi de generar RF directamente desde sus puertos GPIO mediante la reprogramación de su timer, y lo logra en una sorprendente gama de frecuencias que llega hasta el espectro de VHF lejano. 

Cuando se lo activa se obtiene  una señal de RF que puede entregar apróximadamente 10 mW de potencia desde el pin GPIO04 del GPIO. Inicialmente no pensé que fuera posible, pero luego lo medí rudimentariamente (¡no tengo un miliWattimetro!) con una carga fantasma, y si, entrega incluso un poco mas que eso en condiciones ideales. Alimentado por una sana incredulidad hice algunas cuentas.

Lo que sale del pin GPIO04 (sin carga) es una onda cuadrada de 3.3Vpk-pk. Quiere decir que la tensión RMS será Vrms=(Vpk-pk/2) * 0.707 o sea 1.16V. La potencia Pmax=(Vrms^2)/RL y con R=50 ohms eso es 0.026 W (26 mW), si era mas que 10 mW después de todo.... En realidad la potencia es menor, porque al cargar al pin la tensión no es 3.3Vpp y por otra parte cualquier proceso de filtrado introduce algo de pérdida, estimando ambos factores en -3 dB dá... para sorpresa de nadie.... 0.013W (13 mW).

Podemos, para una prueba cruda y algo arriesgada para la integridad de la placa, conectar directamente ese pin a una antena y estar en el aire. Hacer eso es una mala idea por un número importante de razones, entre ellas la posibilidad de dañar la placa por estáticos, la nula protección contra cortocircuitos y sobrecargas y la rica (e indeseable) producción de armónicos que tiene una señal cuadrada como la presente a la salida. Hay que tener en cuenta que muchas (¡muchas!) antenas están en cortocircuito para la tensión continua, eso es mortal para la placa si no hay al menos un capacitor en serie que la proteja.

Se puede hacer una prueba corta, pero muy corta, directamente conectando a la antena. Pero hay que mas o menos rápidamente tomar medidas. Los modos de baja señal son increibles, pues una señal tan débil como 10 mW puede efectivamente llegar muy lejos, y si está mal formada causar problemas muy lejos también.

Un filtro pasa bajos es una medida aconsejable (para aislar y reducir contenido de armónicos) y algo de potencia adicional (10 a 100 mW) con algo de amplificación.

Inicialmente probé con un filtro Pi casero, aislación eléctrica mínima con la antena  y solo 10 mW de potencia. ¡El resultado fue fantástico! en forma marginal la señal era tomada en distancias de hasta 5000 Km (repito ... ¡10 mW!). Lo que me animó a dar el siguiente paso y apelar a la placa QRPi ofrecida por el TAPR [link], la que contiene un filtrado bastante exhaustivo y un amplificador de +10 dB. Esta placa está especialmente diseñada para entrar en el gabinete de la RBPi, provee un buen  filtrado de entrada y salida además de los +10 dB de ganancia; pero comodidad (eufemismo por vagancia) de construcción aparte es perfectamente reproducible con esfuerzo modesto en cualquier taller pues ninguno de sus componentes es crítico.

El resultado fue inmediato y sorprendente, la baliza con ella pasa a ser reportado de ocasionalmente a  rutinariamente en distancias de 5000 Km y habitualmente a distancias entre 8 y 13 mil Km. No es milagro, WSPR puede operar con márgenes de relación señal-ruido de hasta -30 dB, por lo que tiene una ventaja de +40 dB sobre una señal de fonía y +15 dB sobre una de telegrafía. En las mismas condiciones que la baliza es reportada en -30 dB necesitaría transmitir en CW con al menos potencias QRP (3-5W) para ser escuchado en el borde mismo del circuito de comunicación. WSPR logra ese milagro en base al método de codificación empleado y al tiempo de emisión de cada mensaje. Para instalar WsprryPi el proceso es simple.

#!/bin/sh

sudo apt-get install git

git clone https://github.com/JamesP6000/WsprryPi.git

cd WsprryPi

make

#  Install to /usr/local/bin:

sudo make install

exit 0

Para implementar la baliza se necesita algo mas que simplemente lanzar el programa, el cual tendrá una forma

wspr -r -s  LU7DID GF05 20 20m 0 0 0 0

En este caso configurado con mi licencia, mi QTH locator, la potencia que uso [20 dBm=100 mW] y la banda (20m), los cuatro "0" luego de 20m indican que si bien el beacon funciona permanentemente salte 4 "ventanas" sin emitir, o sea que emita una vez cada 10 minutos. Eso es un buen equilibrio entre la calidad del reporte, el uso juicioso del espectro radioeléctrico limitado y preservar la placa en el largo plazo (puede aumentar su temperatura en hasta 3 °C en cada emisión). Como he compartido en entradas anteriores si el objetivo es tener algo ejecutando permanentemente hay que darle un marco que permita su control,  supervisión y gestión.

Para eso es mas conveniente hacer un script de lanzamiento en bash, que de acuerdo a los argumentos que se le den permita lanzar, detener, bloquear, liberar o conocer el estado de ejecución de la baliza, por ahora solo de transmisión; hacerlo de ésta forma es no solo cómodo sino que permite automatizar el lanzamiento del script, el script en mi caso se llama whisper y puede obtenerse una copia del mismo [link]. Para correrlo se ejecuta con la instrucción:

/home/pi/whisper/whisper start

Dado que el script es re-entrante en realidad lo ejecuto una vez por minuto con crontab, si ya está corriendo simplemente termina dejando un registro en el log del intento y si por alguna razón no está corriendo (¿reboot reciente? ¿problema de ejecución? ¿detención manual?) lo reinicia.

La función de lock/reset está implementada, justamente,  como un apoyo a la operación regular del baliza, pues si apagamos la baliza para hacer una prueba el crontab que así está programado intentará cada minuto y lo lanzaría de vuelta, el lock hace que si eso ocurre la baliza no arranque hasta que se dé el reset.

/home/pi/whisper/whisper stop (para detener el beacon)

/home/pi/whisper/whisper lock (para detenerlo y establecer un "lock").

/home/pi/whisper/whisper reset (para eliminar el "lock" y dejar que pueda ser lanzado)

El script es, por lo tanto,  "re-entrante" y "re-usable" condición que permite que a pesar que esté corriendo permanentemente, su lógica es tal que cuando comienza revisa si ya está corriendo el programa principal, y si lo está termina, y si no lo está queda ejecutando. Debido a ésta forma de funcionar  cuando el sistema arranca, bastará que transcurra un minuto para que lance la baliza a funcionar. Y lo repetirá cada minuto luego, solo para detectar que ya está funcionando y terminar. La información que el script va registrando en términos de temperatura, tensión, estado del disco (tarjeta SD en realidad), uso de CPU y condición de "throttling" (restricción de la velocidad de la CPU) es muy útil para gestionar un dispositivo que está funcionando no atendido durante 24 horas.

En el estado actual el script no hace nada con esa información otra que registrarlo, pero no sería descabellado con modificaciones simples que tome acciones de gestión. Por ejemplo si sube la temperatura espaciar las transmisiones o directamente apagar el transmisor, si la tensión no es estable lo mismo o incluso apagar la placa (sudo shutdown -h now); no es muy extenso de desarrollar y permite mucha experimentación.

En la gestión diaria he encontrado útil introducir un reboot diario, usualmente en horas de la madrugada que no hay gran propagación de todas formas para que "limpie" los procesos que se estuvieran ejecutando, borre los espacios temporarios y otras actividades de "limpieza" de la placa que ocurren automáticamente al hacer reboot.

El alcance de la baliza es sorprendente, los reportes que se hacen de el en WSPRNet siempre contienen alguna sorpresa. La siguiente es una mañana típica incluye muchas estaciones de Europa, Norteamérica y de tanto algunas francamente exóticas de Africa, Asia u Oceanía.

¡Realmente da alegría y orgullo lograr semejantes distancias con tan pocos recursos!

ARRL DX Pronóstico vs. Realidad

Y pasó el ARRL DX International de CW 2019. Entretenido a pesar que las condiciones no estuvieron tan buenas. Justamente quería compartir una análisis entre lo que fue el pronóstico del concurso (basado en WSPR) y la realidad, al menos la realidad vista desde mi estación.

El método de abordar númericamente el pronóstico, ensayado ya muchas veces en función de información extraida de los DX Clusters o directamente el Reverse Beacon Network sienta sus bases en métodos de matemáticas aplicadas (estadísticas), en particular una rama llamada estadística inferencial. La estadística tiene sus raices en el estudio de las matemáticas y se hunde en la noche de los tiempos, casi tan lejos como hay evidencia de saber matemático. Pero no fue sino hasta la edad moderna con Descartes, Laplace y Fermat que las estadísticas adquirió un cuerpo formal. A comienzos del siglo XX el trabajo de matemáticos brillantes, pero en particular de Pearson y Fischer, dio los fundamentos en los cuales es posible mediante el estudio de una población en el pasado inferir su comportamiento en el futuro. Todo esto viene a cuento porque es muy común que se menosprecie a las estadísticas como instrumento, lamentablemente con no poca frecuencia las estadísticas son utilizadas (en ocasiones por ignorancia, en otras por simple mala fé) para demostrar cualquier cosa. Sin embargo, cuando se las usa profesionalmente no hay tanto margen a la chantada, así como hay predicciones también hay instrumentos para estimar su validez (que usualmente son omitidos), con lo que uno puede estimar su "confianza" en si los resultados son puro azar o tienen escondido en el ruido cual puede ser la verdad (y medir que tan alto es el ruido). La propagación, dicho múltiples veces, en fenómeno caótico y que involucra energías de escala cósmica, es por lo tanto impredecible sobre una base completamente heurística. Sin embargo, de Einstein (movimiento browniano) para aquí, las estadísticas pueden caracterizar ese tipo de fenómenos aleatorios. Dias pasados compartí lo que podía ser un pronóstico del comportamiento de las bandas de 20 y 40 metros basado en el reporte de estaciones de la red WSPR de-hacia Argentina en la semana inmediata anterior al concurso. Este tipo de análisis se basa en algunas premisas, que si no se sostienen lo invalidan.

La primera y mas obvia es que las condiciones ambientales son similares, hablando del Sol esa es una hipótesis un tanto arriesgada, porque si bien sigue ciclos conocidos (pero no comprendidos) en el largo plazo en el corto es impredecible. Por otra parte su rotación puede ocasionar que una particularidad (un poro, una mancha, un plague, etc) que estaba oculto al comienzo de la semana no lo esté al fin (o viceversa). Las condiciones de acuerdo a las principales mediciones fue razonablemente estable, un SFI del orden de 70 y un SSN cercano o en cero. Los indicadores de actividad magnética K y A  mostraron valores razonablemente calmos. El segundo factor es, según lo comentado antes, la variabilidad misma de un proceso aleatorio. Dicho todo esto resta entonces comparar el pronóstico con el perfil de contactos, lo que se hace en la figura que se corresponde con el pronóstico para 20 metros (banda en la que participé). El perfil nocturno fue adecuadamente representado en el primer día y no tanto en el 2do. Aquí creo que opera un factor que estadística se denomina "especial" y es que allí estaba terminando el concurso y la falta de contactos podía deberse no solo a la propagación sino a otros factores tales como estaciones disponibles, cansancio, cierre de la participación, etc. De hecho había entre 2300Z y 2359Z del Domingo bastantes estaciones, solo que ya había trabajado a la mayoría, y las que no estaban en run con otras partes y no contestaban. En el comienzo de la propagación el pronóstico anduvo bastante bien aunque el sábado se adelantó casi 3 horas y el domingo una hora, la duración de las aperturas fue razonablemente bien pronosticada y por cierto los tiempos sin aperturas fueron bastante bien anticipados, lo que en lo particular me ahorró varias horas de estar llamando inútilmente. O sea que el resultado fue bastante bueno en mi opinión, el error medio está dentro del 10%, margen mas que aceptable para éste tipo de pronósticos. Nada supera el monitorear la situación real para decidir sobre el concurso que hacer, participar o no en Single Band, quedarse o saltar en All Band. Pero es un instrumento mas que bueno para hacer un planeamiento de como se encarará el concurso, mas o menos cuantas horas estará y complementarlo con otras actividades. Una herramienta ciertamente útil que hay que perseverar en mejorarla.

¡Nodo 499 de SatNOGS online!

Luego de algún porrazo en la configuración inicial finalmente pude poner "online" el nodo 499 en SatNOGS (¿quinieleros en la audiencia?) con el nombre artístico LU7DID. Por ahora en modo "testing" según recomienda la guía de puesta en marcha. Guía no del todo clara, por ejemplo no quedaba para nada claro cual era el ID de la estación, sin el cual la conexión a la red no era posible.

He calendarizado tres observaciones a modo de prueba como para ir depurando la configuración. OSCAR 7 (¿sigue vivo?), un satélite ignoto y un FUNCUBE con una pasada de muy baja elevación. A primera vista  parecería que esto se aleja bastante de la experimentación mayormente centrada en modos de señales débiles, sin embargo tiene mucho en común. Se basan en el uso conjunto de una placa Raspberry Pi, el uso intensivo de SDR, la utilización de un dongle RTL-SDR como receptor y el funcionamiento automático.

La configuración inicial es con una antena Ringo (¡ya sé que no es adecuada!) hasta que pueda traer una Walmar de VHF que utilicé durante mucho tiempo (¡años!) para recibir satélites NOAA desde Córdoba la semana que viene. También quiero probar con tiempo la direccional apuntando en forma fija al Norte o al Sur (o viceversa); por bastante tiempo sin rotor en Córdoba hacía satélites así y podía tomar medio paso. El nodo en sí está corriendo en una Raspberry PI Mod 3 (mucrux) que está integrado al cluster de otras máquinas similares, tiene su propio dongle RTL-SDR asignado porque la idea general es que opere en forma autónoma 7x24, bastante lejos de eso todavía.  Todavía falta tomarle bastante la mano y ver como se puede maximizar la toma de pasadas de satélites y a cuales se puede intentar escuchar, por ahora solo en VHF.

Vamos a ver que sale, por ahora el nodo figura ya en el mapa, y eso es todo un logro. La configuración inicial fue un poco a los golpes, la imagen del Raspbian que ofrecen en SatNOGS pesa poco (600+MBytes) comparada con la distribución standard Raspbian pero también le falta las cosas mas elementales, supongo que está hecha así para que la bajen y no la toquen demasiado (en mi caso no fue así)

Transceptor de señales débiles, bit a bit [Parte 1]

Si bien hay un "ecosistema" de aplicaciones derivadas, complementarias y especializada el grueso de la actividad en modos digitales de señales débiles (weak signal) gira alrededor del uso del programa de Joe Taylor (K1JT) [aqui] llamado wsjt-x y cuya versión mas actualizada al momento de ésta entrada es 2.0.0. Tengo el programa instalado y actualizado periódicamente en la PC de mi estación donde hago contactos frecuentemente en estos modos. Pero al mismo tiempo vengo llevando adelante una iniciativa para tener una baliza/estación de escucha de WSPR (Weak Signal Propagation Report, Reporte de Propagación de Señales Débiles) permanente y que funcione con la mejor disponibilidad posible. Y para eso nada mejor que tratar de implementar todo el proyecto alrededor de la plataforma Raspberry Pi, proyecto que terminó siendo muy desafiante y rico en aprendizajes.

Esta entrada y las siguientes dan cuenta de los apuntes tomados durante la experiencia, en ellos trataré de expresar las ideas en la secuencia de implementación que ahora, con el "diario del lunes" de todas las idas, vueltas y callejones sin salida, parece es la forma mas directa de desplegarlo (y no necesariamente el orden en que hice las cosas).

Algunas pruebas rápidas me permitieron estar seguro que el programa wsjt-x mismo puede correr en la plataforma Raspberry Pi. No es novedad, misterio ni gran logro pues está reportado en muchos sitios en Internet y en la página hay una versión específicamente para Raspbian a nivel imagen [aqui] además de, por supuesto, poder construir la aplicación desde los fuentes  [aqui], como por otra parte siempre es preferible cuando sea posible.

Antes de eso, por supuesto, tenemos que tener una placa Raspberry mod 2 o 3 configurada y andando, en general una tarea fácil aunque hay algunas veces que problemas simples dan algo de pelea, no es dentro del alcance de ésta serie abundar en detalles sobre como hacerlo pues hay una enorme cantidad de recursos en Internet que pueden ser de ayuda [video].

En las pruebas que hice tanto la Raspberry Pi (o RBPi) 2 como la 3 han funcionado bien, obviamente cuanto mas potente , lo que se mide en términos de reloj, de memoria y de espacio en SD Card, mejor es. La mayor parte de los experimentos en ésta serie fueron realizados con una RBPi Mod 2 B (900 MHz) y varias Mod 3 (1.2 GHz).

Una vez que el RBPi está andando y configurado, que le hemos puesto la imagen que nos gusta como fondo de pantalla, explorado un poco el vecindario y bajado cosas que no tienen nada que ver (pero son divertidas) empezamos con nuestra materia. Hay dos formas de instalar el programa wsjt-x; la rápida y la divertida.

Empecemos por la rápida. Siguiendo el link anterior desde la RBPi (usando Chromium como browser) bajar el archivo de distribución para el ambiente Raspbian (un archivo que llamará en el estilo de wsjtx_X.X.X_armhf.deb con X.X.X siendo la versión corriente, al momento de ésta entrada es 2.0.0), al hacerlo se descargará en el directorio "Downloads". Al finalizar la descarga ir con el explorador de archivos y hacer "click" en el archivo bajado, nos pedirá la verificación con password y lo instalará. El programa wsjtx estará disponible en la opción "Sonidos y Video", pero en ocasiones dependiendo de la configuración puede terminar en otra parte. Arrancando el programa tendremos la posibilidad de configurarlo, por ahora no mucho mas que establecer la señal distintiva y el QTH locator.

También se puede construir el programa desde los fuentes, lo que tardará un poco mas pero será mucho mas didáctico. La construcción de programas desde los fuentes es la forma mas efectiva de estar en razonable control de lo que estamos creando, pero requiere paciencia y ser riguroso en no omitir pasos, alterar el orden o indicar todas las opciones necesarias.

Instalar WSJT-X

Para construir desde fuentes habrá que construir primero el paquete HamLib y luego el wsjt-x, si bien el Raspbian Jezzy ya viene con el primero está normalmente muy  fuera de nivel y termina conveniendo instalarlo desde cero. Los pasos, que se ejecutan en la misma placa RBPi,  son:

Paso 1 - Instalar pre-requisitos

cd /home/pi
sudo apt-get update
sudo apt-get install -y cmake
sudo apt-get install -y asciidoctor
sudo apt-get install -y asciidoc
sudo apt-get install -y gfortran
sudo apt-get install -y subversion
sudo apt-get install -y libwxgtk3.0-dev
sudo apt-get install -y libusb-1.0-0-dev
sudo apt-get install -y portaudio19-dev
sudo apt-get install -y libsamplerate0-dev
sudo apt-get install -y libasound2-dev
sudo apt-get install -y libao-dev
sudo apt-get install -y libgsm1-dev
sudo apt-get install -y libsndfile1-dev
sudo apt-get install -y libjpeg9-dev
sudo apt-get install -y libxft-dev
sudo apt-get install -y libxinerama-dev
sudo apt-get install -y libxcursor-dev
sudo apt-get install -y libboost-all-dev
sudo apt-get install -y libqt5multimedia5
sudo apt-get install -y libqt5multimedia5-plugins
sudo apt-get install -y libqt5multimediaquick-p5
sudo apt-get install -y libqt5multimediawidgets5
sudo apt-get install -y libqt5serialport5-dev
sudo apt-get install -y libqt5svg5-dev
sudo apt-get install -y libqt5widgets5
sudo apt-get install -y libqt5sql5-sqlite
sudo apt-get install -y libqwt-qt5-dev
sudo apt-get install -y libudev-dev
sudo apt-get install -y qtmultimedia5-dev
sudo apt-get install -y libfftw3-dev
sudo apt-get install -y xsltproc
sudo apt-get install -y swig

Paso 2 - Bajar "tarballs" de fuentes (HamLib y wsjtx)

cd Downloads

wget http://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0.tgz

wget https://sourceforge.net/projects/hamlib/files/hamlib/3.3/hamlib-3.3.tar.gz

Es posible que se tenga que revisar cual es el último nivel de ambos programas pues el mismo puede variar al momento de ejecutar éstas instrucciones.

Paso 3 - Construir HamLib (tarda bastante)

cd /home/pi
sudo apt-get remove libhamlib2
cd Downloads
tar -zxvf hamlib-3.3.tar.gz
cd hamlib-3.3
./configure --prefix=/usr/local --enable-static
make
sudo make install
sudo ldconfig
cd ..

Paso 4 - Construir wsjt-x (tarda aún mas)

cd /home/pi

tar -zxvf Downloads/wsjtx-2.0.0.tgz 

cd wsjtx-2.0.0/src/

tar -zxvf wsjtx.tgz 

mkdir build

cd build

cmake ../wsjtx

make

sudo make install

cd ~

Al finalizar estos pasos debería quedar instalado el programa el cual puede accederse tanto desde el menú como tipeando "wsjtx" en una consola.
Es conveniente para la construcción utilizar "scripts BASH", eso ocurre porque hay que ser muy meticuloso en las acciones y la secuencia de comandos y por otra parte es bastante común tener que repetir la instalación  (scripts de pre-requisitos, construcción de hamlib y construcción de wsjtx).

Usando WSJT-X

El programa wsjtx espera recibir sonido tal como el entregado por un transceptor sintonizando en USB sobre las frecuencias que correspondan a los modos que se desea recibir, por ejemplo en 20 metros FT-8 usará 14.074 MHz mientras que WSPR 14.0956 MHz. El programa cuando se lo ejecuta indica en que frecuencia debe sintonizarse, y si configuramos un CAT lo hará automáticamente.

La placa Raspberry tiene sonido, pero solo de salida, no de entrada. Es necesario instalar algún dispositivo ALSA (Advanced Linux Sound Architecture).

El requisito que suena complicado pero en realidad se soluciona en forma relativamente fácil con un dispositivo de sonido USB, el cual se conectará con el transceptor de la estación. Sin embargo en mi configuración tomé una ruta un poco mas complicada (y específica de mi estación), lo contecté a mi transceiver SDR mcHF, el cual tiene una configuración de conexión USB que se presenta al procesador como un puerto serie y una placa de sonido. Gran misterio gran, ¿como se llevarían una placa Raspberry con un mcHF?

En el caso del transceiver mcHF la página de DF8OE [link] es un recurso imprescindible, la documentación anticipa que conectando el cable USB a uno de los puertos disponibles en la RBPi lo reconocerá inmediatamente, ya así ocurrió. Con el comando aplay -l se pueden ver las placas de sonido instaladas y allí el transceiver está listado como una placa de sonido (plugHW:CARD=mcHF,DEV=1) y el puerto serie para comando está disponible como /dev/ttyACM0.

Para quienes no tengan  un mcHF se conecta un "dongle" de soundcard USB (y se verifica que lo reconozca también con aplay -l) y se conecta por separado un puerto serie USB (tipo Prolific) el que también es reconocido como /dev/ttyACM0 usualmente.

Esos son los dispositivos que se utilizarán posteriormente para configurar, es mas cómodo el primero (para el que tiene un mcHF en particular) pero el segundo también funciona.

En realidad, para comenzar no hace falta ninguna otra cosa que disponer de audio, el no poder controlar la frecuencia del transceptor no es un gran problema pues los modos digitales de señales débiles se sintonizan en un solo canal y todos los contactos ocurren en el. Para transmitir se puede utilizar el sistema VOX, no es lo ideal pero funciona.

Finalmente es útil poder controlar via CAT (Computer Aided Tuning) al transceptor desde wsjt-x, y cuando éste se encuentra habilitado también se puede tener PTT (Push to Talk) por esa vía (no hace falta un dispositivo de hardware para hacerlo).

Puedo ser incluso mas detallista y utilizar el manipulador y PTT por puerto serie a partir de un puerto Prolific USB y con un circuito muy simple [ver sitio de  lu9dpd] operar el PTT del transmisor e incluso, ahora si, controlar la frecuencia y modo mediante CAT. La instalación del puerto serie no tiene ningún misterio (hay links para hacerlo) , al igual que la placa de sonido USB basta enchufarlo en uno de los slots USB que tiene el RBPI para que sea reconocido y puesto como disponible.

Voila! En el aire!

Todos los modos digitales de señales débiles requieren un reloj sumamente preciso, puede usarse al efecto un receptor GPS, pero si de dispone de Internet es preferible sincronizar el reloj de la placa periódicamente con el uso del protocolo NTP. Para eso hay que instalar el paquete ntp que consulta los servidores de protocolo NTPD.

sudo apt-get install ntp

Al instalarlo se sincronizará periódicamente, pero si quisiéramos forzarlo podemos hacerlo ejecutando:

sudo /etc/init.d/ntp stop >> ntpd.sync.log
sudo ntpd -q -g >> ntpd.sync.log
sudo /etc/init.d/ntp start >> ntpd.sync.log
echo 'date' " ntpd sync completed " >> ntpd.sync.log

Una vez instalado se puede utilizar wsjtx para cualquiera de los modos que soporta, primariamente la experimentación inicial está destinada a implementar el receptor de la baliza (beacon) WSPR para transformarlo en un monitor WSPR.
Una vez instalado y funcionando el programa wsjtx se puede usar con todos los modos que soporta, por eso si bien la instalación inicial tenía por proposito usarlo en WSPR hice también  numerosos contactos en FT8 con potencias muy bajas, si bien el mcHF entrega hasta 10W de potencia rara vez lo he usado mas que a 5W, lo que me permite contactos regionales con facilidad y con buenas condiciones de propagación algunos DX muy interesantes. No es para nada casualidad la revolución que está causando FT8, con el nivel de propagación pésima que hay poder realizar los DX que se hacen no es poca cosa.

Toda ésta configuración la hice en una placa dedicada (bcrux) configurada "fresca" desde cero, pues siempre se corre el riesgo cuando se está experimentando de romper algo con las idas y vueltas para luego encontrarnos con comportamientos erráticos que no se deben a lo que estamos haciendo sino a alguna otra cosa (normalmente diferencias de nivel entre los paquetes utilizados). Como toda máquina siempre es útil y efectivo dedicar algún esfuerzo para implementar ciertas rutinas de  backup, recovery y housekeeping, por supuesto no daña implementarlos en ésta placa aunque la capacidad disponible supere en mucho a lo que realmente utilizaremos con ésta configuración. En particular si es algo que vayamos a dejar prendido permanentemente, o por lo menos está hecho con ésta intención.

Una nota de atención, es importante configurar que guardará wsjt-x mientras es operado, dependiendo de que alternativa se utilice en la opción "save" del wsjt-x pueden generarse varios GBytes de información de sonido (.WAV) en muy poco tiempo de uso, y el espacio de "disco" (tarjeta SD) en la placa no es tan grande; es necesario por lo tanto tener desactivada la opción o introducir algún modo de mantenimiento que elimine los archivos mas viejos periódicamente. Un script sencillo para eliminar los archivos mas viejos puede ser:

for f in $(ls -La /home/pi/*.log | head -n 1); do sudo rm -r $f; done

Donde debe reemplazarse "/home/pi/" por el path donde estén los archivos a depurar.

Otro punto importante es asegurarse que la "profundidad" de análisis de wsjtx está puesta en "Normal" o incluso "Rápido", la RBPi es una placa noble pero no tiene el músculo de procesamiento para manejar cómodamente el modo "Profundo" (al menos la RBPi 2).

Al finalizar el proyecto seguramente reflexionaremos que no hay una "ganancia" demasiado exagerada en esta configuración, nada que no hubiéramos podido implementar en forma mucho mas sencilla directamente conectando el transceptor a nuestra PC (si es que ya no lo estaba); pero claro, esta parte del proyecto en realidad no es mas que realizar la configuración inicial de la RBPi y su puesta en marcha, y estar seguro que instalamos wsjt-x de la forma mas sencilla posible, cosa que si no anda podamos estar razonablemente seguros de que pasó y como arreglarlo, puesto que si instalamos muchas cosas al mismo tiempo es quizás luego dificil saber donde está el problema.

Con un proyecto tan polifacético como éste no puedo sino recordar con asombro el cuento de Borges denominado "El Aleph".

SatNOGS (Satellite Networked Open Ground Station)

Información muy interesante distribuida por AMSAT Argentina relacionado con una red abierta para el seguimiento de satélites. Usa una configuración de SDR+RBPi Pi muy similar a la que estoy utilizando en experimentación para modos digitales de bajas señales, lo que hace muy probable que ponga un nodo experimental en los próximos días. La información está contenida en un correo enviado desde AMSAT Arg. que transcribo como ellos pidieron, literalmente, a continuación.

=======================================================================

Amigos,

Hasta que surgieron los SatNOGS, solo había dos posibilidades para recibir un satélite: esperar hasta que este "sobre su cabeza" (y esto puede llevar mucho tiempo) o alquilar una costosa red comercial de estaciones terrestres para la comunicación, ahora hay una tercer posibilidad por demás interesante. 

SatNOGS es libre y gratuito y permite analizar muchos datos, dado que hay muchas estaciones recibiendo muchos satélites y en muchos lugares diferentes, es una solución para recibir voz o datos de casi cualquier satélite este donde este.

SatNOGS integra la Fundación 'Espacio Libre'. El objetivo de este proyecto es armar una red global de estaciones terrestres de satélite. 

Es un proyecto participativo de codigo abierto basado en estaciones automatizadas, accediendo a sus capturas a traves de una pagina web. https://wiki.satnogs.org/Raspberry_Pi_3#Raspbian 

Quienes contribuyen a la red usan una Raspberry Pi-3 + un dongle SDR + una antena VHF o UHF. Hay una imagen de Raspberry Pi disponible para simplificar la instalación del software . 

A nivel publico, podremos escuchar p.ej al LUSAT yendo a https://network.satnogs.org/observations/?norad=20442 donde veremos quienes y cuando lo recibieron, su waterfall, su audio, etc. (20442 es el Nro.de catalogo, puede ponerse cualquier otro).

Otro ejemplo: https://network.satnogs.org/observations/452813/ permite escuchar la operación del AO-92 sobre Norteamérica, ademas de habilitar decodificar telemetría. 

Quizás algún dia tengamos una estación SatNOGS en nuestra region dando un servicio muy util a la radioafición.

Agradecemos, de ser posible, la difusión de esta información.

73, LU7AA, AMSAT Argentina

ARRL DX International 2019 (CW)

Se viene el ARRL DX International de CW edición 2019, uno de los principales concursos del calendario internacional que abre la temporada y otorga puntos para el WRTC 2022 (en ¡Italia!).

Si bien hay algunos signos débiles que el ciclo solar ya pegó en el fondo y está empezando a repuntar estamos aún lejos, muy lejos... varios años, que la propagación sea realmente importante. En éstos días se puede observar un SFI=70 y un SSN=0, pobrísimo  (la nada misma) para sostener propagación en las bandas altas. Dado que las antenas necesarias hacen complicado trabajar en las bandas de 160 y 80 metros es de esperar que el grueso de la acción transcurra en las bandas de 20 y 40 metros. El pronóstico de propagación se complica un poco pues los modelos de propagación ionosférica tienden a dar resultados marginales, sobre todo en 40 metros, cuando no hay una propagación neta por capa F. Por otra parte, el método estadístico basado en contactos registrados en los clusters, en particular en el Reverse Beacon Network, es probable que no sea realistas puesto que hace prácticamente dos meses que no hay concursos significativos que permitan registrar un nivel de actividad aproximadamente similar al de un concurso con la configuración aproximadamente encontrada en el Sol. Para solucionar esos problemas intento estudiar la propagación a partir de los datos en el WSPRNet (Weak Signal Propagation Report). Para ello filtro la actividad durante el mes de Febrero de forma de quedarme con los reportes que involucren estaciones de Argentina y de zonas W/VE/XE. El resultado es un dataset de mas de 15000 reportes para 40 Mts. y otro tanto para 20 Mts. (el que incluye los reportes realizados por y hacia mi estación de monitoreo WSPR). En base a esos

datos es posible establecer una distribución de frecuencias horarias las que, estimo, correlacionarán con las condiciones de propagación (mas frecuencia, mejor propagación). Ahora bien, el WSPR como modo es capaz de generar un reporte para un circuito con una señal que está -30 dB por debajo del ruido en un canal de 2.5 KHz, claramente una performance que CW no tiene. Pero eso puede igualarse (aproximadamente) con algunas cuentas sencillas, las que son mostradas en la figura para mayor sencillez. A la relación señal a ruido (SNR) reportada en WSPR hay que sumarle la diferencia entre la potencia de la estación con la que se concursará (supuesta 100W o 50 dBm) y la señal del beacon que fue reportado, es decir mayor potencia menor SNR. Por otra parte el umbral de detección de CW es un poco difuso, para detección por máquina una estimación rápida entrega -5 dB mientras que se reporta que la combinación "oido-cerebro" puede mejorar esa figura hasta -15 dB, se toma como conservador el punto medio, es decir -10 dB. Eso hace que cualquier señal que esté hasta -10 dB por debajo del ruido en un canal de 2.5 KHz podrá ser decodificada. Con esa cuenta sencilla es posible identificar que señales están por encima del umbral y que por lo tanto deberían ser operables.

Filtrando por el criterio de relación señal-ruido es posible estimar un pronóstico preliminar de horarios tentativos para las aperturas de propagación, los que pueden verse en la figura. Según éste cálculo 40 metros debería presentar aprox. 12 horas de propagación siendo aproximadamente la mitad razonablemente buenos y el resto marginales, es decir aprox. 12 horas en todo el concurso.

Por su parte 20 metros presenta un patrón algo mas restringido  con también 12 horas de propagación esperada pero solo 3 o 4 horas de buenas condiciones. ¡Sin duda que va a ser un evento desafiante!

Datos, datos y mas datos....

La Raspberry Pi depende de como se use puede calentar bastante, por eso los modelos mas recientes vienen con unos pequeños disipadores para colocar sobre la CPU/GPU y el dispositivo periférico  BCM2835. En algunos usos se necesita incluso agregar algún dispositivo soplador para proveer refrigeración adicional. No es raro, además, que mientras se está trabajando normalmente con cualquier GUI X-Windows (lxterminal por ejemplo), aparezca un ícono de un termómetro (sobre-temperatura), o uno como un pequeño rayo (voltaje bajo). La estrategia de gestión de la placa hace que ante eventos de esa naturaleza se intente generar mejores condiciones de funcionamiento mediante bajar la velocidad de los dispositivos (si, disminuir la frecuencia del clock). Cuando tenemos una placa funcionando permanentemente queda la duda sobre si ocurren estos eventos, que tan severos son y con que frecuencia o patrón aparecen. La mejor solución es registrar en el log (del sistema o del programa, yo prefiero del programa) datos de "telemetría" periódicos, tales como temperatura, clock del procesador o tensión. Lo interesante es como medirlo.

Viene en nuestro auxilio un comando disponible en la Raspberry Pi llamado vcgencmd el cual tiene por propósito gestionar distintos aspectos del firmware. Antes que nada es necesario transmitir algo de cautela. Se trata de un comando en el que la mayoría de las opciones no está documentado que hacen, y no son siempre funciones de "lectura", las hay también funciones que operan sobre el hardware modificando la configuración. Algunos incluso el nombre meten "dudita" sobre que tan beneficioso puede ser ejecutarlos.

Por fortuna hay unas pocas opciones del comando que si se sabe que hacen, y son muy útiles.

Para empezar, el comando se ejecuta con vcgencmd operador [argumento] el operador es siempre requerido, el argumento en ocasiones no es necesario, en otras tiene un default y en oportunidades es mandatorio dependiendo del operador. El operador "commands" (vcgencmd commands) produce un listado de todos los operadores soportados, luce como

commands="vcos, ap_output_control, ap_output_post_processing, vchi_test_init, vchi_test_exit, vctest_memmap, vctest_start, vctest_stop, vctest_set, vctest_get, pm_set_policy, pm_get_status, pm_show_stats, pm_start_logging, pm_stop_logging, version, commands, set_vll_dir, set_backlight, set_logging, get_lcd_info, arbiter, cache_flush, otp_dump, test_result, codec_enabled, get_camera, get_mem, measure_clock, measure_volts, scaling_kernel, scaling_sharpness, get_hvs_asserts, get_throttled, measure_temp, get_config, hdmi_ntsc_freqs, hdmi_adjust_clock, hdmi_status_show, hvs_update_fields, pwm_speedup, force_audio, hdmi_stream_channels, hdmi_channel_map, display_power, read_ring_osc, memtest, dispmanx_list, get_rsts, schmoo, render_bar, disk_notify, inuse_notify, sus_suspend, sus_status, sus_is_enabled, sus_stop_test_thread, egl_platform_switch, mem_validate, mem_oom, mem_reloc_stats, hdmi_cvt, hdmi_timings, file"

Lo que es, como corresponde, un poco intimidante. Por ejemplo vcgencmd display_power 0 apaga el video de la placa, vcgencmd display_power 1 lo vuelve a prender. Los operadores que son interesantes con propósito de registro y telemetría son:

vcgencmd measure_clock arm

vcgencmd measure_temp

vcgencmd measure_volts

vcgencmd get_throttled

Que sirven respectivamente para medir el clock, la temperatura del chip, el voltaje (del chip, no de la fuente) y si hay alguna condición que empuje la restricción del clock y cual es.

De esa manera, periódicamente podemos grabar en el log esta información, y luego revisarla para ver en que condiciones ha estado operando el dispositivo, y si hay que hacer algo. Por ejemplo, en el beacon en funcionamiento continuo emitiendo cada 10 minutos el clock es el nominal, la tensión se mantiene estable en 1.2-1.3V, no se observan casi nunca eventos de restricción de performance (get_throttled dá 0x00) y la temperatura oscila entre 45-52 °C dependiendo de la temperatura ambiente y el ciclo de trabajo (suele subir entre 1 °C y 2 °C durante los 2 minutos que está transmitiendo el beacon. He observado alguna ocasión que la temperatura subió a casi 70 °C pero sin mostrar restricción de performance por ello.
Para interpretar los valores de get_throttled debe revisarse la documentación disponible (aqui entre otros), pero un resumen de los posibles valores distintos de 0x00 y su significado es:

bit 0: under-voltage (0xX0001)
bit 1: arm frequency capped (0xX0002 or 0xX0003 with under-voltage)
bit 2: currently throttled (0xX0004 or 0xX0005 with under-voltage)

bit 16: under-voltage has occurred (0x1000X)
bit 17: arm frequency capped has occurred (0x2000X or 0x3000X also under-voltage occurred)
bit 18: throttling has occurred (0x4000X or 0x5000X also under-voltage occurred)

La condición de tensión baja se dá cuando la fuente externa entrega menos de 4.63V y se empieza a gestionar el clock cuando la temperatura excede los 80 ºC, cuando la temperatura excede 85 ºC empieza a marcarse que es excesiva.
La lectura se puede hacer con un simple script en Python (por ejempo picheck.py es el que uso) e integrar fácilmente con otro script que esté manejando el beacon pues la salida es entregada en stdout mediante una función en (por ejemplo) bash.

getTelemetry () {

   TEMP=`sudo python picheck.py -t`

   VOLT=`sudo python picheck.py -v`

   OPST=`sudo python picheck.py -s`

   FREQ=`sudo python picheck.py -f`

   echo "Whisper: "`date`" Telemetry: "$TEMP" °C "$VOLT" V "$FREQ" MHz ("$OPST")" | tee -a $DPATH$TLM

   CMD="python wsprtlm.py -g "$GRID$GRIX" -e "$HEIGHT" -c "$CHANNEL" -b "$VOLT" -t "$TEMP" -l -q -p"  

   TLMG=`$CMD`

   echo "Whisper: "`date`" WSPR TLMF: "$TLMG  

   return 0

}

El log termina teniendo registros que lucen como:

Whisper: vie ene 11 21:31:05 -03 2019 Telemetry: 48.2 °C 1.3125 V 900000000 MHz (Normal operation)

Whisper: vie ene 11 21:32:04 -03 2019 Telemetry: 48.7 °C 1.3125 V 900000000 MHz (Normal operation)

Whisper: vie ene 11 21:33:04 -03 2019 Telemetry: 48.7 °C 1.3125 V 900000000 MHz (Normal operation)

Usando ésta información podemos ir haciendo cambios para refrigerar mejor la placa, por ejemplo, o ponerle una fuente de mayor capacidad. Es improbable que una operación razonable dañe la placa, que por cierto es bastante robusta. Pero lo que en realidad se quiere preservar es que el firmware no recurra a hacer mas lento el clock para gestionar un problema de temperatura o de tensión.
Si tenemos la placa visible en la red con puertos abiertos en el router y la podemos acceder desde Internet, cosa que no siempre se puede hacer pero es muy útil cuando se puede, seguramente nos encontraremos a nosotros mismos tirando de tanto en tanto un

cat whisper.log | grep "Telemetry: " 

Para pegarle una mirada rápida a como van las cosas y si hay algún evento raro, se deja para el lector el ejercicio de hacer que el beacon nos mande un correo si pasa algo raro. Beacon saludable, ¡operador contento!