34 of 83
ELM329
ELM329DSC
Elm Electronics – Circuits for the Hobbyist
www.elmelectronics.com
Figure 4. A CAN OBD Message
standards. It uses 3 header bytes as shown, to provide
details concerning the priority, the receiver, and the
transmitter. Note that many texts refer to the receiver
as the ‘Target Address’ (TA), and the transmitter as
the ‘Source Address’ (SA).
A concern when sending any message is that
errors might occur in the transmission, and the
received data may be falsely interpreted. To detect
errors, all of the protocols provide some form of check
on the received data. This may be as simple as a sum
calculation (ie a ‘running total’ of byte values) that is
sent at the end of a message. If the receiver also
calculates a sum as bytes are received, then the two
values can be compared and if they do not agree, the
receiver will know that an error has occurred. CAN
systems use a special kind of checksum called a
Cyclic Redundancy Check (or ‘CRC’).
The OBD data bytes are thus normally
encapsulated within a message, with ‘header’ bytes at
the beginning, and a ‘checksum’ at the end.
The ISO 15765-4 (CAN) protocol uses a message
structure that is very similar to that of Figure 3 - see
Figure 4, below. The main difference between the two
is really only the structure of the header, as CAN does
not have distinct bytes, but rather has groups of bits.
For this reason, CAN headers are generally known as
‘ID bits’ and not headers. We use the terms
interchangeably, however, as so many people are
familiar with our other OBD chips (the ELM320,
ELM322, ELM323 and ELM327) which use the term
OBD Message Formats (continued)
‘header’ almost exclusively.
The initial CAN standard stated that there will be
11 ID bits for every message, but that has been
expanded and the latest CAN standards now allow for
either 11 or 29 bit IDs.
The ELM329 does not normally show anything
more than the relevant data bytes unless you turn that
feature on with the Headers On command (AT H1).
Issuing it allows you to see the header bytes (ID bits),
and other items which are normally hidden such as the
PCI byte or possibly the data length code. The current
version of the ELM329 does not display the checksum
(CRC) information.
It is not necessary to ever have to set the header
bytes, or to perform a checksum calculation, as the
ELM329 will always do this for you. The header bytes
(ID bits) are adjustable however, should you wish to
experiment with advanced messages such as those
for physical addressing.
ID bits (11 or 29)
7 data bytes
checksum
PCI
data bytes (8 in total)
‘header’ bytes