In our first article of a series, in the March 10 issue, I outlined the history of RDS/RBDS and the differences between the 64-character RadioText and eight-character Program Service.
Let’s go in-depth on how you can optimize them for your stations.
With the renewed importance of RadioText (RT), you should evaluate your RT send rate.
This 2010 Buick Lacrosse ‘Audio System with Navigation’ Package features AM/FM/XM stereo, CD/DVD player, 40 GB hard drive device, MP3 playback, hard-drive-based navigation and rearview camera system. The text display is RDS. Photo by Alan Jurison Most RDS encoders allow an engineer to adjust how frequently the RT is sent in comparison to other RDS data groups. The manufacturer’s default settings are not necessarily ideal for a good end-user experience, so they require your attention.
When we tune to a station with RDS and RT, the receiver looks at the RDS signal and starts decoding. Often, it waits until the RT has been sent twice, to make sure it was received without any errors, before displaying it. If your station isn’t sending RT frequently, this process can take too long.
RDS encoders often arrive from the manufacturer with a very slow setting. For example, the default on one popular model is set to send one RT group for every four PS groups. With a default setting such as this, the receiver takes up to 15 seconds to decode the RT under optimal conditions. Add in some signal impairments such as multipath or a weak signal, and this process can take even longer.
This creates a bad user experience. Now add the new RadioText+ tagging standards (to be discussed later in this series) and it’s clear that your RT transmission rate is an important component to check and consider adjusting.
I recommend increasing the RT transmission rate from the defaults to increase how frequently the RT is sent. The more frequently it is sent, the quicker a receiver can decode and display it to your listeners. Using the example above, instead of one RT group for every four PS groups, I’d recommend sending three RT for one PS.
RT transmission rates
RT transmission rates didn’t matter much when the RT was mostly hidden on capable mobile receivers. If it took 15–20 seconds to resolve, it wasn’t a big deal.
Now it matters more; and I believe we as an industry need to be more aggressive in our RT transmission rates.
This is even more important when it comes to new portable RDS receivers on the market that display the RT prominently. They also are more likely to be operating at lower signal levels due to antenna design, just like using a headphone cable instead of a better antenna, and are more likely to be used in areas with multipath or other signal impairments, such as inside buildings.
Before adjusting your RT send rates, understand what you’re doing. By increasing the rate you’re making a tradeoff on other RDS functions.
The RDS standard is a very slow data stream, under 1,200 bits per second, and there is a limit on how many bits can be sent every second.
When you increase the RT rate, whatever else you are doing with your RDS may suffer because fewer bits will be available for these functions. The PS will be sent less frequently; accordingly, you should make time delay adjustments to the “scrolling” or dynamic PS to maintain a good user experience. I’ll have more on that in the next article in the series.
If your station uses other RDS “specialized” features contained in the Open Data Application (ODA) groups such as Traffic Message Channel (TMC), you may want to consult with your corporate engineering staff or the vendor with whom you have an agreement to make sure the settings you change don’t affect these services.
You may need to reduce RT sending rates from my recommendations as a compromise between a better RT experience for the listener and making sure you are meeting ODA obligations.
Encoder-specific recommendations
I’ve developed a recommended RT sending rate based on my own in-field testing with various RDS receivers on the market.
My benchmark for developing these recommended settings was to get the RT to display, in optimal reception conditions, in three to four seconds after you’ve tuned to the station, or after it has been changed, for example when a new song or program element has come on. See my encoder-specific recommendations in the accompanying chart.
Some may consider these settings too aggressive, but I think the industry needs to make an aggressive improvement overall in its RT sending rates to give a good user experience. Remember, three to four seconds is the optimal experience.
Under bad signal conditions, the radio will take longer to display the RT. Even with these recommended RT settings, under poor reception conditions, RT can take 10 or more seconds to display.
If you left the RT send rates at the typical factory default, in those conditions your receiver may take 30 or more seconds to display the RT or perhaps never resolve the RT.
To combat display problems on legacy receivers, some RDS encoders give you the option to always send 64 characters in the RT. If you send something under 64 characters, the encoder adds spaces to the RT.
Recommended RadioText (RT) Send Rates for several popular models of encoder. Note that these settings may interfere with special ODA groups you may be transmitting such as leased traffic or other data. If you transmit such data, consult your corporate engineering staff or the company leasing the data from you to ensure you do not interfere with these services. It is my experience that few if any receivers on the market need this option; if your encoder has this ability, I would turn it off. The longer the RT, the longer it takes to transmit to the receivers.
By always transmitting 64 characters, you will always have maximum delay. Most receivers do not display the RT data until it’s been fully received without errors twice. If the RT contains less than 64 characters, you’re slowing the process of displaying RT data to the receiver unnecessarily.
Unfortunately, with some legacy encoders, you cannot turn off this option.
I hope you’re enjoying this series. Feel free to comment while we go along. My e-mail is [email protected]. Maybe you have settings you like better, or other findings regarding RDS.
In our next article we’ll discuss optimizing dynamic PS scrolling displays.
Alan Jurison is a regional IT manager/broadcast engineer for Citadel Broadcasting in Syracuse, N.Y. He holds several SBE certifications, including CSRE, AMD, DRB and CBNT. Opinions are the author’s own.
