Apuntes de SDR - The Blackbox.

Después de un tiempo pensando en algún proyecto medianamente interesante relacionado con las radios definidas por software (SDR) vé la luz "The Blackbox".

--

--

"The Blackbox" nace con la intención de hacer algo diferente con respecto al "me compro un SDR-IP, lo configuro y a vivir". Es un concepto respetable pero no vá para nada conmigo.

El comienzo de todo fué probar varias aplicaciones que tenían como opción el realizar el control remoto del receptor, como todo en esta vida; Luces y sombras.

La primera de las opciones fué SDR-Radio, SDR Console ( http://v2.sdr-radio.com/ ) o como querramos llamarle. A su favor tiene muchas cosas y opciones interesantes que ván desde el número de la larga lista de receptores soportados hasta la sencillez de uso y configuración tanto como aplicación cliente como para su implementación como servidor. En su contra tiene lo evidente. Una interfaz gráfica de usuario excesivamente cargada y que en ocasiones ralentiza el sistema más de lo que debería. Otro punto en contra es el tener que utilizar exclusívamente un sistema operativo predeterminado.

Posteriormente pensé en implementar DSPSERVER en una Raspberry Pi modelo B ( https://www.raspberrypi.org/products/model-b/ ). Primer problema, Arch Linux en su versión ARM continuaba con el conocido problema de los Funcube Dongle PRO+ y libusb haciendo que la aplicación escrita en python no reconociese correctamente el dispositivo. Se probó con Raspbian (Wheezy), ese problema desapareció y se continuó experimentando con él.

Con el tiempo lo consideré no factible por dos razones. La primera de ellas fué el tener tanto una Raspberry como una máquina prácticamente dedicada para recibir los datos y procesarlos en el equipo que realizaba la función de servidor del lado del usuario "escuchando" las peticiones de conexión. Debido a la sencillez del hardware de la Raspberry, aún overclockeada, no hacía posible el desempeño correctamente.

La segunda razón es el uso de dos máquinas, debido a la poca portabilidad y dimensiones del conjunto no la considero como opción:

1. Raspberry + PC. Dentro de este apartado tenemos infinidad de tipos de montajes.

A) Conexionado por cable entre la Raspberry Pi y el PC que trabajará como servidor escuchando las peticiones de los clientes (DSPSERVER), crear un punto de acceso WiFi (hostapd) a través de la Raspberry y hacer que se comuniquen ambas redes. Consideración:

ROLLAZO.

--

--

B) Crear un punto de acceso WiFi en la Raspberry Pi, crear un script para la ejecución del "servidor" del lado del receptor y posteriormente realizar la conexión del equipo que estará trabajando con DSPSERVER del lado de los clientes. Posteriormente se podrá acceder a través de QtRadio desde dicha máquina haciendo loopback o establecer conexión desde una tablet/smartphone u otro PC a través del punto de acceso. Consideración:

ROLLAZO.

--

--

2. Raspberry x 2.

A) Realizamos el conexionado de las dos Raspberry por cable y creamos un punto de acceso inalámbrico a través de hostapd, es decir, sólamente podemos acceder a través de el a ambas para realizar las tareas pertinentes de gestión. Consideración:

ROLLAZO.

--

--

B) Otro tipo de conexionado es el siguiente. Trabajamos contra un router conectado a una WAN con las dos Raspberry Pi a través de LAN y podemos optar por la opción de hostapd si no dispone el router de punto de acceso inalámbrico. Consideración:

ROLLAZO.

--

--

Todo esto está muy bien para ir probando aplicaciones y las posibilidades que puede ofrecer un servidor SDR remoto con diversas aplicaciones e incluso probar diferentes tipos de montajes para hallar el que más se ajuste a las necesidades de cada usuario. A las mías no se ajustaba reálmente en nada.

Tiempo después de haber usado en bastantes ocasiones WebSDR, tras haber conseguido y testeado una copia del mismo me dí cuenta que era la aplicación idónea para el proyecto por dos sencillas razones:

La primera de ellas es obvia, que sólamente un equipo fuese el encargado de manejar el receptor. Al mismo tiempo que las dimensiones de la Raspberry Pi son más que idóneas para hacer el proyecto de un receptor SDR que uno se puede llevar a cualquier lugar. Se puede instalar en un vehículo y acceder remotamente, dependiendo de las circunstancias, en un radio de cuarenta a cincuenta metros.

La segunda es el camino que nos ha de llevar a lo que es el cliente para receptores remotos "universal" que se pueda utilizar en cualquier tipo de dispositivo y en cualquier lugar.

. Configuración de Blackbox.

--

--
--

--

. Hostapd + DNSmasq.

Una de las dudas que más me asaltaba de todo el proyecto era el enfoque que le debía de dar con respecto a la conexión inalámbrica entre el cliente y el servidor. Al final opté por configurar un punto de acceso inalámbrico para poder usar el receptor. Una de las ventajas que tiene la configuración final es que a su vez cuando estuviese conectado a una red local mediante cable se pudiese utilizar para acceder también a internet. Sería lo ideal para darle uso a algún switch o extender las posibilidades de algun router sin punto de acceso WiFi que se tenga tirado por casa.

La configuración de hostapd y dnsmasq es bastante sencilla. En esa ocasión he utilizado Raspbian para el uso del FCDPP ya que es la distribución GNU/Linux que menos problemas me ha dado en su uso durante las pruebas pertinentes con DSPSERVER.

Lo primero que hemos de hacer es conectar el dispositivo inalámbrico que queremos utilizar para el punto de acceso y observamos la salida de 'lsusb' en un terminal:

--

pi@AZOR-SDR ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 148f:3072 Ralink Technology, Corp. RT3072 Wireless Adapter
Bus 001 Device 005: ID 04d8:fb31 Microchip Technology, Inc.
pi@AZOR-SDR ~ $

--

A continuación procedemos a instalar el firmware para los dispositivos RaLink y el paquete wireless-tools:

--

pi@AZOR-SDR ~ $ sudo apt-get install firmware-ralink

--

El siguiente paso es la configuración del interface inalámbrico a través de la edición del fichero '/etc/network/interfaces'

--

pi@AZOR-SDR ~ $ more /etc/network/interfaces
auto lo

iface lo inet loopback

iface wlan0 inet static
address 192.168.44.24
netmask 255.255.255.0

auto eth0
iface eth0 inet static
address 192.168.43.23
gateway 192.168.43.1
dns-nameservers 80.58.61.250 80.58.61.254
netmask 255.255.255.0
network 192.168.43.0
broadcast 192.168.43.255

--

Algo que deberíamos hacer aunque no es estríctamente necesario es la instalación de un servidor dhcp para asignar automáticamente la dirección IP del dispositivo que utilizaremos para realizar la conexión del lado del cliente hacia el receptor. En este caso concreto instalaremos y configuraremos dnsmasq.

--

pi@AZOR-SDR ~ $ sudo apt-get install dnsmasq

--

Creamos el fichero '/etc/dnsmasq.d/comolequeramosllamaralared' con la siguiente estructura.

--

pi@AZOR-SDR ~ $ more /etc/dnsmasq.d/fcdpp
interface=wlan0
dhcp-range=192.168.44.200,192.168.44.210,12h
dhcp-option=3,192.168.44.24
server=80.58.61.250
server=80.58.61.254

--

La explicación del fichero de configuración es muy sencilla. En "interface" indicamos que dispositivo de red inalámbrica utilizaremos para escuchar las peticiones de conexión. El rango utilizado por el servidor dhcp en mi caso lo he reducido a 10 direcciones IP debido a que el número de clientes que se conectarán son mínimos (a lo sumo uno o dos simultáneamente), se asignarán las IP en el rango 192.168.44.200/192.168.44.210. Continuamos con la configuración de la dirección de la puerta de enlace que utilizará automáticamente el dispositivo que se conecte al punto de acceso (cuando utilice la obtención de las direcciones gateway, ip y dns a través de dhcp), evidentemente es 192.168.44.24. Y para finalizar he configurado los servidores DNS primario y secundario de orange, también se puede configurar el que a cada uno le apetezca.

Reiniciamos dnsmasq a través de estas órdenes para que cargue la nueva configuración.

--

sudo service dnsmasq restart o sudo /etc/init.d/dnsmasq restart

--

Ahora continuamos con la instalación y configuración de 'hostapd'.

--

pi@AZOR-SDR ~ $ sudo apt-get install hostapd

--

La configuración del mismo es bastante sencilla, sólamente tenemos que cambiar tres parámetros partiendo mismamente de mi propio fichero de configuración; SSID del punto de acceso, canal en el que trabajará y la contraseña.

--

pi@AZOR-SDR ~ $ more /etc/hostapd/hostapd.conf
# interface used by access point
interface=wlan0

# firmware driver
driver=nl80211

# access point SSID
ssid=redwifi

# operation mode (a = IEEE 802.11a, b = IEEE 802.11b, g = IEEE 802.11g)
hw_mode=g

# access point channel
channel=6

# options
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0

# key management algorithm
wpa_key_mgmt=WPA-PSK
wpa_passphrase=contraseña
wpa=2

# set ciphers
wpa_pairwise=TKIP
rsn_pairwise=CCMP

--

El paso siguiente es editar el fichero '/etc/default/hostapd' añadiendo esta línea.

--

DAEMON_CONF="/etc/hostapd/hostapd.conf"

--

Dicha línea es la encargada de indicarle la ubicación a hostapd de su fichero de configuración. Resultando el mismo de la siguiente manera tras la edición.

--

# Defaults for hostapd initscript
#
# See /usr/share/doc/hostapd/README.Debian for information about alternative
# methods of managing hostapd.
#
# Uncomment and set DAEMON_CONF to the absolute path of a hostapd configuration
# file and hostapd will be started during system boot. An example configuration
# file can be found at /usr/share/doc/hostapd/examples/hostapd.conf.gz
#
#DAEMON_CONF=""

# Additional daemon options to be appended to hostapd command:-
# -d show more debug messages (-dd for even more)
# -K include key data in debug messages
# -t include timestamps in some debug messages
#
# Note that -B (daemon mode) and -P (pidfile) options are automatically
# configured by the init.d script and must not be added to DAEMON_OPTS.
#
#DAEMON_OPTS=""
DAEMON_CONF="/etc/hostapd/hostapd.conf"

--

Antes de finalizar con la configuración nos queda por realizar un pequeño "trabajito" con iptables para redirigir el trafico de datos entre ambos interfaces.

Primero editamos el fichero '/etc/sysctl.conf' y descomentamos la línea correspondiente a ip_forward bajo IPv4.

--

net.ipv4.ip_forward=1

--

El siguiente paso es aplicar las reglas correspondientes a iptables.

--

pi@AZOR-SDR ~ $ sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

pi@AZOR-SDR ~ $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

pi@AZOR-SDR ~ $ sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT

--

El último paso que debemos de llevar a cabo antes de reiniciar el sistema es guardar las reglas de iptables en un fichero para su posterior restauración ya que se borrarán una vez se apague o reinicie el dispositivo. De esta manera se cargarán en el arranque del sistema operativo de la Raspberry Pi.

--

pi@AZOR-SDR ~ $ sudo iptables-save > /etc/network/iptables.default

--

Así de esta manera creamos el fichero 'iptables.default' que se cargará automáticamente cada vez que se active el interface "wlan0". Editamos de nuevo el fichero '/etc/network/interfaces' añadiendo la siguiente línea.

--

up iptables-restore @ /etc/network/iptables.default

--

Dejándolo finálmente editado de esta manera.

--

auto lo

iface lo inet loopback

iface wlan0 inet static
address 192.168.44.24
netmask 255.255.255.0
up iptables-restore @ /etc/network/iptables.default

auto eth0
iface eth0 inet static
address 192.168.43.23
gateway 192.168.43.1
dns-nameservers 80.58.61.250 80.58.61.254
netmask 255.255.255.0
network 192.168.43.0
broadcast 192.168.43.255

--

NOTA IMPORTANTE: Debido a la interpretación de símbolos de drupal en full html el carácter @ lo sustituímos por el redireccionador de entrada, drupal al parecer se monta un cacao "mental, por contra con el redireccionador de salida > no existe problema. };-P

Una vez guardados los cambios reiniciamos la Raspberry Pi y comprobamos que el cliente que se conecte al punto de acceso WiFi no tiene problema alguno en la conexión.

. Configuración de WebSDR.

La configuración de WebSDR es reálmente sencilla debido a que el FUNcube Dongle queda configurado en GNU/Linux como una tarjeta de sonido, pero a su vez debemos cambiarle la frecuencia central de trabajo para aprovechar esos 192KHz que utilizará el receptor. Para ello emplearemos la aplicación 'fcdctl' en detrimento de 'qthid', es una razón obvia, interactuar con el receptor a través de SSH a través del intérprete de comandos y no utilizando X11 Forwarding. Se hace referencia a los pasos para compilarlo en el fichero 'README' y lo podemos descargar en un terminal con la órden.

--

git clone https://github.com/csete/fcdctl

--

La definición de los parámetros del receptor para su uso es algo muy sencillo.

--

band 20m

device $hw:1,0,0

samplerate 192000

centerfreq 14096

swapiq

antenna kalypso roma edition

gain 0

--

Centramos la frecuencia del FCD en 14096 y ejecutamos WebSDR. Nos conectamos a través del navegador www a la ip que hayamos asignado a la Raspberry Pi y al puerto definido en el fichero de configuración.

. WebSDR Script.

--

--

Después de darle muchas vueltas de si realizar una aplicación en C o un script para no centrarme en el uso del receptor en una sola banda "a piñón fijo" me decanté por la segunda opción utilizando la siguiente estructura para ejecutar remotamente a través de SSH tanto el centrado de frecuencia como el cambio de configuración necesario para WebSDR acorde con la selección llevada a cabo.

--

echo "| 1A -> 28 MHz HAM - (28000 - 28192) | 01A -> 21 MHz BCAST - (21450 - 21642) |"
echo ""
echo "Seleccione una de las opciones:"

read wsdr

if [ $wsdr = "1A" ]
then

orden 1
orden 2
orden 3

elif [ $wsdr = "01A" ]
then

orden 1
orden 2
orden 3

fi

--

A partir de lo cual cada uno puede modificarlo a su gusto y preferencias personales.

. Pocket RXTX.

--

--

Otra cosa que echaba de menos sobre todo al llevar el receptor instalado en el vehículo era la simplicidad para cambiar la frecuencia de trabajo en la banda sintonizada a modo de "cabezal" con el teléfono móvil. Reálmente no se hace nada cómodo a través de Chrome/Firefox/Palemoon. Y reálmente lo que perjudica el uso de esta aplicación es el no poder introducir manualmente la dirección del servidor propio o ajeno al que deseemos conectarnos. Respeto la idea del desarrollador de la misma para ir incluyendo bajo petición los servidores del resto de usuarios pero no la comparto.

Realizando un pequeño trabajo de estudio de las peticiones al ejecutar la app, tendréis la respuesta de como poder hacerla funcionar con vuestro propio servidor. Hasta aquí puedo leer.

Como consideración final, lo expuesto en este artículo se puede realizar de igual manera con un RTL2832U con una simple conexión en "loop" a través de rtl_tcp. A falta de alojar el conjunto en una caja o bien mecanizada o bien del reciclaje de algún equipo de banda ciudadana de desguace se irán añadiendo imágenes del proyecto finalizado a continuación de estas líneas.

Saludos.

73 TU SK. (for the moment)

--