PI-Code detection

[andimik]

Some enthusiasts in Germany, Austria and Switzerland have an automatic scanning app on a Raspberry PI and use redsea for RDS log files. It's https://github.com/hayguen/fmlist_scan (note that I'm using latest redsea, not the old 0.17 which was in the install script there)

But during scans it may happen (when reception is poor), that a transmitter is identified with a completely wrong PI code. It's difficult to find the root cause out, but I achieved to searched in the (verbose) log files I've made.

I also don't know if the wrong code was coming from another RDS block, but obviously it's not (I checked an error-free recording for that case).

For example, the correct PI is 0x51CC in real. The following RDS blocks were detected

---- ---- ---- 2120
---- 52CC ---- ----
---- 52CC ---- ----
3249 ---- 04E7 ----
3249 ---- ---- ----
---- ---- 041C ----
---- 3556 ---- ----
---- ---- F808 ----
---- ---- ---- F289
---- ---- ---- C412

(Mind the similar codes 52CC in RDS group B, but in an error-free recording, see below, it is not transmitted.)

which then was logged in redsea as

{"pi":"0x3249"}
{"pi":"0x3249"}

and shown in our app as

One minute later, similar reception issues, but the first line already showed the correct PI-Code 0x51CC.

51CC ---- ---- ----
---- 04E2 ---- ----
---- 04E0 ---- ----
35AF ---- ---- ----
---- 04E2 ---- ----
---- 24F2 ---- ----
---- 04E1 ---- ----
---- ---- ---- 5249
51CC ---- 97BF 4120
51CC ---- ---- 7D59
---- 04E7 ---- E9A6
51CC ---- ---- 4020
---- 8426 3F86 522E
---- 04E1 97BF ----
51CC ---- ---- 5249
51CC ---- ---- 4120
51CC 24FB 2020 2020
---- 04E0 EA01 ----
463A ---- ---- ----

andredsea has ignored 0x463A and 0x35AF, fortunately:

{"pi":"0x51CC"}
{"pi":"0x51CC","group":"0A","di":{"stereo":true},"is_music":false,"prog_type":"Culture","ta":false,"tp":true}
{"pi":"0x51CC"}
{"pi":"0x51CC","group":"8A","prog_type":"News","tp":true}
{"pi":"0x51CC"}
{"pi":"0x51CC"}
{"pi":"0x51CC","group":"2A","prog_type":"Culture","tp":true}
{"pi":"0x51CC","group":"0A","di":{"dynamic_pty":false},"is_music":false,"prog_type":"Culture","ta":false,"tp":true}
{"pi":"0x51CC"}

It seems that the first received PI (even when wrong) is used, no matter if later wrong codes were detected, right?

I'll try to set use longer recordings if necessary. As it happens were rarely, I might run out of space when saving all WAV files as well.

But I don't understand that some blocks in RDS group B look similar to the PI-Code in group A (51CC <-> 52CC). Can you exclude there is an offset in redsea?

http://andimik.bplaced.net/rds/spyfiles/51CC_-_2023-12-01_19-19-44.spy

[windytan]

The logic is, wait for two repeats of the same PI. Then, assume that this is the correct PI code. Random noise can generate erroneous PI codes, but it's unlikely that the error repeats. In your first snippet it seems that 3249 was received twice and then assumed to be the correct PI.

If it does happen quite often, maybe some modification to this logic could be designed. Maybe we should wait for three repeats? It should be tested whether this leads to better or poorer reception under noisy conditions.

RDS is designed in such a way that block mis-identification (block2 received as block1) should be unlikely. In this case it's hard to say whether this has happened without seeing the raw binary. Edit, but it does look like 51CC vs. 52CC and 3249 vs. 5249 are both just two bit-flips away.

[windytan]

One thing that comes to mind is we could try disabling error correction when synchronization is lost, so it is not applied to PI code search. RDS error correction will, ironically, cause some more errors to go through undetected (old discussion). Then we could re-enable it once the correct PI code is detected.

[windytan]

It should be fixed in master after 9016e3e, note that build instructions have also changed

[andimik]

Will test it as soon as I am able to compile ...

#108

[andimik]

Have tested with v1.0, but there are still even repeated wrong PI-Codes, but not en suite. The good thing is, that the wrong PI needs to be received 3x ...

---- ---- 4F67 5241
A502 ---- 0667 4449
A904 2418 ---- ----
A502 ---- C323 7FE0
A502 040A 5B67 ----
---- ---- ---- A201
---- 040F 5367 ----
A502 ---- ---- 7FE0
---- ---- ---- 5241
A502 E405 ---- ----
---- ---- 677A ----
---- 2419 2020 ----
A502 8405 C323 7FE0
A502 040A E35A 4F2D
A502 241A 2020 42AC
---- ---- ---- A201
A502 3410 0064 CD46
A502 040F 5A67 ----
A904 241B ---- ----
---- E405 4D39 ----
---- 0408 EB12 ----
A502 ---- 4140 0000
A502 0409 ---- 4449
A502 E405 ---- ----
---- 040A 1255 4F2D
---- 241C ---- ----
---- 8405 ---- ----
A502 ---- 1240 ----
A502 ---- ---- A201
A502 0408 1243 ----
A502 ---- ---- ----
---- 8205 5F01 ----
---- 040A F146 4F2D
---- 241D ---- ----
A502 040F 4667 4B20
---- 241E 2020 ----
---- E405 ---- A201
---- 3410 ---- CD46
---- 8406 C1F4 4BC4
---- ---- ---- 6259
---- 241F 2020 ----
---- E405 5524 ----
A502 ---- 4649 ----
A502 8406 C1F4 ----
---- 040A ---- ----

I wonder if there is any chance to avoid wrong data? It's coming from csdr and an RTL Stick. This was a weak frequency. On local channels I don't have that problem ...

[windytan]

Do you wish to see fewer errors in the hex output? I could think of adding an option to disable the forward error correction. This would lead to much fewer groups received (more ----), but the probability of error would go down somewhat.

Or you can even try this yourself by opening the file src/block_sync.cc and changing line 276 (where it says if (correction.succeeded)) to say:

    if (false) {

And then running meson compile again. This would make redsea as strict about errors as it mathematically can.

But when there's a lot of noise it's not possible to reject 100% of errors. This is from RDS spec:

• Detects all single and double bit errors in a block.
• Detects any single error burst spanning 10 bits or less.
• Detects about 99.8% of bursts spanning 11 bits and about 99.9% of all longer bursts.

[windytan]

Or you can also disable forward error correction with --no-fec. I made a longer writeup if you're interested

[andimik]

Oh, many thanks for your measurements. I wanted to do the same, but you were faster than me.

Yes, there is less data coming out, but you are right, there is no 100% accuracy possible.

I'll close therefore.