Many thanks to SWLing Post contributor, Bob Colegrove, who shares the following guest post:
A Conundrum with the Radio Data System (RDS),
or Why I Set the Clock Manually
By Bob Colegrove
There’s an old story about a man who owned two watches. One watch ran but lost a minute every hour. The other watch didn’t work at all. He always wore the watch that didn’t work, because as he said, “At least it will have the correct time twice a day.”
First off, a couple of caveats. This is not a definitive description of the Radio Data System (RDS). I leave that to much more knowledgeable sources. One detailed description is at https://en.wikipedia.org/wiki/Radio_Data_System. Second, my experience described here is confined to the Eton Elite Executive and the XHDATA/SIHUADON D-808. Other radios may operate differently.
I have surrounded myself with several multiband travel radios over the past year and enjoy them very much – each for different reasons. Besides listening, I like to push buttons to see what happens. The manuals? At best they occasionally provide a clue. I read them, eventually filling in the blanks on my own.
XHDATA/SIHUADON D-808
Basic RDS
What is RDS? RDS is a system which enables an FM station to transmit various fields of information such as date, time, call letters, frequency, and program information in text form. The call letters are useful, but if you have a digital radio, you already know the frequency. The name of the song and artist are particularly helpful if the DJ won’t tell you. As for the date and time, well, I’ll get to that.
RDS is an international standard and Radio Broadcast Data System (RBDS) is the official name used for the U.S. version. So why don’t we in the States just call it RBDS? Probably because our radios aren’t made here.
Eton Elite Executive
The XHDATA and Eton allow the user to display four of the several fields comprising the RDS standard. They each step through the same sequence, indicating a similar or possibly the same demodulator chip.
PS and RT seem to be freeform fields with stations providing whatever information they want to share. Often the call letters and frequency are contained here, along with program content. Clock Time (CT) is not displayed per se, but is used to set the radio time, and is included as part of the DATA field. DATA is important; it has four elements, which should provide the listener with an indication of the call, day, date, and time being received by the radio. The international RDS standard omits the call letters.
The RDS information transmitted by any given station may not contain all the fields identified above, including the time. For example, stepping through the fields you may encounter “NO PTY,” “NO PS,” “NO RT,” or “NO DATA.” Consequently, you may tune in to a station broadcasting RDS and wait a long time for the radio clock to synchronize, which it never does. The display of any content in the DATA field is probably the best clue whether CT is being transmitted.
It is interesting that the Eton is programmed for the US RBDS system, whereas the XDATA follows the international RDS system. For the international system on the D-808:
- “DATE” replaces “DATA” in the display.
- The call letters are omitted from the DATE field.
- The terms in the PTY field differ; for example, WRBS, 95.1 MHz, the PTY element displays “SOCIAL” instead of “RELIGIOUS MUSIC.”
International PTY RDS term on the XHDATA
US PTY RBDS term on the Eton
The Conundrum
The mischief all began when I got my XHDATA D-808 and tried to program the clock to automatically update using the RDS information off FM stations. Minutes seem to display correctly, but try as I might, I couldn’t get the hours to register properly. Then I bought an Eton Elite Executive. It also has the RDS feature, so I tried again. It appeared to work OK for a day or so. Then the hour indication started to misbehave. In addition to the clock, the Eton allows programming of time zones and day of the week. I determined that the erroneous indication did not appear to be related to GMT, EST, 12-hour or 24-hour format settings. In theory, if you try to set your radio to GMT or some other time zone, the RDS time from a local station should override it.
When I tested the radios side-by-side, the DATA field was fraught with problems on both radios. Several local RDS stations containing CT were monitored. The whip antenna was extended a tad, as the information may not reliably register with some otherwise clear audio signals.
- When tuned to the same station, there were occasional inconsistencies between the two radios, presumably receiving the same exact information from the station.
- Sometimes the hour would not advance on the XHDATA after minutes transitioned from 59 to 00.
- Curiously, both radios might exhibit the correct date and time during the day, then at 1900 EST, several stations on both radios prematurely advance to the next day and date, and the hour would display incorrectly, completely unrelated to local hour. Minutes may or may not be correct. 1900 EST happens to be 0000 GMT. Are some station clocks running on GMT?
RDS content obviously requires some attention at the station. In the end, they are responsible for the information going out. In fairness, with all that goes on in a studio and limited staffing, RDS content may not be a priority. As an example:
- Call letters in the DATA field for local WMZQ read KZQK, which is not assigned.
Conclusions
There are two main factors which may impinge on the accuracy of a radio clock when set automatically by the RDS:
- Accuracy depends on the station transmitting it correctly.
- With RDS set to the AUTO mode, there is a good chance that the clock will be updated repeatedly as the radio is tuned among various stations – not necessarily to the correct time.
- For the Eton, the clock would reset each time when changing stations between WTOP (correct time) and WPRS (incorrect time).
- For the XHDATA, the clock would reset each time when changing stations between WTOP (correct minutes) and WPRS (incorrect minutes). In both cases, the displayed hour remained 00.
- There is still the unexplained premature update of day and date by some stations observed on both radios.
- With RDS set to the AUTO mode, there is a good chance that the clock will be updated repeatedly as the radio is tuned among various stations – not necessarily to the correct time.
- Correct time depends on the radio’s RDS demodulator to interpret the incoming data.
Trivial? Perhaps, but you may want to reconsider and program the clock manually, particularly if you depend on the alarm function of the radio to get to work on time.
Time on the XHDATA 808 via RDS CT is broken. Why do I know? Had three of them, all were off by a fixed amount of hours when all my other RdS CT capable radios did show it correctly. Sihuadon never agreed to the firmware bug but it is certainly there.
The automatic setting of the time is solved completely badly. Failure to synchronize with the receiver’s internal rtc. It always only loads RDS data at certain intervals and displays it. Result: deviation of 0-2 minutes. Much more important is an error in the firmware that causes a deviation of exactly -3 hours. Other RDS data are flawless, even with a weak RF signal.
A few years back, before the Big Move last year, the kitchen radio died (c.1981 Pioneer boomboxette). Replaced it with a Sangean HDR-16. Super disappointed that none of the AMs in the market were running HD contrary to what I now call the “wish list” on hdradio.com.
On the FM side, in addition to HD, I could see RBDS … and quickly discovered what you did: if a station has CT enabled at all, it’s usually wrong.
That radio spent a lot of time on the local public radio station and the CE is a friend, so I pestered him to upgrade his time game and he did! Whatever device was providing the RBDS data was not configured to use NTP. Once he set that up, the time was always right.
Now, can we get all stations to do the same? And also to put useful things on their datastream? You know, like artist/title … of the currently playing song, I mean, not something random.
We seem to have confirmed the principle, as technology becomes more and more complex, so does the burden of maintaining it. Ignoring this can easily produce a conundrum.
It all depends on whether the station engineering is keeping the time accurate. There is a station in my area that is for sale and the engineering is to ‘keep it on the air’. Things like correct time seem trivial. I tuned across this station before going to bed. My alarm clock went off an hour late. So now, I set my radio to manual time.
Trouble in RDS in the USA
https://www.radioworld.com/news-and-business/headlines/nab-updates-digital-dashboard-best-practices
I note that no mention is made of how much xperi charges radio stations for their services and software to improve HD radio dashboard presentations.
Remember that DTS Autostage, an xpeiri company can also use the mobile broadband to report on how many people are in the car and if they are listening, along with its location. Their selling point is live ratings.
That DTS Auto Stage is a part of the radio in my car albeit without the live ratings or seamless handoff to streaming. It only provides station logos and slogans based on geography. In fact it overrides anything the HD or RDS transmits which means it’s usually outdated info. I suppose from an end user stance it looks prettier but why even bother with HD or RDS if they’re just going to pull info from a database via cellular connection?
And at least in my case it lacks several regional stations whose signals spill over from adjacent markets, and has some info that’s just flat wrong, like an AM R&B station in Pensacola that’s tagged as “The Moose – Muskegon” with each song displayed being a country song instead of what’s actually playing.
If you want to have a radio signal set a timepiece, you should get one that can tune into WWVB in Fort Collins, Colorado,which puts out the signal that all such timepieces use.
RDS doesn’t control anything. It just displays what it is given to display, which seldom more than a callsign or tag line.
In pure digital systems such as DAB+, DRM in VHF and digital only HDRadio in the FM band, single frequency networks are used. They often use repeaters where the output signal is identical to the input signal but more powerful. These systems need to have not only identical frequencies but the signal content has to be timed to be simultaneous. As a result GPS is used to make sure it is simultaneous and as a frequency reference. GPS is accurate within +/ 3 ns.
Same as with analog AM and FM – SFN is not exclusive for digital broadcasts.
Where us SFNs used in analog radio? Particularly where the signal strengths become equal.?
I know of only one high powered AM pair. The point where the signal strengths are equal is in a rugged terrain where no one lives.
The reason why digital system SFNs work is because the data is transmitted in bursts allowing time for any delayed signals to be ignored.
Lots of these are using AM, i.e. BBC Radio 4, TalkSport, BBC Radio Scotland, MR4 in Hungary etc. As for FM, Vinci Autoroutes in France runs a network of almost 600 low-power transmitters along their highways, all operating on a single FM frequency.
Paul Jamet: ” Nevertheless, in a recent exchange with XHDATA who are thinking about an emergency receiver for the European market (without NOAA frequencies but with FM and DAB+) ”
Intertesting Paul, if the hardware is capable, it may be useful to have a VHF Marine Band receive instead of NOAA (Marine VHF is just below the American NOAA weather band, so maybe the hardware for NOAA is also capable of Marine-VHF?) Weather broadcasts are transmitted on Marine VHF at certain times
Regarding RDS time, any stations who are unable to maintain it accurately, should be asked to disable transmitting RDS CT (time) ! leave it for the stations that can!
Also I have asked this before, but is there any ‘hidden’ means of getting the XHDATA D808 to display RDS PI code? by a holding button sequence or whatever?
Found a callsign to PI converter at https://db.wtfda.org/rds2.html. Link to reverse lookup is on same page.
Bob,
I’ll second what Thomas said: wonderful article!
A couple of weekends ago, I was testing a radio with RDS for my possible personal ownership. I found the RDS pretty neat but never considered the possibility of wrong time.
Thanks for diving down this rabbit hole in such an interesting way.
Cheers, Jock
It’s been my experience that portable radios that support RDS clock time have an option to enable or disable the feature, so it shouldn’t be mandatory on any radio. It’s never been all that accurate in my experience, either, with multiple stations in my market with incorrect times transmitted. Usually it’s off by an hour which makes me think they’re not handling DST correctly.
As for the PI (call sign) field being incorrect, that happens if you’re listening to an iHeart station. They by company policy have wrong data in the PI field. Stations east of the Mississippi will show K-calls and stations west will have W-calls if I remember right. At least in my market, however, all the incorrect call signs are actually other iHeart stations west of the Mississippi!
I’m not sure why they do this, but since few radios show the PI field I guess they don’t think it matters. iHeart is pretty good about utilizing the extended text features of RDS, too.
I’m an FM broadcast station Chief Engineer, and I can assure you that we have no interest in setting the clock time and date (CT) on listener’s radios. All we want is to put our call letters up on your receiver along with the the song title/artist info. We will also put up station slogans to promote ourselves. The CT function in our RBDS generators can be turned off. Some brands of RBDS generators may ship with the CT turned on. Most stations don’t even know it’s there. I didn’t until we got a phone call from a listener complaining that we changed the time on his clock. CT got turned off promptly. RDS began as a European thing, US broadcasters adopted it and changed a few things to suit our needs and called it RBDS. For instance, the European standard strictly prohibits scrolling of the display information, but US stations want the scrolling capability so we added it. Most of the European RDS features we do not want or use. Car radios don’t give the listeners the option to use CT or not, but if your SWL radio lets you turn off CT then by all means do that.
It’s a shame some of the other features aren’t used more widely. AF (auto tune to strongest frequency) is useful for public radio networks but the only one I know using it is Mississippi’s MPB Think Radio statewide net.
There’s also a traffic report flag that can let the radio interrupt other input sources but I’ve never seen it used outside of one station 20 years ago in Toronto.
Poor you! On my 10km drive to the local bigger city my head unit makes use of the AF information to seamlessly switch to the strongest frequency of the same radio station. All without even noticing that my radio did switch frequencies. Also an emergency frequency is broadcasted the radio will switch for travel or emergency announcements.
Why oh why did the US cripple RDS into a half-functional RBDS?
It’s not that the standard is crippled, Johann, it’s just that no one chooses to use some of the extra features. To be fair, the radio landscape in the US and Canada is a lot different than in Europe. We don’t have any country-wide radio networks, and public radio is generally regional or at best a statewide effort. Plus, we tend to use fewer high powered transmitters that cover 100-200 kms range instead of networks of lower powered repeaters. Unless you’re driving for 4+ hours, there is little need to retune stations.
As far as I know the only major difference between RDS and RBDS is the list of formats is different to better match what radio stations do in this part of the world.
The Sangean radios (the 909, 909x and 909×2) have had RDS for many years. My recommendation is to not use AUTO at all. As a longtime broadcaster myself, most of the stations I worked for over the years that had RDS never even properly set the clock time as that requires connection to a master clock (like a Torpey or ESE system). As long as the station calls and/or name, artist and title were correct (RadioText or RadioText+), then all was well. It’s been my experience, at least for stations here in the US, that those three parameters are all that were needed or wanted when RDS came ashore here. Europe has more robust usage of the system than the US.
Occasionally you’ll find a public radio broadcaster that has a network of signals throughout their region that uses the PI code to switch a capable radio or allow the radio to scan to the strongest of their signals wherever that radio might be. Great for traveling in the car.
I never experienced the exact troubles/deviations you described over here in Germany, Bob. But this may be related to the lower density of stations here, and I noticed that the minimum (indicated on the RSSI) SNR needed to decode any RDS data is 18dB on the D-808. To get consistently error-free decoding you need much more than that though, and I just learned (WP) that some stations tweak their RDS system beyond the standard to an extent that it leads to unwanted results with some types of hardware out there.
However, having the clock set to AUTO is still a surefire recipe for trouble when you plan on scanning the band for stations and such – then it will inevitably pick up a bad clock code and be off until you tuned to a “good” station again. Since I’m too lazy to set the clock manually I use the following procedure when I didn’t use the D-808 for a longer time:
1. Set the clock to auto
2. Turn the radio on and tune to a strong station that’s known to transmit a valid CT code (some stations do not transmit that at all, or the SNR is insufficient and leads to errors, I get exactly ONE station here that is apt for that) – wait for the clock to sync, then…
3. Turn the radio off, set the clock back to manual. That sets me up with the clock being off only a few seconds after several weeks.
I don’t ever recall having a portable radio capable of RDS reception, so my only experience (here in the US) has been in automobiles. There, it’s been very hit or miss with song data being displayed incorrectly, if at all. When it does display on certain stations, it’s frequently gibberish.
Cars traditionally have had a clock separate from the radio, so incorrect RDS time is something I’ve also never noticed. My current car uses GPS to set the time and date. It seems most stations care minimally about RDS.
Amen. I noticed same in my XHDATA D-808. Nothing worse than broken firmware that reduces a simple task to impossible.
Here is how I want the clock to work on my shortwave radio:
* No RDS interface or allow override
* Allow manual time and time zone entry
* Add a button labelled ZERO SECONDS that allows me to quickly align the clock seconds to WWV/CHU, etc…. obviously with the radio powered ON.
I add that last item because frustratingly I find newer radios only allow setting the clock with the radio powered OFF. BOO!
Keep it simple.
You will find the following links useful
https://tech.ebu.ch/docs/techreview/trev_255-beale.pdf I searched the word
‘time’ and there was no mention bits being allocated to the time data.
https://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf page 68
I then went looking for more recent standard.
For the USA https://www.nrscstandards.org/standards-and-guidelines/accept.asp?name=documents/guidelines/nrsc-g303.pdf
The Emergency Warning systems all use a time stamp, so it is important that the radio has the correct time. The most accurate method is to use a GPS signal which transmits the most accurate Universal Co-ordinate time. The receiver should be sent the time offset required by the longitude zone that the broadcaster is in.
The DAB+/DRM standards include the current date and time as part of the data transmissions
https://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf page 29
https://www.etsi.org/deliver/etsi_en/300700_300799/300751/01.02.01_60/en_300751v010201p.pdf
Last year’s version of the Digital Radio Mondiale, like its forebears, using the Alternate Frequency Signalling uses RDS on FM transmissions to identify what other frequencies and modulations which carry the same identical program from that broadcaster. Then a DRM,DAB+, FM and AM receiver can select the program with the lowest error rate or the best signal to ratio in FM or AM
Lastly TPEG has morphed into the https://tisa.org/ in FM uses the RDS for a data transmission system.
The data capacity of RDS is much less than available in digital radio systems which can allocate how much data capacity is used for ditital audio channels and dat channels.
> https://tech.ebu.ch/docs/techreview/trev_255-beale.pdf I searched the word
> ‘time’ and there was no mention bits being allocated to the time data.
That article is a basic overview of just a few aspects of a few of the 16 group types available in RDS. In particular, it doesn’t mention group 4A which is where the “clock time” (CT) data is transmitted.
(Group 4A is 37 bits long – 18 bits for date, 5 bits for hrs & 6 bits for minutes (both in UTC, and note – no seconds), and 6 bits for local time offset in 30 minute increments.)
Oh, and there’s 3 bits of padding 😉
Very interesting, I had never really noticed the clock changing (but it must because my time is always off!),
Fortunately for me it is just a convenience that I rarely use, but I will be watching for it in the future!
Cheers! Robert
I have had similar experiences with RDS timekeeping. I wasn’t expecting WWV standards… but would it be too much to ask for them to keep time to the correct minute?
Thank you very much for this very interesting contribution. I will be vigilant with the time displayed by my D-808.
Your observations should be of interest not only to users but also to the manufacturers of emergency radios. There are more and more models of emergency radios and not all of them offer RDS.
I’ve had a DRM receiver since 2010 – a Diwave 100 that I used a lot when the BBC and DW were broadcasting a joint program. From memory, I’ve never noticed any problems with the time display.
We need to hear from an Indian listener how things are going in his country, which has chosen DRM as the radio digitization standard for both the OM and FM bands.
In Europe, it’s important to know how DAB/DAB+ receivers display the time transmitted by the signal from stations using this digital radio standard. I’m not yet correctly served at home by DAB+, but the receiver in my car always displays the time correctly.
Nevertheless, in a recent exchange with XHDATA who are thinking about an emergency receiver for the European market (without NOAA frequencies but with FM and DAB+) I strongly suggested adding the possibility of picking up the DCF77 (77.5 kHz) time signal used by radio-controlled alarm clocks :
https://en.wikipedia.org/wiki/DCF77 [The signal range is around 1,500 km during the day and 2,000 km at night] arguing that an emergency radio should offer a reliable time display.
Your article, Bob, is therefore particularly welcome.
Wait and see … For the next three weeks, the Chinese are busy welcoming the Blue Dragon …
Paul JAMET
Radio Club du Perche
Wonderful article, Bob.
Honestly, most of us don’t think about how RDS could be modifying our radio clocks and, as you point out, if you’ve set an alarm to, say, catch an early flight? Yeah, might not want to use RDS for timekeeping! 🙂
Also, I had never thought about inconsistencies between radios regarding how RDS is displayed and the time might be interpreted. Thank you for sharing these details with us!
Cheers,
Thomas