CRC-15: [VAN Intro
[USB VAN Monitor
[Pioneer Headunit Control
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 VAN Line Protocol
Redundancy Check which gives modulus 2 division of the data by the IVAN Frame Check Sequence|
polynomial x!54x!1+x104x94x84x7444x34x7+1, Wikipedia et.al IVAN Bus Packets
have plenty of generic information on the implimentation of CRCs so
4
T won't cover that here, CRC Check
The Vehicle area network (VAN) standard (ISO 11519-3-1994) Data:
contains the basic information required to generate and check these 5 4C 20 FF
sequences but like most other mentions of CRC-15 online is rather Po
light on the detail J
Result:
Overview (OxF934 (4 data byte input)
generate CRC! || check frame CRC!
Let's take a nice short example packet to look at (in hex) 5€ 4c 20 FF
F934
|
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 la
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 iscrucial 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!
1 initially had some dificulty in matching this value until I realised that
T 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.
Author: Graham Auld
Dated: 27th November 2011