Serial Packet Question: How to calculate CRC

[nickpuy]

Thanks Mathew, this is a chinese device, manual is really bad... the only thing i got was the CRC calculation code, and this information:

D14：CRC checking value from the 4th data byte

so annoying that i dont have more infomation! i really appreciate if you can help me on this!

thanks!

[nickpuy]

Mathew, here is the definition for the packet:

00 01Header fixes at A5 09

02Data Length (its fixed at 0C)

D3 D4First Sensor Id

D5Data Type:60=Sensor Reset, 61=Periodical signal, 62=Status Change Signal

D6 D7Second Sensor Id

D8Second Sensor Status11= Closed   10= Opened

D9Battery StatusA0= Battery Charged   A1=Battery Discharged

D10 D11First Sensor Value

D12 D13Second Sensor Value

D14CRC

hope it helps!

thanks

[Mark_Yedinak]

Here is the LabVIEW version of the code above. I would need to know your data definition better to know what the CRC is actually being calculated over as well as what as the expected CRCs for the data you posted. This would verify this code.

Update: Stripping the header from the data I also calculate the correct CRC (last byte of what you posted) so this code should work for you.

[nickpuy]

Mark, thanks so much!!!!!!! thanks for your time.

[nickpuy]

Mathew! thanks so much! your example worked perfectly!!! you and Mark helped me so much in understanding this complex calculations!

thanks!

[Matthew_Kelton]

So, the A5 09 0C is not included in the CRC calculation.  If you strip those bytes off and feed the next 11 bytes to the CRC calculator, you should see the CRC is the last byte.

[Mark_Yedinak]

---

@Matthew Kelton wrote:

So, the A5 09 0C is not included in the CRC calculation.  If you strip those bytes off and feed the next 11 bytes to the CRC calculator, you should see the CRC is the last byte.

---

To further clarify, you can determine if the CRC is correct in one of 2 ways. You can strip the last byte off (as well as the header) and compare the calculated CRC with the CRC from the packet. The other method which is much more straightforward is to calculate the CRC with the received CRC included. If they match your resulting CRC will be 0x00. If there is any data corruption you will get a nonzero CRC.

The one thing to note is that the larger the CRC the less likely you can get a matching CRC with data corruption in the packet. So, it is possible to receive a corrputed message and have the CRC match. On a 32-bit CRC the odds are extremely low. On an 8-bit CRC it is more likely to occur. You can calculate the odds yourself: "Typically an n-bit CRC applied to a data block of arbitrary length, will detect any single error burst not longer than n bits and will detect a fraction 1−2⁻ⁿ of all longer error bursts."