ELM329
Multiline Responses
There are occasions when a vehicle must respond
following VIN for the vehicle:
with more information than is able to fit in a single
‘message’. In these cases, it responds with several
data frames which the receiver must assemble into
one complete response. The following shows how this
is done with the ISO 15765-4 protocol.
Consider a request for the vehicle identification
number, or VIN. This is available from newer vehicles
using a mode 09, PID 02 request (but was not initially
an OBD requirement, so may not be supported by your
vehicle). Here is a typical response that the ELM329
might show:
1 D 4 G P 0 0 R 5 5 B 1 2 3 4 5 6
From this example, you can see that the format of
the data received may not always be obvious. For this
reason, a copy of the SAE J1979 (ISO 15031-5)
standard would be essential if you are planning to do a
lot of work with this, for example if you were writing
software to display the received data.
The next example shows how similar messages
might occasionally be ‘mixed up’ in a CAN system. We
ask the vehicle for Calibration ID #1 with an 09 04
request and receive the following response:
>0902
014
>09 04
013
0: 49 02 01 31 44 34
1: 47 50 30 30 52 35 35
2: 42 31 32 33 34 35 36
0: 49 04 01 35 36 30
1: 32 38 39 34 39 41 43
013
0: 49 04 01 35 36 30
2: 00 00 00 00 00 00 31
1: 32 38 39 35 34 41 43
2: 00 00 00 00 00 00 00
The CAN Formatting has been left on (the default),
making the reading of the data easier. With formatting
on, the lines begin with a sequence number and then a
colon (‘:’) to separate it from the data bytes. CAN
systems add this single hex digit (it goes from 0 to F
then repeats), to provide an aid for reassembling the
data.
The first line of this response says that there are
014 bytes of information in total. That is 14 in hex, or
20 in decimal, which agrees with the 6 + 7 + 7 bytes
shown on the three lines. The VIN numbers are
generally 17 digits long, however, so how do we
assemble the VIN from 20 digits?
Looking at the first three bytes of the response,
you can see that the first two are the familiar 49 02, as
this is a response to an 09 02 request. They can be
ignored. The third byte (the ‘01’), tells the number of
data items that are to follow (the vehicle can only have
one VIN), and it is not part of the VIN. Eliminating the
first three bytes then leaves 17 data bytes which may
be used to form the vehicle identification (serial)
number. To do this requires first assembling the 17
data bytes in order:
which is quite confusing. The first group (the 013, 0:, 1:
group) seems to make some sense (but the number of
data bytes do not agree with the response), and the
remaining data is also very confusing, as it has two
segment twos. It seems that two ECUs are responding
and the information is getting mixed up. Which ECU do
the responses belong to? The only way to know is to
turn on the headers, and repeat your request. Turning
the headers on, is simply a matter of sending H1:
>AT H1
OK
Then you can repeat the request:
>09 04
7E8 10 13 49 04 01 35 36 30
7E8 21 32 38 39 34 39 41 43
7E9 10 13 49 04 01 35 36 30
7E8 22 00 00 00 00 00 00 31
7E9 21 32 38 39 35 34 41 43
7E9 22 00 00 00 00 00 00 00
31 44 34 47 50 30 30 52 35 35 42 31
32 33 34 35 36
The above data values actually represent the
ASCII codes for all the characters of the VIN, so the
final step is to convert those codes into the actual
characters that they represent. ASCII tables are freely
available on the web, and may be used to yield the
This time, the order appears to be the same, but
be aware that it may not be – that is why the standard
requires that sequence codes be transmitted with
ELM329DSB
Elm Electronics – Circuits for the Hobbyist
www.elmelectronics.com
37 of 76
ELM [ ELM ELECTRONICS ]
