Receptor SDR remoto con Raspberry Pi

Imagen de EB1HBK
Español

 

En esta ocasión comentaremos la puesta en marcha de un receptor SDR remoto, empleando para ello , como receptor de radio, un decodificador de TDT USB con el chipset RTL2832 + sintonizador R820T. El trabajo de servidor de datos a través de la red ethernet correrá a cargo de un Raspberry Pi.

 

 

- Requisitos previos: Raspberry Pi (Raspi) con Debian Wheezy (Raspbian) funcionando correctamente y con la red configurada (ip fija y acceso a internet) y con el servidor SSH activo, así como un programa cliente para SSH.

(fuente: http://sdr.osmocom.org/trac/wiki/rtl-sdr )

 

Como servidor de datos empleamos el computador monoplaca Raspberri Pi. En el "Raspi" corremos la versión oficial de Debian adaptada para este sistema: Raspbian. El sistema receptor completo queda configurado del siguiente modo:

 

 

Toda la gestion del Raspi se realiza de modo remoto a traves de la red mediante SSH, con lo cual la placa solo necesita la conexion de alimentación, cable ethernet (o adpatador wifi USB) y el decodificador de TDT. Ademas de este modo nos ahorramos lanzar en entorno gráfico en el Raspberry, con lo cual no malgastamos innecesariamente los recursos del sistema.

 

Para instalar el servidor de SDR en el Raspi debemos antes compilar el driver que se encargará de manejar el decodificador de TDT como un receptor de radio de cobertura general. Para ello lo primero que haremos será actualizar completamente el sistema operativo que da vida al Raspi:

 

$sudo apt-get update

$sudo apt-get dist-upgrade

 

- Instalamos Git:

$ sudo apt-get install git

 

- Clonamos en nuestro sistema el directorio de las fuentes:

$ git clone git://git.osmocom.org/rtl-sdr.git

 

- Una vez cargado el directorio en nuestro Raspi, entramos en él y creamos el directorio "build":

$ cd rtl-sdr

/rtl-sdr $ mkdir build

 

- Y a su vez entramos al directorio "build" que acabamos de crear:

/rtl-sdr/cd build

/rtl-sdr/build $

 

- En la carpeta build es donde realizaremos el compilado de los driver que nos permitiran manejar el decodificador de TDT como un receptor SDR, pero antes de iniciar la compilación debemos asegurarnos de tener instaladas en nuestro sistema todas las herramientas y librerías necesarias:

/rtl-sdr/build $ sudo apt-get install cmake

/rtl-sdr/build $ sudo apt-get install build-essential

/rtl-sdr/build $ sudo apt-get install libusb-1.0-0.dev

 

- Si ya tenemos instalado alguno de estos paquetes en nuestro Raspbian, el propio sistema nos avisará y no pasa nada, ahora iniciamos el proceso de compiación e instalación de los drivers:

/rtl-sdr/build $ cmake ../ -DINSTALL_UDEV_RULES=ON

/rtl-sdr/build $ make 

/rtl-sdr/build $ sudo make install

/rtl-sdr/build $ sudo ldconfig

 

- Siguiendo los pasos indicados ya debíeramos tener insatalados los driver del SDR en el Raspi. Si durante este proceso el sistema nos devuelve algun tipo de error los driver no se instalarán correctamente y el "picho" TDT no funcionará aunque el sistema lo detecte. Una vez solucionado el problema que interrumpe el proceso de compilado (dependencias, permisos, etc.) reanudamos la instalación. En tal caso tal vez lo mejor sea borrar todo el directorio "rtl-sdr" con su contenido y repetimos todo el proceso. Para manejarse con los directorios y capetas en modo remoto resulta muy práctico el Midnigth Commander, que aunque no viene con la distribución, nada nos impide instalarlo a voluntad ($ sudo apt-get install mc).

Si la compilación e instalación se realizaron correctamente, pero queremos actualizar los driver, antes de compliar e instalar los nuevos drivers es preciso desinstalar los anteriores mediante "sudo make uninstall"

 

- Probando el sistema:

Lo primero a tener en cuenta es dotar al Raspi de una fuente de alimentación adecuada. En nuestro caso la alimentación la proporciona un pequeño adaptador de red de 5 voltios/1 amperio y estamos casi al límite. De hecho si con el Raspi encendido enchufamos el deco TDT, su elevado consumo de corriente inicial provoca una caida de tensión que reinicia todo el sistema. Esto puede solucionarse de varias maneras: con una fuente capaz de suministrar mas corriente, con un HUB USB que incorpore su propia fuente alimentación o, en nuetro caso, iniciar el sistema con el deco TDT ya conectado al Raspi.

 

- Para "ver" que efectivamente el TDT está ahí y el sistema lo reconoce (lo cual no significa que sea capaz de manejarlo):

/rtl-sdr $ lsusb

 

- Y este es el resultado:

 

- Ahora hacemos un test del driver:

/rtl-sdr $ rtl_test

 

- El sistema nos debe mostrar algo como esto:

 

- Activamos el servidor tcp para el streaming de datos del decodificador, para ello es preciso indicar la dirección ip del Raspi (en mi caso es la ip 192.168.2.14, pero la ip correcta en cada caso particular será aquella que tenga asignada según la configuración de la red local):

/rtl-sdr $ rtl_tcp -a 192.168.2.14

 

- El sistema se queda escuchando las peticiones de los posibles clientes SDR en el puerto 1234:

 

- Esta es la respuesta del servidor funcionando en el Raspi cuando me conecto con el sofware SDR Sharp desde un pc remoto (en este caso un notebook con Windows XP). En el programa SDR que utilicemos para conectarnos al Raspi, en nuestro caso el SDR#, debemos configurar correctamente la IP y puerto del servidor, en este ejemplo es "192.168.2.14:1234", pero cada uno deberá indicarle la IP que corresponda a su Raspi. Una vez establecida la conexión el programa envia al servidor todos los datos necesarios para sintonizar correctamente el deco TDT:

 

- Y este es el detalle de la carga sobre sistema del Raspi. Para un streaming de un 1 MHz la carga sobre el pequeño procesador AMR es menor de un 10%:

 

Y esta es una captura de pantalla desde el ordenador que se conecta al Raspi mediante el software SDR#. Ademas del programa de SDR, se ha lanzado también Gpredict para seguimiento de satélites y un par de sesiones en SSH para lanzar el servidor rtl_tcp y monitorizar el funcionamiento del Raspi.

Es preciso indicar que, salvo el SDR#, todas las ventanas abiertas son aplicaciones que se están ejecutando en el Raspi a través de diferentes sesiones de SSH. Una de ellas (Gpredict) es una aplicación gráfica que estoy ejecutando de modo remoto sin necesidad de lanzar el entorno gráfico en el Raspberry.

 

 

 

Como programa cliente para establecer la conexion SSH dese Windows usamos PUTTY, este sistema resulta mucho mas eficiente que  un escritorio remoto y permite redirigir la salida del servidor X al equipo remoto, para las aplicaciones que lo precisen, sin iniciar el entorno gráfico en el servidor. El mayor requerimiento de recursos de esta disposición se realiza sobre la red ethernet para el streaming de la banda capturada por el deco TDT. Visualizar de modo remoto 1 MHz de banda requiere unos 16 Mb/s sobre la red mantenidos. En este caso el PC remoto no tiene conexión clableada, si no que se conecta a la red mediante un enlace wifi. Al aumentar la ventana de recepción por encima de 1 MHz el audio de la señal comienza a experimentar interrupciones, aunque el programa de configuracion permite hasta 3 MHz. Para mayoría de las ocasiones seleccionar un ancho de banda de 250 KHz es suficiente.

 

Durante la preparación de esta entrada del blog he tenido activo el servidor sdr-rtl en el Raspi escuchando la FM comercial en tanto preparaba y subía las fotos, consultaba el correo y buscaba documentación adicional en internet. Todo esto desde mi viejo PC portátil pentium Mobile 725 a 1600 MHz. Usando el enlace wifi al enrutador y monitorizando un ancho de banda de casi 1 Mhz (900 KHz) ha funcionado perfectamente durante todo el rato.

 

73, J.Moldes -EB1HBK-

Comentarios

Hola muy buenas, el tutorial es una pasada, pero por desgracias para mi no consigo ponerlo en marcha en mi raspi, e seguido todos los pasos una y otra vez y no hay forma posible de solucionarlo me sale este tipo de error.

root@raspberrypi:~/rtl-sdr/build#  rtl_test
Found 1 device(s):
  0:  Generic RTL2832U OEM

Using device 0: Generic RTL2832U OEM

Kernel driver is active, or device is claimed by second instance of librtlsdr.
In the first case, please either detach or blacklist the kernel module
(dvb_usb_rtl28xxu), or enable automatic detaching at compile time.

usb_claim_interface error -6
Failed to open rtlsdr device #0.

y no hay forma de echarlo a andar, me podria echar una mano, gracias

 

Imagen de EB1AGG

Buenas tardes, ahi tienes el problema que seguramente estará cargado el módulo dvb-usb-rtl2832u en el kernel. Prueba descargando estos dos módulos como "root" con la siguiente órden desde un intérprete de comandos:

lsmod <---- para listar los módulos cargados

modprobe -r dvb-usb-rtl2832u dvb-usb <--- si aparecen en la lista de modulos cargados 

Espero que te funcione.

Saludos.

Imagen de EB1HBK

Hola, coincido con Jesus.

El sistema te indica que hay un conflicto con el driver dvb-usb-rtl2838u.

¿Como ha llegado ese driver ahi?

Si has utilizado previamente el pincho como receptor normal de TV, con su driver correspondiente, el sistema reconoce el pincho cuando lo enchufas y emplea ese driver para manejarlo.

Todo apunta a lo que te ha comentado Jesus. Duplicidad de driver para un mismo dispositivo.

Debes desactivar uno de ellos.

73.

 

Imagen de EB1HBK

HOla, buscando info sobre ADS-B para el Raspi, encontre esta nota (http://www.satsignal.eu/raspberry-pi/dump1090.html):

 

"Yesterday I did an upgrade of my Raspberry Pi (sudo apt-get update & sudo apt-get upgrade), but after a reboot dump1090 failed to start. I did some research and quickly found this:

Apparently the upgrade incorporates a new Linux kernel which includes a DVB driver for the dongle as a TV receiver.  Since the device is already in use by this driver, the driver needed for dump1090 can't access it.  Instead the following error message appears:

 

> *Kernel driver is active, or device is claimed by second instance of
> librtlsdr. 
> In the first case, please either detach or blacklist the kernel module 
> (dvb_usb_rtl28xxu), or enable automatic detaching at compile time. 
> * 

 

Luckily a solution is pretty straightforward.  In /etc/modprobe.d create a new file with sudo, named no-rtl.conf (the actual name is not important, but the .conf is).

 

cd /etc/modprobe.d
sudo nano no-rtl.conf

 

Add the following lines:

 

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

The second and third lines might not even be necessary, but on the other hand can't harm either.  After a reboot dump1090 works again as intended."

 

Lo que dicho en español, significa que las nuevas versiones de núcleo para el Raspi, incorporan de serie el driver para ver la TDT con los pinchos USB.

 

Este driver está cargado por defecto, y entra en colisión con el driver para usar el pincho como receptor SDR.

 

La solucion está indicada en el mismo texto, añadiendo la blacklist los drivers originales del núcleo para que no los cargue en el arranque.

 

73.

 

 

hola he hecho el manual al pie de la letra pero me da un error cuando le doy a idconfig: error while loading shared libraries: librtlsdr.so.0: cannot open shared objet file

 

la cosa es que si hago un lsusb lo ha detectado el pincho. tambien me da el mismo fallo en la instrucciond e rtl_test

 

gracias de antemano

Imagen de EB1AGG

Lo que se me ocurre es que puede que precises que las librerías estén presentes en el directorio /usr/lib/ y estén instaladas en /usr/local/lib. Desconozco si estás usando raspbian, archlinux ARM, etc.

Como orientación en este otro manual que publiqué hace ya algún tiempo para Arch Linux pero aplicable a otras distribuciones GNU/Linux tienes la explicación de la instalación "híbrida" realizada por aquel entonces debido a que el paquete incluído en los repos no tenía soporte todavía para los dispositivos que intentaba configurar.

Es el punto acerca de los enlaces simbólicos:

http://eb1agg.hol.es/?q=node/88

 

73

<p>Buenas, fantastico trabajo. Pero una cosa que no termino de aceptar, es el ancho de banda que usa el SDR por ejemplo cuando nos conectamos a la Pi, con el SDR# y estamos viendo el espectro, es enorme el ancho de banda que esto consume, en el desplegable puedes bajarlo hasta 0.250 MSPS que no se lo que es y va regurar, pero asi y todo son unos buenos Mbps.</p><p>Alguie sabe como bajar este ancho de banda?</p><p>Saludos.</p>

<p>Hola:</p><p>Excelente, funciono a la primera, salvo como de costumbre errores por espacios y comas, jajajajajajajaajaa, pero muy bien felicitaciones. me gustaria saber si tienes algo similar para CENTOS 6.7.</p><p>Muchas gracias</p><p>y nuevamente felicitaciones</p><p>Ricardo</p><p>CE3AZT</p><p>Chile</p>

Hola soy Raúl de Burgos, EA1HUZ. Estoy leyendo todos vuestros comentarios por ver si ahí doy con la solución de mi problema. Tengo en un monte donde tenemos nuestros repetidores un sdr montado con el server del sdr-console, del cual me funciona muy bien. Me decidí a montar sobre una Pi 3 el server rtl_tcp , el cual lo tengo instalado sin problemas, pero algo no funciona bien. Os cuento: en la red local se mueve con soltura, pero ya a traves de otra red externa, conectando en remoto al dyndns o la ip pública y con el puerto bien configurado, se conecta pero la cascada va super lenta, y es imposible oir nada. Lo probé con sdr radio, sdr sharp, con los de mac, etc y aun bajando el simbol rate . El adsl que yo tengo es de 12 megas y unos 600 kb de upload. Que debo tener mal ?? Gracias y saludos.
Imagen de EB1HBK

Hola Raul, lo que comentas parece apuntar a una capacidad insuficiente de la conexion de datos. Con 600 kb de subida a la red, aun poniedo el rtl_tcp al menor ancho de banda (250 kHz)... haz números. Muestreo y digitalización de 250 kHz a 8 bits... ya nos vamos a 2 Mb, mas el empaquetado tcp, mas las tramas de sincronizacion y correción de errores en la red...

Lo que te podria funcionar ahi es el websdr.

73.

Añadir nuevo comentario