Searching \ for '[EE]:reverse CRC algorithm ?' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/method/errors.htm?key=crc
Search entire site for: 'reverse CRC algorithm ?'.

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

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
shift-register/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 sub-code 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....

> 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....

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Perhaps this appnote from Dallas/Maxim might help. It is about CRC checks and
algorithms for the 1-wire devices:

<http://www.maxim-ic.com/appnotes.cfm/appnote_number/27>

Regards / Ruben

{Quote hidden}

> -
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.

piclist-bounces@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.

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...