CRC-16-CCITT of serial packets

[josborne]

So I have read a lot of posts about calculating cyclic redundancy checks, but I am still having trouble.  Even with all the example VIs available in the public domain.  Here's my challenge:

I need to calculate a CRC on RS232 messages going to/from a device.  According to the user manual, I need to calculate a:

"16 bit CRC-CCITT cyclic redundancy check (not the popular XMODEM variation of CRC-CCITT). Refer to the document "Serial Infrared Link Access Protocol (IrLAP) Version 1.1" for the actual computation method of the CRC. The one’s complement of the CRC is transmitted, rather than the CRC itself. The CRC is transmitted LSB first. If the CRC is not correct, you should ignore the message."

And according to the referenced IrLAP document:

-- We should use a CRC with polynomial equal to X^16 + X^12 + X^5 + 1
-- The CRC is initialized to all ones. This allows detection of any missed or inserted zero bits at the beginning of a block. (Missed or inserted ones are still detected.)

I assume that the above information means that I should calculate a CRC-16-CCITT that begins with 0xFFFF.  Like the example code listed here. But it doesn't seem to match up.

Here are some example messages and the CRC that accompanied them:

     Incoming packet (in Hex) = 1101001A0A187DE11661803080020101A080638080010000000000000000

     CRC received (in Hex) = 0052

     Incoming packet (in Hex) = 11010028E10000020001002000000007001A00210000000000000000F13B000C00030001002A000000000000
     CRC received (in Hex) = 437C

I can't seem to calculate a CRC that matches up.  I know I need to take the one's complement and then convert it to LSB first, but I am stumped.  I attached my code (LV2010).  Any tips out there?  Thanks!

[Mark_Yedinak]

Here is the code that I have developed and that I have found to work quite well. It matches most of the various online calculators. Many published algorithms are not 100% correct. I have verfiied mine for the CRC-CCITT algorithm. You will noticed I return both an agumented value and the CRC-16. The agumented value is technically the correct value when you look at teh math behind the calculation. However, many algorithms in use stop the calculation short and return the value CRC-16. I am not sure what algorithm your device is using as I couldn't find anything that produced a match to your examples.

On a unrelated note I would recommend against using the old llb libraries for your code. Use the current library file (similar to the project) for your code. The old llb libraries had an issue that if one file was corrupted the entire library was then corrupted. The new version stores each VI in the library as it's own file. This also helps with source code code.

[josborne]

Thank you, Mark.  I think the device I am communicating with using an unusual algorithm.  I found this link which provided the code I needed.  Thanks!

[PhoenixCall]

Mark, this did it for us!  I know it's an old post but I wanted to thank you for your work here.  We struggled with the issue for a while and found your example which solved our issue.  Thanks.