Hace tiempo me compré un TDT tipo PEN de los que circulan por EBAY a un precio muy adquisitivo (incluido portes) no más de 10€ puesto en casa....
El caso es que estuve trasteando con él , sobre todo, para visualizar el "espectro radioeléctrico" en la banda de HF y en la modalidad de Comunicaciones Digitales, como "soft" para CCDD dado que utilizó principalmente el HDR (Ham Radio de Luxe) , pero la subpantalla de visualización del espectro nunca fué de mi agrado... con lo cual el TDT tipo PEN me facilitaba mucho las cosas en la CCDD...
Después de mirar las distintas posibilidades con las que que podemos "jugar" con el pincho "TDT" , hay una que los colegas de URO (Unión de Radioaficionados de Ourense) me ha llamado bastante la atención por su poca complejidad constructiva y la versatilidad con la que juegan en la "Raspberry Pi" ,tan de moda últimamente :-)
73 de EA7DYY (Santi)
Extraido del Blog www.cacharreo.es
Autor: J.Moldes -EB1HBK-
"Continuamos experimentando las posiblidades del Raspberry PI trabajando como servidor con el driver rtl_tcp
y los receptores de TDT con chipset RTL2832. Veremos a continuación
como trabajar a la vez con el Raspi y dos receptores de TDT
independientes.
En las anteriores entradas hemos visto
como configurar el Raspi para que realice la funcion de servidor remoto
para el receptor SDR. De este modo podemos colocar el receptor en una
ubicación mas adecuada para la recepción. El límite de distancia física
está determinado por la calidad del cable de red y las características
de la red Ethernet, o la calidad del enlace wifi o del ancho de banda
disponible en la red si accedemos al Raspi a través de internet.
Lo que hemos explorado ahora es la
posibilidad de manejar a la vez dos "pinchos" TDT y enviar el flujo de
datos de ambos dispositivos a traves de la red Ethernet hasta el
ordenador cliente en el que se ejecuta el software SDR. En teoría esto
nos permitiría visualizar el doble de espectro, puesto que sumamos la
capacidad disponible en cada uno de los receptores, o bién podemos
examinar dos bandas diferentes a la vez. En estas condiciones la
capacidad de ancho de banda de la red Ethernet se aprovecha al máximo,
debe por tanto ser de muy buena calidad o tendremos que conformarnos con
ver un espectro de radio mas pequeño.
La idea es esta:
Aspectos previos a tener en cuenta:
- Los "pinchos" TDT no pueden obtener
del Raspi la suficiente energía para su correcto funcionamiento. En
lugar de enchufarlos directamente en el puerto USB del Raspi, usaremos
un replicador de puertos USB (HUB) con su propia fuente de alimentación,
y los conectaremos del modo que se indica en el dibujo.
- Antes de continuar, es preciso haber configurado correctamente en nuestro Raspi el driver rtl_sdr, tal y como explicamos en esta entrada.
Una vez satisfechos los requisitos anteriores, enchufamos en el HUB los dos receptores TDT y ejecutamos el comando rtl_test (desde una consola local o remotamente por ssh), a ver que ocurre...
- $ rtl_test
Esto es lo que nos dice el sistema:
¡Estamos de enhorabuena!... si
observamos la captura de pantalla, el driver ha detectado correctamente
los dos "pinchos" conectados, y lo que es mejor les ha asignado a cada uno un número de dispositivo diferente: "0:" y "1:".
Consultando la documentacion del driver
rtl_tcp observamos que entre las opciones disponibles al lanzar el
servidor podemos indicarle la IP local (opcion -a), el número de puerto (opción -p), que por defecto es 1234, y... ¡el número de dispositivo! (opción -d).
Luego ¿será posible lanzar el servidor rtl-tcp desde el Raspi,
asignando a cada uno de los receptores a un puerto diferente sobre la
misma IP?
Es posible. ¡Ole y ole por los programadores!, que han previsto e implementado esta posibilidad.
Lanzamos el servidor rtl_tcp
para el primer dispositivo, en este caso el 0 y lo asignamos al puerto
por defecto (1234). Recordad que la IP debe ser la de vuestro Raspi (en
el siguiente comando el último caracter es un cero):
-$ rtl_tcp -a 192.168.2.14 -p 1234 -d 0
Tal como se ve en la siguiente captura de pantalla:
Ahora desde otra consola, o como en
nuestro caso, abriendo una nueva sesión por ssh, lanzamos el servidor
para el segundo dispositivo. En este caso el dispositivo 1 en el puerto
1235:
- $ rtl_tcp -a 192.168.2.14 -p 1235 -d 1
En esta imagen vemos las dos sesiones de ssh con el servidor activo en cada una de ellas:
Ahora ya tenemos funcionando los servidores para ambos dispositivos, 0 y 1,
en la dirección 192.168.2.14 y en los puertos 1234 y 1235
respectivamente. Desde el ordenador cliente lanzamos el programa SDR#
con la opcion RTL-TCP, en la que le indicamos la IP del Raspi
(192.168.2.14) y el puerto en el que queremos conectar 1234 ó 1235. Con
esto comenzaremos a recibir el flujo de datos de uno de los dos
dispositios, el 0 o el 1. Para conectar con el segundo dispositivo
lanzamos otra instancia del programa SDR# (tanto en el mismo PC cliente
como en otro diferente) indicando de nuevo la opción RTL-TCP, la IP del
Raspi, pero marcaremos el puerto que tengamos libre.
Aqui tenemos una captura de escritorio
con las dos instancias de SDR# corriendo en el mismo PC cliente, en una
se recibe la FM comercial en W FM y en la otra se ve el segmento de
radioaficionados de 144 en FM-N. en cada caso el ancho de espectro
monitorizado de de 2 MHz, con lo que en total estamos visualizando 4 MHz de espectro.
Aquí la mayor carga de tarea corre a cargo del PC cliente, puesto que
debe realizar toda la función de DSP para monitorizar el espectro y
proceder la demodulación de las señales correspondientes, pero... ¿que
ocurre entretanto en el Raspi?...
Esta es la carga del sistema sobre el Raspi con los dos servidores rtl_tcp activos, cada uno enviando el flujo de datos correspondiente a una anchura de espectro de 2 MHz (4 MHz en total):
Esto ya representa una tarea mas
exigente para el Raspi aunque, puesto que no estamos usando entorno
gráfico ya que todo el manejo lo realizamos íntegramente mediante
consola a través de ssh, la eficiencia del sistema es muy alta y todavía no se queja.
Esta es una buena propuesta para colocar
los receptores hasta el máximo que nos permita la red Ethernet, para no
perder ancho de banda, y alimentar el conjunto a través de la misma
red:
No hay comentarios:
Publicar un comentario