tags:

views:

106

answers:

1

I have a sensing device that transmits a 6-byte message along with an 1-byte counter and supposedly a checksum.

The data looks something like this:

------DATA----------- -Counter- --Checksum?--

55 FF 00 00 EC FF ---- 60---------- 1F

The last four bits in the counter are always set 0, i.e those bits are probably not used. The last byte is assumed to be the checksum since it has a quite peculiar nature. It tends to randomly change as data changes.

Now what I need is to find the algorithm to compute this checksum based on --DATA--. what I have tried is all possible CRC-8 polynomials, for each polynomial i have tried to reflect data, toggle it, initiate it with non-zeroes etc. I've come to the conclusion that i am not dealing with a normal crc-algorithm. I have also tried some flether and adler methods without success, xor stuff back and forth but still i have no clue how to generate the checksum.

My biggest concern is, how is the counter used??? Same data but with different countervalue generates different checksums. I have tried to include the counter in my computations but without any luck.

Here are some other datasamples:

55 FF 00 00 F0 FF A0 38  
66 0B EA FF BF FF C0 CA  
5E 18 EA FF B7 FF 60 BD  
F6 30 16 00 FC FE 10 81  

One more thing that might be worth mentioning is that the last byte in the data only takes on the values FF or FE

Please, if you have any tips or tricks that i may try post them here, I am truly desperate.

Thanks

A: 

Some random ideas:

  1. Bit ordering: you are currently representing the data as octets, but this is not how the CRC algorthm sees it. CRCs operate on polynomials represented as arrays of bits, not arrays of octets. Because of this, it is possible that the device performs the CRC using different bit ordering scheme than the one you are using.
  2. Depending on the device, I would say it is rather likely that the counter is included in the CRC calculation.
  3. If this is an embedded device, it might be use some other code, such as a BCH.

Is there any other information that can be given about the device in question?

This might give some indication as to how strong coding has been used. As an example, certain CRC-12 (0x8F8) provides Hamming distance of 5 up to data word lengths of 53 bits (in your data the data word could be 52 bits, assuming CRC size of 12 bits).

Edit: See the answer in http://stackoverflow.com/questions/149617/how-could-i-guess-a-checksum-algorithm for some additional ideas.

Schedler
Hi,1. Yes I have thought of this,(I think). I've read the bytes starting from right instead, i have also reflected each byte. I have not swapped positions of the bytes, but I have little faith that this would be the case.2. Is the counter there to mix it up because of low variety in the message or what?3. I am not sure about this. I will check out BCH. Unfortunatly I do not have much more information to give you. It is a sensor used in the automotive industry to measure accelerations of an object.
knivmannen
3. After some considerations I would think that BCH is very unlikely, given the high number of data bits vs. small number of check bits. Do you know how to interpret the data already? This might give some ideas on the overall structure of the data frame.
Schedler
I have indications what the different bytes mean, but nothing is for sure. I have not given it too much attention since I figured that it wouldnt matter what they actually represented.
knivmannen
I talked to a collegue and he was somewhat sure that atleast the second byte (counting from left hand side) was an yawrate, byte 5 and 6 are lateral accelerations. I dont see though, how this can be helpfull.
knivmannen