Monitor FM-RDS (v1.2)

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.

Monitor FM-RDS v2

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.

Receptor RDS: tabla de caracteres

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).

Esquema: Radio LCD con SI4703

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.

Logo: PCBWay

Ahora también puedes encargar trabajos 3D, mecanizados con CNC y fabricación de cajas metálicas o de plástico inyectado.

https://www.pcbway.es/

4 comentarios en «Monitor FM-RDS (v1.2)»

  1. 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.

  2. 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

    1. 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

Si tienes alguna duda o sugerencia, deja un comentario.