ELM327
Multiline Responses
There are occasions when a vehicle must respond
the data, instead of the byte value that the J1850
vehicle did.
with more information than one ‘message’ is able to
show. In these cases, it responds with several lines
which the receiver must assemble into one complete
message.
One example of this is a request for the 17 digit
vehicle identification number, or VIN. This is available
from newer vehicles using a mode 09, PID 02 request
(but was not initially a requirement, so many older
vehicles do not support it). Here is one example of a
response that might be obtained from a J1850 vehicle:
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 terms, 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 number from 20 digits?
This is done by discarding the first three bytes of
the message. The first two are the familiar 49 02, as
this is a response to an 09 02 request, so are not part
of the VIN. The third byte (the ‘01’), tells the number of
data items that are to follow (the vehicle can only have
one VIN, and this agrees with that). Ignoring the third
byte leaves 17 data bytes which are the serial number
(purposely chosen to be identical to the those of the
previous example). All that is needed is a conversion
to ASCII, in order to read them, exactly as before.
From these two examples, you can see that the
format of the data received may depend on the
protocol used to transmit it. For this reason, a copy of
the SAE J1979 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 following shows an example of a different type
of multiline response that can occur when two or more
ECUs respond to one request. Here is a typical
response to an 01 00 request:
>0902
49 02 01 00 00 00 31
49 02 02 44 34 47 50
49 02 03 30 30 52 35
49 02 04 35 42 31 32
49 02 05 33 34 35 36
The first two bytes (49 and 02) on each line of the
response are used to show that the information is in
reply to an 09 02 request. The next byte shows which
response it is, while the remaining four bytes are the
data bytes that are being sent. Assembling the data in
the order specified by the third byte, and ignoring the
first few 00’s (they are filler bytes - see J1979) gives:
31 44 34 47 50 30 30 52 35 35 42 31
32 33 34 35 36
>01 00
41 00 BE 3E B8 11
41 00 80 10 80 00
The data values actually represent the ASCII
codes for the digits of the VIN. Using an ASCII table to
convert these into characters gives the following VIN
for the vehicle:
This is difficult to decipher without knowing a little
more information. First, turn the headers on to actually
see ‘who’ is doing the talking:
1 D 4 G P 0 0 R 5 5 B 1 2 3 4 5 6
CAN systems will display this information in a
somewhat different fashion. Here is a typical response
from a CAN vehicle:
>AT H1
OK
>01 00
>0902
48 6B 10 41 00 BE 3E B8 11 FA
48 6B 18 41 00 80 10 80 00 C0
014
0: 49 02 01 31 44 34
1: 47 50 30 30 52 35 35
2: 42 31 32 33 34 35 36
Now, if you analyze the header, you can see that
the third byte shows ECU 10 (the engine controller)
and ECU 18 (the transmission) are both responding
with a reply to the 01 00 request. With modern
vehicles, this type of response occurs often, and you
should be prepared for it.
The CAN Formatting has been left on (the default),
making the reading of the data easier. With formatting
on, the sequence numbers are shown with a colon (‘:’)
after each. CAN systems add this single hex digit (it
goes from 0 to F then repeats), to aid in reassembling
A final example shows how similar messages
ELM327DSI
Elm Electronics – Circuits for the Hobbyist
www.elmelectronics.com
44 of 82
ELM [ ELM ELECTRONICS ]
