Strange 16 bit CRC check

[Z4CRUZN]

Hi,

   So I am working with what appears to be a non-standard 16 bit CRC check. I have searched over the forums, and found many great examples of how to do this. I have enclosed the one that I am using at the moment. It seems to work just fine. I went to the website https://www.scadacore.com/tools/programming-calculators/online-checksum-calculator/

and it matches what the CRC check seems to be outputting, with the same set of data. However, this does not match what the system is outputting for a CRC-check. So with the following data set: 2000 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA 5555 5555 5555 5555 5555 5555 5555 AAAA 5555 5555 AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA 5555 5555 AAAA AAAA AAAA AA55 5555 5555 5555 5555 5555 5555 5555 AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA 5555 5555 5555 5555 5555 5555 5555 AAAA AAAA AAAA AAAA AAAA AAAA 5555 AAAA 5555 AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA 5555 AAAA AAAA 5555 5555 5555 5555 5555 5555 5555 AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AA55 AAAA AAAA 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555 5555  can anyone see how it might be able to produce an output of " 901C h" ? Is there some additional math gyration that I might be missing? Thanks...

[billko]

From my experience with this forum, I know there are a lot of related posts out there.  I Googled "CRC-16 LabVIEW" and I think probably almost all of the hits will be useful.

[crossrulz]

What instrument are you trying to communicate with?  Is there example code supplied giving more details on how the CRC is calculated?  There are just way too many variables to be just guessing.

[Z4CRUZN]

Not trying to be cryptic on purpose. There might not be an easy solution to this one. I might see if I can get more information from our software team about it. I thought I would put it out to the forum, to see if the solution might be something obvious that I have overlooked.

I was told that it is an IBM CRC 16 style check. And that I would need to use "A001 or 8005" polynomial depending on big or small endian (which I am using). The answers that I am getting seem to match the online stuff, but not what the SW folks are telling me. 🙂

[Z4CRUZN · Accepted solution]

As with so many things in engineering, the devil is in the details. So I have found what the issue was, I will list it here just in case others may run into this at some later time. As it turns out, the SW team decided to reverse all of the bytes before they get calculated in the CRC checker. So "6D" becomes "76". Once I added this to my code, and changed the polynomial to 8005. Works perfectly. Thanks again to everyone... 🙂

[Ben]

Ah hah!

The NUXI problem.

Spoiler

Since I can not seem to find anything via Google that tells the original story, I will report what I was told about the origin of that term.

Old computers used to use a line printer as the user interface and when an operating system started, the first thing that would be printed was the OS name and the version number.

That applied to Unix as well. Unix was originally develop on a DEC PDP 11-40 (may have been a 11-70 but I am sticking 11-40 for now). It ran great and it was not long until they made an attempt to port UNIX to an IBM machine. When they stated it up the first time it did the normal "Flying the banner" and printed out the OS was NUXI. DEC addressed bytes within a 16 bit word with the low byte first while the IBM machines considered the High byte the first byte.

Done with the old time trivia (for now)

Ben

[billko]

I once worked on a project where our PC had to talk to a UNIX box via serial, and we had the same byte order issue.  Fortunately someone had been kind enough to note the byte order in the documents.

[crossrulz]

---

@billko wrote:

I once worked on a project where our PC had to talk to a UNIX box via serial, and we had the same byte order issue.  Fortunately someone had been kind enough to note the byte order in the documents.

---

Exactly why I much prefer the Flatten To String and the Unflatten From String functions: you can choose the Endianness (byte order).