In this installment of our series about various facets of RDS, I’m going to focus on optimizing Program Service name scrolling on your stations. You can read the first two articles in this series here.
As we’ve discussed, many stations in the United States employ PS “scrolling,” “framing” or “dynamic PS,” changing the text over time in the eight-character PS field. In April, when we talked about RDS/RBDS RadioText send rate optimization, I suggested an RT adjustment. Even before that adjustment, you might have found your station dropping the eight-character PS frames periodically.
I’ve found that a lot of stations have this scrolling delay set way too low. Text scrolls too quickly and, if the receiver has impairments such as multipath, you may drop these frames. With typical RDS encoder defaults, anyone running a delay on their PS at under 2 seconds already was prone to this dropping phenomenon.
I can’t tell you how many times I’ve seen dropped PS packets because the station had its dynamic PS scrolling delays set too low. Often the demand to “make it faster” comes from a PD or GM who is looking at the radio in his or her car, near the studio, in optimal receiving conditions. They get frustrated that the song information, station name etc. aren’t scrolling fast enough.
To a point, that’s understandable. We’re often trying to display something that’s 50–100 characters long, eight characters at a time, with a delay in between. By decreasing the delay, and making the scroll go faster, it looks great in optimal conditions.
But then get in the car and drive around and you’ll quickly find that you’re jumping frames as the receiver runs into multipath and other impairments. This isn’t a great user experience. You need to be mindful not to set your delay too low.
If you’ve followed my recommendations for an aggressive RT sending rate, you’ll find that the receivers that prominently display the PS may start dropping frames, perhaps even under optimal conditions. This drop is due to the data rate limitations of the RDS standard.
Minimum delay
Given this, I would recommend a minimum delay of 3.75 seconds to 4.0 seconds between frames. If your station is more multipath-prone, you might want to make the delay closer to 5.0 seconds.
At first, this delay might drive your GM or PD crazy. After all, they might have thought 2 seconds was too slow. But again, I maintain that we need to fine-tune or “tweak” our RDS implementations so it provides a good experience for all receivers, not just in the PD’s car in the station parking lot. It might take some explaining for this concept to get this point across.
Feel free to fine-tune these settings as you deem appropriate for your situation. Some people may feel my recommendations are almost too aggressive.
Or perhaps your station has an Open Data Application agreement and can’t dedicate that much data to RT because you’re leasing out your RDS carrier for traffic data. Or maybe you feel that a delay of 4 seconds on the PS is just too long.
For those situations, I’d recommend that you find a “middle ground” compromise. For example, on the Inovonics line of encoders, perhaps you change the DRTS=8 and change your PS delay to 3.5 seconds to back off the aggressive nature of the RT. While I don’t recommend this setting because the RT will take longer to send, you might like it better.
Luckily, the RDS standards are flexible to allow you to have a variety of parameters you can customize for your situation.
I’ve been getting good feedback from people interested in these details of RDS. Feel free to comment as we continue this discussion. My e-mail is [email protected].
In our next article in the series, we’ll discuss RDS subcarrier injection rates and pilot synchronization of the RDS signal.
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.
