Serial RS232 Communication Checksums?

Question

I am communicating with a servo via RS232 serial. The built-in functions that came with my servo are too slow (25 ms for a simple 54 byte message on a 57,600 baud port), so I am

Answer 1

this is a late answer, but hopefully this can help for other CRC re-engineering tasks:

Your CRC is a derivation of the so-called "16 bit width CRC as designated by CCITT", but with "init value zero".

The CRC is calculated from byte position 3 to byte position 12 of your example data. e.g.

08 20 03 01 11 25 00 00 00 00

The full CRC specification according to our CRC specification overview is:

CRC:16,1021,0000,0000,No,No

The problem was not only to find the right CRC polynomial, but finding the following answers:

• Which part of the data is included in the CRC calculation, and which is not.
• Which init value to use? Apply final xor value?
• Does this algorithm expect reflected input or output values?

Again, see our manual description or the Boost CRC library on what this means.

What I did is running a brute-force script that simply tries out several popular 16 bit CRC polynomials with all kinds of combinations of start/end positions, initial values, reflected versions. Here is how the processing output looked:

 Finding CRC for test message (HEX): 10 13 08 20 03 01 11 25 00 00 00 00 E9 64
 Trying CRC spec : CRC:16,1021,FFFF,0000,No,No
 Trying CRC spec : CRC:16,8005,0000,0000,No,No
 Trying CRC spec : CRC:16,8005,FFFF,0000,No,No
 Trying CRC spec : CRC:16,1021,FFFF,FFFF,No,No
 Trying CRC spec : CRC:16,1021,0000,FFFF,No,No
 Trying CRC spec : CRC:16,1021,0000,0000,No,No
 Found it!
 Relevant sequence for checksum from startpos=3 to endpos=12
 08 20 03 01 11 25 00 00 00 00
 CRC spec:   CRC:16,1021,0000,0000,No,No
 CRC result: E9 64 (Integer = 59748)

With the result I could re-calculate the checksum of your example telegrams correctly

19.09.2016 12:18:12.764 [TX] - 10 13 08 20 03 01 11 25 00 00 00 00 E9 64 
19.09.2016 12:18:14.606 [TX] - 10 13 08 20 03 01 11 25 01 00 00 00 9F D0 
19.09.2016 12:18:16.030 [TX] - 10 13 08 20 03 01 11 25 02 00 00 00 04 0C 

I uploaded the documented CRC finder example script which works with the free Docklight Scripting V2.2 evaluation. I assume this can be very useful for other CRC re-engineering puzzles, too.

The example also helped to solve Stackoverflow question 22219796