Noise-proof coding: Are there options between simple parity control and hamming code

I need to encode the parcel (8 bits) in such a way that transmission errors, if any, can be detected at the receiving end.

The task of correcting errors is not worth it, however, it would be great, of course.

I now see two options:

  1. Simple and least stable (single error detected). This is a parity check.

  2. Quite complex, but very stable (detectable double and single error is fixed, if I'm not mistaken). Hamming code 8 bits of data are encoded into a 12-bit parcel (4 redundant bits). Actually, this is a classic, like an 11-bit package from which 7 bits of data are obtained, but it seems that you can encode the "extra" 8th bit.

I've dug through quite a few Hamming coding solutions, but either I don't understand the principle itself, or it's really quite a difficult task. I don't have much time for debugging, CPU resources (ATMega48PA @ 1MHz) are also not a big deal, although in my case it is clearly not a limiting factor.

Purely intuitively, it seems to me that the Hamming code for mine is redundant (and the 33% reduction in the transfer rate is also annoying), and the parity control is insufficient.

Are there no solutions somewhere in between?

Author: Vlada Katlinskaya, 2015-12-18

1 answers

First, you should decide what errors you actually have, and how often. After that, how difficult it is to re-request and transfer the corrupted data.

For example, if you have one error per million bits, the error consists of one corrupted bit, and the data can be requested again, then parity is enough for the eyes. If re-requesting data is very expensive, and processing needs to be as fast as possible, and it does not tolerate delays, then it is worth looking in the direction of the code Hemming.

Parity control can be extended to any number of bits, if you really need it, for example, you can take not the remainder of the division by 2, but the remainder of the division by 4. Then the algorithm will detect not one broken bit per byte, but two. You can also act in the opposite direction, for example, consider the parity of not one byte, but blocks larger than the size: if errors occur extremely rarely, and the speed is very critical, this can be beneficial.

 6
Author: Kyubey, 2015-12-18 16:37:47