| Author |
Message |
jhurley@avtecinc.com
New User
Joined: 06 May 2011
Posts: 2
|
| May 06, 2011 7:45 pm |
|
|
I have a protocol that is using CRC-6 (x^6 + x^5 + x^2 + x + 1) and the CRC values listed in the packet capture do not match with any of the online calculators.
Example:
26 bits of data + 6 bits CRC
c1 01 00 2e -> Can not get 2e for CRC
01 10 00 0f -> Can not get 0f for CRC
05 10 00 09 -> Can not get 09 for CRC
I would appreciate any suggestions.
Thanks. |
|
regregex
Preferred Member
Joined: 30 Oct 2007
Posts: 184
Location: London, UK
|
| May 08, 2011 4:43 pm |
|
|
Hello jhurley, welcome to the forum!
The set of messages is solved by the following Rocksoft model: | Code: | Name : (none)
Width : 6
Poly : 27
Init : 3F
RefIn : False
RefOut : False
XorOut : 00
Check : 0D |
Alternatively, here is a bitwise implementation in C: if the CRC is inserted in the last character of a message string the function will return zero instead. | Code: | #include <stdio.h>
char crc6(char *, size_t);
int main(int, char *[]);
char crc6(char *msg, size_t bits) {
int i = 0;
unsigned char crc = 0xfc;
while(bits--) {
if(!i--) {
i = 7;
crc ^= *msg++;
}
crc = crc << 1 ^ (crc & 0x80 ? 0x9c : 0);
}
return(crc >> 2 & 0x3f);
}
int main(int argc, char *argv[]) {
printf("%02x\n%02x\n%02x\n%02x\n",
(int) crc6("\xc1\x01\x00\x00",26),
(int) crc6("\x01\x10\x00\x00",26),
(int) crc6("\x05\x10\x00\x00",26),
(int) crc6("123456789", 72));
return(0);
} |
Thanks for specifying the polynomial as it has turned up a specification for a similar algorithm. The cdma2000 physical layer specification contains several CRC definitions but the bit ordering (RefIn, RefOut) is unclear and so the above model is not necessarily the same as in cdma2000.
Hope this helps.
Greg |
|
jhurley@avtecinc.com
New User
Joined: 06 May 2011
Posts: 2
|
| May 09, 2011 1:24 pm |
|
|
Thanks for the fast response and the information.
I had tried online calculators and even went through some hand calculations. It appears that the starting value was the key.
How did you come up with the inital value? Did you just left shift all "1s" left by 2. I see in your sample code that you right shift by two before you return the final value.
I have a couple other odd CRCs that I need to implement (CRC-12, CRC-15).
Again thanks for the help. |
|
regregex
Preferred Member
Joined: 30 Oct 2007
Posts: 184
Location: London, UK
|
| May 10, 2011 1:18 pm |
|
|
The constant 0xfc is indeed the initial value shifted left two places. This is a consequence of carrying out the calculation in the upper six bits of crc, which in turn allows each byte of the message to be XORed directly into crc.
Greg |
|
pidloop
Guest
|
| Dec 21, 2011 7:02 pm |
|
|
| Hello. I've been googling for crc info and found this great code snippet. I hope this thread is still open. My main problem is my message is 34 bits long, and all the code samples I've found assume the message is a whole number of bytes. I see this code is passed number of bits so it looks encouraging. My CRC is also 6 but the polynomial is just x^6 + x + 1. How would the code change for this? Thanks in advance for any info. Elwood Downey, Tucson AZ. |
|
regregex
Preferred Member
Joined: 30 Oct 2007
Posts: 184
Location: London, UK
|
| Dec 22, 2011 5:40 pm |
|
|
Hello Elwood, welcome to the forums!
For the polynomial you provide, the only change needed is to line 15, which should now read: | Code: | | crc = crc << 1 ^ (crc & 0x80 ? 0x0c : 0); |
If I'm right in guessing you're implementing G.704 or an identical algorithm, then the register must also be pre-cleared (line 8): | Code: | | unsigned char crc = 0x00; |
HTH.
Greg |
|
