Calculating Odd CRC

[MikeMack747]

I think I have discovered the issue, If I rearrange the byte order; F1 = 1F, use the last 3 bytes of data, this thing works.

[Bob_Schor]

Ok, Magic.  Or maybe Voodoo.

BS

[nathand]

---

@MikeMack747 wrote:

I think I have discovered the issue, If I rearrange the byte order; F1 = 1F, use the last 3 bytes of data, this thing works.

---

That would be swapping nibbles, which is a bit weird. In hex, F1 is a single byte.

Note that in the C code, the second and third byte are the message length, but they are also part of the CRC. The Delphi example, on which you seem to have based your LabVIEW code, has a fixed Count of 3, but the sample messages you provided actually have a length of 6 (thus the "00 06" in the second and third positions) - although, oddly, that length appears to include the CRC byte. Alternatively, following the comments in the Delphi code, it's hard-coded for mode 1 (starts with FE) but your messages are mode 3 (starts with F1, contains 5 bytes without the CRC).

[MikeMack747]

Swapping nibbles seems to be a fluke that just happens to work with the mode commands only

[nathand · Accepted solution]

Here's a direct translation of the C code into LabVIEW, as a snippet:

[MikeMack747]

The Exclusive Or seems to have the same results as ANDing with with x80.

Thanks and kudos to nathand for solving this for me!

Many thanks

Mike

[MikeMack747]

My mistake, shifting a right 7 has the same effect as ANDing with 80h

[nathand]

---

@MikeMack747 wrote:

My mistake, shifting a right 7 has the same effect as ANDing with 80h

---

Only when followed by a comparison with 0. When combined with that comparison, they both check if the highest bit in a byte is set. In one case you are ANDing with a value that has only the high bit set; in the other case, you are shifting the highest bit to the lowest and replacing all the higher bits with 0.