Exact match. Not showing close matches.
PICList
Thread
'[EE]:reverse CRC algorithm ?'
2006\04\14@054049
by
Mike Harrison

I'm looking at a CRC algorithm for an RFID application. This is for read/write tags so I'm not
constrained to any particular algorithm.
I'll admit that I don't understand the maths behind CRCs, but can handle the idea of the
shiftregister/xor process if someone tells me the XOR values to use....
I'm currently using the 'conventional' method of :
Send : Generate 16 bit CRC of data packet, and append it to the end of the packet.
Receive : Run the received data packet (excluding the CRC) through the CRC algorithm, and check that
the result is the same as the CRC at the end of the packet.
However I'm sure I've seen a different method which simplifies the checking at the decoder end:
Send : Generate a 16 bit CRC of the data packet and append it.
Receive : Run the received data, _including_ the CRC through the 'reverse' algorithm , and check
that the CRC result is a constant (e.g. 0000 or FFFF)
i.e the initial CRC value is calculated such that the CRC of all the data _including the calculated
CRC_ is a constant.
I have a very vague recollection that this latter method is used in CD Audio for the subcode info
for track numbering etc.
What I'm looking for are the algorithms for generating and checking the CRC, expressed in terms of
XORs/Shifts, not scary mathematical things like polynomials which make my head hurt....
2006\04\14@061537
by
Wouter van Ooijen
2006\04\14@062243
by
Ruben Jönsson

Perhaps this appnote from Dallas/Maxim might help. It is about CRC checks and
algorithms for the 1wire devices:
<http://www.maximic.com/appnotes.cfm/appnote_number/27>
Regards / Ruben
{Quote hidden}> I'm looking at a CRC algorithm for an RFID application. This is for read/write tags so I'm not
> constrained to any particular algorithm.
>
> I'll admit that I don't understand the maths behind CRCs, but can handle the idea of the
> shiftregister/xor process if someone tells me the XOR values to use....
>
> I'm currently using the 'conventional' method of :
>
> Send : Generate 16 bit CRC of data packet, and append it to the end of the packet.
> Receive : Run the received data packet (excluding the CRC) through the CRC algorithm, and check that
> the result is the same as the CRC at the end of the packet.
>
> However I'm sure I've seen a different method which simplifies the checking at the decoder end:
> Send : Generate a 16 bit CRC of the data packet and append it.
> Receive : Run the received data, _including_ the CRC through the 'reverse' algorithm , and check
> that the CRC result is a constant (e.g. 0000 or FFFF)
>
> i.e the initial CRC value is calculated such that the CRC of all the data _including the calculated
> CRC_ is a constant.
>
> I have a very vague recollection that this latter method is used in CD Audio for the subcode info
> for track numbering etc.
>
> What I'm looking for are the algorithms for generating and checking the CRC, expressed in terms of
> XORs/Shifts, not scary mathematical things like polynomials which make my head hurt....
>
>
>
>
>
> 
2006\04\14@075953
by
olin piclist
Mike Harrison wrote:
> However I'm sure I've seen a different method which simplifies the
> checking at the decoder end: Send : Generate a 16 bit CRC of the data
> packet and append it.
> Receive : Run the received data, _including_ the CRC through the
> 'reverse' algorithm , and check that the CRC result is a constant (e.g.
> 0000 or FFFF)
To do that the sender has to run the CRC algorithm on an additional 16 zero
bits after all the data bits. The receiver runs the CRC algorithm on the
data bits plus the 16 CRC bits and the result will be 0 if all bits were
received correctly. This is a good approach if you want the receiver as
simple as possible at the expense of a little more complexity in the
transmitter.
2006\04\14@083301
by
Peiserma

piclistbounces@MIT.EDU wrote:
> Mike Harrison wrote:
>> However I'm sure I've seen a different method which simplifies the
>> checking at the decoder end: Send : Generate a 16 bit CRC of the
>> data packet and append it. Receive : Run the received data,
>> _including_ the CRC through the 'reverse' algorithm , and check that
>> the CRC result is a constant (e.g. 0000 or FFFF)
>
I've used the following (Hi Tech 'C') but you should be able to easily
port it to assembly
// found at http://www.eagleairaust.com.au/sampcode.htm
// Update the CRC for transmitted and received data using
// the CCITT 16bit algorithm (X^16 + X^12 + X^5 + 1).
unsigned char ser_data;
static unsigned int crc;
crc = (unsigned char)(crc >> 8)  (crc << 8);
crc ^= ser_data;
crc ^= (unsigned char)(crc & 0xff) >> 4;
crc ^= (crc << 8) << 4;
crc ^= ((crc & 0xff) << 4) << 1;
The receiver runs the same algorithm on all the received data and the
result should be zero. Be sure to initialize the <unsigned chat crc>
variable to zero at the start.
2006\04\14@094250
by
Mike Harrison

On Fri, 14 Apr 2006 08:02:05 0400, you wrote:
>Mike Harrison wrote:
>> However I'm sure I've seen a different method which simplifies the
>> checking at the decoder end: Send : Generate a 16 bit CRC of the data
>> packet and append it.
>> Receive : Run the received data, _including_ the CRC through the
>> 'reverse' algorithm , and check that the CRC result is a constant (e.g.
>> 0000 or FFFF)
>
>To do that the sender has to run the CRC algorithm on an additional 16 zero
>bits after all the data bits. The receiver runs the CRC algorithm on the
>data bits plus the 16 CRC bits and the result will be 0 if all bits were
>received correctly. This is a good approach if you want the receiver as
>simple as possible at the expense of a little more complexity in the
>transmitter.
Am I understanding correctly, given data d0..3 :
C1 = CRC(d0 d1 d2 d3 00 00)
CRC (d0 d1 d2 d3 C1lo C1hi) = constant ?
Can't seem get this to work  is the sending and receiving CRC algorithm the same ?
do you have an example algorithm this works with ?
More... (looser matching)
 Last day of these posts
 In 2006
, 2007 only
 Today
 New search...