meetanthony/crccsharp

All main CRC Algorithms on C#

crccsharp's Issues

Is that a bug?

I wrote my own version of CRC algorithm and experienced a problem when the Input string has an odd number of digits (I work with hexadecimal type of string). But when Input has an even number off charracters, my algorithm works well.
I tried a simple test and did the calculations by hand. The result points that maybe there is bug in algorithm of site http://crccalc.com/ (either I am not knowing how to calculate CRC yet) .

WHAT IS WORNG ? (Is its my test bellow or a bug?)

(Try to copy and paste lines bellow to a text editor with nomospaced fonts to easy view.)

Input String: C23
String Type: Hexadecinal characters
Input Bitstream: 0xC23

CRC version: CRC-8/CDMA2000

Polynomial: 0x9B
Init: 0xFF

Bitstream:
1100 0010 0011

Start of calculation process:

11000010001100000000             <:= Original Input bitstream plus excess remainder (0000 0000)

Xor 11111111 <:= Init (FF) <:= CRC Initial value Xored to first byte of bitstream and the rest of bitstream

---

00111101001100000000             <:= CRC Remainder and the rest of bitstream
..111101001   		     <:= shift 2 bits and include 3 bits from the rest of bitstream 

Xor..110011011 <:= Polynomial(9B)

---

...01110010100000000             <:= CRC Remainder and the rest of bitstream
....111001010   		     <:= shift 1 bit and include 2 bits from the rest of bitstream 
Xor 110011011    <:= Polynomial(9B) 
  ______________
.....010100010000000             <:= CRC Remainder and the rest of bitstream
......101000100                  <:= shift 1 bit and include 2 bits from the rest of bitstream 
  Xor 110011011    <:= Polynomial(9B) 
    ______________
.......1101111100000             <:= CRC Remainder and the rest of bitstream
.......110111110                 <:= NO shift but include 1 bit from the rest of bitstream 
   Xor 110011011    <:= Polynomial(9B) 
     ______________
........001001010000             <:= CRC Remainder and the rest of bitstream 
..........100101000              <:= shift 2 bits and include 3 bits from the rest of bitstream 
     Xor  110011011    <:= Polynomial(9B) 
       ______________
...........101100110             <:= CRC Remainder and the rest of bitstream 
...........101100110             <:= NO shift but include 1 bit from the rest of bitstream 
       Xor 110011011    <:= Polynomial(9B) 
         ______________
............11111101    <:= CRC = 0xFD    

Or using a different view approach:

Start of calculation process:

1100 0010  [0011 (0000 0000)]    <:= Original Input bitstream plus excess remainder (0000 0000)

Xor 1111 1111 <:= Init (FF) <:= CRC Initial value Xored to first byte of bitstream and the rest of bitstream

---

0011 1101  [0011 (0000 0000)]    <:= CRC Remainder and rest of bitstream
  1 1110 1001   		     <:= shift 2 bits and include 3 bits from the rest of bitstream 

Xor (1)1001 1011 <:= Polynomial(9B)
______________
0111 0010 [1 (0000 0000)] <:= CRC Remainder and rest of bitstream
1 1100 1010 <:= shift 1 bit and include 2 bits from the rest of bitstream
Xor (1)1001 1011 <:= Polynomial(9B)
______________
0101 0001 [000 0000] <:= CRC Remainder and rest of bitstream
1 0100 0100 <:= shift 1 bit and include 2 bits from the rest of bitstream
Xor (1)1001 1011 <:= Polynomial(9B)
______________
1101 1111 [0 0000] <:= CRC Remainder and rest of bitstream
1 1011 1110 <:= NO shift but include 1 bit from the rest of bitstream
Xor (1)1001 1011 <:= Polynomial(9B)
______________
0010 0101 [0000] <:= CRC Remainder and rest of bitstream
1 0010 1000 <:= shift 2 bits and include 3 bits from the rest of bitstream
Xor (1)1001 1011 <:= Polynomial(9B)
______________
1011 0011 [0] <:= CRC Remainder and rest of bitstream
1 0110 0110 <:= shift 2 bits and include 3 bits from the rest of bitstream
Xor (1)1001 1011 <:= Polynomial(9B)
______________
1111 1101 <:= CRC = 0xFD

Using BitConvert to determine Endian-ness of bytes

Would it be possible to establish the Endianness through a property established in the Crc class or the Parameters class?
Most of the CRC computations I perform are cross platform and setting a global .NET static class, BitConverter, can be problematic. I use BitConverter in numerous other libraries and when the Endianness is changed at the global level, it changes the Endianness through the application.

Can you provide some example?

I'm new to C#, can you provide some example? thanks
@meetanthony

What is the correct result to expect for zero length CRC checks ?

Sorry to raise this as an issue as it probably is not. I asked this question on stackoverflow : https://stackoverflow.com/questions/61385241/what-is-the-correct-crc-value-for-a-zero-length-check

Essentially I used you online tool which I like very much to check if my CRC functions are doing the correct thing. I am not CRC expert so I am not sure what is the correct result you should get for a check on a string which has zero length.

I hope you could post an informative comment.

Possible problem with endian-ness

I have compiled your DLL, and tested it:

crc = new CRC.Crc(CRC.CrcStdParams.StandartParameters[CRC.CrcAlgorithms.Crc16Arc]);

byte[] test = new byte[4] { 0x5e, 0x00, 0x06, 0x52 };
byte[] testcrc = crc.ComputeHash(test);

the correct CRC result 0xb591 is in array position 6 and 7.

uint16 crcResult = CRC.CrcHelper.ToUInt16(crc.ComputeHash(bytes));

Returns 0x0000

Probably as the value should be in array position 0 and 1, not 6 and 7.

Can you assist?

thanks

CRC-12/3GPP not pass the test

Hi,

Seems CRC-12/3GPP does not pass the test (CrcTest.cs).
Can you take a look?