39 of 83
ELM329
ELM329DSC
Elm Electronics – Circuits for the Hobbyist
www.elmelectronics.com
Multiline Responses (continued)
multiline responses.
Looking at the first digits of these responses, you
can see that some begin with 7E8, and some begin
with 7E9, which are the CAN IDs representing ECU#1
and ECU#2, respectively. Grouping the responses by
ECU gives:
7E8 10 13 49 04 01 35 36 30
7E8 21 32 38 39 34 39 41 43
7E8 22 00 00 00 00 00 00 31
and
7E9 10 13 49 04 01 35 36 30
7E9 21 32 38 39 35 34 41 43
7E9 22 00 00 00 00 00 00 00
From these, the messages can be assembled in
their proper order. To do this, look at the byte following
the CAN ID - it is what is known as the PCI byte, and
is used to tell what type of data follows. In this case,
the PCI byte begins with either a 1 (for a ‘First Frame’
message), or a 2 (for the ‘Consecutive Frames’). The
second half of the PCI byte shows the order in which
the information is to be assembled (ie. the segment
number). In this case, the segment numbers are
already in order, but if they had not been, it would
have been necessary to rearrange the messages to
place them in order. The actual data can then be
extracted from the remaining bytes in each line.
The information presented here was only meant to
provide an overview of how long messages are
handled by the ISO 15765 standard. If you do wish to
learn more about the actual mechanism, we urge you
to purchase a copy of the standard, and study it.
Multiple PID Requests
The SAE J1979 (ISO 15031-5) standard allows
requesting multiple PIDs with one message, but only if
you connect to the vehicle with CAN (ISO 15765-4).
Up to six parameters may be requested at once, and
the reply is one message that contains all the
responses.
For example, let us say that you need to know
engine load (04), engine coolant temperature (05),
manifold pressure (0B), and engine rpm (0C) on a
regular basis. You could send four separate requests
for them (01 04, then 01 05, then 01 0B, etc.) or you
could put them all into one message like this:
>01 04 05 0B 0C
to which, a typical reply might be:
00A
0: 41 04 3F 05 44 0B
1: 21 0C 17 B8 00 00 00
The reply is a multiline one, as was just discussed
in the previous section. Looking at the reply in detail,
the first line tells us that it is 00A (decimal 10) bytes
long, so we only pay attention to the first ten bytes of
the following lines (and ignore the final three 00’s on
the last line). The first byte is 41, which tells us that the
message is a response to an 01 request.
Following the 41 is the actual information, with the
PID numbers followed by their data bytes. You will
need to know how many data bytes to expect in order
to make sense of it in most cases.
The order in which you ask for the PIDs should not
matter. For example, the previous request might have
been sent as:
>01 0B 04 0C 05
00A
0: 41 0B 21 04 3F 0C
1: 17 B8 05 44 00 00 00
in which case, the responses might be as shown
above (but the order in which the PIDs appear in the
response does not have to match the order in which
they were requested).
Using this technique, you can make more efficient
use of the data bus. The cost is the extra work that you
must do in creating the requests, and in parsing each
response. If you are writing software to do this, the
time initially taken may well be worth it, but if you are
typing requests at a terminal screen, it is very unlikley
that this will be of benefit to you.