ELM327P datasheet(34/51 Pages) ELM

34 / 51 page

CAN Message Formats

The ISO 15765-4 (CAN) standard defines several

message types that are to be used with diagnostic

systems. Currently, there are four main ones that may

be used:

SF - the Single Frame

FF - the First Frame (of a multiframe message)

CF - the Consecutive Frame ( “

“ )

FC - the Flow Control frame

The Single Frame message contains storage for

up to seven data bytes and what is known as a PCI

(Protocol Control Information) byte. The PCI byte is

always the first byte of them all, and tells how many

data bytes are to follow. If the CAN Auto Formatting

option is on (CAF1) then the ELM327 will create this

byte for you when sending, and remove it for you when

receiving. (If the headers are enabled, you will always

see it.)

If you turn the Auto Formatting off (with CAF0), it

is expected that you will provide all of the data bytes to

be sent. For diagnostics systems, this means the PCI

byte and the data bytes. The ELM327 will not modify

your data in any way, except to add extra padding

bytes for you, to ensure that you always send a total of

eight data bytes (the data length is not adjustable with

this version of the ELM327). You do not need to set

the Allow Long (AT AL) option in order to do this, as

the IC overrides it for you.

A First Frame message is used to say that a

multiframe message is about to be sent, and tells the

receiver just how many data bytes to expect. The

length descripter is limited to 12 bits, so a maximum of

4095 byes can be received at once using this method.

Consecutive Frame messages are sent after the

First Frame message to provide the remainder of the

data. Each Consecutive Frame message includes a

single hex digit ‘sequence number’ that is used to

determine the order when reassembling the data. It is

expected that if a message were corrupted and resent,

it could be out of order by a few packets, but not by

more than 16, so the single digit is normally more than

adequate. As seen previously, the serial number for a

vehicle is often a multiframe response:

>0902

014

0: 49 02 01 31 44 34

1: 47 50 30 30 52 35 35

2: 42 31 32 33 34 35 36

In this example, the line that begins with 0: is the

First Frame message. The length (014) was actually

extracted from the message by the ELM327 and

printed on the separate line as shown. Following the

First Frame line are two Consecutive Frames as

shown (1: and 2:). To learn more details of the exact

formatting, you may want to send a request such as

the one above, then repeat the same request with the

headers enabled (AT H1). This will show the PCI bytes

that are actually used to send these components of the

total message.

The Flow Control frame is one that you do not

normally have to deal with. When a First Frame

message is sent as part of a reply, the ELM327 must

tell the sender some technical things (such as how

long to delay between Consecutive Frames, etc.) and

does so by replying immediately with a Flow Control

message. These are predefined by the ISO 15765-4

standard, so can be automatically inserted for you. If

you wish to generate custom Flow Control messages,

then refer to the next section.

Flow

Control

frame

detected

while

monitoring, the line will be displayed with ‘FC: ’ before

the data, to help you with decoding of the information.

There

final

type

message

that

occasionally reported, but is not supported by the

diagnostics standard. The (Bosch) CAN standard

allows for the transmission of a data request without

sending any data in the requesting message. To

ensure that the message is seen as such, the sender

also sets a special flag in the message (the RTR bit),

which is seen at each receiver. The ELM327 always

looks for this flag, or for zero data bytes, and may

report to you that an RTR was detected while

monitoring. This is shown by the characters RTR

where data would normally appear, but only if the CAN

Auto Formatting is off, or headers are enabled. Often,

when monitoring a CAN system with an incorrect baud

rate chosen, RTRs may be seen.

Note that the CAN system is quite robust with

several error detecting methods in place, so that

during normal data transmission you will rarely see

any errors. When monitoring buses however, you may

well see errors (especially if the ELM327 is set to an

incorrect baud rate). As a diagnostic aid, when errors

do occur, the ELM327 will print all bytes (no matter

what CAF, etc., is set to), followed by the message

‘<RX ERROR’.

ELM327

34 of 51

ELM327DSC

Elm Electronics – Circuits for the Hobbyist

ELM327P Datasheet(PDF) 34 Page - ELM Electronics

ELM327P Datasheet(HTML) 34 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

Datasheet Download

Link URL