Skip to content
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

return number of repaired errors #10

Open
ghost opened this issue Jan 23, 2020 · 1 comment
Open

return number of repaired errors #10

ghost opened this issue Jan 23, 2020 · 1 comment

Comments

@ghost
Copy link

ghost commented Jan 23, 2020

Hi,

Would it be possible to not only return the data but also the number of repaired errors?
That way, for example a communication-channel can switch to a lower bitrate if errors are detected.

@lrq3000
Copy link
Owner

lrq3000 commented Jan 23, 2020

Hello,

Normally you can know the number of errors by looking at the syndrome. I am not sure/can't remember if it is returned in the high level class, but if you manipulate the low-level functions manually (from the class it should be possible, just call the internal methods), and simply call the syndrome function, simply count the number of non-zero items and you'll have the number of errors/erasures corrected.

However, keep in mind that if the number of errors or erasures exceed the theoretical singleton bound, the syndrome can't be trusted and you can't know whether the decoder validly corrected the messages or not. That's an intrinsic limitation of all error correction codes. A workaround is to add a checksum in your message as an additional protection mechanism, that also is not guaranteed to always work (ie, risk of tampering by noise or attacker and then collision) but it significantly reduces the risks (ie, collision is highly unlikely if the tampering is caused by noise, but if there is an attacker scenario the likelihood is potentially higher).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant