ELM327P datasheet(25/51 Pages) ELM

25 / 51 page

OBD Message Formats

To this point we have only discussed the contents

(data portion) of an OBD message, and made only

passing mention of other parts such as headers and

checksums, which all messages use to some extent.

On Board Diagnostics systems are designed to be

very flexible, providing a means for several devices to

communicate with one another. In order for messages

to be sent between devices, it is necessary to add

information describing the type of information being

sent, the device that it is being sent to, and perhaps

which device is doing the sending. Additionally, the

importance of the message becomes a concern as

well – crankshaft position information is certainly of

considerably more importance to a running engine

than a request for the number of trouble codes stored.

So to convey importance, messages are also assigned

a priority.

The

information

describing

the

priority,

the

intended recipient, and the transmitter are usually

needed by the recipient even before they know the

type of request that the message contains. To ensure

that this information is obtained first, OBD systems

transmit it at the start (or head) of the message. Since

these bytes are at the head, they are usually referred

to as header bytes. Figure 3 below shows a typical

OBD

message

structure

that

used

the

SAE J1850, ISO 9141-2, and ISO 14230-4 standards.

It uses 3 header bytes as shown, to provide details

concerning

the

priority,

the

receiver,

and

the

25 of 51

ELM327

ELM327DSC

Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

transmitter. Note that many texts refer to the receiver

as the “Target Address” (TA), and the transmitter as

the “Source Address” (SA).

Another concern when sending any message is

that errors might occur, and the received data may be

falsely interpreted. To detect errors, the various

protocols all provide some form of check on the

received data, often as simple as a sum calculation (a

‘running total’ is maintained by the receiver as a

message is being processed). This is compared to the

‘running total’ sent by the transmitter, and if they do

not agree, an error has occured. The total is generally

referred to as a ‘checksum’ or a ‘CRC byte’ and is

usually sent at the end of a message. If an error is

detected, the different protocols provide various ways

of handling it.

The

OBD

data

bytes

are

thus

normally

encapsulated within a message, with ‘header’ bytes at

the beginning, and a ‘checksum’ at the end. The

J1850, ISO 9141-2, and ISO 14230-4 protocols all use

essentially the same structure, with three header

bytes, a maximum of seven data bytes and one

checksum byte, as shown in Figure 3 below.

The ISO 15765-4 (CAN) protocol uses a very

similar structure, the main difference really only

relating to the structure of the header. CAN header

bytes are not referred to as that – they are called ‘ID

bits’ instead. The initial CAN standard defined the ID

bits as being 11 in number, and the more recent CAN

Figure 3. An OBD Message

Figure 4. A CAN OBD Message

ID bits (11 or 29)

7 data bytes

checksum

PCI

up to 7 data bytes

checksum

3 header bytes

priority

receiver

transmitter

ELM327P датащи(PDF) 25 Page - ELM Electronics

ELM327P датащи(HTML) 25 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

датащи скачать

ссылки URL