-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
could the crc error correction return wrong result? #35
Comments
Weird indeed. I'll need to write tests for the error detector. This much is said about the RDS error protection scheme:
Maybe it could be a long error burst (like |
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. |
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. |
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:
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. |
hm, interesting distribution. So what's the default currently? Don't correct, discard? |
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. |
Will reopen if it causes further problems :) The restrictions mentioned in that document seem to keep it in order. |
* With --no-fec you will see fewer errors in noisy conditions but also fewer blocks. * Also, testability improvements.
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
The text was updated successfully, but these errors were encountered: