Con este receptor es posible conocer los parámetros más importantes que se transmiten por la subportadora RDS. Con esta nueva actualización (v1.2), las librerías del RDS permiten analizar más información que antes, y todo el código está depurado para optimizar la memoria del ATMEGA328P, permitiendo así añadir más prestaciones en el receptor de radio, utilizando el mismo microprocesador.
Tabla de caracteres del RDS
El sistema RDS transmite los textos codificando los caracteres con su propia tabla de 8 bits, y dispone de 3 tablas de caracteres diferentes, denominadas G0, G1 y G2. Por defecto, los receptores de radio traducen los 8 Bytes del PS y el Radio Texto (RT) utilizando la tabla de caracteres G0. La tabla GO incluye la mayoría de los caracteres utilizados por las diferentes lenguas de la zona EBU. Los receptores de radio tienen que leer el código de 8 bit que reciben por cada letra, y convertirlo al código que se corresponda con la tabla de caracteres que estén utilizando. En este caso sería necesario convertir los caracteres dos veces, una vez para adaptarlos a la tabla de caracteres gráficos de su display LCD, y otra más para codificarlos en UTF-8 y transmitirlos por el puerto serie.
Los primeros 127 caracteres de la tabla del RDS siguen el estándar ISO, por lo tanto no hay que convertirlos. Sin embargo, los 127 caracteres más altos de la tabla del RDS no son estándar, y es necesario convertir sus códigos para mostrar correctamente las letras. En este receptor sólo se convierten los caracteres latinos más utilizados, son los caracteres enmarcados con color en la tabla del gráfico anterior.
El display LCD de este receptor dispone de una memoria RAM, que le permite almacenar un máximo de 8 caracteres gráficos diferentes. El display reserva las 16 primeras posiciones de su mapa de caracteres para almacenar gráficos, pero hay que tener en cuenta que el display sólo guardará 8 caracteres gráficos diferentes. Si se guardan los 8 caracteres en las primeras posiciones de la CGRAM (direcciones 0x00 a 0x07), estos mismos caracteres se copiarán también en las 8 posiciones siguientes (direcciones 0x08 a 0x0F). Debido a esta limitación, sólo se generan y guardan los gráficos de las 5 letras acentuadas en minúscula, y las letras: ü, ñ y ç. Cuando se reciban por RDS letras mayúsculas acentuadas, el programa las convertirá en letras mayúsculas sin acento.
Receptor FM-RDS con: SI4703
Este sencillo receptor de radio está basado en el módulo SI4703, de bajo coste y altas prestaciones. Este módulo incluye en su interior todo el receptor de radio, incluso el decodificador Estéreo, el decodificador RDS y un pequeño amplificador de audio. Para controlar este módulo, he utilizado el micro-controlador ATMEGA328P (Arduino).
Descarga de ficheros
El firmware y librerías que necesitas para programar el ATMEGA328P, los puedes descargar desde el siguiente enlace: RDS_Radio_SI4703 (v1.2)
¿Necesitas fabricar un PCB?
Actualmente hay muchas empresas que se dedican a fabricar circuitos impresos (PCB), pero no en todas podemos conseguir pequeñas tiradas a buen precio. Por suerte, ahora disponemos de Internet y es mucho más fácil que antes. Podemos buscar empresas en cualquier parte del mundo, y es más fácil encontrar un fabricante que haga nuestros prototipos (PCB) a buen precio. Una de las empresas más grandes del sector es PCBWay.
Ahora también puedes encargar trabajos 3D, mecanizados con CNC y fabricación de cajas metálicas o de plástico inyectado.
El código da el error »variable or field ‘DisplayFrequency’ declared void»
Copia el error que te aparece, pero supongo que no estás utilizando las mismas librerías.
He Makes Money Online WITHOUT Traffic!
Most people believe that you need traffic to profit online…
And for the most part, they’re right!
Fact is.. 99.99% of methods require you to have traffic.
And that in itself is the problem..
Because frankly, getting traffic is a pain in the rear!
Don’t you agree?
That’s why I was excited when a good friend told me that he was profiting, but with ZERO traffic.
I didn’t believe him at first…
But after he showed me the proof, it’s certainly the real deal!
I’m curious what your thoughts are.
Click here to take a look >> https://bit.ly/3mOAfVp
Please view it before it’s taken down.
I am not looking for traffic on the web, only to help those who search for technical information on the web.
Hola
Soy un seguidor tuyo y me gustan todos tus montajes.
Hace unos 6 años hice un montaje parecido, pero mis conclusiones fueron un tanto regulares:
La cuestión de los datos que proporciona la emisora mediante el RDS es un tanto heterogénea.
La mayoría de las emisoras solo transmite en nombre de la emisora y las frecuencias alternativas.
En los datos que proporciona como frecuencias alternativas, la mayoría carga una serie de frecuencia por defecto, las cuales solo 2 o 3 te sirvan.
El dato de hora y fecha es un tanto irregular, la mayoría no la transmite bien, y para colmo lo hace en modo de hora UTC, y la fecha en modo Juliano.
En la única emisora que pude implementar bien la hora, estaba adelantada en 5 minutos. Y en otras mandaban los datos erróneos.
Vivo en Palencia, y puede que las emisoras no retransmitan bien los códigos.
08/01/2015 – Arduino-Radio RDA5807 con RDS-LCD Nokia 3310-Parte 2.
http://seta43.duckdns.org/rards.html
24/07/2018 – Arduino nano – Radio RDA5807 – Control mediante un PC con RDS.
http://seta43.duckdns.org/radpc.html
¿Te pasó lo mismo?
Espero otro montaje tuyo.
Saludos
Juan
Hola Juan.
El modo en el que se envía la información de fecha y hora (CT) por RDS, permite que un receptor de radio pueda mostrar con precisión la fecha y hora local, ajustando la fecha y hora al huso horario del receptor. Lo primero que se debe hacer es leer el valor offset y la hora UTC. A partir de ahí, se corrige la hora con el offset recibido, y ya tienes la hora local. Si al hacer el ajuste se sobrepasa el valor de 23:59, se incrementa en 1 el valor del número del día recibido en formato Juliano. Si el ajuste offset provoca el salto a una hora inferior a 00:00, se resta 1 al número del día en formato Juliano. Una vez corregido el número del día recibido, sólo tienes que aplicar las fórmulas para obtener el día, día de la semana, mes y año LOCAL (no UTC).
Es cierto que la mayoría de los radiodifusores que envían la información de fecha y hora (Grupo: 4A), no sincronizan los relojes de sus codificadores RDS, y por eso lo que se recibe es la hora que tiene el reloj de cuarzo del codificador RDS (con su deriva y sin respetar los cambios horarios verano/invierno).
En España, todas las emisoras de RNE que transmiten RDS son bastante precisas. Todos los codificadores RDS sincronizan sus relojes 24 veces al día, y lo hacen en el segundo 10 de todas las horas en punto. La información de referencia es el reloj patrón de RNE, y además se envía compensando el retardo del satélite. Como curiosidad, la información de la hora del RDS no es UTC, es la hora peninsular. Así en todos los transmisores de la Península, Baleares, Ceuta y Melilla recibirás siempre un offset = 0, ya sea en verano o invierno. En las islas Canarias, el offset siempre será -2 (2 medias horas = 1 hora menos). Esto no afecta en nada al cálculo que tienes que hacer para extraer la información de fecha y hora local, pero facilita enormemente la gestión del envío en el servidor RDS.
En cuanto a las frecuencias alternativas, la lista de frecuencias deberían estar ordenadas por proximidad y potencia con el transmisor que las envía. De todas forma, esto no es relevante, porque la mayoría de los receptores de radio con RDS modernos gestionan y ordenan las frecuencias alternativas, y ninguno de ellos cambia a otra frecuencia sin antes comprobar que el PI de ambas emisoras indican que se trata del mismo programa.
Saludos,
José Ramón