Convertidor Analógico Digital de 16 bits y 448000 muestras por segundo basado en el Bt878A

Os transcribo un interesante artículo publicado por :Juan Domenech Fernandez

Convertidor Analógico Digital de 16 bits y 448000 muestras por segundo basado en el Bt878A

 

Antecedentes: La potencia de los actuales ordenadores personales, ofrecen infinitas posibilidades de análisis y manipulación de señales analógicas, pero primero, es necesario digitalizarlas mediante un Convertidor Analógico Digital (ADC). El PC mas sencillo incorpora una tarjeta de sonido con la que podemos digitalizar fácilmente señales, pero con la limitación de 44000 muestras por segundo (Sps) en la mayoría de casos y de 96000 Sps en algunas tarjetas de gama alta. Según Nyquist esto nos permitirá llegar a señales con amplitud de 48Khz en el mejor de los casos. Para realizar experimentación con sonidos, esta frecuencia puede ser mas que suficiente pero para subir mas por el espectro o analizar con mas detalle señales de baja frecuencia son necesarias mas muestras por segundo.

Objetivo: Obtener un ADC que nos permita digitalizar a la frecuencia mas alta posible, utilizando hardware de uso corriente.

Método: Utilizaremos el ADC de baja frecuencia que incorpora el chip Bt878A en un tarjeta capturadora de video de uso corriente.

Advertencia: Este artículo narra practicas que deben ser realizadas por personas con experiencia en electrónica y que pueden provocar daños en sus equipos.

Preparación:

1 - Material utilizado:

- Tarjeta capturadora de video con sintonizador (tuner) de la marca: BestBuy modelo: EasyTV (Fabricada por Prolink modelo PV-BT878P+ Rev 9D) basada en el chip Conexant 878A Fusion y tuner Philips PAL_BG FI1216
- PC de uso corriente con tarjeta de sonido Creative.
- Linux Mandrake 9.1
- Condensador 1ľF (no polarizado).
- Conectores RCA hembra y cables de audio coaxiales.
- Herramientas diversas: alicates de corte, soldador, etc.
 

2 - ¿Qué el chip Bt878A?

Es el sucesor del famoso Bt848. En el diseño de este nuevo integrado, Brooktree (ahora Conexant) incluyó diversas mejoras, entre ellas un ADC de baja frecuencia destinado inicialmente a digitalizar las señales de sonido (y las subportadoras de audio) provenientes del sintonizador (tuner) para realizar la posterior demodulación (FM estereo, TV estereo, RDS, MTS, etc.) mediante software, en el driver del sistema operativo. Por desgracia, ningún fabricante ha aprovechado estas características (que yo sepa) y simplemente se utiliza el ADC de un Bt878A para obtener el sonido mono del tuner (en el mejor de los casos).

3 - Yo tengo una capturadora con un "878" pero no esta fabricado por Brooktree.

Lo podemos encontrar fabricado por Rockwell (datasheet download page)

Y por Conexant, con el encapsulado Bt878KHF (datasheet download page)

o el Fusion 878A (datasheet download page), que es el mas habitual.

4 - ¿Qué características tiene este ADC?

Conexant dice en su datasheet:

"1.2.6 Audio DMA Channels
The audio channel delivers 8-bit or 16-bit digital samples of a digital frequency-multiplexed analog signal to system memory in packets of DWORDs.
A RISC program controls the audio DMA Program Initiator. The flow of audio data and audio RISC instructions is completely independent and asynchronous to the flow of video data and video RISC instructions.
Since the audio data path operates in continuous transfer mode (no sync gaps), both the analog and the digital audio inputs can be used for other data capture applications. The analog input offers 360 kHz usable BW at 8 effective bits or 100kHz usable BW at 12 effective bits. The digital input offers up to 20 Mbps for the parallel mode and 40 Mbps for the serial mode."
 

Gerd Knorr, dice en el README de su modulo btaudio: 

"The analog mode supports mono only.  Both 8 + 16 bit.  Both are _signed_int, which is uncommon for the 8 bit case.  Sample rate range is 119 kHz to 448 kHz.  Yes, the number of digits is correct.  The driver supports downsampling by powers of two, so you can ask for more usual sample rates like 44 kHz too."

Por lo que al presente documento se refiere, concluimos que: El ADC del Bt878A puede operar a 8 y 16 bits, a 119000 y 448000 Sps y un canal (monaural) de forma nativa sin ningún tipo de hardware o conversión adicional.

5 - Mi capturadora está basada en un Bt878A pero no es una "PV-BT878P+ Rev 9D" ¿Me sirve igualmente?

Es necesario realizar una inspección ocular de la tarjeta y averiguar si el fabricante ha aprovechado las entradas del ADC.

Datasheet Conexant Fusion 878A

Los pins del ADC son:

Pin #	Signal	Description
100	STV I	TV sound input from TV tuner.
98	SFM I	FM sound input from FM tuner.
94	SML I	MIC/line input.
96	SMXC A	Audio MUX anti-alias filter RC node. Connect through 68 pF capacitor to BGND.
106	RBIAS A	Connection point for external bias 9.53 kΩ 1% resistor.
105	VCOMO A	Common mode voltage for the audio analog circuitry. This pin should be connected to an external filtering 0.1 ľF capacitor.
104	VCOMI A	Common mode voltage for the audio analog circuitry. This pin should be connected to an external filtering 0.1 ľF capacitor.
107	VCCAP A	Audio analog voltage compensation capacitor. This pin should be connected to an external filtering 0.1 ľF capacitor.
103	VRXP A	Audio input circuitry reference voltage. This pin should be connected to an external filtering 0.1 ľF capacitor.
102	VRXN A	Audio input circuitry reference voltage. This pin should be connected to an external filtering 0.1 ľF capacitor.

Los pins que nos interesan son 100, 98 y 94 que son las entradas de la señal. En mi caso el 94 no esta utilizado, el 100 y 98 están unidos por una pista y luego conectados directamente a la salida de sonido del tuner. Se recomienda verificar que el fabricante haya instalado los condensadores externos para los voltajes de referencia.

El Bt878A incorpora un multiplexador interno (mux) para seleccionar la entrada de sonido activa (TV, FM o MIC) al igual que incorpora un mux interno para seleccionar la señal de video activa (Tuner, S-Video o Composite).

Es importante no confundir este mux con el mux externo que incorpora la PV-BT878P+ utilizando un Philips HEF4052B (datasheet download page) gobernado a través de GPIO.

Las instrucciones de este documento se aplican directamente solo a la tarjeta Prolink PV-BT878P+ 9D, pero aprovechándolas y estudiando con detalle otro tipo de tarjeta se puede conseguir el mismo objetivo.

En el caso de que el fabricante no aproveche las entradas del ADC (no estén soldadas a ninguna pista) se recomienda no utilizar esta tarjeta, ya que para realizar soldaduras en un integrado SMD se requieren herramientas que no están al alcance de la mayoría de nosotros.

Instalación:

1 - Como paso previo necesitamos tener funcionando un Linux con Kernel 2.4.x y con soporte de sonido.

Yo he utilizado un Mandrake 9.1

# uname –a
Linux lab 2.4.21-0.13mdk #1 Fri Mar 14 15:08:06 EST 2003 i586 unknown unknown GNU/Linux

La principal razón de utilizar Linux en la fase de captura de las señales es que no he encontrado drivers para Windows que permitan utilizar el ADC del Bt878A como periférico de sonido en el sistema operativo. Si alguien aporta información al respecto, se agradecerá enormemente. (Esto no significa que no me guste trabajar con Linux... Al contrario :)

2 - Verificaremos que se ha cargado el modulo de sonido correctamente:

# lsmod
Module                  Size  Used by    Not tainted
af_packet              14952   0  (autoclean)
ide-floppy             15580   0  (autoclean)
ide-tape               48304   0  (autoclean)
ide-cd                 33856   0  (autoclean)
cdrom                  31648   0  (autoclean) [ide-cd]
floppy                 55132   0 
ne2k-pci                6752   1  (autoclean)
8390                    7916   0  (autoclean) [ne2k-pci]
supermount             15296   2  (autoclean)
videodev                7872   0 
sb                      9044   0  (unused)
sb_lib                 41454   0  [sb]
uart401                 8196   0  [sb_lib]
sound                  70644   0  [sb_lib uart401]
soundcore               6276   0  [sb_lib sound]
rtc                     8060   0  (autoclean)
ext3                   59916   2 
jbd                    38972   2  [ext3]

3 - Verificamos que se ha creado el primer dispositivo de sonido:

# ll /dev/dsp*
lr-xr-xr-x    1 root     root            9 Jan  6 12:26 /dev/dsp -> sound/dsp
lr-xr-xr-x    1 root     root           10 Jan  6 12:26 /dev/dspW -> sound/dspW

4 - Desde Xwindows verificaremos que el mezclador, nos muestra los parámetros de nuestra tarjeta de sonido:

5 - Reproduciremos un sonido de muestra que debemos escuchar por nuestros altavoces.

Por ejemplo:

# sox –t .wav /usr/share/licq/sounds/fun/Online.wav –t ossdsp /dev/dsp

6 - Instalamos físicamente la tarjeta sintonizadora en el PC

Conectar únicamente el cable de antena de televisión. No conectar ningún cable de sonido.

7 - Instalamos bttv (0.7.107)

Debido a diversos problemas con la instalación de modulo bttv y sus componentes asociados, se ha simplificado este paso, omitiendo esta fase y saltando directamente a la instalación única del modulo btaudio.

8 - Carga de btaudio

btaudio es el módulo que nos permite utilizar el ADC del Bt878A, montándolo como un dispositivo de sonido (¡Gracias Gerd!). Mi release de Linux (Mandrake 9.1) lleva incluido este modulo en /lib/modules/2.4.21-0.13mdk/kernel/drivers/sound/btaudio.o.gz y sin mas complicaciones podemos proceder a cargarlo.

# insmod btaudio debug=1

Si todo ha ido bien, podemos observar la salida del kernel:

#tail -100f /var/log/syslog | grep btaudio
Apr 17 19:08:57 lab kernel: btaudio: driver version 0.7 loaded [digital+analog]
Apr 17 19:08:57 lab kernel: btaudio: Bt878 (rev 17) at 00:09.1, irq: 10, latency: 32, mmio: 0xde001000
Apr 17 19:08:57 lab kernel: btaudio: using card config "default"
Apr 17 19:08:57 lab kernel: btaudio: registered device dsp1 [digital]
Apr 17 19:08:57 lab kernel: btaudio: registered device dsp2 [analog]
Apr 17 19:08:57 lab kernel: btaudio: registered device mixer1

 

9 - Compilación del modulo

En el caso de que nuestro linux no incluya el modulo compilado podemos intentar hacerlo nosotros mimos. Puedes descargarlo de aqui btaudio-0.7.tar.

Descomprimimos, nos situamos en el directorio y compilamos:

# gcc -O2 -DMODULE -D__KERNEL__ -c btaudio.c -isystem /lib/modules/2.4.21-0.13mdk/build/include/

Se comprime el modulo y lo movemos a su sito:

# gzip btaudio.o
# mv btaudio.o.gz /lib/modules/2.4.21-0.13mdk/kernel/drivers/sound/
# depmod -a

En mi caso aparece el mensaje "depmod: *** Unresolved symbols in btaudio.o.gz" pero hago caso omiso de él.

# insmod btaudio debug=1

Si nos aparece el mensaje:

./btaudio.o: kernel-module version mismatch
./btaudio.o was compiled for kernel version 2.4.21-0.13mdkcustom while this kernel is version 2.4.21-0.13mdk.

Deberemos editar el fichero /usr/src/linux/include/linux/version.h y sustituir '#define UTS_RELEASE "2.4.21-0.13mdkcustom"' por '#define UTS_RELEASE "2.4.21-0.13mdk"' y repetimos la compilación.

10 - Verificamos que se han creado dos nuevos dispositivos de sonido:

# ll /dev/dsp*
lr-xr-xr-x    1 root     root            9 Jan  6 13:54 /dev/dsp -> sound/dsp
lr-xr-xr-x    1 root     root           10 Jan  6 14:04 /dev/dsp1 -> sound/dsp1
lr-xr-xr-x    1 root     root           10 Jan  6 14:04 /dev/dsp2 -> sound/dsp2
lr-xr-xr-x    1 root     root           10 Jan  6 13:54 /dev/dspW -> sound/dspW

El /dev/dsp1 es para la interfase digital I2S y /dev/dsp2 para el ADC del Bt878A, la cual utilizaremos.

11 - El mezclador ha detectado el nuevo dispositivo: "Brooktree_Bt878_audio"

Activamos el Rec y subimos la ganancia en Line1, dejando en Mute Line2 y Line3 tal como indica la imagen.

12 - Prueba de entrada de sonido:

# sox -w -r 32000 -t ossdsp /dev/dsp2 -t ossdsp /dev/dsp

Deberíamos oír una fuerte señal de ruido en nuestros altavoces conectados a la tarjeta de sonido. Se trata de la señal de sonido que proviene del tuner (que se activa tan pronto como arranca el PC) la cual estamos digitalizando y enviando a la tarjeta de sonido. ¡Lo estamos haciendo con nuestro Bt878! :)

Podemos utilizar un programa de televisión para sintonizar un canal (xawTV). No es necesario que veamos correctamente la imagen de televisión. Si dejamos el comando sox funcionando en una shell, escucharemos el sonido del canal.

13 - Prueba de captura de sonido:

# sox -w -r 448000 -t ossdsp /dev/dsp2 -t .wav sound.wav

-w            16 bits
-r            448000 Sps
/dev/dsp2     entrada analógica del ADC
-t .wav       formato archivo de sonido

Realizando un análisis del fichero de sonido utilizando Audacity (freeware), podemos observar que hasta 20Khz tenemos el sonido audible que proviene de la televisión pero también aparecen señales a frecuencias mas altas (sobretodo ruido) que son la mejor prueba de que estamos digitalizando frecuencias superiores (hasta 224Khz aproximadamente).

Modificaciones

1 - Entrada de señal externa

La PV-BT878P+ 9D dispone de las siguientes conexiones:

Todo parece indicar que el conector AudioIN nos permite introducir una señal en la tarjeta y en consecuencia, en la entrada del ADC del Bt878A, pero por desgracia no es así. Inexplicablemente, la misión de la entra AudioIN es únicamente obtener esa misma señal en AudioOUT al pasar por el mux Philips tal como muestra el siguiente gráfico. Desearía estar equivocado, pero... :(

Resumiendo: Mediante el mux externo escogemos si en la salida AudioOut obtenemos la señal externa del AudioIN o la señal de sonido del tuner, pero en ningún caso esta señal externa llegara al ADC

2 - Acceso a la salida del tuner.

La idea del "mod" es: Inyectar una señal externa utilizando la conexión de la salida del tuner en el pin 25, inhabilitando primero dicha salida y conduciéndola luego hasta fuera del PC.

También sacamos fuera del PC la salida de sonido del tuner para no perder este recurso.

Datasheet Tuner Philips FI1216

SYMBOL	PIN	DESCRIPTION
VT	11	tuning voltage (monitor)
VS	12	supply voltage tuner section +5 V
SCL	13	I2C-bus serial clock
SDA	14	I2C-bus serial data
AS	15	I2C-bus address select
n.c.	21	not connected
2nd IF sound output	22	second IF sound output
CVBS	23	Composite Video Baseband Signal output
VIF	24	supply voltage IF section +5 V
AF sound output	25	AF sound output

3 - Pasos:

- Extraer la tarjeta del PC
- Cortar (¡con cuidado!) la salida de sonido del tuner, en el pin 25
- Soldar en la antigua conexión del pin 25 (en la superficie de la tarjeta) un condensador de 1ľF para bloquear la CC, con las patas mas cortas que nos sea posible.
- Soldar entre el condensador y la toma de masa de la tarjeta un cable coaxial de sonido (la malla del cable conectada a masa).
- Se recomienda utilizar como conexión de masa la pata del chasis del tuner que atraviesa el circuito impreso.
- Soldar un conector de audio RCA hembra (o lo que mas nos interese) al extremo del cable. Llamaremos a esta entrada: ADC_IN
- Soldar entre el pin 25 del tuner (que ha quedado al aire) y masa otro cable coaxial de audio.
- Soldar un conector de audio RCA hembra (o lo que mas nos interese) al extremo del cable. Llamaremos a esta salida: Tuner_OUT
- Instalar la tarjeta dejando los cables fuera del PC.

4 - Prueba.

Una vez instalada la tarjeta, realizaremos una prueba para asegurarnos que hemos realizado correctamente las soldaduras.

Utilizando un cable normal de audio con conectores RCA macho, puenteamos ADC_IN con Tuner_OUT y repetiremos el punto: Instalación-12. Deberíamos oír nuevamente la señal de ruido (o sonido si tenemos sintonizado un canal) que proviene del tuner pero ésta vez saliendo y entrando en nuestro PC.

Si la prueba es satisfactoria ya tenemos listo nuestro ADC casero de 16 bits y 448000 Sps.

5 - Interferencias.

Llegados a este punto es interesante realizar una pequeña prueba para conocer a las "vecinas" que tendremos siempre en nuestros experimentos: Las interferencias del interior de nuestro ordenador.

Por muy bien que realicemos las soldaduras y por muy cortos que dejemos los trozos de cobre sin apantallar, sufriremos diversas interferencias provocadas por toda la electrónica que rodea al Bt878A.

Esta imagen es un espectrograma realizado con el programa SpectraPLUS (demo 30 días) para Microsoft Windows, de una señal obtenida del Bt878A sin nada conectado al ADC_IN y amplificada por software con el parámetro Plot_Top = 0.010

En mi caso se observan fuertes señales en la zona de 0 a los 2000Hz y diversos "pitos" a 60, 98, 102, 120.4 y 180.4 Khz.

Teóricamente, cada modelo de PC provocará otro tipo de interferencias y es importante conocerlas para evitar obtener falsos resultados en nuestros experimentos. Pero sin preocuparnos demasiado, ya que si tenemos una carga conectada y en el nivel de entrada es lo suficientemente fuerte, las interferencias casi desaparecen.

6 - ¿Y ahora que?

Vosotros mismos, ya no tenemos el limite de nuestra pobre tarjeta de sonido. Yo estoy explorando nuevas zonas y encontrando cosas realmente interesantes y espero publicar nuevos artículos pronto.

¿Alguien adivina a qué corresponde el espectro de la siguiente señal? (clic para ampliar)

73 de EA7DYY (Santi)

Sistema D-Star ED4YAG de EA4URE

Sistema D-Star ED4YAG de EA4URE

Viernes, 22 de Agosto de 2014 10:18 | |

Después de revisar y actualizar el Sistema D-Star "ED4YAG" de EA4URE, ya está nuevamente en funcionamiento ofreciendo la cobertura habitual, aunque estamos en vías de mejoras en la antena. Cualquier usuario que no esté registrado en la red D-Star mundial, podrá enviar un correo a: Esta dirección electrónica esta protegida contra spam bots. Necesita activar JavaScript para visualizarla indicándo su indicativo, nombre y e-mail y le podremos dar de alta para que a través de nuestro repetidor (si llegara vía radio) u otros repetidores de su zona pueda conectar con cualquier parte del mundo a través del sistema D-Star.
(Se requiere tener un equipo con placa D-Star)
Óscar del Nogal, EA4TD EA4URE Office Manager

73 de EA7DYY(Santi)

Echolink en estado "ON"

Después de rectificar el Audio TX ( salía con señal baja) , ya vuelve a estar operativa la conexión vía ECHOLINK hacia el RU-748.

73 de EA7DYY (Santi)

SDR con control remoto vía RJ45.... de Alto Standing ;-)

Se trata de una tarjeta diseñada y construida por un ruso aficionado que vive en Israel 4Z5LV Alex Trushkin la presentación del citado proyecto(en inglés) está en el sitio:
http://www.afedri-sdr.com/

AFEDRI SDR-Net rev2.1 in Box

AFEDRI SDR-Net (Rev. 2.0) - default configuration

Este receptor convenientemente conectado a una discreta antena de banda ancha  permite escuchar  todo el espectro de la banda de HF y de forma remota a través de Internet mediante la obtención del software de cliente  desarrollado por Simon HB9DRV ; la innegable ventaja de esta configuración es que el programa cliente está muy bien desarrollado y permite operaciones muy interesante.
Su problema (desde mi punto de vista) el precio :
AFEDRI SDR Network Rev. 3.0a (In box!)
It provides up to 2000 ksamples/s when working trough Ethernet interface and up 250 ksample/s, when connected trough USB interface.
259$ + shipment: per fully assembled, tested and  working  SDR

Un saludo
73 de EA7DYY (Santi)

Identificación sonora de los diferentes MODOS DIGITALES

     Para aquellos que se inician en la modalidad de las COMUNICACIONES DIGITALES ,sobre todo en la banda de HF , os dejo un enlace donde podéis escuchar el tono de transmisión de los diferentes modos digitales más usados en la radioafición.

     Siempre ha sido un obstáculo, sobre todo para aquellos que se inician en esta modalidad, el poder distinguir una transmisión digital, dentro del "batiburillo" de transmisiones digitales que escuchamos en el segmento asiginado para este tipo de transmisión.

Aunque está en italiano, con el magnífico traslator del Google Chrome, o el traslator del Google, no tendremos ningún problema  :-)

Enlace:

http://www.iw6on.it/sistemi.html

73 de EA7DYY(Santi)

Proyecto DMR Spain (Sistema Digital)

Extraido de: http://www.slideshare.net/ssppcc/proyecto-dmr-spain

DMR Spain es la iniciativa española del proyecto DMR-MARC, una red Internacional de repetidores digitales que utilizan la tecnología DMR para sus comunicaciones.

Actualmente la red DMR-MARC tiene presencia en más de 18 países. A grandes rasgos, esta red nació de la mano de un grupo de ingenieros de Motorola que a su vez eran radioaficionados y que decidieron ir un paso más allá integrando las comunicaciones digitales entre los radioaficionados, creando la mayor red digital del momento..

En Europa la red DMR-MARC ha tenido un crecimiento exponencial en los últimos meses, y creemos que los radioaficionados de EA no podemos desaprovechar la oportunidad de pasar a formar parte de esta red que actualmente tiene más de 3500 usuarios, y 350 repetidores repartidos en 18 países (ver mapa), por esta razón nace el proyecto DMR Spain.

73 de EA7DYY (Santi)

Puesta en "PRUEBAS" Echolink --> ED7YAU-R (URE SAN FERNANDO-CADIZ)

A partir de hoy se ha instalado en "PRUEBAS " , el acceso al RU-748 vía ECHOLINK , bajo el Tipo de Nodo -> Repetidor , con indicativo ED7YAU-R .

Al acceso al repetidor vía Echolink solamente está autorizado a los "USERS" , es decir, todos aquellos radioaficionados con licencia validada por el Servidor Echolink (previo envío de copia de la licencia) podrán acceder al RU-748.

De igual modo las conversaciones que se produzcan vía radio por el RU748 serán reenviadas al Echolink (ED7YAU-R) , de esta forma aquellos/as que estemos fuera de "cobertura radio" de la zona del RU-748 tenemos la posibilidad de estar en contacto con los colegas de la zona de Cádiz.

Estará durante un tiempo prudencial , para comprobar y valorar su necesidad técnica , y cubrir aquellas zonas de sombra del repetidor.

Os dejo un enlace para aquellos que NO tenéis instalado el Echolink en el PC, tablet o Móvil, existen versiones tanto para Android como para IOS .

Manuales Echolink:

http://redlk2.es/echolink/spanish.html

NOTA-1: A efectos de NO tener problemas de acceso al servidor Echolink, tener presente que tanto en el FIREWALL de vuestro PC o Tablet , tenéis que tener abiertos los puertos TCP/UDP 5198 y 5199 y en ROUTER también.

NOTA-2: Hay otra cuestión entre cambio y cambio (comunicaciones Echolink-RU-748) debéis dejar unos 3 segundos "de espera" pues hay un retorno entre la conversión de la señal analógica y la digital en el procesamiento del AUDIO.

73 de EA7DYY (Santi) 

Sobre comentarios al respecto o incidencias que se produzcan podéis mandar un email a:

ea7urfvocaliant@gmail.com

 

Experimentación con el RTL-TCP + Raspberry Pi con dos receptores TDT Chinos

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:

PRUEBAS CON EL RU-706 EN LA MODALIDAD ANALÓGICO-DIGITAL (FUTURO DSTAR)

Como ya os comenté en mi POST del día 10/07/2014 , sobre de que ya teníamos todos los materiales necesarios para la confección del repetidor DStar , en estos días he procedido a su construcción en lo que corresponde a la parte de RX/TX+Duplexor y placa controladora, en estos días a intervalos no contínuos se procederán a efectuar pruebas en la QRG : 438.825 (-7.600Mhz)  Subtono:77  , que es la frecuencia solicitada a Teleco por ser la que menos nos afectaría o afectaríamos a repetidores cercanos a la ubicación del Repetidor.

En una fase posterior , comprobado el rendimiento de los equipos y duplexor, voy a conectar el módulo DVRPT_V1 (GMSK) , ya tengo instalado en un PC el Linux (Ubuntu 14.2 LTS) e instalaré el soft de gestión  de comunicación entre el el DVRPT_V1 y el PC para la gestión del Dstar.

73 de EA7DYY