How to "hack" a CRC?

ManAtWork

I'm just about to find out how to talk to an encoder of a Misubishi servo motor with a propeller. This is an optical absolute encoder with 17 bits resolution (single turn) and an RS485 interafce. If I send a command byte of $02 to it it answers with a sequence of 9 bytes. Each byte starts with a start bit of 0 and a stop bit of 1. Lowest significant bit is transmited first. A data frame looks like this:

• Byte #1: always $02
• Byte #2: always $31
• Byte #3: position bits 0..7
• Byte #4: position bits 8..15
• Byte #5: position bit 16
• Byte #6: always $C0
• Byte #7: always $00
• Byte #8: always $C0
• Byte #9: CRC

I found this out by turning the shaft and watching the scope. Now the question: Is it possible to find out how the CRC is calculated? It would be nice if I could verify if the transmission is error-free. I think this could be done with brute force (trying out all possible cases). What are the variables?

• CRC polynomial, Wiki lists only 5 possibilies of common CRC-8 polynomials
• different starting values ($00 or $FF are common)
• data is inverted or not (I can't tell because I don't know the sign/direction of rotation)

Here is a list of some data frame samples:

Data: 02 31 57 8F 01 C0 00 C0 EA
Data: 02 31 8F 97 01 C0 00 C0 2A
Data: 02 31 35 A5 01 C0 00 C0 A2
Data: 02 31 0D AC 01 C0 00 C0 93
Data: 02 31 1A B3 01 C0 00 C0 9B
Data: 02 31 6A B7 01 C0 00 C0 EF
Data: 02 31 C8 C7 01 C0 00 C0 3D
Data: 02 31 97 CD 01 C0 00 C0 68
Data: 02 31 96 D7 01 C0 00 C0 73
Data: 02 31 44 CE 01 C0 00 C0 B8
Data: 02 31 C9 CD 01 C0 00 C0 36
Data: 02 31 E2 D0 01 C0 00 C0 00
Data: 02 31 EC E5 01 C0 00 C0 3B
Data: 02 31 22 EB 01 C0 00 C0 FB
Data: 02 31 EE EE 01 C0 00 C0 32
Data: 02 31 51 F3 01 C0 00 C0 90
Data: 02 31 79 FD 01 C0 00 C0 B6
Data: 02 31 79 0A 00 C0 00 C0 40
Data: 02 31 6F 18 00 C0 00 C0 44
Data: 02 31 B0 28 00 C0 00 C0 AB
Data: 02 31 C4 31 00 C0 00 C0 C6
Data: 02 31 71 46 00 C0 00 C0 04
Data: 02 31 35 55 00 C0 00 C0 53
Data: 02 31 F8 6C 00 C0 00 C0 A7
Data: 02 31 E3 78 00 C0 00 C0 A8
Data: 02 31 5F 8D 00 C0 00 C0 E1
Data: 02 31 0F 90 00 C0 00 C0 AC
Data: 02 31 67 8D 00 C0 00 C0 D9
Data: 02 31 81 8D 00 C0 00 C0 3F

Has anybody done this before or can give me some hints?

Heater.

First clue is that the check sum is only one byte so it is probably not any CRC which are usually 16 bits.

So what about a simple sum of all the bytes?

Sure enough the first example is 0x02 + 0x31 + 0x57 + 0x8F + 0x01 + 0xC0 + 0x00 + 0xC0 + 0xea = 0x384

Throw away the overflow out of 8 bits and you have 00.

So the you have it. Adding up all the bytes of the message including the check sum byte must give zero to be a correct message.


Edit: Opps. Not so fast that sum is wrong. Changed it now in red.

Dave Hein

Write a program that computes 8-bit CRCs that allows for changing the polynomial, starting value, polarity and shift direction. With 5 polynomials, 2 starting values, 2 polarities and 2 shift directions there will be 40 possibilities. It's most likely one of those combinations. Run your program until you find a matching combination.

EDIT: Heater, I get 0x384 when I add up the bytes. How did you get 0x900?

Tor

As far as I can tell it's not a CRC, it's an XOR checksum. You XOR the first 8 bytes, and the 9th byte should be the same value.

-Tor

ManAtWork

You made my day! This is another example that often, we just worry too much and expect things to be more complex that they actually are. Yes, it's really a simple checksum, not cyclic/shift/xor/whatever. I thought it was a CRC because a similar encoder from SanyoDenki which also has 17 bits resolution and RS485 uses a CRC (yes, CRC-8 by the way).

Dave Hein

Yes, Tor is correct. It is an XOR checksum. I tried it on a couple of rows and got zero both times.

Heater.

No. It's doing a check sum by simply exclusive ORing the bytes together. So we have two examples in the data:

0x02 ^ 0x31 ^ 0x57 ^ 0x8F ^ 0x01 ^ 0xC0 ^ 0x00 ^ 0xC0 ^ 0xEA = 0x00

and

0x02 ^ 0x31 ^ 0x22 ^ 0xEB ^ 0x01 ^ 0xC0 ^ 0x00 ^ 0xC0 ^ 0xFB = 0x00

Heater.

Dave,

Yes I notice the error in my arithmetic and then corrected.

ManAtWork

Correction... Tor is right. The sum of $300 I got or $900 from Heater were lucky speacial cases. But if we use XOR instead it works for all cases. I just tried out. Thank you very much.