ELM327P datasheet(43/76 Pages) ELM

43 / 76 page

Multiline Responses (continued)

ELM327

43 of 76

ELM327DSH

Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

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:

>01 00

41 00 BE 3E B8 11

41 00 80 10 80 00

This is difficult to decipher without knowing a little

more information. First, turn the headers on to actually

see ‘who’ is doing the talking:

>AT H1

>01 00

48 6B 10 41 00 BE 3E B8 11 FA

48 6B 18 41 00 80 10 80 00 C0

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.

A final example shows how similar messages

might occasionally be ‘mixed up’ in a CAN system. We

ask the vehicle for the Calibration ID (09 04) and are

presented with the following response:

>09 04

013

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

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

following group is 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:

>AT H1

>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

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

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.

Each OBD standard has some minor peculiarities,

but hopefully this has helped you with some of the

more common ones. If you are still having trouble, we

urge you to purchase the relevant standard, and study

it.

ELM327P Datasheet(PDF) 43 Page - ELM Electronics

ELM327P Datasheet(HTML) 43 Page - ELM Electronics

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

Datasheet Download

Link URL