Another CRC16 Question...

[DailyDose]

Hello.  Been digging through many of the CRC16 discussions on NI Forums and various other C forums as well as wikipedia.  One question that doesn't seem to be addressed: what is the initial value?  My client asked for CRC16 with following polynomial: X16 + X15 + X5 + X2 + 1 but did not specify an Initial value.  This being my first go at this, I have to ask myself (and am now asking you) is there an initial value standard?  Is the initial value hidden in the polynomial?  Does X16 mean initial value = 0xFFFF?  I'd prefer to ask LabVIEW forums first cuz you won't judge me before I ask client for an initial value.  I know y'all love CRC16 questions.  Any help here would be hot.

[DailyDose]

Also, they asked for CRC16 ANSI.  Does this mean the polynomial they asked for is actually wrong?  The X5 should be removed?

[crossrulz]

As I have said before, there are many different ways to do a CRC.  It is best if you can get the source code from the client if possible.  Then you can figure out most of these issues.  The initial values I have seen are 0xFFFF and 0x0000.

Do you have any example data and corresponding CRC?  I can at least attempt to figure out the combination based on the common standards I have seen.

[crossrulz]

---

@DailyDose wrote:

Also, they asked for CRC16 ANSI.  Does this mean the polynomial they asked for is actually wrong?  The X5 should be removed?

---

Are they using two different CRCs?  It would not be the first time I have seen that done.

[DailyDose]

Answers to questions I am trying to acquire.  But I would not be wrong in asking for initial value?

[crossrulz]

---

@DailyDose wrote:

But I would not be wrong in asking for initial value?

---

Absolutely not.  That is a key parameter.  Another variation I see a lot is whether or not to invert the result.

Again, code will tell you everything.  It is also a requirement to have example data to test your code with.

[DailyDose]

Here's an actual technical question:

Attached is a CRC16 code I found online and I have added comments to but is still true to original (outside of changing U16 constants to LV2015) and one thing I noticed was that the U8 Array was changed to U16 but not typecasted to U16.  Why not?  Code is in LV2015SP1

[crossrulz]

---

@DailyDose wrote:

Here's an actual technical question:

Attached is a CRC16 code I found online and I have added comments to but is still true to original (outside of changing U16 constants to LV2015) and one thing I noticed was that the U8 Array was changed to U16 but not typecasted to U16.  Why not?  Code is in LV2015SP1

---

Type Cast would take 2 bytes and turn them into a U16.  What is happening here is that each byte is turned into a U16.  So the upper byte is just 0x00.  This allows for the upper byte of the CRC to be unchanged during the XOR.  That is just the way some CRC algorthms work.

Have I stated that I have seen a lot of ways that a CRC is performed?

[DailyDose]

---

@crossrulz wrote:

Have I stated that I have seen a lot of ways that a CRC is performed?

---

Yeah, you mentioned that somewhere.  

I guess I'll just smile and nod and accept that there are people much smarter than I who know what they're doing.

[DailyDose]

Ok, so...

I am getting a value using the VI I attached that is not matching that of the client's.  I found another CRC16 VI to compare to and they were both written similarly.  But the second VI confirmed my final CRC.  The client is currently looking through their code to verify.  So I continued to verify my end.  I have found several online CRC16 calculators that will take the HEX data and output a value.  I have not been able to find anything to match what I get.  Any chance you could look at it real quick and give it a thumbs up or down (you know, seeing as how you've seen many a CRC16 written )?  I verified the initial value with the client to be 0xFFFF.