RDS or Radio Data Services or RBDS Radio Broadcast Data Services has been around for a long time and used in a number of devices such as pagers and smart meters but for our purposes we will stay with the text display on FM receivers.
This is a process where an RDS encoder inserts small amounts of text in the FM signal which will display on FM Receivers. This may be the artist and title of the current song, station slogan or other informational, promotional or commercial campaigns.
There are two text messages sent to the encoder. The Program Service Name or PS which is an 8 character static message with the stations call letters or street name and Radio Text or RT which is a 64 character dynamic message text message. While newer receivers have larger screens showing all data, most older and even some newer FM Receivers do not display Radio Text or require the listener to press and “i” info or “D” display button.
The listener may unaware of the command or if used they see a blank display or a “No Text Data” message as the station is not sending RDS data. To overcome this issue encoder manufactures introduced the Dynamic Program Service or DPS where the 64 character messages is broken into 8 character segments and sent as the PS. When introduced thousands of listeners turned on their radios and the now playing data displayed with the most common response of “I Love That”. While not part of the standard it has become common place but when used it is recommended to use Block scrolling where the text is scrolled 8 characters at a time and a scroll rate to 2-3 seconds. Using the scroll method scrolls 1 character at a time and can be distracting.
Posting data to and RDS Encoder
Depending on the station equipment the encoder may be located at the station or may be at the transmitter site. Either way, information is sent to the encoder via RS-232 Serial connection or via an IP link.
For a serial feed it may be necessary to add a serial card to the PC or to use a USB to Serial connector. If the encoder is at the station a serial connection is normally not an issue. If the encoder is at the Transmitter it may be necessary to use the Serial port on the STL to connect to encoder at the transmitter. If the port is unavailable it may be necessary to install a serial line to the transmitter or to use an IP connection. Note: The Serial connection will be required every few minutes 24×7 so it needs to be a reliable connection.
Most encoders support a TCP/IP or UDP connection which can be used to send the RDS data to the encoder. Like the serial connection, if the encoder is at the station it just needs to be on the same network as the sending application. If it’s at the transmitter if will require a static IP or require port forwarding to get to the encoder.
The two most common IP issues is the encoder IP cannot be accessed from the sending computer. If so, it may require a second NIC to connect to the encoders network or altering the networks so both the CSRDS computer and encoder are on the same network. When connected we can ping the encoder from the sending computer.
The second and more common issue is the port. While we can ping the encoder we may still have issues sending data if the port is blocked by the network security which may be on the computer running the application, the network switch/router or a group policy. Errors can occur if the port is already in use by another application or service.
There are two protocols for sending text to the encoder. UECP which is the original encoding format commonly used in Europe and ASCII which sends text based commands commonly used in North America. CSL uses the ASCII option as it is easier to track and trouble shoot as you can see the actual data being sent rather then text and binary codes in the feed.