Does RDS Time Callback works in your project? about radioino HOT 4 CLOSED

Hello @wmarkow,

in principe rds.attachTimeCallback(UpdateRDSTime) works, but the result vary from station to station. I live near "Frankfurt am Main" and took a look at FFH 105.90 MHz and hr3 89.30MHz. The time signal for FFH seems to be good but for hr3 its quite confusing (eg 55:23). Mostly the hour is wrong.

Probably there is a bug in RDSParser.cpp. I looked at RDS EN50067 Page 28 and Annex G in comparsion to lines 148 to 166 but could not find a logicial issue (like wrong bit shift or so). Hence RDS is standardizied in DIN EN 62106 it's a look worth if there are differnces in those papers.

I hope to find some time for research in this pet project.
Also I want to get out the date data ... just because its there and has place on LCD

Cheers!
Leif

EDIT: (16.02.2018) I took a look at the actual standard paper of RDS. There is no difference how date and time is transfered in the RDS bit stream.

from radioino.

@DerKleineLeif, thanks for the link to this RDS datasheet, it is helpful.

I took a look at the source code of RDSParser class and it looks that it should correctly decode the 4A Group: Clock-Time and Date but I'm still receiving some confusing time: actually I have never received a correct time.

I even uncommented the line in RDSParser::processData where it dumps in HEX the four blocks of the RDS group. I read that the first block always contains the PI Code which is something like a station ID. This PI Code should be always the same for a specific station that I'm listening to. But in this HEX dumps I see that the PI code is "like a random"; it is never the same. I have checked that in my country and the station that I have it should be always 0x3293 but for most of the time it returns a different values. I should consider this as a bug but I do not know how to deal with this.

RDS sends something like CRC for error correction but RDA5870 seems to not provide access to this CRC data. It only provides information about error detection/correction for block A and block B (bits BLERA and BLERB in register 0BH) but these in my case have value less than 3 (so the errors should be corrected).
I do not knkow what to think right now.

from radioino.

I think this issue is an effect of how RDA5807M works and we need to live with this. I have observed that this chip feeds you with a bogus/invalid RDS groups. The chip only gives the error information for blocks A and B. Even if it say that there are no errors for block 1 and 2 (bits BLERA and BLERB), we know nothing about errors in block C and D. Moreover the documentation says that bits BLERA and BLERB are available only in the RDS verbose mode but the docs doesn't say how to enable this mode or if this mode is enabled automatically after reset, so I do not know if I should use those BLERA and BLERB bits.

The RDS Time Groups - that I have received - were an effect of those bogus/invalid RDS groups that RDA5807M was giving me. I have noticed that it starts to output bogus frames where the signal reception is not good or poor (when I had a poor antenna).

As a workaround I have introduced in my project a RDS group validation:

• I'm checking if the Country Code from BLOCK 1 (Annex D of EN50067_RDS_Standard matches my country; if not - then the whole RDS group goes to trash
• for groups of version B, the BLOCK 1 should be exactly the same as BLOCK 3; if they do not mach, the whole RDS group goes to trash

This helps a lot to lower the ratio of invalid RDS groups read from the RDA5807A.

from radioino.

@DerKleineLeif, if you do not mind I will close this issue as it looks like the things have been clarified.

from radioino.