LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

CCITT-CRC I'm guessing

Solved!
Go to solution

I have searched through the various threads on CRCs and am at a loss as to what I really need. I have been given a specificaiton with almost no information. I am very unfamiliar with CRCs so I hope some of you can help me out.

 

Requirements

* A 16-bit CRC shall be calculated for the sequence number and message payload fields. The CRC shall be placed after the message payload.

* The CRC shall be calculated using the standard polynomial x16 + x12 + x5 + 1

* CRC Initial Value. When calculating the CRC, the initial value shall be zero

 

Then I'm given a sample of C code which is suppose to calculate the CRC using a look-up table. The top of the code has the following comment, "CRC-16-CCITT, Reversed, x^(16) + x^(12) + x^(5) + 1, 0x8408"

 

Verification Test Data

The following is a sequence of test data for verification of the CRC algorithm. This data consists of 16, 16-bit words (in Hex format).

0x 5554 CCCE EEE9 6963 637B 7B5B 5B24 DB8E DA16 D836 DFB6 D5B6 CDB6 EDB6 9249 C71D

 

The CRC for this data sequence is 0x86DE

 

I've tried putting this sequence into various vi I've found in the forums, but none of them give me the 0x86DE. Even with changing the inputs form 8 bit to 16 bit etc. Because I can't seem to find out how the CRC is suppose to work I can't debug the problem. I've been working with this code as it seems the simplist (wish I could remember who posted it so that I could give credit).

 

Any help would be appreciated.

0 Kudos
Message 1 of 9
(7,254 Views)

Here is a stack overflow question that seems to address your problem. http://stackoverflow.com/questions/17196743/crc-ccitt-implementation I can see how your C solution with lookup tables might be difficult to reverse engineer; the solution presented at stack overflow is simpler. Try directly translating this to LabVIEW. 

 

I also think it worth noting that a CRC algorithm will sometimes use constant, non-zero value either as the initial value, or XOR'd with the final result. You can check your C code to see if the one you are trying to match does this.

0 Kudos
Message 2 of 9
(7,239 Views)

I don't know very much about C (which is why I use Labview and not Labwindows). But here is the C code without the 256 entry long table.

 

#define CRC_INIT (unsigned short)0x0000

 

unsigned short get_buffer_crc(unsigned short init_crc, unsigned char *buf, unsigned int length)

{

unsigned short crc = init_crc;

while (length>0)

{

   crc = crc_byte(crc, *buf);

   length--;

   buf++;

}

return(crc);

}

 

unsigned short crc_byte(unsigned short working_crc, unsigned char uc)

{

return ((working_crc>>8) ^ (crc_table[(working_crc ^ uc) & 0xFF]));

}

0 Kudos
Message 3 of 9
(7,224 Views)
Solution
Accepted by topic author Skydyvr

Skydyvr,

 

I fiddled a bit and got you an implementation that i think works as you need (based off one of the several others I've done).  No tables, so it's a slower implementation, but that's generally irrelevent for short messages and/or infrequent calls.

 

From the sources I have, this looks like it's the "Kermit" flavor, which some descriptions describe as a "true" CCITT-CRC.

 

Here is one pretty good link:

 

CRC online calculator - Lammert Bies

 

Let me know if this works for you.  I pasted your example string in and made it the default input data, just to make the demonstration easier.

 

Best regards,

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
Message 4 of 9
(7,195 Views)

I have a CRC calculator that I use for most of my purposes, the problem with CRC is there are just so many goddamn different standard ways of doing it, however after a little googling and testing I found that your version is apparently CRC CCITT Kermit, so using that in my program you need your Init Value to be 0 and your XOR comparator value to be 8408.

 

CRC 16.png

Download All
Message 5 of 9
(7,182 Views)

Thanks for your solution (everyone actually). This community is the greatest!! Smiley Very Happy I'm just starting to write the program to interface with the device so it will be a while before I can actually test it with real data. I'll let you know if this works. And yes, I don't care about implementation time. The data packets will come over no faster then 1/sec.

0 Kudos
Message 6 of 9
(7,169 Views)

Here is a more generic (read: slower) solution that is compatible with the parameters at CRCRevEng : http://reveng.sourceforge.net/crc-catalogue/16.htm

 

 

crc_generic.png

Download All
0 Kudos
Message 7 of 9
(7,149 Views)

Hi DavidBoyd,

 

Thanks for the solution.

It works fantastic for my work.

 

Regards,

Pankaj

0 Kudos
Message 8 of 9
(6,923 Views)

David,

Your Kermit CRC appears to be correct. Another seed sample "123456789" [sans quotes] should results in a CCITT-CRC/Kermit Checksome of 0x2189.

 

And your example does.

 

Wanna talk about a throwback checksum, take a look at the 'Fletcher Checksum' it was used in the Apollo programs.

Regards and thanks for the *working* code!

Jack Hamilton

0 Kudos
Message 9 of 9
(4,601 Views)