sábado, 6 de abril de 2019

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

Para terminar de comentar sobre los diferentes modos que implementé en la baliza, aunque no todos ellos quedaron programados en forma permanente por razones prácticas fuera de la experimentación en si describo ahora la implementación de RTTY.
El viejo modo de "radioteletipo" pese que ha sido objetivamente superado técnicamente sigue estando vigente, hay bastante actividad con quienes lo practican, en especial en concursos del modo.
En realidad se trata de un modo de modulación en frecuencia, toda vez que los dos simbolos binarios con que se lo representa se les asigna dos frecuencias. La separación entre las dos frecuencias se denomina "desplazamiento" (shift) y en emisiones de radioaficionado es, por convención, de 170 Hz.
Las frecuencias de los tonos serán entonces 1350 Hz y 1520 Hz. Al equipo de SSB convencional se lo puede alimentar tanto como una señal de audio (AFSK) como mediante un desplazamiento (FSK). En un ambiente virtualizado es mas conveniente el primer método. El RTTY utiliza 5 bits para emitir cada caracter utilizando una codificación denominada BAUDOT, como 5 bits alcanzan para codificar solo 32 caracteres y eso es insuficiente hasta para un código ASCII muy restringido se soluciona enviando un caracter de "escape" denominado LETRAS o FIGURAS con lo cual se indica que los caracters que siguen pertenecen a dos conjuntos diferentes, cada uno de 32 caracteres. Aun así no es tan rico como el conjunto ASCII pero sirve para transmitir casi cualquier texto, no sirve para transmitir textos complicados como pueden ser programas de computación pues le faltan algunos caracteres; hace muchisimo tiempo, con las primeras computadoras y cuando las impresoras eran muy caras, se usaban máquinas de teletipo como impresoras, aunque no servían para imprimir programas normalmente por esa misma razón.
Buscando en Internet encontré un programa denominado rpi_rtty creado hace algún tiempo por Mike Adams (G3ZLO), el que permitía dado un texto generar los tonos con el que emitirlo en RTTY para a continuación grabarlo en un formato especial del programa rpitx denominado "frecuencia-tiempo" (.ft). En ese archivo se especifican pares de "frecuencia" junto al tiempo que el tono dura. Un archivo en ese formato puede ser procesado por el "viejo" (V1) programa rpitx usando la opción "-m RF". Para mi sorpresa esa función no está mas soportada en el "nuevo" (V2) programa rpitx, el cual existe y acepta la opción pero no funciona como tal. Chequeado con Evariste (F5OEO) me confirmó que efectivamente la función no estaba implementada aún, parece que todos tenemos el mismo problemita de tiempo con nuestros proyectos :-) .
Sin embargo el programa pisstv del paquete rpitx, que sirve para emitir en SSTV y veremos a continuación, internamente genera una estructura de datos similar a la que se utiliza para el formato .ft.
Asi que fue solo cuestión de poner manos a la obra, hice un "fork" del programa pisstv, una mezcla (merge) entre el programa rpi_rtty en lo que hace a la manipulación de textos y generación de tonos junto con el programa pisstv para emitirlos, fue necesario un poco de código propio para pegotear ambos programas para que funcionaran juntos. También para adecuar el hecho que rpi_rtty es un programa escrito en C mientras que pisstv está escrito en C++. Existe la creencia que ambos lenguajes son iguales, o al menos compatibles entre si, pero no siempre es el caso. Y este no fue el caso ciertamente. Para que funcionara tuve que cambiar la forma en que internamente el programa manipulaba los punteros a las áreas de memoria, trabajo simple pero tedioso.
Como sea que fuera completé y puse en github el programa pirtty que es justo para balizas, recibe un texto como argumento y lo emite en RTTY en la frecuencia que se le indique.
Para instalar pirtty se ejecutan los siguientes comandos:

cd ~
git clone http://www.github.com/lu7did/pirtty
cd ./pirtty/src
make
sudo make install

Para ejecutarlo se lo llama con

sudo pirtty  14097000 "   RYRY CQ LU7DID/B LU7DID/B GF05TE 20 K  " 170 45.5

Esto hará que en la frecuencia de 14.097 MHz se emita el mensaje con RTTY shift de 170 Hz y 
velocidad 45.5 bauds.
Aprovechando la mención  también se puede comentar como transmitir SSTV en forma automática.
El estandar que usa pisstv (rpitx) para transmitir SSTV es el denominado MARTIN1, que tarda algo menos de 2 minutos para transmitir una imagen a color.  SSTV emite una señal de variación analógica de frecuencia para transmitir la distinta información de luminancia (intensidad) y crominancia (color), utilizando frecuencias extremas del segmento de audio para representar los sincronismos horizontal y vertical.
El programa toma una imagen en formato "RGB" (formato crudo) y lo emite en la frecuencia indicada; como el formato RGB no es la forma mas común de almacenar archivos se debe primero convertir la imagen desde otro formato, por ejemplo .JPG, para su emisión. El script que hace eso viene en el paquete rpitx y se denomina testsstv.sh su contenido es:

#!/bin/sh
convert -depth 8 BBC.jpg picture.rgb
sudo ./pisstv picture.rgb "$1"

Aqui el archivo BBC.jpg es el emitido y lo hace en la frecuencia que indica el argumento con el que es llamado el script, por ejemplo:

/home/pi/rpitx/testsstv 14235000

El funcionamiento es excelente, pero probablemente SSTV no es un modo práctico para una baliza de solo 100 mW excepto quizás en un entorno local o quizás como parte de un experimento en bandas de VHF o UHF; es un modo relativamente sensible a la relación señal al ruido deteriorada. Adicionalmente una figura tarda casi dos minutos en emitirse, y se difícil encontrar una secuencia de emisión que no "empuje" la relación transmisión-recepción de la estación monitora y la proporción entre los distintos modos fuera de valores razonables. Nada impide no tener en cuenta esta facilidad para algún proyecto futuro (¿globo?¿satélite?¿baliza dedicada?). ¡Quien sabe!

No hay comentarios:

Publicar un comentario