could the crc error correction return wrong result?

[flux242]

that is not discarded?

{"group":"2A","pi":"0x141D","prog_type":"No PTY","radiotext":"Jetzt on air: KUNGS feat. JAMIE N COMMONS DONT YOU KNOW","tp":true} {"group":"2A","pi":"0x141D","prog_type":"No PTY","radiotext":"Jetzt on air: KUNGS feat. JAMIE N COMMONS DOOL YOU KNOW","tp":true} {"group":"2A","pi":"0x141D","prog_type":"No PTY","radiotext":"Jetzt on air: KUNGS feat. JAMIE N COMMONS DONT YOU KNOW","tp":true}

DONT -> DOOL -> DONT

[windytan]

Weird indeed. I'll need to write tests for the error detector.

This much is said about the RDS error protection scheme:

• 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.

Maybe it could be a long error burst (like 11000000011)?

[flux242]

I let my computer record the bit stream tonight for 5-6 hours but I couldn't reproduce the problem unfortunately. This is somehow related to the noise introduced by the usb cable, dongle, computer and antenna constellation.

I have recorded samples with cases when the radiotext message is not fully displayed first, then more symbols are shown and then the full message is shown. Maybe it's somehow related but maybe it's ok

I will try to record more bit stream samples trying to catch similar cases.

[windytan]

I tested the error detector with a million known error vectors, and it works as advertised. (However, error correction doesn't do anything for some reason. Erroneous blocks are discarded however).

This means that 0.1 - 0.2 % of long error bursts go undetected, so there will inevitably be some errors when the signal is very noisy.

[windytan]

Just for the record - this is affected by the correction algorithm.

Here's a test run to measure error detection rates for errors of different length when correction is disabled vs. enabled for 1-2 bit errors:

burstLen	don't correct	correct 1bit	correct 1-2bit
1	100.0 %	100.0 %	100.0 %
2	100.0 %	100.0 %	100.0 %
3	100.0 %	100.0 %	100.0 %
4	100.0 %	100.0 %	100.0 %
5	100.0 %	100.0 %	100.0 %
6	100.0 %	97.4 %	89.0 %
7	100.0 %	99.8 %	98.6 %
8	100.0 %	98.2 %	98.3 %
9	100.0 %	99.0 %	98.1 %
10	100.0 %	97.3 %	96.5 %
11	99.8 %	97.1 %	94.6 %
12	99.9 %	97.5 %	95.7 %
13	99.9 %	97.5 %	95.7 %
...

This shows that error detection rates are somewhat impacted by enabling error correction. This will result in some errors slipping through. I think it's an expected tradeoff of the error protection scheme used.

[flux242]

hm, interesting distribution. So what's the default currently? Don't correct, discard?

[windytan]

Currently (at least in the latest commit) errors of 1 or 2 bits will be corrected, and uncorrectable blocks are discarded. I based this on Kopitz & Marks 1999: "RDS: The Radio Data System", p. 224: "...the error-correction system should be enabled, but should be restricted by attempting to correct bursts of errors spanning one or two bits."

1-bit errors should not be very common because of delta encoding; perhaps 2-bit errors only would suffice.

[windytan]

Will reopen if it causes further problems :) The restrictions mentioned in that document seem to keep it in order.