Radio Data System (RDS) is a communications protocol standard for embedding small amounts of digital information in conventional FM radio broadcasts. RDS standardizes several types of information transmitted, including time, station identification and program information.
The standard began as a project of the European Broadcasting Union (EBU), but has since become an international standard of the International Electrotechnical Commission (IEC). Radio Broadcast Data System (RBDS) is the official name used for the U.S. version of RDS.[1] The two standards are only slightly different, with receivers able to work with either system with only minor inconsistencies in the displayed data.
Both versions carry data at 1,187.5 bits per second (about 1.2kbit/s) on a 57 kHz subcarrier, so there are exactly 48 cycles of subcarrier during every data bit. The RBDS/RDS subcarrier was set to the third harmonic of the 19 kHz FM stereo pilot tone to minimize interference and intermodulation between the data signal, the stereo pilot and the 38 kHz DSB-SC stereo difference signal. (The stereo difference signal extends up 38 kHz + 15 kHz = 53 kHz, leaving 4 kHz for the lower sideband of the RDS signal.)
The data is sent with an error correction code, but receivers may choose to use it only for error detection without correction. RDS defines many features including how private (in-house) or other undefined features can be "packaged" in unused program groups.
RDS is only used on analog stations. The HD Radio equivalent is Program-associated data (PAD).
RDS was inspired by the development of the Autofahrer-Rundfunk-Informationssystem (ARI) in Germany by the Institut für Rundfunktechnik (IRT) and the radio manufacturer Blaupunkt.[2] ARI used a 57-kHz subcarrier to indicate the presence of traffic information in an FM radio broadcast.[3]
The EBU Technical Committee launched a project at its 1974 Paris meeting to develop a technology with similar purposes to ARI, but which was more flexible and which would enable automated retuning of a receiver where a broadcast network transmitted the same radio programme on a number of different frequencies. The modulation system was based on that used in a Swedish paging system and the baseband coding was a new design, mainly developed by the British Broadcasting Corporation (BBC) and the IRT. The EBU issued the first RDS specification in 1984.
Of the three broadcasting partners of the EBU, the BBC were reportedly pursuing the application of RDS technology most enthusiastically and sought to attract bids from manufacturers to make a "BBC-accredited radio" supporting RDS features. Having received no manufacturer interest, however, the corporation engaged designers at Kinneir Dufort to produce a prototype showcasing these features. This prototype, unveiled in 1989, incorporated a liquid-crystal display capable of showing images such as weather maps, accompanied by "a light pen with which the radio can be programmed from barcodes", these barcodes encoding programme information, and supported detachable modules, of which a cassette player module and a printer module were developed. Despite reluctance to develop screen-based functionality that might bring RDS into competition with television, the utility of being able to print out information such as weather maps or even advertising was regarded as potentially interesting to both radio and television manufacturers alike.[4]
Enhancements to the alternative frequencies functionality were added to the standard and it was subsequently published as a European Committee for Electrotechnical Standardization (CENELEC) standard in 1990.
In 1992 the U.S. National Radio Systems Committee issued the North American version of the RDS standard, called the Radio Broadcast Data System. The CENELEC standard was updated in 1992 with the addition of Traffic Message Channel and in 1998 with Open Data Applications and, in 2000, RDS was published worldwide as IEC standard 62106.[5]
The RDS-Forum (Geneva/CH) decided at its annual meeting (8–9 June 2015) in Glion/Montreux to bring the new standard RDS2 on the way. The standard will be created in close collaboration with U.S. colleagues from NRSC RBDS-Subcommittee and should offer a unified platform for FM broadcasting and data services worldwide.
The following information fields are normally contained in the RDS data:
As far as implementation is concerned, most car stereos will support at least AF, EON, REG, PS and TA/TP.
There are a growing number of RDS implementations in portable audio and navigation devices thanks to lower-priced, small-footprint solutions.
The RDS sub-carrier at 57 kHz occupies ±2 kHz of the composite spectrum which in theory keeps it above the upper cutoff of the stereo subcarrier at 53 kHz. However the 53 kHz cutoff is entirely dependent on the performance of the 15 kHz low pass filters used before the stereo encoder. In older equipment, these filters were only designed to protect the 19 kHz pilot and sometimes did not provide sufficient protection to the RDS subcarrier when a significant amount of stereo information was present. In this situation, stereo enhancement devices combined with aggressive audio processing could render the RDS subcarrier unreceivable.
Composite clipping systems may also degrade the RDS sub-carrier because of the harmonics created by the clipping. More modern composite clippers include filtering to protect the RDS subcarrier.
The RDS subcarrier typically uses 2–4 kHz of carrier deviation. Therefore, the deviation available for the program material is reduced by this amount, assuming the usual 75 kHz deviation limit is not exceeded.
The following table lists the RDS and RBDS (North American) program type (PTY) codes and their meanings:
| RDS program type | RBDS program type | PTY code | RDS program type | RBDS program type | ||
|---|---|---|---|---|---|---|
| 0 | No programme type or undefined | 16 | Weather | Rhythm and blues | ||
| 1 | News | 17 | Finance | Soft rhythm and blues | ||
| 2 | Current affairs | Information | 18 | Children's programmes | Language | |
| 3 | Information | Sports | 19 | Social affairs | Religious music | |
| 4 | Sport | Talk | 20 | Religious talk | ||
| 5 | Education | Rock | 21 | Personality | ||
| 6 | Drama | Classic rock | 22 | Travel | Public | |
| 7 | Culture | Adult hits | 23 | Leisure | College | |
| 8 | Science | Soft rock | 24 | Jazz music | Spanish Talk | |
| 9 | Varied | Top 40 | 25 | Spanish Music | ||
| 10 | Country | 26 | National music | Hip hop | ||
| 11 | Rock music | Oldies | 27 | Oldies music | Unassigned | |
| 12 | Soft music | 28 | Folk music | |||
| 13 | Light classical | Nostalgia | 29 | Documentary | Weather | |
| 14 | Serious classical | Jazz | 30 | Alarm test | Emergency test | |
| 15 | Other music | Classical | 31 | Alarm | Emergency | |
The PTY codes have undergone several expansions. The first RDS standard only defined 0–15 and 31. The later RBDS standard implemented in the U.S. assigned the same meanings to codes 0, 1 and 31, but made no attempt to match the rest of the original RDS plan and created its own list for codes 2–22 and 30,[8] including commercially important (in the U.S.) radio formats such as top 40, religious, country, jazz and R&B which were not in the RDS list. This included mismatched codes for information. sport, and rock. Later RBDS standards added types 23 (College) and 29 (Weather), while the RDS type code list grew to its current size,[9] importing some types (e.g. jazz and country) from the RDBS list. RDBS types 24–26 were added in April 2011. The code mismatches are mainly a problem for people taking portable radios into or out of North America.
The RDS standard as specified in EN 50067:1998[10] is separated into these sections according to the OSI model. (The network and transport layers are excluded, as this is a unidirectional broadcast standard.)
The physical layer in the standard describes how the bitstream is retrieved from the radio signal. The RDS hardware first demodulates the 57 kHz RDS subcarrier signal to extract a differential Manchester encoded signal which contains both the bit clock and the differentially encoded bitstream. This allows the RDS decoder to tolerate phase inversion of its input.
At the data link layer, 26 consecutive bits form a "block", consisting of 16 data bits followed by 10 error correction bits. Four blocks make a 104-bit "group". The error correction bits also encode the "offset", or block number within a 4-block group.
The error correction is done using a 10-bit cyclic redundancy check, with polynomial . (Neither a preset nor post-invert is used, as they are not necessary with a fixed-size data field.) The CRC is also summed with one of five "offset" words which identify the block: A, B, C, C′, or D. Four consecutive blocks (ABCD or ABC′D) make up a "group" of 104 bits (64 data bits + 40 check bits). There are slightly over 11.4 groups transmitted per second.
There is no gap between blocks. The receiver synchronizes to groups and blocks by checking CRCs on each 26 bits until synchronization is achieved. Once synchronized (the offset word is predictable), the code is capable of correcting up to 5-bit burst errors.
This basic modulation and block structure was originally developed for the "mobile search" protocol, with the difference that MBS (or the North American equivalent MMBS "modified MBS") does not use an offset word. To allow the two systems to interoperate (and to allow FM radio stations to transmit RBDS data while maintaining their pager contracts), the RBDS standard defines a sixth all-zero offset word E. Groups of four E blocks may be mixed with RBDS groups, and ignored by RBDS receivers. (Likewise, the RBS offset words are chosen to appear as uncorrectable errors to MBS receivers.)
Data within each block (and group) is transmitted most significant bit first, and thus are numbered from bit 15 (transmitted first) to bit 0 (transmitted last).
The most frequently information transmitted is a 16-bit "program identification" code, identifying the transmitting radio station. Blocks A and C′ always include the PI code; offset C is used when the third block contains something else.
Block 1 always contains the 16-bit program identifier. The first 11 bits (bits 15–5) of block 2 are also the same in all groups.
The first 4 bits (bits 15–11) of block 2 are the "group type code", which describe the interpretation of the remaining data. Each group type comes "A" and "B" variants, distinguished by the fifth "B" bit (bit 10): If B=0, then the group is 0A through 15A, and contains 5+16+16 = 37 bits of data. If B=1, block 2 contains a PI code (and is encoded with offset word C′), the group is one of 0B through 15B, and contains 21 bits of data.
Within Block 1 and Block 2 are structures that will always be present in both group versions, for fast and responsive identifications. The first block of every group, will always be the program identification code. The second block dedicates the first 4 bits for Application/Group Type.
| Block 1 | Block 2 | ||||||
| Block Meaning | Program Identification Code | GTYPE | B0 | TP | PTY | varies | |
| bit notation per block | b15 — b0 | b15–b12 | b11 | b10 | b9–b5 | b4–b0 | |
| Fixed Meaning Per Group? | Yes | Yes | Yes | Yes | Yes | No | |
| Block 1 | Block 2 | Block 3 | Block 4 | ||||||
| Block Meaning | Program Identification Code | Group Type | B0 | TP | PTY | APP | Group Specific Payload | Group Specific Payload | |
| Block Payload Bit Value | XXXX XXXX XXXX XXXX | XXXX | 0 | X | XXXXX | XXXXX | XXXX XXXX XXXX XXXX | XXXX XXXX XXXX XXXX | |
| Offset Value (Sync) | Offset A | Offset B | Offset C | Offset D | |||||
Block 3 is used for repeating program identification code.
| Block 1 | Block 2 | Block 3 | Block 4 | ||||||
| Block Meaning | Program Identification Code | Group Type | B0 | TP | PTY | APP | Program Identification Code | Group Specific Payload | |
| Payload Bit Value | XXXX XXXX XXXX XXXX | XXXX | 1 | X | XXXXX | XXXXX | XXXX XXXX XXXX XXXX | XXXX XXXX XXXX XXXX | |
| Offset Value (Sync) | Offset A | Offset B | Offset C' | Offset D | |||||
This allows for quick identification of radio program type, based on country, coverage area, and program reference number. While the country code is specified by the standard, bit 11 to bit 0 is specified by each country local authorities.
| PI Code | Nibble 0 | Nibble 1 | Nibble 2 | Nibble 3 | |||||||||||||
| Meaning | Country Code | Program Area Coverage | Program Reference Number | ||||||||||||||
| Bit Position | b15 | b12 | b11 | b8 | b7 | b4 | b3 | b0 | |||||||||
Country codes are re-used, but only in geographically distant regions beyond FM broadcast range from each other. For example, country code F is assigned to France, Norway, Belarus and Egypt. Neighbouring countries never have the same country code which means it is not necessary for PI codes to be coordinated with adjacent countries.
This is a short list of the full group type. Each group type may have a secondary version available
| Group Type | Bit Value | Message Version A | Message Version B | |
| 0 | 0000 | Basic Tuning and Switching Information Only | ||
| 1 | 0001 | Program Item Number and Slow Labeling Code | Program Item Number | |
| 2 | 0010 | Radio Text | ||
| 3 | 0011 | Application Identification for Open Data Applications | Open Data Applications | |
| 4 | 0100 | Clock Time and Date | Open Data Applications | |
| etc... | etc... | |||
This can be considered an additional program type bit, and indicates that the station broadcasts periodic traffic reports. By including it in every group, a receiver can quickly search for a station which includes traffic reports.
Another bit, traffic announcement (TA), is sent in block types 0A, 0B and 15B to indicate that such a report is in progress. It is common for otherwise-simulcast transmitters to have periodic local traffic reports which are customized to the individual transmitter. The traffic announcement bit tells a receiver that a transmitter-specific broadcast is in progress, and it should avoid switching frequencies while they are in progress.
(There is a different form of traffic announcement bit in block type 14B, which indicates the presence of a traffic announcement on a different frequency, so that radio receivers can automatically switch.)
These are non-comprehensive examples that cover just the simple messages likes station name, radio text, and date/time.
| Version | Block 1 : 26bits | Block 2 : 26bits | Block 3 : 26bits | Block 4 : 26bits | ||||||||||||||
| Block Internal | PI Code | Check + Offset A | GTYPE | B0 | TP | PTY | TA | M/S | DI | C1 | C0 | Check + Offset B | PI Code | Check + Offset C' | Character A | Character B | Check + Offset D | |
| Bit Value | 16 bits | 0000 | 1 | X | XXXXX | X | X | X | X | X | 16 bits | 8 bits char | 8 bits char | |||||
The station name and decoder identification code is sent progressively over 4 groups, where the offset is defined by bit C1 and C0.
| Character Segment | Station Name : | Decoder Identification Code : 4 bit | |||||||||||||
| C1 | C0 | Offset | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 3 | 2 | 1 | 0 | |
| 0 | 0 | 0 | A | B | DI | ||||||||||
| 0 | 1 | 1 | A | B | DI | ||||||||||
| 1 | 0 | 2 | A | B | DI | ||||||||||
| 1 | 1 | 3 | A | B | DI | ||||||||||
| RadioText Version A | Block 1 : 26bits | Block 2 : 26bits | Block 3 : 26bits | Block 4 : 26bits | |||||||||||||||
| Block Internal | PI Code | Check + Offset A | GTYPE | B0 | TP | PTY | A/B | C3 | C2 | C1 | C0 | Check + Offset B | Character A | Character B | Check + Offset C | Character C | Character D | Check + Offset D | |
| Bit Value | 16 bits | 0010 | 0 | X | XXXXX | X | X | X | X | X | 8 bits char | 8 bits char | 8 bits char | 8 bits char | |||||
| RadioText Version B | Block 1 : 26bits | Block 2 : 26bits | Block 3 : 26bits | Block 4 : 26bits | ||||||||||||||
| Block Internal | PI Code | Check + Offset A | GTYPE | B0 | TP | PTY | A/B | C3 | C2 | C1 | C0 | Check + Offset B | PI Code | Check + Offset C' | Character C | Character D | Check + Offset D | |
| Bit Value | 16 bits | 0010 | 1 | X | XXXXX | X | X | X | X | X | 16 bits | 8 bits char | 8 bits char | |||||
As we have already described previous fields above, these dot points below show just the application specific fields.
The station name and decoder identification code is sent progressively over 4 groups, where the offset is defined by bit C1 and C0.
| Text Segment | Version A | Version B | ||||||||||
| C3 | C2 | C1 | C0 | Offset | Char A | Char B | Char C | Char D | Char A | Char B | Char C | Char D |
| 0 | 0 | 0 | 0 | 0 | 1 | 2 | 3 | 4 | Version B Specifies That This Field Is For Program Identification Code | 1 | 2 | |
| 0 | 0 | 0 | 1 | 1 | 5 | 6 | 7 | 8 | 3 | 4 | ||
| 0 | 0 | 1 | 0 | 2 | 9 | 10 | 11 | 12 | 5 | 6 | ||
| ... | ... | ... | ... | etc... | ... | ... | ... | ... | ... | ... | ||
| 1 | 1 | 1 | 1 | 15 | 61 | 62 | 63 | 64 | 31 | 32 | ||
| Version | Block 1: 26 bits | Block 2: 26 bits | Block 3: 26 bits | Block 4: 26 bits | ||||||||||||
| Block Internal | PI Code | Check + Offset A | GTYPE | B0 | TP | PTY | R | R | R | Time/Date Data | Check + Offset B | Time/Date Data | Check + Offset C' | Time/Date Data | Check + Offset D | |
| Bit Value | 16 bits | 0100 | 0 | X | XXXXX | 2 bits | 16 bits | 16 bits | ||||||||
The clock time group is inserted so that the minute edge will occur within ±0.1 seconds of the end of the clock time group.
Time and date are packed as these:
| Time/Date Data | Half Block 2 Payload | Block 3 Payload | Block 4 Payload | |||||||||||||||||||||||||||||||||||||
| Payload Bit Pos | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Field Bit Pos | etc... | Reserved | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 5 | 4 | 3 | 2 | 1 | 0 | ± | 4 | 3 | 2 | 1 | 0 | ||||
| Description | Reserved | Modified Julian Day Number | UTC Hours (0–23) | UTC Minutes (0–59) | Local Time Offset | |||||||||||||||||||||||||||||||||||
The following images illustrate how RDS can be used on an FM radio station. The first three images show the display on the Sony XDR-S1 DAB/FM/MW/LW portable radio. The second and third were taken when the radio was tuned to Nottingham radio station Trent FM.
Companies such as ST Microelectronics, Skyworks Solutions in Austin, Texas and NXP Semiconductors (formerly Philips) offer single-chip solutions that are found in these devices.