# A good ecc algorithm for random errors?

I know I will have a 10% error rate, but this errors are truly random. I was using solomon reed codes, but if a single bit in the code or parity word is bad the whole word becomes useless. If I have eight bytes of data and eight bytes of parity codes then 5 bit error can make my whole message bad. Is there a better algorithm for cases like this?

Edit:

I am trying to send packets of 128bit or 16bytes. 1/2 is data 1/2 is parity. I am having trouble figuring out how LDPC would be more beneficial.

If I have the same 16bytes with 8 bytes of parity and 8 bytes of data how ldpc be better? For example suppose with my example I have 1 bit errors in 5 different bytes. This would make SR unable to decode my data. Would it be the same LDPC or would it be able to recover that. From would I understand from LDPC it would still be unable to decode it.

• Reed-Solomon codes are not intended for use with random errors but make a very good straw man to knock down when touting the merits of a more appropriate error-correction scheme. I have sat in countless presentations which compare the performance of a Reed-Solomon code in AWGN against a good convolutional code/turbo code/LDPC code etc: the comparisons are meaningless. Use an LDPC code but be prepared for a lot of computation and a low-rate code: 10% error rate is pretty difficult to manage with just coding alone. Oct 18, 2012 at 12:11
• Most errors can be considered "random". If they were correlated somehow, then you could come up with a scheme to use that information to help correct them. Your question is probably better posed as how to design a system to accommodate a very high channel bit error rate. Oct 18, 2012 at 12:43

This really is a comment but is posted as an answer because it is too long to post as a comment.

Your edited question says that you are transmitting $16$-byte packets consisting of $8$ data bytes and $8$ parity bytes over a channel with bit error rate of $10\%$ or $0.1$. Thus, your code rate is fixed at $0.5$. Now Shannon's capacity formula for a (binary memoryless) channel with bit error rate $p$ is $$C = -p\cdot\log_2(p) - (1-p)\cdot\log_2(1-p) = 0.46899559358929 ~~ \text{when}~p=0.1.$$ Thus it is not too surprising that using a rate-$\frac{1}{2}$ code is not working too well, and switching from a Reed-Solomon code to an LDPC code is not going to help matters very much as long as the code rate is fixed at $\frac{1}{2}$. You may need to redesign the packet structure to reduce the code rate and/or improve SNR on the physical layer channel to reduce the error rate to something more easily handled by coding.

• So you are saying that his bit rate needs to be at most C? In other words, he needs to increase the amount of parity? Oct 24, 2012 at 15:47
• No, Shannon's capacity theorem says that it is possible to find codes with rates less than $C$ with post-decoding error rates no larger than any pre-specified number. If this number is very small, the code will have long block-length. Shannon did not claim that no code with rate larger than $C$ can achieve a given small error probability, but the result does suggest that insisting on a specific block length and code rate larger than $C$ is starting off on the wrong foot. Better to use a lower rate code (i.e. more parity) and probably block length much larger than 128 bits might be needed. Oct 24, 2012 at 17:12

First, it is not true that an error in the parity portion of a Reed-Solomon code word renders the word useless. RS codes can correct errors in their parity and their data.

Having said that, 10% errors is very high and I would not use a RS code in that situation. In fact, in a situation with that many errors you will occasionally have > 50% errors just due to random distribution (random distribution is often "clumpy") of the errors. No code you use will correct all of the errors all of the time. Your system should be designed with that fact in mind.

I would use a big turbo code or LDPC code. Either one will get you near optimal performance. The code needs to be "big" in the sense of using large blocks to avoid the clumpiness problem noted above. You will still get more errors on occasion, but (assuming a gaussian distribution) your tails will be MUCH smaller if you make your blocks large.

If your errors are bursty you can use interleaving to spread them out among multiple blocks. If they aren't bursty, interleaving won't help any.