CRC-15:

If you are serious about actually using data read from the bus or want to transmit your own packets then you will want to be able to calculate the frame check sequence. The sequence used is is a 15 bit Cyclic Redundancy Check which gives modulus 2 division of the data by the polynomial x¹⁵+x¹¹+x¹⁰+x⁹+x⁸+x⁷+x⁴+x³+x²+1. Wikipedia et.al. have plenty of generic information on the implimentation of CRCs so I won't cover that here.

The Vehicle area network (VAN) standard (ISO 11519-3-1994) contains the basic information required to generate and check these sequences but like most other mentions of CRC-15 online is rather light on the detail.

Overview

Let's take a nice short example packet to look at (in hex) 5E 4C 20 FF F9 34

The detail of this data string is covered here but for the sake of this explanation let's just say the first 4 bytes are the data and the last 2 bytes are the frame check sequence (CRC)

Encoding to create CRC

1. Preset the CRC result by setting all bits high (0x3FFF)
2. Shift each bit of the four bytes, most significant bit first in to the CRC register
3. once all data has been shifted in, invert every bit (perform a bitwise XOR with 0x3FFF)
4. multiply the result by 2 (left shift by 1 bit)

The preset of the CRC register and the final XOR are standard CRC operations, the multiply on the end is the tricky bit that isn't explicitly mentioned anywhere. The reason for it is in a hardware implimentation the 15 bit CRC is sent on the line MSB first following the data but data on VAN bus is sent in 4 byte chunks. The remaining bit on the end is used as the end of data delimiter and reads a zero. Hence when working on most software systems this data is generally interpreted as 16 bits but in this case the unused bit is at the least significant end rather than the most significant end.

Checking at reception

Of course now you know how to calculate the CRC directly you could just recieve all the data, then calculate a CRC for all but the last two bytes of the CRC and compare your result with the one that arrived. The trouble with this method is that generally you'll have to get to the end of data marker before you know how many bytes to calculate the CRC over without accidentally including the CRC bytes. The standard does however provide for on the fly hardware checking of CRC's which can be implimented in software to reduce the time between end of data marker reception and knowing if the data is good or bad, this is crucial when you've only got about 16us in which to decide if you're going to acknowledge error free reception of the frame of data.

The standard says preset the CRC register with all ones as before, read your data in putting each bit into the CRC as it arrives, when the end of data marker arrives the data in your CRC register should equal the constant result 0x4B15 if the sum is correct!

I initially had some dificulty in matching this value until I realised that I was putting all 16 bits of the recieved checksum into the CRC, assuming your LSB on the end of the CRC is zero then this gives 0x19B7 instead. Which value you want to match at the end all depends on your implimentation of end of data detection and when you send data to the CRC register.