RDS Forum - RDS in Europe/RBDS in the USA

The Radio Data System "RDS" in Europe and the
Radio Broadcast Data System "RBDS" in the USA -
What are the differences and how can receivers cope with both systems?

By

Dietmar Kopitz, Chief Engineer,
European Broadcasting Union
Geneva, Switzerland

and

Terrance Beale, Project Engineer,
Delco Electronics Corporation
Kokomo, USA

Revised on 5 January 1993

Click here to download this document as an Acrobat PDF file (i.e. RBDS.PDF 109,373 bytes) or click here for help on Adobe Acrobat.

1. Introduction

The Radio Data System (RDS) for FM broadcasting was developed within the European Broadcasting Union (EBU). This system was specified by the EBU in 1984 and has been introduced in the large majority of European countries since 1987. Later the system was slightly enhanced through several modifications, and in 1990 it was adopted as a European standard of CENELEC (EN 50067). Today most FM stations in Western Europe use RDS, and receivers, mostly car radios, with RDS functionality are available in Europe from some 50 different manufacturers at prices that are only slightly higher than those of conventional radios [1,2,3,4].

Although the RDS system offers a wide range of implementation options (some like Traffic Message Channel -TMC are still under development), most of the existing RDS car radios have only the so called five basic features: Programme Identification (PI), Programme Service (PS) name, Alternative Frequency (AF) list, Traffic Programme (TP) identification, and Traffic Announcement (TA) signal. Programme Type (PTY) code will perhaps be one of the next popular features, apart from the Enhanced Other Networks (EON) function which is increasingly used now by the European broadcasting networks, and has lead to a so called second generation of RDS receivers.

In the United States, a sub-group on Radio broadcast data systems of the National Radio Systems Committee (NRSC), sponsored by the Electronics Industry Association (EIA) and the National Association of Broadcasters (NAB) began its work in February 1990, after the EBU had demonstrated RDS at various NAB and SAE conventions. The NRSC sub-group based its work on RDS as specified within the EBU, and every attempt was made to keep the US standard compatible with it. However, it became soon evident that the completely different broadcasting structure of the U.S. required a number of modifications to be made. Finally, the U.S. standard had not only to cover FM broadcasting alone, as is the case in Europe, but also AM broadcasting.

In August 1992, the NRSC released for final adoption by 30 September 1992 the draft standard Radio Broadcast Data System (RBDS) version 2.0 [5]. The result of the final voting procedure was that the draft standard has been unanimously accepted as reported to the RBDS subcommittee on 10 November 1992. Final editorial changes are now being made to the RBDS draft standard and the release of the U.S. RBDS specification is to take place at the Winter Consumer Electronics Show (WCES) in Las Vegas, Nevada (January 1993). During the WCES show, the EIA will be doing a large promotion for RBDS. RBDS will also be promoted by the NAB during NAB '93 in Las Vegas (April 1993).

2. Differences between "RDS" and "RBDS"

2.1 The "RDS" component within "RBDS"

RDS has been fully included within RBDS, however slightly modified. Minor modifications to European RDS were made in adapting RDS to the United States broadcasting environment:

Since U.S. AF lists are smaller, AF Method B will not be required. The number of stations that have AF's in the United States is significantly fewer than in Europe. For this reason, Group type 15A (see Figure 1) which transmits four PS characters per group was defined to more efficiently utilize bandwidth and to achieve faster PS acquisition. To keep compatibility with existing receivers, Group type 0A will be transmitted even when Group type 15A is being used.

Since there is no central agency in the U.S. to keep track of assigning the PI codes, there was a need for formulating PI codes for each programme. To ensure the PI codes were unique, a conversion from call letters (which are unique to each programme) was used. This conversion utilizes all PI code elements starting with a first nibble of 1 through A. In doing so, the meaning of the second nibble, and thus the concept of using generic PI codes as defined in European RDS, was lost. For PI codes below B000/hex, receivers should therefore not allow any regional variant AF switching to prevent false AF or PI searches. For PI codes above B000/hex, the receivers may treat the PI code as defined under European RDS.

A new feature for the United States will be the Programme type scanning feature. PTY information will allow a user to seek for his favorite programme format such as a particular type of music. Since U.S. broadcasting differs in content, a new Programme type list of 24 items was created (see Table 1). The U.S. broadcasters are very sensitive of the programme type name shown on the receiver. Therefore, Programme type name (PTYN), Group type 10A (see Figure 2), was also defined. The default eight character name should be shown during the scanning process. Once the receiver stops on a station with the default PTY category, a more specific PTY identifier may be given with PTYN. The PTYN is not intended to change the default eight characters which will be used during the search, but only to more clearly define the programme type once tuned to a programme. If the broadcaster is satisfied with the default PTY name, he will not need to use data transmission capacity to change the default name. Receivers that implement the PTY feature should allow the user to select one from the two different PTY tables (European CENELEC version and U.S RBDS version). The table may also be automatically switched using the Extended Country code (ECC).

2.2 Optional multiplexing of "RDS" and "MMBS"

RBDS includes further an option for the multiplexing of RDS with the slightly modified MBS (MMBS) system, used exclusively by a company called Cue Paging.

To receive RDS information from stations that time-multiplex RDS and MMBS information, receivers should recognize offset word E=0 (all zeros). Current receivers that flywheel through E words, even if seen as errors, will work with no modification. However, improved performance will be obtained with recognition of the new offset word. The MMBS information (blocks with E offset words) will be time multiplexed into the RDS data stream in modulo-4 multiple blocks. Thus, between RDS blocks with offset words D and A, could occur 4, 8, 12, ... MMBS blocks with the E offset. The interleaving will be such that at least two Group type 0A's will be transmitted each second in compliance with the original European specification for acceptable acquisition of the PS name. However, the RDS and MMBS multiplexing will unavoidably degrade the performance for stations that desire to make use of the AF feature due to the loss of repetition of the fast pertinent tuning information needed by the receiver. A typical time multiplex of RDS and MMBS data is shown in Figure 3 where three Group type 0A's are inserted per second. Currently, Cue Paging utilizes the MBS (Mobile Search) paging protocol [6] in about 300 stations out of the approximately 5000 existing FM stations, usually one per

area, covering 90% of the population of the U.S. The option of multiplexing between RDS and MMBS will thus permit these stations to implement RDS while maintaining compatibility with the existing MBS paging receivers.

2.3 Optional In-receiver database

RBDS includes an option for using an "In-receiver database" (typically requiring a 256 kbyte ROM along with some additional RAM capacity) permitting some sort of RDS functionality for AM stations and FM stations that do not implement RDS.

To support all AM and FM stations with the RDS features of PS and PTY, an In-receiver database system (IRDS) may be used. This consists of a ROM that lists all station's call letters (rather than PS) and PTY. An obvious problem is that once a station changes format or call letters, the ROM is outdated. However, the RDS Transparent data (TDC) channels 0 and 1 will be used to update the ROM. This feature is proprietary and requires the acquisition of a license from its owner for implementation in hardware, firmware, and/or software. Implementation details are given in the RBDS specification.

2.4 Option to add an AM data system

An option to add to RBDS a still to be defined AM data system.

A dynamic AM "RDS type" system is being investigated by the NRSC subgroup. One proponent has a system that transmits the data on two-tones within the AM baseband frequency and is compatible with AM stereo. A section within the RBDS specification has been reserved for an AM "RDS type" system.

2.5 New concepts within RBDS

New concepts were included within RBDS for future generation U.S. RDS receivers.

Group type 3A - Location and Navigation (LN) (see Figure 4): This group will allow for Differential GPS (DGPS). The pseudorange corrections will be sent by reference stations over the RDS data stream. A bit definition based on an industry-wide standard called RTCM SC-104 (Radio Technical Commission for Maritime Services Special Committee 104) and which has been defined by a DGPS subgroup under the RBDS subcommittee. The transmission rate for the reduced bit definition is promising, but is still in the testing phases.

Group type 5 - Reserved Transparent Data Channels: Channels 0 and 1 are reserved for the IRDS updates described above. Channel 2 is reserved as an SCA switch. This is to accommodate broadcasting such items as emergency, traffic and weather information via a separate subcarrier at either 67 kHz, 76 or 92 kHz. The information on these sub

carriers can be either speech or data. RDS acts as a switch to tell the receiver when an event is happening on these subcarriers.

3. Conclusions

RDS and RBDS both allow broadcasters and receiver manufacturers to decide which of the possible standardized features they wish to implement. It is in that context that the question arises of whether RDS manufacturers can adapt their software to modify existing products, designed for Europe, for sale in the U.S.A.

The answer to this question is not very obvious because of the large range of implementation options that are theoretically permitted in the two standards. However, in reality the problem is not too difficult to be solved,

simply because most existing RDS car radios have implemented only the five basic features already mentioned above, and these also appear to be quite sufficient during the initial phase of the RBDS implementation in the United States.

RDS and the three components of RBDS have also in common exactly the same data broadcast signal modulation characteristics. This is a suppressed 57 kHz subcarrier which is PSK modulated with a datastream of 1187.5 bps and identical baseband coding, and with data synchronization, optimized for mobile reception. Consequently the same hardware for data demodulation and display can be used, and suitable radio data decoder ICs are now currently available from Philips (SAA 6579), SGS-Thomson (TDA 7330), Sanyo (LC 7070) and a couple of other manufacturers at very competitive prices, because several million of these chips have already been sold. Consequently the question of adaptation becomes entirely a matter of software, apart from the additional memory needed to implement RBDS in its more complete form. A block diagram of a typical VHF/FM radio-data receiver is shown in Figure 5.

As is common practice with all new system standards, a certain time is required by the manufacturers to implement them (typically three years). In this case, however, it is expected by all experts who were involved in the RBDS standardization process that the RBDS standard can be implemented with a much shorter delay, by using the existing and already well proven RDS technology applied for the European market.

Therefore the question asked above could perhaps be simplified to whether the typical European RDS software might be initially sufficient for implementing RBDS within a relatively short delay. Then, it is important to take advantage of the fact that RDS is fully included in RBDS, and the major modifications to be made could then be restricted only to a few. Perhaps the not so urgent items could be left for a later implementation, because they are less essential for the initial introduction of RBDS:

1. The PTY codes are different, and also there are a few new data groups (Group type 3A for navigational information, Group type 10A for Programme type names permitting the use of sub-categories within the relatively limited range of the 24 PTY format codes, and Group type 15A for a faster PS acquisition).
2. The multiplexed operation of RDS and MMBS will be encountered by a receiver rather infrequently, and only on one FM station per area. For the moment only 300 FM stations out of the existing 5000 FM stations use MBS. The only additional requirement to be met in this context is that the data synchronization mechanism, which is a sort of flywheel, will need to recognize the new offset word E (all zeros).
3. Implementation of the "In-receiver database" option is a completely separate issue that will now most likely be exclusively developed further by the company owning the rights for licensing the usage of this module. They will thus also have to market and publicize the acceptance of this option by manufacturers. Also, since the use of automated programme format search tuning in new RBDS receivers is still a controversial issue among broadcasters, this may actually cause a delay in establishing a ROM that contains an agreed programme format for all existing stations.

All the above indicates that existing RDS radios with the five basic features can perfectly meet initial RBDS requirements. If urgent changes to the existing software were to be made, the first thing to do would be to add a recognition of offset word E and, if PTY is additionally implemented, the new table of U.S. PTY codes will have to be used. Contrary to Europe, EON will not yet be required in the U.S., since the functions associated with this feature are more advanced applications for large networks, and thus of little interest during the initial introduction.

Figure 1: Group type 15A - Fast basic tuning and switching information

Figure 2: Group type 10A - Programme type name (PTYN)

Figure 3: Typical time-multiplex of RDS and MMBS

Figure 4: Group type 3A - Location and Navigation (LN)

Figure 5: Block diagram of a typical VHF/FM radio data receiver

Bibliographical references

1. Specification of the Radio Data System RDS for VHF-FM sound broadcasting. EBU document Tech. 3244 (1984) and supplements 1 to 4, published by European Broadcasting Union, Ancienne Route 17A, CH-1218 Grand-Saconnex (Geneva), Switzerland, Now replaced by:
2. CENELEC EN 50067:1992, published jointly by CENELEC (rue de Stassart, B-1050 Brussels, Belgium) and EBU, Geneva.
3. System for automatic tuning and other applications in FM radio receivers for use with the pilot-tone system. CCIR Recommendation 643, Vol. X-Part 1, XVIth Plenary Assembly, Dubrovnik 1986.
4. RDS Newsletters published by EBU, especially No. 14 (the last RDS Newsletter) of August 1992.
5. United States RBDS Standard - Draft No. 2.0, NRSC Document August 1, 1992, published jointly by EIA, 2001 Pennsylvania Ave., NW, Washington D.C. 20006 and NAB, 1771 N Street, NW, Washington D.C 20036.
6. Swedish Telecommunication Administration (Televerket): Paging Receiver for the Swedish Public Radio Paging System, 76-1650-ZE (1976).

Issue date 5 January 1993
Copyright © 1996 RDS Forum. All rights reserved.

Back to the RDS Forum Contents