1
\$\begingroup\$

I am building a hardware parallel crc_6 encoder and decoder. The polynomial I am using with the given length of input data has HD=3, meaning it can detect up to 2 error bits. The flow is at the transmitter, CRC bits are calculated based on the data block and appended to the data.

At the receiver, the CRC is recalculated based on the received data block and compared with the received CRC. If the calculated CRC matches the received CRC, the frame is considered error-free. If they don’t match, an error is detected.

My Question is how to know in case error is detected if I had one error or two errors?
Can I compare the calculated CRC and received CRC and if it has one bit difference then one error, 2 bit difference then 2 errors?

\$\endgroup\$
4
  • 2
    \$\begingroup\$ There are (5) CRC 6's mentioned in this CRC catalog. Which, does matter somewhat. For all, the double-bit detection guarantee only is true for bit errors not separated by \$2^6-1=63\$ bit positions. If that distance is achieved, then it won't be detected. So now I want to know the message length and type of CRC 6 before considering an answer. Not all CRC 6's are the same. Message length also matters, though HD=3 says something. Please also review here. It may help. \$\endgroup\$ Commented Sep 26 at 6:36
  • \$\begingroup\$ My Polynomial is x^6 +x^5 +x^2 +x +1 and message length input to encoder is 27 bit , I can also use Polynomial x^6 +x +1 for message length input to encoder 27 bit \$\endgroup\$ Commented Sep 26 at 11:32
  • 1
    \$\begingroup\$ Koopman, 2004 is the reference that sticks in mind as seminal on the topic. Koopman is famous and maintains extensive material on the topic here and discusses your 0x33 polynomial here and here. If your message length were just 25 bits instead of 27, you'd have HD=4. Have you contacted Koopman? He still seems active, or staff in his office seems to be. \$\endgroup\$ Commented Sep 26 at 13:02
  • \$\begingroup\$ I would strongly suggest you contact Koopman (or staff.) I am certain there is a paper or two that they can suggest to address your question directly. As Justme suggests, this is a remainder problem (the quotient is tossed away.) But there is an interesting note in the link I provided earlier that strongly suggests to me that you may be able to detect differences, as my skimming there seems to imply single bit errors yield the same remainder, while 2 bit errors do not. I'd give a call to Koopman to confirm, personally. Give it a try? \$\endgroup\$ Commented Sep 26 at 13:06

2 Answers 2

Reset to default
2
\$\begingroup\$

As CRC is a bit like a remainder of a division operation between message and the polynomial, it doesn't really give an indication how many errors happened or where they happened, or if you even fed in correct number of message bits for a variable size message.

What it does give you is simply if the CRC matches or not.

If it does not match then there are definitely one or more errors somewhere.

If it matches, there either are either no errors at all, or too many errors so the completely different received message with errors just happens to match the received CRC and passes along as OK even if it wasn't the transmitted message.

Also, you have to consider that the message may have been received OK but the errors happened during transfer of the CRC. You cannot know purely based on data and CRC how many errors happened.

\$\endgroup\$
2
\$\begingroup\$

In general, transmitting a data block with CRC tells you whether the whole thing has been transmitted correctly or incorrectly. There's no easy-to-use pattern in differences between the receiver's calculated CRC and the received (potentially corrupted) CRC and the position or number of errors.

CRCs are specially good for certain kinds of errors: that's why we use them. For example, we might have a 1,024 bit message which includes a 32-bit CRC. There are very many (21024) different messages which means that very many must share the same CRC, as there are only 232 different CRC values. (In a perfect CRC scheme, there would be 2992 different messages with each CRC value.) The trick is this: certain errors are lot more common than others (bursts, for example) and good CRCs pick them up with a very low overhead. (Ie, the number of bits in the CRC is small compared to the number of payload bits. "Small" would be perhaps 4 bytes on a 512-byte data block, about 100:1.)

So, no, you can't find or even count the bit errors with CRCs.

BUT

Technique 1: multi-dimensional CRCs. If you arrange your bits in a rectangular grid, you can send CRCs with each row and each column. Now you can easily identify (and thus correct) any single bit error. Under many conditions you can do better.

Technique 2: hunt the error. If you have a block of n bits with a CRC error, perhaps it was only a single bit, and there are only n different positions it could be. Try flipping each bit and see if the CRC computes correctly. If it was 2 bits, try the n x (n-1) possible 2-bit errors. If errors are rare and retransmission is expensive/impossible, and you have a lot of CPU available, this is a great technique.

AND

If you want proper error correction, you'll need a lot more bits in your checksum. Have a look at Hamming(7,4) and Golay binary codes. But these codes use vastly more checking bits than CRCs: Golay for example is 2:1 ie, a third of the transmitted data are check bits.

\$\endgroup\$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.