RDS/RBDS and RadioText Plus (RT+) FM Receiver in Simulink
This example shows how to extract program or song information from FM radio stations using the RDS or RBDS standard and, optionally, the RadioText Plus (RT+) standard. You can use a captured signal, or receive signals over-the-air in real time using an RTL-SDR radio, an ADALM-PLUTO radio, or a USRP B200/B210 radio.
Required Hardware and Software
To run this example using captured signals, you need Simulink® and Communications Toolbox™ software.
To receive signals in real time, you also need one of these SDR devices and the corresponding software add-on:
RTL-SDR radio and Communications Toolbox Support Package for RTL-SDR Radio add-on
ADALM-PLUTO radio and Communications Toolbox Support Package for ADALM-PLUTO Radio add-on
USRP radio and Communications Toolbox Support Package for USRP Radio add-on
For a full list of Communications Toolbox supported SDR platforms, refer to Supported Hardware section of the Software Defined Radio (SDR) discovery page.
RBDS and RDS are very similar standards specifying how to supplement FM radio signals with additional information. RBDS is used in North America, while RDS was originally used in Europe and evolved to an international standard. RBDS and RDS comprise 3 layers:
Physical layer (Layer 1)
Data-link layer (Layer 2)
Session and presentation layer (Layer 3)
RBDSSimulinkExample model in this diagram receives FM signals either from a captured file or over the air. The model plays the audio signal and displays the RBDS information.
Physical Layer (Layer 1)
The physical layer subsystem receives the captured signal from a file or the live signal from the radio and performs these steps:
FM demodulation: Once the FM signal is demodulated, the RDS/RBDS signal resides at the 57 kHz +/- 2.4 kHz band. Be aware that the RDS/RBDS signal is transmitted with relatively low power, so it is not always visible in the FM spectrum as shown in this figure.
FM signals contain a pilot tone at 19 kHz, which can be used as a phase and frequency reference for coherent demodulation of the RDS/RBDS signal at 57 kHz and the stereo audio at 38 kHz. Pilot tones at 38 kHz and 57 kHz can be generated by doubling and tripling the frequency of the 19 kHz pilot tone [ 2 ].
Processing steps for coherent demodulation of the RDS/RBDS signal are:
Bandpass filtering: The PHY receiver conducts bandpass filtering at 19 kHz and 57 kHz, to isolate the pilot tone and the RDS/RBDS signal, respectively.
Frequency tripling: Raise the complex representation of the 19 kHz pilot tone to the 3rd power to triple its frequency and obtain a 57 kHz pilot tone.
AM Demodulation: RDS and RBDS symbols are generated at an 1187.5 Hz rate and are AM-modulated to a 57 kHz carrier. The 57 kHz RDS/RBDS signal can be coherently demodulated with a 57 kHz carrier that is locked in frequency and phase. Typically, the frequency-tripled 19 kHz pilot tone suffices for coherent demodulation. The next figures show the 19 kHz and 57 kHz pilot tones, the 57 kHz RDS/RBDS signal, and the AM-demodulated baseband RDS/RBDS signal.
At the same time, there exist several FM stations whose 57 kHz RDS/RBDS signal exhibits a time-varying phase offset from the 19 kHz pilot tone and its frequency-tripled version. The PHY receiver contains a Costas loop to compensate for such time-varying phase offsets.
Costas loop: The Costas loop performs 2 orthogonal AM demodulations, one demodulation with a 57 kHz sine and another with a 57 kHz cosine. The sampling rate of the received signal is carefully chosen as 228 kHz, which provides 4 samples per 57 kHz cycle. Therefore, a one sample delay of the 57 kHz pilot tone results to a one quarter wavelength phase offset, and allows us to generate a cosine wave from a sine wave. The sine-demodulated signal corresponds to the coherent demodulation output. The cosine-demodulated signal is used for detection of phase error. The products of the 57 kHz RDS/RBDS signal with the sine/cosine waves are low-pass filtered with the filter specified in Sec. 1.7 of [ 1 ]. The product of the two filter outputs is an error signal. The larger it is, the more the 19 kHz pilot tone is delayed to behave more like the cosine-based demodulator.
Clock extraction: To perform biphase symbol decoding, a clock matching the RDS/RBDS symbol rate of 1187.5 Hz is extracted from the 19 kHz pilot tone. Note, 1187.5 Hz x 16 = 19 kHz. To account for frequency offsets, frequency division is used to extract the clock from the 19 kHz pilot tone. Since the frequency division operation provides multiple correct answers, the baseband RDS/RBDS signal serves as training data that aid in the determination of the desired output.
Biphase symbol decoder: RDS and RBDS use bi-phase-level (bi- -L) coding, which is commonly known as Manchester coding. In each clock cycle, the RDS/RBDS symbol takes two opposite amplitude values, either a positive followed by a negative, or a negative followed by a positive. The biphase symbol decoder negates the second amplitude level, so that each symbol holds the same amplitude level throughout the entire clock cycle. The new clock-wide amplitude level corresponds to the symbol's bit representation. These screenshots correspond to the waveforms #1-6 in Figure 2 of [ 1 ].
To obtain each symbol's bit value, the waveform is integrated over each clock cycle, and the outcome is compared to zero (slicer).
Differential decoding: Finally, the bits are differentially decoded to revert the differential encoding at the transmitter.
Data-link Layer (Layer 2)
Layer 2 is implemented using the RBDSDataLinkDecoder System block. This layer is responsible for synchronization and error correction.
The bit output of the PHY layer is logically organized in 104-bit groups comprising four 26-bit blocks. Each block contains a 16-bit information word and 10 parity bits (see Figure 8 in [ 1 ]). A distinct 10-bit offset word is modulo-2 added to the parity bits of each block.
Synchronization: Initially, block and group boundaries are sought exhaustively using a sliding window of 104 bits. For each 104-bit window, the 4 offset words are sought at the last 10 bits of each 26-bit block. An offset word is identified if no bit errors are detected in the RBDSErrorDetection System block. Once the offset words are identified, group-level synchronization is attained and the exhaustive sliding-window processing stops. Subsequently, the next 104 bits will be treated as the next group.
If future groups contain bit errors and the offset words cannot be identified at their expected position, synchronization may be lost. In this case, Layer 2 first examines the possibility of 1-bit synchronization slips, exploiting the fact that the first information word (16 bits) is always the same for all bit groups. If the first information word is found dislocated by 1 bit (either leftward or rightward), synchronization is retained and the group boundaries are adjusted accordingly. If bit errors persist for 25 group receptions and at the same time synchronization cannot be reestablished using such leftward/rightward 1-bit shifts, then synchronization is lost and Layer 2 re-enters the exhaustive, sliding-window-based search for synchronization.
Session and Presentation Layer (Layer 3)
Layer 2 removes the parity/offset bits, therefore Layer 3 receives groups of 64-bits, comprising four 16-bit blocks. There exist up to 32 different group types, each labeled with a number from 0 to 15 and the letter 'A' or 'B', for example, 0B, 2A, 3A. The format of each group can be fixed or it can be abstract if this group is allocated for an Open Data Application (ODA, see list in [ 3 ]).
Layer 3 is implemented using the RBDSSessionDecoder System block. This block supports decoding of the 0A, 0B, 2A, 2B, 3A, 4A, 10A fixed-format group types.
0A and 0B convey an 8-character string, which typically changes in a scrolling-text fashion.
2A and 2B convey longer 64- or 32-character strings.
3A registers ODAs and specifies their dedicated abstract-format group type.
4A conveys the system time.
10A further categorizes the program type, such as 'Football' for 'Sports' program type).
For ODAs, the RDS/RBDS receiver supports decoding of RadioText Plus (RT+) [ 4 ]. This ODA can break down the long 32 or 64-character string from group types 2A and 2B into two specific content types (for example, artist and song).
This screenshot illustrates the graphical display of the processed RDS/RBDS data:
linux; GNU C++ version 10.3.0; Boost_107500; UHD_184.108.40.206-vendor ---------- see libuhd version information above this line ----------
Basic RDS/RBDS information:
The first field corresponds to the program type, which is conveyed by the second information word of all group types. If 10A group types are received, the first field provides further characterization, such as Sports \ Football.
The second field illustrates the 8-character text conveyed by 0A/0B groups.
The third field illustrates the longer 32/64-character text conveyed by 2A/2B group types.
RadioText Plus (RT+): This section is used if any 3A groups indicate that the RadioText Plus (RT+) ODA [ 4 ] uses a certain abstract-format group type, such as 11A. Then, upon receptions of this abstract group type, the 32/64-character text conveyed by groups 2A/2B will be split to two substrings. Moreover, the two labels will be updated to characterize the substrings, such as Artist and Song).
Group type receptions: The tables act as a histogram illustrating which group types have been received from a station and with what frequency. As a result, users may want to look at the logged data for further information not depicted in the graphical viewer. For example, system time in 4A, alternate frequencies in 0A, or others.
Open data applications (ODA): If any 3A group types are received, then the list of encountered ODAs is updated with the ODA name and their dedicated group type.
Moreover, you can enable the 'Log data to file' checkbox in order to log further fields from all group types.
National Radio Systems Committee, United States RBDS standard, April 1998
Der, Lawrence. "Frequency Modulation (FM) Tutorial". Silicon Laboratories Inc.
National Radio Systems Committee, List of ODA Applications in RDS
RadioText Plus (RT+) Specification
Joseph P. Hoffbeck, "Teaching Communication Systems with Simulink® and the USRP", ASEE Annual Conference, San Antonio, TX, June 2012