Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need help identifying the checksum algorithm in the following packets please.

So, packets format is:

sd ?? dd dd dd ??


s = start nibble d = data (binary coded decimal) ? = unknown - possibly checksum

Here are five packets (number being transmitted in brackets) and the actual packet sent on the wire in hex on the right.

(1112694): f1 f7 11 26 94 74

(5432432): f5 7c 43 24 32 a2

(6430116): f6 dc 43 01 16 48

(3254817): f3 d8 25 48 17 e9

(0042863): f0 ce 04 28 63 b2

I've tried XOR and summing but they dont seem to work. The packets are transmitted using UART.

any help appreciated!

share|improve this question
How is this related to electronics? – pipe Mar 4 at 14:23
What device is it? It might be just documented. – Eugene Sh. Mar 4 at 14:35
@pipe I would say it is. Communication protocols are more of EE than programmers stuff.. – Eugene Sh. Mar 4 at 14:41
You'll need a lot more than five random samples to figure this out. To what extent can you control the contents of the transmission? For example, can you try sending 0000000, 0000001, 0000002, etc.? Such a pattern would provide a lot of clues. What does the data represent, anyway? – Dave Tweed Mar 4 at 15:01
It is my judgement that this question should not be closed. Almost any electrical engineer that has had their hands in embedded coding as part of their project has faced the problem of either getting a CRC code working for their project or reverse engineering a CRC from something that they have to connect to. Checking codes play a huge role in electronics whether those codes be generated and checked in hardware, FPGA or microcontroller firmware. – Michael Karas Mar 4 at 15:25
up vote 16 down vote accepted

Take your first data row:

(1112694): f1 f7 11 26 94 74

Make a byte stream of hex numbers as:





Run those bytes in that order through a CRC-CCITT (XModem) CRC algorithm to arrive at a CRC of 0xF774. The high byte of the CRC goes to the second position of the message and the low byte of the CRC goes to the last position of the message.

This same technique works for each of the messages in your sample. I used the online calculator to show the result as here:

enter image description here

The polynomial function for the CRC-CCITT algorithm is as follows:

enter image description here

I leave it to you to look up and find source code for the CRC-CCITT algorithm and understand the specific nuances of using that code in the old XModem methodology. The 0x1021 polynomial is well known and I have used it for years in my projects for everything from communications protocols to check codes on data sets stored in serial EEPROMs and FRAM chips. The usage nuances come into play as to whether the CRC fields of the packet are preset to something like 0x0000 or 0xFFFF and whether those preset fields are also passed through the CRC calculator to arrive at a result. Note that there is a plethora of information online.

share|improve this answer
Well done! The calculator link could be useful. – Spehro Pefhany Mar 4 at 15:29
Ha. Good work.. – Eugene Sh. Mar 4 at 16:11
I love you. Seriously. Thank you so so much. I'd just started disassembling the firmware to work out how it was doing it!!!! – user3780104 Mar 4 at 16:41
Hats off to you. I don't think I'd have looked for the MSB of the checksum in the second byte. That's pretty weird. And padding the msn with an F rather than a 0? – WhatRoughBeast Mar 4 at 20:35
@WhatRoughBeast Maybe it's to guarantee a non-zero input value for the checksum? Regardless, this is stellar work on Michael's part. – Adam Haun Mar 4 at 22:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.