Topics

Truncated RT data for RDS within SDR#

Ian DXer
 

Hi Youssef & all,

Hope you can help out with this small problem I have with SDR#.

Problem Description: With some FM BCB radio stations with SDR# I experience a truncation of the last 2 to 3 characters
of the RT (Radio text), i.e last 2-3 characters missing. It doesn't appear to matter how long the RT text is. Maybe short-ish or long.
And sometimes; with different RT message, from same station, the full RT text length may appear.

For the record; Experienced with all SDR# releases I have tried in recent times. Also it is definitely a SDR# issue as Simon's SDR-Console v3 beta release
doesn't experience the same problem.

Setup: Occurs with Windows 7 Pro & Windows 10 Pro. Using HF+ latest firmware & using SDR Release 1664.
Have tested with local FM station on 104.9MHz

I could send you a RAW data file (if requested) as output from 3rd party RDS Data Logger plugin if that's of any use?

Don't know if any other users have experienced this same issue?

Any assistance much appreciated.

Ian

jdow
 

Does the length of the text modulo four suggest anything to you? If so this is a lack of defensive programming I've brought to Youssef's attention several times now. Some equipment does not terminate the left over bytes in a four byte text frame according to specification. So the frame gets marked as an error and is never displayed. The fix is very easy to make. (I have a very old version of SDRSharp from when the source was available but not "open" in the conventional sense. I made the change and use it for the radio I keep running 24/7 on the local listener supported classical music station here in Los Angeles. (Pumps hand for KUSC.)

{^_^}

On 20180419 17:15, Ian DXer wrote:
Hi Youssef & all,
Hope you can help out with this small problem I have with SDR#.
Problem Description: With some FM BCB radio stations with SDR# I experience a truncation of the last 2 to 3 characters
of the RT (Radio text), i.e last 2-3 characters missing. It doesn't appear to matter how long the RT text is. Maybe short-ish or long.
And sometimes; with different RT message, from same station, the full RT text length may appear.
For the record; Experienced with all SDR# releases I have tried in recent times. Also it is definitely a SDR# issue as Simon's SDR-Console v3 beta release
doesn't experience the same problem.
Setup: Occurs with Windows 7 Pro & Windows 10 Pro. Using HF+ latest firmware & using SDR Release 1664.
Have tested with local FM station on 104.9MHz
I could send you a RAW data file (if requested) as output from 3rd party RDS Data Logger plugin if that's of any use?
Don't know if any other users have experienced this same issue?
Any assistance much appreciated.
Ian

Simon Brown
 

There are some very poor FM Stereo/RDS transmissions in the US, all the exceptions to the rules can be found there.

Round here the BBC appears to be excellent, as do all national broadcasts I can pick up (France always, all of Europe and N. Africa when there's Sporadic-E).

Simon Brown, G4ELI
www.sdr-radio.com

-----Original Message-----
From: main@airspy.groups.io <main@airspy.groups.io> On Behalf Of jdow
Sent: 20 April 2018 01:41
To: main@airspy.groups.io
Subject: Re: [airspy] Truncated RT data for RDS within SDR#

Does the length of the text modulo four suggest anything to you? If so this is a lack of defensive programming I've brought to Youssef's attention several times now. Some equipment does not terminate the left over bytes in a four byte text frame according to specification. So the frame gets marked as an error and is never displayed. The fix is very easy to make. (I have a very old version of SDRSharp from when the source was available but not "open" in the conventional sense. I made the change and use it for the radio I keep running 24/7 on the local listener supported classical music station here in Los Angeles. (Pumps hand for KUSC.)

Ian DXer
 

Hi Joanne,

Thanks 4 feedback. This sounds exactly like the cause of the problem.
re: 'Some equipment does not terminate the left over bytes in a four byte text frame'
I haven't proven this, not sure yet how to test this with my available resources atm without further investigation.
I'm sure i could record a 16bit PCM baseband signal for Youssef (if required) of a sample effected station.

Joanne you mention: "..this is a lack of defensive programming I've brought to Youssef's attention several times now"
This reminds me of my Digital Electronics 2 'project' from my college years where students were required to
design a 'programmable security lock' using TTL/CMOS logic chips & other electronics.
I created most of the design whilst quietly lying in bed at 4am.
Unfortunately at project completion time I was marked down from 95% to 90% because my teacher found that my design had not catered for
users performing a mis-operation outside the design specification. I had actually thought about this error scenario occurring (and proved in testing) earlier
and knew it would
only take two logic gates to prevent this error, but foolishly decided during design & construction phase
it was just extra work, time & money to implement during a busy study schedule.
Moral of the story:- design engineers should cater for (all possible) error scenarios occurring during initial design or eg. patch/correct software where
later informed by users & in this example where broadcast engineers aren't feeding data as per RDS design specification, so end (SDR#) users aren't effected.
Just my personal learned experience ;-)

If it is indeed an easy fix for Youssef I'd be very appreciative of his investment of time to correct software for us both & no doubt more users.

Not sure how many of my local radio stations in Australia have this RDS RT problem (might do a count later tonight), not all use RT.
Certainly several stations are slack with correcting 'clock time' with their RDS despite me reporting problem.
Would be more satisfying for Youssef to program a fix rather than be disappointed with often lack of action (after reporting) to broadcast stations.

Thanks for feedback Simon. 

Ian




prog
 

On Fri, Apr 20, 2018 at 01:40 am, Ian DXer wrote:
Would be more satisfying for Youssef to program a fix rather than be disappointed with often lack of action (after reporting) to broadcast stations.
No. I optimize my own satisfaction quite differently. There are many other hot topics that require more attention and are much, much more rewarding.
Adding code to work around cheap FM transmitters is something I'd put in my todo list with a low priority, though.

Ian DXer
 

Thanks for putting the job on your list (low priority) Youssef - totally understand your attention to matters that drive your interest.
Hope your to-do list isn't as deep as mine ;-)

However to put the problem in perspective at my QTH; I did a quick survey of most FM RDS stations with RT tonight.
Test sample total: 13
Stations with RT displaying correctly: 6 (consisting of low budget community stations & high powered commercial)
* Stations with RT displaying incorrectly: 7 (consisting of high powered (HP) commercial, HP community & all HP National broadcasters)
Not a good result....

So for the interest of Simon (and maybe some others) it looks like the situation here is similar to the problems within the US with poorly
implemented RDS standard with many stations.

Did a count of numbers of displayed characters in instances where truncation occurs & yes is a multiple of 4. Thanks Joanne.

Regards

Ian

prog
 

On Fri, Apr 20, 2018 at 04:38 am, Ian DXer wrote:
Thanks for putting the job on your list (low priority) Youssef - totally understand your attention to matters that drive your interest.
Hope your to-do list isn't as deep as mine ;-)

However to put the problem in perspective at my QTH; I did a quick survey of most FM RDS stations with RT tonight.
Test sample total: 13
Stations with RT displaying correctly: 6 (consisting of low budget community stations & high powered commercial)
* Stations with RT displaying incorrectly: 7 (consisting of high powered (HP) commercial, HP community & all HP National broadcasters)
Not a good result....

So for the interest of Simon (and maybe some others) it looks like the situation here is similar to the problems within the US with poorly
implemented RDS standard with many stations.

Did a count of numbers of displayed characters in instances where truncation occurs & yes is a multiple of 4. Thanks Joanne.

Regards

Ian
I prefer being honest. Changing that part of the code requires a lot of testing and testing requires a lot time. RDS and RBDS seem to be two different things. I'm not using a COTS library to handle them like it is the case with other software. It will have to wait until I'm either really bored of what I'm currently doing or reached the performance objectives.

Hope your to-do list isn't as deep as mine ;-)
Unless you are also managing tens of Corporate and Investment Banking projects, there's little chance you beat me at this.

jdow
 

When something you are working on just isn't coming together making the rds stuff a little more forgiving is not all that hard to do. The two fills I have seen so far are spaces and nulls. So testing for either will probably handle almost all cases. However, I can believe an encoder exists that has either random or previous frame's data in it. Since there is no way to reliability check such frames I'd toss them. I suspect the problem is really old equipment that was shoved out the door while the specification was not quite finished. And aside from blown transmitter tubes and the like getting a radio station to spend money on something the owner does not consider vitally important just does not happen. "It ain't broke so why fix it?" (And REAL radios get it right - somehow. {^_-})

{^_^}

On 20180420 04:47, prog wrote:
On Fri, Apr 20, 2018 at 04:38 am, Ian DXer wrote:
Thanks for putting the job on your list (low priority) Youssef - totally
understand your attention to matters that drive your interest.
Hope your to-do list isn't as deep as mine ;-)
However to put the problem in perspective at my QTH; I did a quick survey of
most FM RDS stations with RT tonight.
Test sample total: 13
Stations with RT displaying correctly: 6 (consisting of low budget community
stations & high powered commercial)
* Stations with RT displaying incorrectly: 7 (consisting of high powered
(HP) commercial, HP community & all HP National broadcasters)
Not a good result....
So for the interest of Simon (and maybe some others) it looks like the
situation here is similar to the problems within the US with poorly
implemented RDS standard with many stations.
Did a count of numbers of displayed characters in instances where truncation
occurs & yes is a multiple of 4. Thanks Joanne.
Regards
Ian
I prefer being honest. Changing that part of the code requires a lot of testing and testing requires a lot time. RDS and RBDS seem to be two different things. I'm not using a COTS library to handle them like it is the case with other software. It will have to wait until I'm either really bored of what I'm currently doing or reached the performance objectives.
Hope your to-do list isn't as deep as mine ;-)
Unless you are also managing tens of Corporate and Investment Banking projects, there's little chance you beat me at this.

Ray Dees
 

Well if we follow the spec, as in:

"The number of text segments is determined by the length of the message, and each message should be ended by the code 0x0D (Hex) - carriage return - if the current message requires less than 16 segment addresses." 

As the designer of commercial RDS decoders in use all over the world, its always worked for me!

Ray


On ‎Friday‎, ‎April‎ ‎20‎, ‎2018‎ ‎06‎:‎24‎:‎51‎ ‎PM, jdow <jdow@...> wrote:


When something you are working on just isn't coming together making the rds
stuff a little more forgiving is not all that hard to do. The two fills I have
seen so far are spaces and nulls. So testing for either will probably handle
almost all cases. However, I can believe an encoder exists that has either
random or previous frame's data in it. Since there is no way to reliability
check such frames I'd toss them. I suspect the problem is really old equipment
that was shoved out the door while the specification was not quite finished. And
aside from blown transmitter tubes and the like getting a radio station to spend
money on something the owner does not consider vitally important just does not
happen. "It ain't broke so why fix it?" (And REAL radios get it right - somehow.
{^_-})

{^_^}

On 20180420 04:47, prog wrote:
> On Fri, Apr 20, 2018 at 04:38 am, Ian DXer wrote:
>
>    Thanks for putting the job on your list (low priority) Youssef - totally
>    understand your attention to matters that drive your interest.
>    Hope your to-do list isn't as deep as mine ;-)
>
>    However to put the problem in perspective at my QTH; I did a quick survey of
>    most FM RDS stations with RT tonight.
>    Test sample total: 13
>    Stations with RT displaying correctly: 6 (consisting of low budget community
>    stations & high powered commercial)
>    * Stations with RT displaying incorrectly: 7 (consisting of high powered
>    (HP) commercial, HP community & all HP National broadcasters)
>    Not a good result....
>
>    So for the interest of Simon (and maybe some others) it looks like the
>    situation here is similar to the problems within the US with poorly
>    implemented RDS standard with many stations.
>
>    Did a count of numbers of displayed characters in instances where truncation
>    occurs & yes is a multiple of 4. Thanks Joanne.
>
>    Regards
>
>    Ian
>
> I prefer being honest. Changing that part of the code requires a lot of testing
> and testing requires a lot time. RDS and RBDS seem to be two different things.
> I'm not using a COTS library to handle them like it is the case with other
> software. It will have to wait until I'm either really bored of what I'm
> currently doing or reached the performance objectives.
>
>    Hope your to-do list isn't as deep as mine ;-)
>
> Unless you are also managing tens of Corporate and Investment Banking projects,
> there's little chance you beat me at this.
>



prog
 

On Fri, Apr 20, 2018 at 03:24 pm, jdow wrote:
When something you are working on just isn't coming together making the rds stuff a little more forgiving is not all that hard to do. The two fills I have seen so far are spaces and nulls. So testing for either will probably handle almost all cases. However, I can believe an encoder exists that has either random or previous frame's data in it. Since there is no way to reliability check such frames I'd toss them. I suspect the problem is really old equipment that was shoved out the door while the specification was not quite finished. And aside from blown transmitter tubes and the like getting a radio station to spend money on something the owner does not consider vitally important just does not happen. "It ain't broke so why fix it?" (And REAL radios get it right - somehow. {^_-})

{^_^}
So, I took some time to implement it properly but I can't test it with your corrupted transmitters.
Can you check this special build and report: http://airspy.com/downloads/sdrsharp-x86-rds-test.zip

Ray Dees
 

Youssef:

Works perfect with the Airspy Mini!  Tested on 10 different stations showing as few as six and as many as sixty one characters.

Thanks!

Ray


On ‎Sunday‎, ‎April‎ ‎22‎, ‎2018‎ ‎03‎:‎24‎:‎29‎ ‎PM, prog <info@...> wrote:


On Fri, Apr 20, 2018 at 03:24 pm, jdow wrote:
When something you are working on just isn't coming together making the rds stuff a little more forgiving is not all that hard to do. The two fills I have seen so far are spaces and nulls. So testing for either will probably handle almost all cases. However, I can believe an encoder exists that has either random or previous frame's data in it. Since there is no way to reliability check such frames I'd toss them. I suspect the problem is really old equipment that was shoved out the door while the specification was not quite finished. And aside from blown transmitter tubes and the like getting a radio station to spend money on something the owner does not consider vitally important just does not happen. "It ain't broke so why fix it?" (And REAL radios get it right - somehow. {^_-})

{^_^}
So, I took some time to implement it properly but I can't test it with your corrupted transmitters.
Can you check this special build and report: http://airspy.com/downloads/sdrsharp-x86-rds-test.zip

prog
 

On Sun, Apr 22, 2018 at 01:28 pm, Ray Dees wrote:
Youssef:

Works perfect with the Airspy Mini!  Tested on 10 different stations showing as few as six and as many as sixty one characters.

Thanks!
 
Ray
Thanks for testing, Ray. Meanwhile, I added more group handlers to not miss any text sent by the transmitter.
Revision 1666 is available: http://airspy.com/download

Ian DXer
 

Youssef:

"Merci Beaucoup"

Tested Revision 1666 on each of my seven problem RDS RT FM stations down here in the southern hemisphere.

All now correctly decoding/displaying full text length (two thumbs up).

Thanks again for your investment in time & effort with this prompt fix.

Ian

jdow
 

Tell that to the people at KUSC in Los Angeles. I diagnosed the problem given the old software I'd downloaded. The purist inside insists they are wrong and must suffer for it. The good sense inside suggests it is not the KUSC listeners who should "suffer" for it. So I fixed it. (Human beings are rationalizing animals.)

{^_-}

On 20180421 07:59, Ray Dees via Groups.Io wrote:
Well if we follow the spec, as in:
"The number of text segments is determined by the length of the message, and each message should be ended by the code 0x0D (Hex) - carriage return - if the current message requires less than 16 segment addresses."
As the designer of commercial RDS decoders in use all over the world, its always worked for me!
Ray
On ‎Friday‎, ‎April‎ ‎20‎, ‎2018‎ ‎06‎:‎24‎:‎51‎ ‎PM, jdow <jdow@...> wrote:
When something you are working on just isn't coming together making the rds
stuff a little more forgiving is not all that hard to do. The two fills I have
seen so far are spaces and nulls. So testing for either will probably handle
almost all cases. However, I can believe an encoder exists that has either
random or previous frame's data in it. Since there is no way to reliability
check such frames I'd toss them. I suspect the problem is really old equipment
that was shoved out the door while the specification was not quite finished. And
aside from blown transmitter tubes and the like getting a radio station to spend
money on something the owner does not consider vitally important just does not
happen. "It ain't broke so why fix it?" (And REAL radios get it right - somehow.
{^_-})
{^_^}
On 20180420 04:47, prog wrote:
> On Fri, Apr 20, 2018 at 04:38 am, Ian DXer wrote:
>
>    Thanks for putting the job on your list (low priority) Youssef - totally
>    understand your attention to matters that drive your interest.
>    Hope your to-do list isn't as deep as mine ;-)
>
>    However to put the problem in perspective at my QTH; I did a quick survey of
>    most FM RDS stations with RT tonight.
>    Test sample total: 13
>    Stations with RT displaying correctly: 6 (consisting of low budget community
>    stations & high powered commercial)
>    * Stations with RT displaying incorrectly: 7 (consisting of high powered
>    (HP) commercial, HP community & all HP National broadcasters)
>    Not a good result....
>
>    So for the interest of Simon (and maybe some others) it looks like the
>    situation here is similar to the problems within the US with poorly
>    implemented RDS standard with many stations.
>
>    Did a count of numbers of displayed characters in instances where truncation
>    occurs & yes is a multiple of 4. Thanks Joanne.
>
>    Regards
>
>    Ian
>
> I prefer being honest. Changing that part of the code requires a lot of testing
> and testing requires a lot time. RDS and RBDS seem to be two different things.
> I'm not using a COTS library to handle them like it is the case with other
> software. It will have to wait until I'm either really bored of what I'm
> currently doing or reached the performance objectives.
>
>    Hope your to-do list isn't as deep as mine ;-)
>
> Unless you are also managing tens of Corporate and Investment Banking projects,
> there's little chance you beat me at this.
>

jdow
 

On 20180422 12:24, prog wrote:
On Fri, Apr 20, 2018 at 03:24 pm, jdow wrote:
When something you are working on just isn't coming together making the rds
stuff a little more forgiving is not all that hard to do. The two fills I
have seen so far are spaces and nulls. So testing for either will probably
handle almost all cases. However, I can believe an encoder exists that has
either random or previous frame's data in it. Since there is no way to
reliability check such frames I'd toss them. I suspect the problem is really
old equipment that was shoved out the door while the specification was not
quite finished. And aside from blown transmitter tubes and the like getting
a radio station to spend money on something the owner does not consider
vitally important just does not happen. "It ain't broke so why fix it?" (And
REAL radios get it right - somehow. {^_-})
{^_^}
So, I took some time to implement it properly but I can't test it with your corrupted transmitters.
Can you check this special build and report: http://airspy.com/downloads/sdrsharp-x86-rds-test.zip
Oh my! 1000 + the number of the beast!

{^_-}

jdow
 

Seems to work. Produces the same data as my massaged SW and what is announced on their web site, 34 characters worth in this case.

{^_^}

On 20180422 12:24, prog wrote:
On Fri, Apr 20, 2018 at 03:24 pm, jdow wrote:
When something you are working on just isn't coming together making the rds
stuff a little more forgiving is not all that hard to do. The two fills I
have seen so far are spaces and nulls. So testing for either will probably
handle almost all cases. However, I can believe an encoder exists that has
either random or previous frame's data in it. Since there is no way to
reliability check such frames I'd toss them. I suspect the problem is really
old equipment that was shoved out the door while the specification was not
quite finished. And aside from blown transmitter tubes and the like getting
a radio station to spend money on something the owner does not consider
vitally important just does not happen. "It ain't broke so why fix it?" (And
REAL radios get it right - somehow. {^_-})
{^_^}
So, I took some time to implement it properly but I can't test it with your corrupted transmitters.
Can you check this special build and report: http://airspy.com/downloads/sdrsharp-x86-rds-test.zip