Receptor SDR remoto con Raspberry Pi
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
USB TDT SDR RASPBERRY
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
RTL2832U
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.
Coincido.
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.
Problema con driver RTL-SDR en Raspberry
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:
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).
Add the following lines:
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.
rtl en rapberry
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
librtlsdr.so.0
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
ancho de banda
RTL-SDR para centos
RTL_TCP
rtl_tcp lento
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