Radio Data System (RDS)
Radio Data System (RDS) is a method of transmitting digital data along with the audio signal on FM radio. Although RDS is a European standard, it is also used in a slightly modified way in the USA, where it is called RBDS. Information on this page applies to both RDS and RBDS, and in the following discussion, the term "RDS" is used to refer to both standards.
What data is transmitted by RDS?
Data transmitted by many FM radio stations includes:
- Name of the station.
- List of alternative frequencies for the same station.
- Radiotext, e.g. artist and song title.
- Current date and time.
- Program type, e.g. Rock, Pop, Country, News...
- Traffic Message Channel (TMC), information about traffic jams etc.
Even though analog radio may seem a bit old fashioned nowadays, RDS will certainly continue for several years, as it is relied upon by most car radio and navigation systems.
What devices can receive RDS information?
The first requirement in order for a device to receive RDS should be self evident - it must be equipped with a radio receiver/tuner. In addition, it will also require a RDS decoder.
For TV tuner cards which such capabilities, the most common RDS decoder chip seems to be the Philips SAA6588; which is found connected, via I²C, to the card's video decoder chip. Examples of RDS capable cards include:
- Terratec Cinergy 600
- KNC ONE TV-Station RDS
- KNC One TV-Station DVR
- TYPHOON TV TUNER CARD RDS
Some USB radio dongles also have the capability to receive RDS data, such as the Silabs-based radio dongles (kernel module radio_si470x).
RDS in V4L2 standard
According to V4L2 specifications, raw data from RDS decoders is read from the radio device. Data consists of blocks where each block is 3 bytes long. All decoding has to be done in user space.
A kernel module for accessing the RDS decoder is needed. Hans J. Koch wrote a module for the SAA6588 (saa6588.ko). It's in the stable kernel since 2.6.14.
The modules for the main video chips (bttv, saa7134...) have to be modified to load and use the RDS decoder module. This has only been done for bttv so far. With a bttv card that has a SAA6588, you can read raw RDS data via /dev/radio after loading the saa6588 kernel module. For the moment, saa6588 is not requested automatically by bttv, you have to modprobe it manually.
When loading saa6588, you might need to pass parameters to make it work with your card. The SAA6588 chip uses its own crystal with a frequency that is a multiple of 4.332MHz (4.332, 8.664, 12.996, or 17.328 MHz). Depending on the crystal you have on your board, the module parameter "xtal" must have a value of 0, 1, 2, or 3, respectively. Default is 0, so you don't need the "xtal" parameter if you have a 4.332 MHz crystal for the SAA6588 on your card.
See this page for more details.
RDS decoding in user space has to address the following situations:
- There are more than one RDS capable cards in the system.
- There are more than one applications that want to access an RDS source.
This can best be done by a daemon that reads raw data from all RDS sources, decodes it, and distributes the results via TCP/IP or a unix domain socket. Such a daemon (rdsd) is under development, the project is hosted here:
There is also a library (librds) that simplifies application development by handling the communication with rdsd. While rdsd depends on a V4L2 compatible architecture, librds can be cross platform! It could therefore be possible to write applications for other operating systems that can connect via TCP/IP to an rdsd running on a Linux box.
Development progress in that project is somewhat slow as there is only one developer. Any help is highly welcome!
Within the rdsd project, a simple console tool (rdsquery) has been developed. Other possible applications could be:
- Enhance current radio applications (radio text, station names, ...)
- Stand alone RDS viewers.
- TMC applications to process traffic messages.
- Application to set the system clock according to RDS date/time.