ELM327P - ELM Technology - Datasheet.Directory

ELM327

Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

OBD to RS232 Interpreter

Almost all new automobiles produced today are

required, by law, to provide an interface from which

test equipment can obtain diagnostic information.

The data transfer on these interfaces follow several

standards, none of which are directly compatible

with PCs or PDAs. The ELM327 is designed to act

as a bridge between these On-Board Diagnostics

(OBD) ports and standard RS232 ports.

The ELM327 builds on improved versions of our

proven ELM320, ELM322, and ELM323 interfaces

by adding seven CAN protocols to them. The result

is an IC that can automatically sense and convert

the most common protocols in use today. There are

a number of other improvements as well – a high

speed RS232 option, battery voltage monitoring, and

customizable features through programmable

parameters, to name only a few.

The ELM327 requires few external components

to make a fully functioning circuit. The following

pages discuss the interface details, and show how to

use the IC to ‘talk’ to your vehicle, then concludes

with two schematics to get you started.

• Supports 12 protocols

• Automatically searches for a protocol

• Fully configurable with AT commands

• RS232 baud rates to 500Kbps

• Voltage input for battery monitoring

• Low power CMOS design

• Diagnostic trouble code readers

• Automotive scan tools

• Teaching aids

Description

Applications

Block Diagram

Features

ELM327DSC 1 of 51

Connection Diagram

PDIP and SOIC

(top view)

OBD Tx LED

OBD Rx LED

RS232 Tx LED

RS232 Rx LED

CAN Rx

CAN Tx

ISO L

ISO K

VDD

RS232 Rx

RS232 Tx

Busy

RTS

MCLR

Memory

Baud Rate

LFmode

J1850 Volts

XT1

XT2

VSS

ISO In

PWM In

J1850 Bus+

VPW In

J1850 Bus-

Vmeasure

VSS

4.00 MHz

XT1 XT2

Command

and

Protocol

Interpreter

RS232Tx

RS232Rx

LFmode

RS232

Interface

CAN

ISO 15765-4

SAE J1939* ISO 9141-2

ISO 14230-4 SAE J1850

PWM & VPW

A/D

Converter

Baud Rate

…

Memory

status LEDs OBD interfaces

Busy

MCLR Vmeasure

RTS

*some support

ELM327

Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Pin Descriptions

2 of 51

Every effort is made to verify the accuracy of information provided in this document, but no representation or warranty can be

given and no liability assumed by Elm Electronics with respect to the accuracy and/or use of any products or information

described in this document. Elm Electronics will not be responsible for any patent infringements arising from the use of these

products or information, and does not authorize or warrant the use of any Elm Electronics product in life support devices and/or

systems. Elm Electronics reserves the right to make changes to the device(s) described in this document in order to improve

reliability, function, or design.

MCLR (pin 1)

A momentary logic low applied to this input will reset

the IC. If unused, this pin should be connected to a

logic high (VDD) level.

Vmeasure (pin 2)

This analog input is used to measure a 0 to 5V

signal that is applied to it. Care must be taken to

prevent the voltage from going outside of the supply

levels of the ELM327, or damage may occur. If it is

not used, this pin should be tied to either VDD or VSS.

J1850 Volts (pin 3)

This output can be used to control a voltage supply

for the J1850 Bus+ output. The pin will output a logic

high level when a nominal 8V is required (for J1850

VPW), and will output a low level when 5V is needed

(as for J1850 PWM applications). If this switching

capability is not required for your application, this

output can be left open-circuited.

J1850 Bus+ (pin 4)

This active high output is used to drive the

J1850 Bus+ Line to an active level. Note that this

signal does not have to be used for the Bus- Line (as

was the case for the ELM320), since a separate

J1850 Bus- drive output is provided on pin 14.

Memory (pin 5)

This input controls the default state of the memory

option. If this pin is at a high level during power-up or

reset, the memory function will be enabled by

default. If it is at a low level, then the default will be

to have it disabled. Memory can always be enabled

or disabled with the AT M1 and AT M0 commands.

Baud Rate (pin 6)

This input controls the baud rate of the RS232

interface. If it is at a high level during power-up or

reset, the baud rate will be set to 38400 (or the

rate that has been set by PP 0C). If at a low level,

the baud rate will be 9600.

LFmode (pin 7)

This input is used to select the default linefeed

mode to be used after a power-up or system reset.

If it is at a high level, then by default messages

sent by the ELM327 will be terminated with both a

carriage return and a linefeed character. If it is at a

low level, lines will be terminated by a carriage

return only. This behaviour can always be modified

by issuing an AT L1 or AT L0 command (see the

section on AT Commands).

VSS (pins 8 and 19)

Circuit common must be connected to these pins.

XT1 (pin 9) and XT2 (pin 10)

A 4.000 MHz oscillator crystal is connected

between these two pins. Loading capacitors as

required by the crystal (typically 27pF each) will

also need to be connected between each of these

pins and circuit common (Vss).

Note that this device has not been configured for

operation with an external oscillator – it expects a

crystal to be connected to these pins. Use of an

external clock source is not recommended.

VPW In (pin 11)

This is the active high input for the J1850 VPW

data signal. When at rest (bus recessive) this pin

should be at a low logic level. This input has

Schmitt trigger waveshaping, so no special

amplification is required.

ELM327DSC

Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

ELM327

3 of 51

ELM327DSC

Ordering Information

These integrated circuits are 28 pin devices, available in either a 300 mil wide plastic (‘skinny’) DIP format or in a

300 mil SOIC surface mount type of package. To order, add the appropriate suffix to the part number:

300 mil 28 pin Plastic DIP..............................ELM327P 300 mil 28 pin SOIC....................................ELM327SM

ISO In (pin 12)

This is the active low input for the ISO 9141 and

ISO 14230 data signal. It is derived from the K Line,

and should be at a high logic level when at rest (bus

recessive). No special amplification is required, as

this input has Schmitt trigger waveshaping.

PWM In (pin 13)

This is the active low input for the J1850 PWM data

signal. It should normally be at a high level when at

rest (ie. bus recessive). This input has Schmitt

trigger waveshaping, so no special amplification is

required.

J1850 Bus- (pin 14)

This active high output is used to drive the J1850

Bus- Line to an active (dominant) level for J1850

PWM applications. If unused, this output can be left

open-circuited.

RTS (pin 15)

This active low “Request To Send” input can be used

to interrupt the OBD processing in order to send a

new command. Normally high, the line is brought low

for attention, and should remain so until the Busy

line (pin 16) indicates that the ELM327 is no longer

busy. This input has Schmitt trigger waveshaping.

Busy (pin 16)

This active high output shows the current state of the

ELM327. If it is at a low level, the processor is ready

to receive ASCII commands and characters, but if it

is at a high level, commands are being processed.

RS232Tx (pin 17)

This is the RS232 data transmit output. The signal

level is compatible with most interface ICs (output is

normally high), and there is sufficient current drive to

allow interfacing using only a PNP transistor, if

desired.

RS232Rx (pin 18)

This is the RS232 receive data input. The signal

level is compatible with most interface ICs (when at

idle, the level is normally high), but can be used with

other interfaces as well, since the input has Schmitt

trigger waveshaping.

VDD (pin 20)

This pin is the positive supply pin, and should always

be the most positive point in the circuit. Internal

circuitry connected to this pin is used to provide

power on reset of the microprocessor, so an external

reset signal is not required. Refer to the Electrical

Characteristics section for further information.

ISO K (pin 21) and ISO L (pin 22)

These are the active high output signals which are

used to drive the ISO 9141 and ISO 14230 buses to

an active (dominant) level. Many new vehicles do not

require the L Line – if yours does not, you can simply

leave pin 22 open-circuited.

CAN Tx (pin 23) and CAN Rx (pin 24)

These are the two CAN interface signals that must

be connected to a CAN transeiver IC for proper

operation. If you are connecting to an existing CAN

system, the integrity of the entire system might be

jeopardized if a proper interface is not used. See the

Example Applications section for more information.

RS232 Rx LED (pin 25), RS232 Tx LED (pin 26),

OBD Rx LED (pin 27) and OBD Tx LED (pin 28)

These four output pins are normally high, and are

driven to low levels when the ELM327 is transmitting

or receiving data. Current capability is suitable for

directly driving most LEDs through current limiting

resistors, or interfacing to other logic for status

reporting. If unused, these pins should be left open-

circuited.

Pin Descriptions (continued)

Electrical Characteristics

Absolute Maximum Ratings

Storage Temperature.......................-65°C to +150°C

Ambient Temperature with

Power Applied....................................-40°C to +85°C

Voltage on VDD with respect to VSS............0 to +7.5V

Voltage on any other pin with

respect to VSS........................... -0.3V to (VDD + 0.3V)

Note:

Stresses beyond those listed here will likely damage

the device. These values are given as a design

guideline only. The ability to operate to these levels

is neither inferred nor recommended.

Notes: 1. This integrated circuit is produced with one of Microchip Technology Inc.’s PIC18F2x8x family of devices as

the core embedded microcontroller. For further device specifications, and possibly clarification of those

given, please refer to the appropriate Microchip documentation (available at http://www.microchip.com/).

2. This spec must be met in order to ensure that a correct power on reset occurs. It is quite easily achieved

using most common types of supplies, but may be violated if one uses a slowly varying supply voltage, as

may be obtained through direct connection to solar cells or some charge pump circuits.

3. Device only. Does not include any load currents.

4. Pins 1, 11, 12, 13, 15 and 18 (only) have internal Schmitt trigger waveshaping circuitry. All other inputs use

standard CMOS circuitry.

5. The typical width of the Busy output pulse while the ELM327 interprets the command, measures the voltage,

scales it and then transmits the result of a mid-range measurement, with the RS232 rate at 38400 baud.

4 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

All values are for operation at 25°C and a 5V supply, unless otherwise noted. For further information, refer to note 1 below.

Characteristic Minimum Typical Maximum ConditionsUnits

Supply voltage, VDD 4.5 5.0 5.5 V

VDD rate of rise 0.05 V/ms

Average supply current, IDD 9 mA

Input threshold voltage 1.0 1.3 V

Output low voltage

Output high voltage

current (sink) = 10 mA

current (source) = 10 mA

see note 2

see note 5

see note 3

Schmitt trigger

input thresholds

Brown-out reset voltage 4.07 4.2 4.59 V

rising

falling

A/D conversion time 7 msec

all except Schmitt inputs

0.3

4.6

2.9

1.5

see note 4

1.0

4.0

5 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Communicating with the ELM327

The ELM327 expects to communicate with the

host through an RS232 serial connection. Modern

computers do not usually provide a physical

connection such as this, but there are several ways in

which a ‘virtual serial port’ can be created. The most

common devices are USB to RS232 adapters, but

there are several others such as ethernet to RS232

devices, or Bluetooth to serial adapters.

No matter how you physically connect to the

ELM327, you will need a way to send and receive

characters. To do this, the simplest method is to use

one of the many ‘terminal’ programs that are available

(HyperTerminal, ZTerm, etc.), to allow typing the

characters directly from your keyboard.

To use a terminal program, you will need to make

several settings. First, ensure that your software is set

to use the proper ‘COM’ port, and that you have

chosen the proper data rate - this will be either 9600

baud (if pin 6=0V at power up), or 38400 baud (if

PP 0C has not been changed). If you select the wrong

“COM” port, you will not be able to send or receive any

data. If you select the wrong data rate, the information

that you send and receive will be all garbled, and

unreadable by you or the ELM327. Don’t forget to also

set your connection for 8 data bits, no parity bits, and 1

stop bit, and to also set it for the proper “line end”

mode. All of the responses from the ELM327 are

terminated with a single carriage return character and,

optionally, a linefeed character (depending on your

settings).

Properly connected and powered, the ELM327 will

energize the four LED outputs in sequence (as a lamp

test) and will then send the message:

ELM327 v1.2

In addition to identifying the version of this IC,

receiving this string is a good way to confirm that the

computer connections and terminal software settings

are correct (however, at this point no communications

have taken place with the vehicle, so the state of that

connection is still unknown). The ‘>’ character that is

shown on the second line is the ELM327’s prompt

character. It indicates that the device is in the idle

state, ready to receive characters on the RS232 port.

Characters sent from the computer can either be

intended for the ELM327’s internal use, or for

reformatting and passing on to the vehicle. The

ELM327 can quickly determine where the received

characters are to be directed by analyzing the entire

string once the complete message has been received.

Commands for the ELM327’s internal use will always

begin with the characters ‘AT’, while OBD commands

for the vehicle are only allowed to contain the ASCII

codes for hexadecimal digits (0 to 9 and A to F).

Whether an ‘AT’ type internal command or a hex

string for the OBD bus, all messages to the ELM327

must be terminated with a carriage return character

(hex ‘0D’) before it will be acted upon. The one

exception is when an incomplete string is sent and no

carriage return appears. In this case, an internal timer

will automatically abort the incomplete message after

about 20 seconds, and the ELM327 will print a single

question mark (‘?’) to show that the input was not

understood (and was not acted upon).

Messages that are not understood by the ELM327

(syntax errors) will always be signalled by a single

question mark. These include incomplete messages,

incorrect AT commands, or invalid hexadecimal digit

strings, but are not an indication of whether or not the

message was understood by the vehicle. One must

keep in mind that the ELM327 is a protocol interpreter

that makes no attempt to assess the OBD messages

for validity – it only ensures that an even number of

hex digits were received, combined into bytes, then

sent out the OBD port, and it does not know if the

Overview

The following describes how to use the ELM327 to

obtain information from your vehicle.

We begin by discussing just how to “talk” to the IC

using a PC, then explain how to change options using

‘AT’ commands, and finally we show how to use the

ELM327 to obtain trouble codes (and reset them). For

the more advanced experimenters, there are also

sections on how to use some of the programmable

features of this product as well.

Using the ELM327 is not as daunting as it first

seems. Many users will never need to issue an ‘AT’

command, adjust timeouts, or change the headers. For

most, all that is required is a PC or a PDA with a

terminal program (such as HyperTerminal or ZTerm),

and knowledge of one or two OBD commands, which

we will provide in the following sections…

6 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Communicating with the ELM327 (continued)

AL [ Allow Long messages ]

The standard OBDII protocols restrict the number

of data bytes in a message to seven, which the

ELM327 normally does as well (for both send and

receive). If AL is selected, the ELM327 will allow long

sends (eight data bytes) and long receives (unlimited

in number). The default is AL off (and NL selected).

AR [ Automatically set the Receive address ]

Responses from the vehicle will be acknowledged

and displayed by the ELM327, if its internally stored

receive address matches the address that the

Several parameters within the ELM327 can be

adjusted in order to modify its behaviour. These do not

normally have to be changed before attempting to talk

to the vehicle, but occasionally the user may wish to

customize these settings – for example by turning the

character echo off, adjusting a timeout value, or

changing the header bytes. In order to do this, internal

‘AT’ commands must be issued.

Those familiar with PC modems will immediately

recognize AT commands as a standard way in which

modems are internally configured. The ELM327 uses

essentially the same method, always watching the

data sent by the PC, looking for messages that begin

with the character ‘A’ followed by the character ‘T’. If

found, the next characters will be interpreted as

internal configuration or ‘AT’ commands, and will be

executed upon receipt of a terminating carriage return

character. The ELM327 will usually reply with the

characters ‘OK’ on the successful completion of a

command, so the user knows that it has been

executed.

Some of the following commands allow passing

numbers as arguments in order to set the internal

values. These will always be hexadecimal numbers

which must generally be provided in pairs. The

hexadecimal conversion chart in the OBD Commands

section may prove useful if you wish to interpret the

values. Also, one should be aware that for the on/off

types of commands, the second character is the

number 1 or 0, the universal terms for on and off.

The following is a description of all of the AT

commands that are recognized by the current version

of the ELM327. Since there are many, a summary

page is provided after this section.

message is being sent to. With the auto receive mode

in effect, the value used for the receive address will be

chosen based on the current header bytes, and will

automatically be updated whenever the header bytes

are changed.

The value that is used for the receive address is

determined based on the contents of the first header

byte. If it shows that the message uses physical

addressing, the third header byte of the header is used

for the receive address, otherwise (for functional

addressing) the second header byte, increased in

value by 1, will be used. Auto Receive is turned on by

default, and is not used by the J1939 formatting.

AT Commands

message sent to the vehicle was in error.

While processing OBD commands, the ELM327

will continually monitor for an RTS input, or an RS232

input. Either one will interrupt the IC, quickly returning

control to the user, and possibly aborting any initiation,

etc. that was in progress. If you desire to interrupt the

ELM327, that’s fine, but for normal orderly data

transfer, users should always wait for either the prompt

character (‘>’ or hex 3E), or a low level on the Busy

output before beginning to send the next command.

Finally, it should be noted that the ELM327 is not

case-sensitive, so ‘ATZ’ is equivalent to ‘atz’, and to

‘AtZ’. Also, it ignores space characters and all control

characters (tab, linefeed, etc.) in the input, so they can

be inserted anywhere to improve readability. Another

feature is that sending only a single carriage return

character will always repeat the last command (making

it easier to request updates on dynamic data such as

engine rpm).

7 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

AT0, AT1 and AT2 [ Adaptive Timing control ]

When receiving responses from a vehicle, the

ELM327 has traditionally waited the time set by the

AT ST hh setting for a response. To ensure that the IC

would work with a wide variety of vehicles, the default

value was set to a conservative (slow) value. Although

it was adjustable, many people did not have the

equipment or experience to determine a better value.

The new Adaptive Timing feature will automatically

set the timeout value for you, based on the actual

response times that your vehicle is responding in. As

conditions such as bus loading, etc. change, the

algorithm learns from them, and makes appropriate

adjustments. Note that it always uses your AT ST hh

setting as a maximum setting, however. With this new

Adaptive Timing, sampling rates are often doubled or

tripled from those typically experienced with prior

versions.

There are three adaptive timing settings that are

available for use. By default, Adaptive Timing option 1

(AT1) is selected, and is the recommended setting.

AT0 is used to disable Adaptive timing (usually used

when experimenting), while AT2 is a more agressive

version of AT1 (the effect is more noticeable for very

slow connections – you may not see much difference

with faster OBD systems). The J1939 protocol does

not support Adaptive Timing – responses for J1939

use fixed timeouts as set in the standard.

BD [ perform an OBD Buffer Dump ]

All messages sent and received by the ELM327

are stored temporarily in a set of twelve memory

storage locations called the OBD Buffer. Occasionally,

it may be of use to view the contents of this buffer,

perhaps to see why an initiation failed, to see the

header bytes in the last message, or just to learn more

of the structure of OBD messages. You can ask at any

time for the contents of this buffer to be ‘dumped’

(printed) – when you do, the ELM327 sends a length

byte (representing the length of the message in the

buffer) followed by the contents of all twelve OBD

buffer locations.

The length byte represents the actual number of

bytes received, whether they fit into the OBD buffer or

not. This may be useful when viewing long data

streams (with AT AL), as the number accurately

represents the number of bytes received, mod 256.

Note that only the first twelve bytes received are

stored in the buffer.

BI [ Bypass the Initialization sequence ]

This command should be used with caution. It

allows an OBD protocol to be made active without

requiring any sort of initiation or handshaking to occur.

The initiation process is normally used to validate the

protocol, and without it, results may be difficult to

predict. It should not be used for routine OBD use, and

has only been provided to allow the construction of

ECU simulators and training demonstrators.

BRD hh [ try Baud Rate Divisor hh ]

This command is used to change the RS232 baud

rate divisor to the hex value provided by hh. The actual

baud rate (in kbps) will be 4000 divided by this divisor.

For example, a setting of 115.2kbps would require a

divisor of 4000/115.2 or 35. In hexadecimal notation,

35 is written as 23, so the actual command that needs

to be sent would be AT BRD 23.

Since the ELM327 may be able to operate at

much higher rates than some interfaces can support,

the BRD command allows requested rates to be tested

before they are committed to (with automatic fall-back

to the previous baud rate if there are problems). In

use, the command is sent to request a change in the

baud rate, and the ELM327 responds with the familiar

“OK”. After that, an internal timer begins waiting, to

ensure that the controlling computer has sufficient time

to change their baud rate to the new rate. The ELM327

then sends the poweron message at the new baud

rate, and begins waiting while the controlling computer

assesses what has been received. If the AT I message

was received without errors, the controlling computer

sends a carriage return character, and if received by

the ELM327, the rate will be retained. If the controlling

computer sees errors (or worse, nothing), it provides

no response, and switches back to the initial baud

rate. If the ELM327 times out after receiving no

response, or has received something that does not

appear to be a carriage return character, it will revert

back to the former baud rate. A more detailed

discussion of this entire process is provided in the

‘Using Higher RS232 Baud Rates’ section.

Any new baud rate that is set in this manner is

retained across calls to set defaults (AT D), and for

warm starts (AT WS), but will not survive a hardware

reset (a power off/on or a call to AT Z). If you are in the

habit of calling AT Z in your code, we advise using AT

WS instead.

8 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

BRT hh [ set Baud Rate Timeout to hh ]

This command allows the timeout used for the

Baud Rate handshake (AT BRD) to be varied. The

time delay is given by hh x 5.0 msec, where hh is a

hexadecimal value. The default value for this setting is

0F, providing 75msec. Note that a value of 00 does not

result in 0 msec - it provides the maximum time of 256

x 5.0 msec.

CAF0 and CAF1 [ CAN Auto Formatting off or on ]

These commands determine whether the ELM327

assists you with the formatting of the CAN data that is

sent and received. With CAN Automatic Formatting

enabled (CAF1), the IC will automatically generate

formatting (PCI) bytes for you when sending, and will

remove them when receiving. This means that you can

continue to issue OBD requests (01 00, etc.) as usual,

without regard to these extra bytes that the CAN

diagnostics systems require. With formatting on, the

trailing (unused) data bytes that are received in a

frame will be removed as well, and only the relevant

ones will be shown. Beginning with v1.2 of the

ELM327, lines with invalid PCI bytes are now ignored,

rather than showing them as ‘<DATA ERROR’s.

Occasionally, long (multi-frame) responses are

returned by the vehicle. To help you analyze these, the

Auto Formatting mode will extract the total data length

and print it on one line. Following this will be each

segment of the message, with the segment number (a

single hexadecimal digit) shown at the beginning of the

line with a colon (':') as a separator.

You may also see the characters 'FC: ' at the

beginning of a line (if you are experimenting). This

represents a Flow Control message that is sent in

response to a multi-line message. Flow Control

messages are automatically generated by the ELM327

in response to a “First Frame” reply, as long as the

CFC setting is on (it does not matter whether you have

selected the CAF1 or the CAF0 modes).

Another type of message – the RTR (or ‘Remote

Transfer Request’) – will be automatically hidden for

you when in the CAF1 mode, since they contain no

data. When auto formatting is off (CAF0), you will see

the characters 'RTR' printed when a remote transfer

request frame has been received.

Turning the CAN Automatic Formatting off (CAF0),

will cause the ELM327 to print all of the received data

bytes. No bytes will be hidden from you, and none will

be inserted for you. Similarly, when sending a data

request with formatting off, you must provide all of the

required data bytes exactly as they are to be sent –

the ELM327 will not perform any formatting for you

other than to add some trailing 'padding' bytes to

ensure that the required eight data bytes are sent. This

allows operation in systems that do not use PCI bytes

as ISO 15765-4 does.

Note that turning the display of headers on (with

AT H1) will override some of the CAF1 formatting of

the received data frames, so that the received bytes

will appear much like in the CAF0 mode (ie. as

received). It is only the printing of the received data

that will be affected when both CAF1 and H1 modes

are enabled, though; when sending data, the PCI byte

will still be created for you and padding bytes will still

be added. Auto Formatting on (CAF1) is the default

setting for the ELM327.

CF hhh [ set the CAN ID Filter to hhh ]

The CAN Filter works in conjunction with the CAN

Mask to determine what information is to be accepted

by the receiver. As each message is received, the

incoming CAN ID bits are compared to the CAN Filter

bits (when the mask bit is a ‘1’). If all of the relevant

bits match, the message will be accepted, and

processed by the ELM327, otherwise it will be

discarded. This three nibble version of the CAN Filter

command makes it a little easier to set filters with 11

bit ID CAN systems. Only the rightmost 11 bits of the

provided nibbles are used, and the most significant bit

is ignored. The data is actually stored as four bytes

internally however, with this command adding leading

zeros for the other bytes. See the CM command(s) for

more details.

CF hh hh hh hh [ set the CAN ID Filter to hhhhhhhh ]

This command allows all four bytes (actually 29

bits) of the CAN Filter to be set at once. The 3 most

significant bits will always be ignored, and can be

given any value. Note that this command can be used

to enter 11 bit ID filters as well, since they are stored in

the same locations internally (entering AT CF 00 00 0h

hh is exactly the same as entering the shorter AT CF

hhh command).

9 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

CFC0 and CFC1 [ CAN Flow Control off or on ]

The ISO 15765-4 protocol expects a “Flow

Control” message to always be sent in response to a

“First Frame” message. The ELM327 automatically

sends these, without any intervention by the user. If

experimenting with a non-OBD system, it may be

desirable to turn this automatic response off, and the

AT CFC0 command has been provided for that

purpose. The default setting is CFC1 - Flow Controls

on. Note that during monitoring (AT MA, MR, or MT),

there are never any Flow Controls sent no matter what

the CFC option is set to.

CM hhh [ set the CAN ID Mask to hhh ]

There can be a great many messages being

transmitted in a CAN system at any one time. In order

to limit what the ELM327 views, there needs to be a

system of filtering out the relevant ones from all the

others. This is accomplished by the filter, which works

in conjunction with the mask. A mask is a group of bits

that show the ELM327 which bits in the filter are

relevant, and which ones can be ignored. A ‘must

match’ condition is signaled by setting a mask bit to '1',

while a 'don't care' is signaled by setting a bit to '0'.

This three digit variation of the CM command is used

to provide mask values for 11 bit ID systems (the most

significant bit is always ignored).

Note that a common storage location is used

internally for the 29 bit and 11 bit masks, so an 11 bit

mask could conceivably be assigned with the next

command (CM hh hh hh hh), should you wish to do the

extra typing. The values are right justified, so you

would need to provide five leading zeros followed by

the three mask bytes.

CM hh hh hh hh [ set the CAN ID Mask to hhhhhhhh ]

This command is used to assign mask values for

29 bit ID systems. See the discussion under the

CM hhh command – it is essentially identical, except

for the length. Note that the three most significant bits

that you provide in the first digit will be ignored.

CP hh [ set CAN Priority bits to hh ]

This command is used to set the five most

significant bits in a 29 bit CAN ID word (the other 24

bits are set with the AT SH command). Some systems

use several of these bits to assign a priority value to

messages, which is how the command was named.

Any bits provided in excess of the five required will be

ignored, and not stored by the ELM327 (it only uses

the five least significant bits of this byte). The default

value for these priority bits is hex 18.

CS [ show the CAN Status ]

The CAN protocol requires that statistics be kept

regarding the number of transmit and receive errors

detected. If there should be a significant number of

them, the device can even go off-line in order not to

affect other data on the bus, should there be a

hardware or software fault. The AT CS command lets

you see both the Tx and the Rx error counts. If the

transmitter should be off (count >FF), you will see

‘OFF’ rather than a specific count.

CV dddd [ Calibrate the Voltage to dd.dd volts ]

The voltage reading that the ELM327 presents for

an AT RV reading can be calibrated with this

command. The argument (‘dddd’) must always be

provided as 4 digits, with no decimal point (it assumes

that a decimal place is between the second and the

third digits).

To use this calibration feature, simply use a meter

with sufficient accuracy to read the actual input

voltage. If, for example, the ELM327 consistently says

the voltage is 12.2V when you measure 11.99 volts,

simply issue AT CV 1199, and the device will

recalibrate itself for the provided voltage (it should then

read 12.0V due to roundoff). If you use a test voltage

that is less than 10 volts, don’t forget to add a leading

zero (that is, 9.02 volts should be entered as AT CV

0902).

D[ set all to Defaults ]

This command is used to set the options to their

default (or factory) settings, as when power is first

applied. The last stored protocol will be retrieved from

memory, and will become the current setting (possibly

closing other protocols that are active). Any settings

that the user had made for custom headers, filters, or

masks will be restored to their default values, and all

timer settings will also be restored to their defaults.

AT Commands (continued)

10 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

DM1 [ monitor for DM1s ]

The SAE J1939 Protocol broadcasts trouble codes

periodically as they are detected, using Diagnostic

Mode 1 (DM1) messages. This command sets the

ELM327 to continually monitor for this type of

message for you, following multi-segment transport

protocols as required. Note that a combination of

masks and filters could be set to provide a similar

output, but they would not allow multiline messages to

be detected. The DM1 command adds the extra logic

needed for multiline messages.

This command is only available when a CAN

Protocol (A, B, or C) has been selected for J1939

formatting. It returns an error if attempted under any

other conditions.

DP [ Describe the current Protocol ]

The ELM327 is capable of automatically

determining the appropriate OBD protocol to use for

each vehicle that it is connected to. When the IC

connects to a vehicle, however, it returns only the data

requested, and does not report the protocol found. The

DP command is used to determine the current protocol

that the ELM327 is selected for (even if not

connected). If the automatic option is also selected,

the protocol will show the word "AUTO" before it,

followed by the type. Note that the actual protocol

names are displayed, not the numbers used by the

protocol setting commands.

DPN [ Describe the Protocol by Number ]

This command is similar to the DP command, but

it returns a number which represents the current

protocol. If the automatic search function is also

enabled, the number will be preceded with the letter

‘A’. The number is the same one that is used with the

set protocol and test protocol commands.

E0 and E1 [ Echo off (0) or on(1) ]

These commands control whether or not

characters received on the RS232 port are

retransmitted (or echoed) back to the host computer.

To reduce traffic on the RS232 bus, users may wish to

turn echoing off by issuing ATE0. The default is E1 (or

echo on).

FC SM h [ Flow Control Set Mode to h ]

This command sets how the ELM327 responds to

First Frame messages when automatic Flow Control

responses are enabled. The single digit provided can

either be ‘0’ (the default) for fully automatic responses,

‘1’ for completely user defined responses, or ‘2’ for

user defined data bytes in the response. More

complete details and examples can be found in the

Altering Flow Control Messages section.

FC SH hhh [ Flow Control Set Header to… ]

The header (or more properly ‘CAN ID’) bytes

used for CAN Flow Control response messages can

be set using this command. Only the right-most 11 bits

of those provided will be used - the most significant bit

is always removed. This command currently only

affects Flow Control mode 1.

FC SH hhhhhhhh [ Flow Control Set Header to… ]

This command is used to set the header (or ‘CAN

ID’) bits for Flow Control responses with 29 bit CAN ID

systems. Since the 8 nibbles define 32 bits, only the

right-most 29 bits of those provided will be used - the

most significant three bits are always removed. This

command currently only affects Flow Control mode 1.

FC SD [1-5 bytes] [ Flow Control Set Data to… ]

The data bytes that are sent in a CAN Flow

Control message can be set with this command. The

current version of the software allows one to five data

bytes to be defined, with the remainder of the data

bytes in the message being automatically set to the

default CAN filler byte. Data provided with this

command is only used when Flow Control modes 1 or

2 have been enabled.

H0 and H1 [ Headers off (0) or on(1) ]

These commands control whether or not the

additional (header) bytes of information are shown in

the responses from the vehicle. These are normally

not shown by the ELM327, but can be turned on by

issuing the AT H1 command.

Turning the headers on actually shows more than

just the header bytes – you will see the complete

message as transmitted, including the check-digits and

11 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

PCI bytes, and possibly the CAN data length code

(DLC) if it has been enabled with PP 29. The current

version of this IC does not display the CAN CRC code,

nor the special J1850 IFR bytes (which some protocols

use to acknowledge receipt of a message).

I[ Identify yourself ]

Issuing this command causes the chip to identify

itself, by printing the startup product ID string (currently

“ELM327 v1.2”). Software can use this to determine

exactly which integrated circuit it is talking to, without

having to reset the IC.

IB 10 [set the ISO Baud rate to 10400 ]

This command restores the ISO 9141-2 and

ISO 14230-4 baud rates to the default value of 10400.

IB 96 [set the ISO Baud rate to 9600 ]

Several users have requested this command. It is

used to change the baud rate used for the ISO 9141-2

and ISO 14230-4 protocols (numbers 3, 4, and 5) to

9600 baud, while relaxing some of the requirements

for the initiation byte transfers. It may be useful for

experimenting with some vehicles. Normal 10,400

baud operation can be restored at any time by issuing

an IB 10 command.

IFR0, IFR1, and IFR2 [ IFR control ]

The SAE J1850 protocol allows for an In-Frame

Response (IFR) byte to be sent after each message,

usually to acknowledge the correct receipt of that

message. The ELM327 automatically generates and

sends this byte for you by default, but you can override

this behaviour with this command.

The AT IFR0 command will disable the sending of

all IFRs, no matter what the header bytes require.

AT IFR2 is the opposite - it will force an IFR byte to

always be sent, no matter what header bytes indicate.

The AT IFR1 command restores the response to

provide the automatic sending of IFRs, as determined

by the ‘K’ bit of the header byte. IFR1 is the default

setting of the ELM327.

IFR H and IFR S [ IFR from Header or Source ]

The value sent in the J1850 In-Frame Response

(IFR) byte is normally the same as the value sent as

the Source (or Tester) Address byte that was in the

header of the request. There may be occasions when

it is desireable to use some other value, however, and

this set of commands allows for this.

If you send AT IFR S, the ELM327 will use the

value defined as the Source Address (usually F1, but it

can be changed by PP 06), even if another value was

sent in the Header bytes. This is not what is normally

required, and caution should be used when using

AT IFR S. AT IFR H restores the sending of the IFR

bytes to those provided in the Header. AT IFR H is the

default setting.

IIA hh [ set the ISO Init Address to hh ]

The ISO 9141-2 and ISO 14230-4 standards state

that when beginning a session with an ECU, the

initiation sequence is to be directed to a specific

address ($33). If you wish to experiment by directing

the slow five baud sequence to another address, it is

done with this command. For example, if you prefer

that the initiation be performed with the ECU at

address $7A, then simply send:

>AT IIA 7A

and the ELM327 will use that address when called to

do so (protocols 3 or 4). The full eight bit value is used

exactly as provided – no changes are made to it (ie no

adding of parity bits, etc.)

Note that setting this value does not affect any

address values used in the header bytes, and that this

value is reset to to $33 whenever the defaults, or the

ELM327, are reset.

KW0 and KW1 [ Key Word checks off (0) or on (1) ]

The ELM327 looks for specific bytes (called Key

Words) to be sent to it during the ISO 9141-2 and

ISO14230-4 initiation sequences. If those bytes are

not found, the initiation is said to have failed (you

might see “UNABLE TO CONNECT” or perhaps “BUS

INIT: ...ERROR”). This may be because you are trying

to connect to a non-OBD compliant ECU, or perhaps

to an older one.

If you wish to experiment, but do not want the

ELM327 to check the values contained in the key

words, you can turn the checking off with:

>AT KW0

AT Commands (continued)

12 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

after which the IC will look for a response, but will not

look at the actual values of the bytes in the response.

This may allow a connection in an otherwise

‘impossible’ situation. Normal behaviour can be

returned with AT KW1, which is the default setting.

Caution should be used with this command, as

you are bypassing the checks that are normally

performed on the keyword bytes. The ELM327 sends

an acknowledgement to the ECU for these bytes, but

that is without considering what the bytes actually are.

You could be incorrectly activating an ISO 9141, or

KWP 2000 protocol, so should be very careful.

L0 and L1 [ Linefeeds off (0) or on(1) ]

This option controls the sending of linefeed

characters after each carriage return character. For

AT L1, linefeeds will be generated after every carriage

return character, and for AT L0, they will be off. Users

will generally wish to have this option on if using a

terminal program, but off if using a custom computer

interface (as the extra characters transmitted will only

serve to slow the communications down). The default

setting is determined by the voltage at pin 7 during

power on (or reset). If the level is high, then linefeeds

on will be the default; otherwise it will be linefeeds off.

M0 and M1 [ Memory off (0) or on(1) ]

The ELM327 has internal ‘non-volatile’ memory

that is capable of remembering the last protocol used,

even after the power is turned off. This can be

convenient if the IC is often used for one particular

protocol, as that will be the first one attempted when

next powered on. To enable this memory function, it is

necessary to either use an AT command to select the

M1 option, or to have chosen “memory on” as the

default power on mode (by connecting pin 5 of the

ELM327 to a high logic level).

When the memory function is enabled, each time

that the ELM327 finds a valid OBD protocol, that

protocol will be memorized (stored) and will become

the new default. If the memory function is not enabled,

protocols found during a session will not be

memorized, and the ELM327 will always start at power

up using the same (last saved) protocol.

If the ELM327 is to be used in an environment

where the protocol is constantly changing, it would

likely be best to turn the memory function off, and

issue an AT SP 0 command once. The SP 0 command

tells the ELM327 to always start in an 'Automatic'

protocol search mode, which is the most useful for an

unknown environment. ICs come from the factory set

to this mode. If, however, you have only one vehicle

that you regularly connect to, storing that vehicle’s

protocol as the default would make the most sense.

As mentioned, the default setting for the memory

function is determined by the voltage level at pin 5 at

power up (or system reset). If it is connected to a high

level (VDD), then the memory function will be on by

default. If pin 5 is connected to a low level, the

memory saving will be off by default.

MA [ Monitor All messages ]

Using this command places the ELM327 into a

bus monitoring mode, in which it displays all messages

as it sees them on the OBD bus. It remains a quiet

monitor on the bus, not sending In Frame Responses

for J1850 systems or Acknowledges for CAN systems.

This continues indefinitely until stopped by activity on

the RS232 input, or the RTS pin.

To stop the monitoring, one can send a single

character then wait for the ELM327 to respond with a

prompt character (‘>’). Alternatively, the RTS input can

be brought to a low level to interrupt the device as

well. Waiting for the prompt is necessary as the

response time is unpredictable, varying depending on

what the IC was doing when interrupted. If for instance

it is in the middle of printing a line, it will first complete

that line then return to the command state, issuing the

prompt character. If it were simply waiting for input, it

would return immediately. Note that the character

which stops the monitoring will always be discarded,

and will not affect subsequent commands.

MP hhhh [ Monitor for PGN hhhh ]

The AT MA, MR and MT commands are quite

useful for when you wish to monitor for a specific byte

in the header of a typical OBD message. For the SAE

J1939 Protocol, however, it is often desireable to

monitor for the multi-byte Parameter Group Numbers

(or PGNs), which can appear in either the header, or

the data bytes. The MP command is a special J1939

only command that is used to look for responses to a

particular PGN request, and follow any multi-segment

occurances of them.

Note that the MP command provides no means to

set the first two digits of the requested PGN, and they

AT Commands (continued)

13 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

are always assumed to be 00. For example, the DM2

PGN has an assigned value of 00FECB (see SAE

J1939-73). To monitor for all DM2 messages, you

would issue AT MP FECB, eliminating the 00, since

the ELM327 always assumes that the PGN is

preceeded by these two zeros.

This command is only available when a CAN

Protocol (A, B, or C) has been selected for SAE J1939

formatting. It returns an error if attempted under any

other conditions. Note also that this version of the

ELM327 only displays responses that match the

criteria, not the requests that are asking for the

information.

MR hh [ Monitor for Receiver hh ]

This command also places the IC in a bus

monitoring mode, displaying only messages that were

sent to the hex address given by hh. These are

messages which are found to have the value hh in the

second byte of a traditional three byte OBD header, in

bits 8 to 15 of a 29 bit CAN ID, or in bits 8 to 10 of an

11 bit CAN ID. Any single RS232 character aborts the

monitoring, as with the MA command.

MT hh [ Monitor for Transmitter hh ]

This command places the IC in a bus monitoring

mode, displaying only messages that were sent by the

transmitter at the hex address given by hh. These are

messages which are found to have that value in the

third byte of a traditional three byte OBD header, or in

bits 0 to 7 for CAN IDs. As with the MA and MR

monitoring modes, any RS232 activity (single

character) aborts the monitoring.

NL [ Normal Length messages ]

Setting the NL mode on forces all sends and

receives to be limited to the standard seven data bytes

in length, similar to the other ELM32x OBD ICs. To

allow longer messages, use the AL command.

Beginning with v1.2, the ELM327 does not require

a change to AL to allow longer message lengths for

the KWP protocols to be received (as determined by

the header length values). You can simply leave the IC

set to the default setting of NL, and all of the received

bytes will be shown.

PC [ Protocol Close ]

There may be occasions where it is desirable to

stop (deactivate) a protocol. Perhaps you are not using

the automatic protocol finding, and wish to manually

activate and deactivate protocols. Perhaps you wish to

stop the sending of idle (wakeup) messages, or have

another reason. The PC command is used in these

cases to force a protocol to close.

PP hh OFF [ turn Prog. Parameter hh OFF ]

This command disables Programmable Parameter

number hh. Any value assigned using the PP hh SV

command will no longer be used, and the factory

default setting will once again be in effect. The actual

time when the new value for this parameter becomes

effective is determined by its type. Refer to the

Programmable Parameters section for more

information on the types.

Note that ‘PP FF OFF’ is a special command that

disables all of the Programmable Parameters, as if you

had entered PP OFF for every possible one.

It is possible to alter some of the Programmable

Parameters so that it may be difficult, or even

impossible, to communicate with the ELM327. If this

occurs, there is a hardware means of resetting all of

the Programmable Parameters at once. Connect a

jumper from circuit common to pin 28, holding it there

while powering up the ELM327 circuit. Hold it in

position until you see the RS232 Receive LED begin to

flash (which indicates that all of the PPs have been

turned off). At this point, remove the jumper to allow

the IC to perform a normal startup. Note that a reset of

the PPs occurs quite quickly – if you are holding the

jumper on for more than a few seconds and do not see

the RS232 receive light flashing, remove the jumper

and try again – there may be a problem with your

connection. This feature is only available beginning

with v1.2, and is not a provided with any earlier

versions of the ELM327 IC.

PP hh ON [ turn Programmable Parameter hh ON ]

This command enables Programmable Parameter

number hh. Once enabled, any value assigned using

the PP hh SV command will be used where the factory

default value was before. Note that all programmable

parameter values are set to ‘FF’ at the factory, so

enabling a programmable parameter before assigning

14 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

a value to it might result in unexpected behaviour. The

actual time when the value for this parameter becomes

effective is determined by its type. Refer to the

Programmable Parameters section for more

information on the types.

Note that ‘PP FF ON’ is a special command that

enables all of the Programmable Parameters at the

same time.

PP xx SV yy [ Prog. Param. xx: Set the Value to yy ]

A value is assigned to a Programmable Parameter

using this command. The system will not be able to

use this new value until the Programmable Parameter

has been enabled, however.

PPS [ Programmable Parameter Summary ]

The complete range of current Programmable

Parameters are displayed with this command (even

those not yet implemented). Each is shown as a PP

value followed by a colon and the value that is

assigned to it. This is followed by a single digit – either

‘N’ or ‘F’ to show that it is ON (enabled), or OFF

(disabled), respectively. See the Programmable

Parameters section for a more complete discussion.

R0 and R1 [ Responses off (0) or on(1) ]

These commands control the ELM327’s automatic

display of responses. If responses have been turned

off, the IC will not wait for a reply from the vehicle after

sending a request, and will return immediately to wait

for the next RS232 command. This is useful if sending

commands blindly when using the IC for a non-OBD

network application, or simulating an ECU in a basic

learning environment. It is not recommended that this

option normally be used, however, as the vehicle may

have difficulty if it is expecting an acknowledgement

byte and never receives one. The default is R1, or

responses on.

RV [ Read the input Voltage ]

This initiaties the reading of the voltage present at

pin 2, and the conversion of it to a decimal voltage. By

default, it is assumed that the input is connected to the

voltage to be measured through a 47KΩ and 10KΩ

resistor divider (with the 10KΩ connected from pin 2 to

Vss), and that the ELM327 supply is a nominal 5V.

This will allow for the measurement of input voltages

up to about 28V, with an uncalibrated accuracy of

typically about 2%.

SH xx yy zz [ Set the Header to xx yy zz ]

This command allows the user to manually control

the values that are sent as the three header bytes in a

message. These bytes are normally assigned values

for you (and are not required to be adjusted), but there

may be occasions when it is desirable to change them

(particularly if experimenting with physical addressing).

The value of hex digits xx will be used for the first or

priority/type byte, yy will be used for the second or

receiver/target byte, and zz will be used for the third or

transmitter/source byte. These remain in effect until

set again, or until restored to their default values with

the D, WS, or Z commands.

This command is used to assign all header bytes,

whether they are for a J1850, ISO 9141, ISO 14230, or

a CAN system. The CAN systems will use these three

bytes to fill bits 0 to 23 of the ID word (for a 29 bit ID),

or will use only the rightmost 11 bits for an 11 bit CAN

ID. The additional 5 bits needed for a 29 bit system are

provided through the AT CP command (since they

rarely change).

If assigning header values for the KWP protocols

(4 and 5), care must be taken when setting the first

header byte (xx) value. The ELM327 will always insert

the number of data bytes for you, but how it is done

depends on the values that you assign to this byte. If

the second digit of this first header byte is anything

other than 0 (zero), the ELM327 assumes that you

wish to have the length value inserted in that first byte

when sending. In other words, providing a length value

in the first header byte tells the ELM327 that you wish

to use a traditional 3 byte header, where the length is

stored in the first byte of the header.

If you provide a value of 0 for that second digit of

the first header byte, the ELM327 will assume that you

wish that value to remain as 0, and that you want to

have a fourth header (length) byte inserted into the

message. This is contrary to the ISO 14230-4 OBD

standard, but is in use by many KWP2000 systems for

(non-OBD) data transfer, so may be useful when

experimenting. Support for 4 byte headers has only

been added with v1.2 of the ELM327 IC, and was not

supported in previous versions.

15 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

SH xyz [ Set the Header to 00 0x yz ]

Entering CAN 11 bit ID words (headers) normally

requires that extra leading zeros be added (eg. AT SH

00 07 DF), but this command simplifies doing so. The

AT SH xyz command accepts a three digit argument,

takes only the right-most 11 bits from that, adds

leading zeros, and stores the result in the header

storage locations for you. As an example, AT SH 7DF

is a valid command, and is quite useful for working

with 11 bit CAN systems. It actually results in the

header bytes being internally stored as 00 07 DF.

SP h [ Set Protocol to h ]

This command is used to set the ELM327 for

operation using the protocol specified by 'h', and to

also save it as the new default. Note that the protocol

will be saved no matter what the AT M0/M1 setting is.

The currently valid protocols are:

0 - Automatic

1 - SAE J1850 PWM (41.6 Kbaud)

2 - SAE J1850 VPW (10.4 Kbaud)

3 - ISO 9141-2 (5 baud init, 10.4 Kbaud)

4 - ISO 14230-4 KWP (5 baud init, 10.4 Kbaud)

5 - ISO 14230-4 KWP (fast init, 10.4 Kbaud)

6 - ISO 15765-4 CAN (11 bit ID, 500 Kbaud)

7 - ISO 15765-4 CAN (29 bit ID, 500 Kbaud)

8 - ISO 15765-4 CAN (11 bit ID, 250 Kbaud)

9 - ISO 15765-4 CAN (29 bit ID, 250 Kbaud)

A - SAE J1939 CAN (29 bit ID, 250* Kbaud)

B - USER1 CAN (11* bit ID, 125* Kbaud)

C - USER2 CAN (11* bit ID, 50* Kbaud)

* default settings (user adjustable)

The first protocol shown (0) is a convenient way of

telling the ELM327 to automatically try all protocols,

when looking for a valid one. It causes the ELM327 to

sequence through each of the protocols, looking for

one that can be initiated correctly. When a valid

protocol is found, and the memory function is enabled,

that protocol will then be remembered, and will

become the new default setting. When saved like this,

the automatic mode searching will still be enabled, and

the next time the ELM327 fails to connect to the saved

protocol, it will again search all protocols for another

valid one.

If another protocol (other than the Automatic one)

is selected with this command (eg. AT SP 3), that

protocol will become the default, and will be the only

protocol used by the ELM327. Failure to initiate a

connection in this situation will result in familiar

responses such as ‘BUS INIT: ...ERROR’, and no

other protocols will be attempted. This is a useful

setting if you know that your vehicle(s) only require the

one protocol.

SP Ah [ Set Protocol to Auto, h ]

This variation of the SP command allows you to

choose a starting (default) protocol, while still retaining

the ability to automatically search for a valid protocol

on a failure to connect. For example, if your vehicle is

ISO 9141-2, but you want to occasionally use the

ELM327 circuit on other vehicles, you might set

AT SP A3. The default protocol will then be 3, but with

the ability to automatically search for other protocols.

Don't forget to disable the memory function if doing

this, or your neighbour’s protocol could become your

new default. As for AT SP h, an AT SP Ah will save

the protocol information even if the memory option is

off. Note that the ‘A’ can come before or after the h, so

AT SP A3 can also be entered as AT SP 3A.

SR hh [Set the Receive address to hh ]

Depending on the application, users may wish to

manually set the address to which the ELM327 will

respond. Issuing this command will turn off the AR

mode, and force the IC to only accept responses

addressed to hh. Use caution with this setting, as

depending on what you set it to, you may end up

accepting (acknowledging with an IFR) a message that

was actually meant for another module.

This command does not affect addresses used by

the J1939 protocol. The J1939 routines derive the

required addresses from the header values, as

required by the SAE standard.

ST hh [ Set Timeout to hh ]

After sending a request, the ELM327 waits a

preset time for a response before it can declare that

there was ‘NO DATA’ from the vehicle. The same

timer setting is also used after a response has been

received, to be sure that no more responses are

coming. The AT ST command allows this time to be

adjusted, in increments of about 4 msec.

16 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Commands (continued)

Setting the timer to a new value simply requires

using the ST command. For example, AT ST 19 will

give a setting of about 100 msec (19 in hex is 25 in

decimal). The ST timer is set to 32 by default (205

msec), but the default setting can be adjusted by

changing PP 03. Note that a value of 00 does not

result in 0 msec – it is a special value that sets the

timer to the default value.

When Adaptive Timing is enabled, the AT ST time

is modified by the actual measured response times,

however, the timer will never be set to a value that is

greater than the AT ST setting.

SW hh [ Set Wakeup to hh ]

Once a data connection has been made, some

vehicles require that there be data flow every few

seconds, or the connection may time out and ‘go to

sleep.’ The ELM327 will automatically generate

periodic ‘wakeup’ messages in order to maintain this

connection, whenever the user is not requesting any

data. (Currently, only protocols 3, 4, and 5 generate

these messages.) The replies to these messages are

always ignored, and are not visible to the user.

The time interval between these periodic ‘wakeup’

messages can be adjusted in 20 msec increments

using the AT SW hh command, where hh is any

hexadecimal value from 00 to FF. The maximum

possible time delay of just over 5 seconds thus occurs

when a value of FF (decimal 255) is used. The default

setting provides a nominal delay of 3 seconds between

messages.

Note that the value 00 (zero) is treated as a very

special case, and must be used with caution, as it will

stop all periodic messages. This is provided as it may

be convenient in certain circumstances. Issuing

AT SW 00 will not change a prior setting for the time

between wakeup messages, should the protocol be re-

initialized.

TP h [ Try Protocol h ]

This command is identical to the SP command,

except that the protocol that you select is not

immediately saved in internal memory, so does not

change the default setting. Note that if the memory

function is enabled (AT M1), and this new protocol that

you are trying is found to be valid, that protocol will

then be stored in memory as the new default.

TP Ah [ Try Protocol h with Auto ]

This command is very similar to the AT TP

command above, except that if the protocol that is tried

should fail to initialize, the ELM327 will then

automatically sequence through all of the protocols,

attempting to connect to one of them.

WM [1 to 6 bytes] [ set Wakeup Message to…]

This command allows the user to override the

default settings for the wakeup messages (sometimes

known as the ‘periodic idle’ messages). Simply provide

the bytes that you wish to have sent (one to six of

them), and the ELM327 will then send them as

required, at the rate determined by the AT SW setting.

Note that you do not have to add a checksum byte to

the data – the ELM327 calculates the value and adds

it for you.

WS [ Warm Start ]

This command causes the ELM327 to perform a

complete reset which is very similar to the AT Z

command, but does not include the power on LED

test. Users may find this a convenient means to

quickly ‘start over’ without having the extra delay of the

AT Z command.

If using variable RS232 baud rates (ie AT BRD

commands), it is preferred that you reset the IC using

this command, rather than AT Z, as AT WS will not

affect the chosen RS232 baud rate.

Z[ reset all ]

This command causes the chip to perform a

complete reset as if power were cycled off and then on

again. All settings are returned to their default values,

and the chip will be put in the idle state, waiting for

characters on the RS232 bus. Any baud rate set with

the AT BRD command will be reset to the default

setting.

17 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

AT Command Summary

General Commands

BRD hh try Baud Rate Divisor hh

BRT hh set Baud Rate handshake Timeout

Dset all to Defaults

E0, E1 Echo Off, or On*

Iprint the version ID

L0, L1 Linefeeds Off, or On

M0, M1 Memory Off, or On

WS Warm Start (quick software restart)

Zreset all

<CR> repeat the last command

OBD Commands

AL Allow Long (>7 byte) messages

AR Automatically Receive

AT0, 1, 2 Adaptive Timing Off, Auto1*, Auto2

BD perform a Buffer Dump

BI Bypass the Initialization sequence

DP Describe the current Protocol

DPN Describe the Protocol by Number

H0, H1 Headers Off*, or On

MA Monitor All

MR hh Monitor for Receiver = hh

MT hh Monitor for Transmitter = hh

NL Normal Length messages*

PC Protocol Close

R0, R1 Responses Off, or On

SH xyz Set Header

SH xxyyzz Set Header

SP h Set Protocol to h and save it

SP Ah Set Protocol to Auto, h and save it

SR hh Set the Receive address

ST hh Set Timeout to hh x 4 msec

TP h Try Protocol h

TP Ah Try Protocol h with Auto search

J1850 Specific Commands (protocols 1 and 2)

IFR0, 1, 2 IFRs Off, Auto*, or On

IFR H, S IFR value from Header or Source

ISO Specific Commands (protocols 3 to 5)

IB 10 Set the ISO Baud rate to 10400*

IB 96 Set the ISO Baud rate to 9600

IIA hh Set the ISO (slow) Init Address to hh

KW0, KW1 Key Word checking Off, or On*

SW hh Set Wakeup interval to hh x 20 msec

WM [1 - 6 bytes] Set the Wakeup Message

CAN Specific Commands (protocols 6 to C)

CAF0, CAF1 Automatic Formatting Off, or On*

CF hhh set the ID Filter to hhh

CF hhhhhhhh set the ID Filter to hhhhhhhh

CFC0, CFC1 Flow Control Off, or On*

CM hhh set the ID Mask to hhh

CM hhhhhhhh set the ID Mask to hhhhhhhh

CP hh set CAN Priority (only for 29 bit)

CS show the CAN Status

DM1 (J1939) Monitor for DM1 messages

FC SM h Flow Control Set the Mode to h

FC SH hhh FC Set the Header to hhh

FC SH hhhhhhhh FC Set the Header to hhhhhhhh

FC SD [1 - 5 bytes] FC Set Data to [...]

MP hhhh (J1939) Monitor for PGN hhhh

Misc. Commands

CV dddd Calibrate the Voltage to dd.dd volts

PP xx OFF disable Prog Parameter xx

PP FF OFF all Prog Parameters Off

PP xx ON enable Prog Parameter xx

PP FF ON all Prog Parameters On

PP xx SV yy for PP xx, Set the Value to yy

PPS print a PP Summary

RV Read the Voltage

* = default setting

18 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Reading the Battery Voltage

Before proceding to the OBD Commands, we will

show an example of how to use an AT Command. We

will assume that you have built (or purchased) a circuit

which is similar to that of Figure 9 in the Example

Applications section. This circuit provides a connection

to read the vehicle’s battery voltage, which many will

find very useful.

If you look in the AT Command list, you will see

there is one command that is listed as RV [Read the

input Voltage]. This is the command which you will

need to use. First, be sure that the prompt character is

shown (that is the ‘>’ character), then simply enter ‘AT’

followed by RV, and press return (or enter):

>at rv

12.6V

Note that we did not use upper case characters in

this example, mostly out of laziness. The ELM327 will

accept upper case (AT RV) as well as lower case (at

rv) or any combination of these (At rV). It does not

matter to the ELM327. Also note that we have shown a

space character (‘ ’) between the ‘at’ and the ‘rv’. This

is only to separate the commands and make them

more readable. You do not have to add spaces, or if

you wish, you can add many spaces – it does not

affect the internal interpretation of the command.

As shipped from the factory, the ELM327 voltage

reading circuitry will typically be accurate to about 2%.

For many, this is all that is needed. Some people may

want to calibrate the circuitry for more accurate

readings, however, so we have provided a special

‘Calibrate Voltage’ command for this.

To change the internal calibration constants, you

will need to know the actual battery voltage to more

accuracy than the ELM327 shows. Many quality digital

multimeters can do this, but you should verify the

accuracy before making too many changes. Perhaps

in this case, you have connected your multimeter, and

find that it reads 12.47V, and you would like the

ELM327 to read the same. Simply calibrate it to that

voltage using the CV command:

>at cv 1247

At this point, the internal calibration values have

been changed, and the ELM327 knows that the

voltage at the input is actually 12.47V. You should not

provide the decimal point in the CV value, as the IC

knows that it should be between the second and the

third digits. To verify that the changes have taken

place, simply read the voltage again:

>at rv

12.5V

The ELM327 always rounds off the measurement

to one decimal place, so the 12.47V actually appears

as 12.5V. Note that the second decimal place is

always maintained internally for accuracy and use in

the calculations, but it is never displayed.

The ELM327 can be calibrated with any reference

voltage that you have available, but note that the CV

command always expects to receive four characters

representing the voltage at the input. If you used a 9V

battery for your reference, and it is actually 9.32V, then

you must add a leading zero to that when calibrating

the IC:

>at cv 0932

The other AT Commands are used in the same

manner. Simply type the letters A and T, follow that

with the command you want to send, then any

arguments that are required for that command, and

press return (or enter, depending on your keyboard).

You can place space characters as often as you wish

if it improves the readability for you, as they are

ignored by the ELM327.

OBD Commands

If the bytes that you send to the ELM327 do not

begin with the letters ‘A’ and ‘T’, they are assumed to

be OBD commands for the vehicle. Each pair of ASCII

bytes will be tested to ensure that they are valid

hexadecimal digits, and will then be combined into

single data bytes for transmitting to the vehicle.

OBD commands are actually sent to the vehicle

embedded in a data packet. Most standards require

that three header bytes and an error checksum byte

be included with every OBD message, and the

ELM327 adds these extra bytes to your command

bytes automatically. The initial (default) values for

these extra bytes are usually appropriate for most

requests, but if you wish to change them, there is a

method to do so (see the “Setting the Headers”

section).

Most OBD commands are only one or two bytes in

length, but some can be longer. The ELM327 will limit

the number of bytes that can be sent to the maximum

number allowed by the standards (seven bytes or 14

hexadecimal digits). Attempts to send more bytes, or

an odd number of hex digits, will result in a syntax

error – the entire command is then ignored and a

single question mark printed.

Hexadecimal digits are used for all of the data

exchange with the ELM327 because it is the data

format used most often in the OBD standards. Most

mode request listings use haxadecimal notation, and it

is the format most frequently used when results are

shown. With a little practice, it should not be very

difficult to deal in hex numbers, but some people may

want to use a table such as Figure 1, or keep a

calculator nearby. All users will be required to

manipulate the results in some way, though –

combining bytes and dividing by 4 to obtain rpm,

dividing by 2 to obtain degrees of advance, etc., and

may find a software front-end to be of help.

As an example of sending a command to the

vehicle, assume that A6 (or decimal 166) is the

command that is required to be sent. In this case, the

user would type the letter A, then the number 6, then

would press the return key. These three characters

would be sent to the ELM327 by way of the RS232

port. The ELM327 would store the characters as they

are received, and when the third character (the

carriage return) was received, would begin to assess

the other two. It would see that they are both valid hex

digits, and would convert them to a one byte value (the

decimal value is 166). The header bytes and a

checksum byte would then be added, and a total of

five bytes would typically be sent to the vehicle. Note

that the carriage return character is only a signal to the

ELM327, and is not sent on to the vehicle.

After sending the command, the ELM327 listens

on the OBD bus for messages, looking for ones that

are directed to it. If a message address matches,

those received bytes will be sent on the RS232 port to

the user, while messages received that do not have

matching addresses will be ignored (but are often still

available for viewing with the AT BD command).

The ELM327 will continue to wait for messages

addressed to it until there are none found in the time

that was set by the AT ST command. As long as

messages are received, the ELM327 will continue to

reset this timer. Note that the IC will always respond

with something, even if it is to say “NO DATA”

(meaning that there were no messages found that

were addressed to it).

19 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Figure 1. Hex to Decimal Conversion

Hexadecimal

Number Decimal

Equivalent

7 7

8 8

9 9

A 10

B 11

C 12

D 13

E 14

F 15

Talking to the Vehicle

The OBD standards specify that each request that

is sent to the vehicle must adhere to a set format. The

first byte (known as the ‘mode’) always describes the

type of data being requested, while the second, third,

etc. bytes specify the actual information required

(given by a ‘parameter identification’ or PID number).

These modes and PIDs are described in detail in

documents such as the SAE J1979, or ISO 15031-5

standards, and may also be expanded on by the

vehicle manufacturers.

Normally, one is only concerned with the nine

diagnostic test modes described by J1979 (although

there is provision for more). All of these modes are not

required to be supported by every vehicle, and are

often not. These are the nine modes:

01 - show current data

02 - show freeze frame data

03 - show diagnostic trouble codes

04 - clear trouble codes and stored values

05 - test results, oxygen sensors

06 - test results, non-continuously monitored

07 - show ‘pending’ trouble codes

08 - special control mode

09 - request vehicle information

Within each mode, PID 00 is normally reserved to

show which PIDs are supported by that mode. Mode

01, PID 00 must be supported by all vehicles, and can

be accessed as follows…

Ensure that your ELM327 interface is properly

connected to the vehicle, and powered. Most vehicles

will not respond without the ignition key in the ON

position, so turn the ignition to on, but do not start the

engine. At the prompt, issue the mode 01 PID 00

command:

>01 00

The first time the bus is accessed, you may see a

bus initialization message, and then the response,

which might typically be as follows:

41 00 BE 1F B8 10

The 41 signifies a response from a mode 01

request (01+40=41), while the second number (00)

simply repeats the PID number requested. A mode 02,

request is answered with a 42, a mode 03 with a 43,

etc. The next four bytes (BE, 1F, B8, and 10)

represent the requested data, in this case a bit pattern

showing the PIDs supported by this mode

(1=supported, 0=not). Although this information is not

very useful for the casual user, it does prove that the

connection is working.

Another example requests the current engine

coolant temperature (ECT). This is PID 05 in mode 01,

and can be requested as follows:

>01 05

The response will be of the form:

41 05 7B

The 41 05 shows that this is a response to a

mode 1 request for PID 05, while the 7B is the desired

data. Converting the hexadecimal 7B to decimal, one

gets 7 x 16 + 11 = 123. This represents the current

temperature in degrees Celsius, but with the zero

offset to allow for subzero temperatures. To convert to

the actual coolant temperature, you need to subtract

40 from the value obtained. In this case, then, the

coolant temperature is 123 - 40 or 83 °C.

A final example shows a request for the engine

rpm. This is PID 0C of mode 01, so at the prompt type:

>01 0C

A typical response would be:

41 0C 1A F8

The returned value (1A F8) is actually a two byte

value that must be converted to a decimal value to be

useful. Converting it, we get a value of 6904, which

seems to be a very high value for engine rpm. That is

because rpm is sent in increments of 1/4 rpm! To

convert to the actual engine speed, we need to divide

the 6904 by 4. In this case, then, the rpm is 1726,

which is much more reasonable.

Hopefully this has shown how typical requests

proceed. It has not been meant to be a definitive guide

on modes and PIDs – this information can be obtained

from the manufacturer of your vehicle, the SAE

(http://www.sae.org/), from ISO (http://www.iso.org/),

or from various other sources on the web.

20 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Interpreting Trouble Codes

Likely the most common use that the ELM327 will

be put to is in obtaining the current Diagnostic Trouble

Codes (or DTCs). Minimally, this requires that a mode

03 request be made, but first one should determine

how many trouble codes are presently stored. This is

done with a mode 01 PID 01 request as follows:

>01 01

To which a typical response might be:

41 01 81 07 65 04

The 41 01 signifies a response to the request, and

the next data byte (81) is the number of current trouble

codes. Clearly there would not be 81 (hex) or 129

(decimal) trouble codes present if the vehicle is at all

operational. In fact, this byte does double duty, with

the most significant bit being used to indicate that the

malfunction indicator lamp (MIL, or ‘Check Engine

Light’) has been turned on by one of this module’s

codes (if there are more than one), while the other 7

bits of this byte provide the actual number of stored

trouble codes. In order to calculate the number of

stored codes when the MIL is on, simply subtract 128

(or 80 hex) from the number.

The above response then indicates that there is

one stored code, and it was the one that set the Check

Engine Lamp or MIL on. The remaining bytes in the

response provide information on the types of tests

supported by that particular module (see the SAE

document J1979 for further information).

In this instance, there was only one line to the

response, but if there were codes stored in other

modules, they each could have provided a line of

response. To determine which module is reporting the

trouble code, one would have to turn the headers on

(AT H1) and then look at the third byte of the three

byte header for the address of the module that sent

the information.

Having determined the number of codes stored,

the next step is to request the actual trouble codes

with a mode 03 request (there is no PID needed):

>03

A response to this could be:

43 01 33 00 00 00 00

The ‘43’ in the above response simply indicates

that this is a response to a mode 03 request. The other

6 bytes in the response have to be read in pairs to

show the trouble codes (the above would be

interpreted as 0133, 0000, and 0000). Note that the

response has been padded with 00’s as required by

the SAE standard for this mode – the 0000’s do not

represent actual trouble codes.

As was the case when requesting the number of

stored codes, the most significant bits of each trouble

code also contain additional information. It is easiest to

use the following table to interpret the extra bits in the

first digit as follows:

Powertrain Codes - SAE defined

0“ “ - manufacturer defined

“ “ - SAE defined

“ “ - jointly defined

If the first hex digit received is this,

Replace it with these two characters

Chassis Codes - SAE defined

“ “ - reserved for future

7Body Codes - SAE defined

BNetwork Codes - SAE defined

“ “ - reserved for future

“ “ - manufacturer defined

“ “ - reserved for future

Taking the example trouble code (0133), the first

digit (0) would then be replaced with P0, and the 0133

reported would become P0133 (which is the code for

an ‘oxygen sensor circuit slow response’). Note that

the ISO 15765-4 (CAN) protocol is very similar, but it

adds an extra data byte (in the second position),

showing how many data items (DTCs) are to follow.

To provide a few further examples, if the received

code was D016, you would replace the D with U1, and

the resulting trouble code would be U1016. Similarly,

1131 received would actually be for the code P1131.

21 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Resetting Trouble Codes

The ELM327 is quite capable of resetting

diagnostic trouble codes, as this only requires issuing

a mode 04 command. The consequences should

always be considered before sending it, however, as

more than the MIL (or ‘Check Engine Light’) will be

reset. In fact, issuing a mode 04 will:

- reset the number of trouble codes

- erase any diagnostic trouble codes

- erase any stored freeze frame data

- erase the DTC that initiated the freeze frame

- erase all oxygen sensor test data

- erase mode 06 and 07 information

Clearing of all of this data is not unique to the

ELM327 – it occurs whenever any scan tool is used to

reset the codes. The biggest problem with losing this

data is that your vehicle may run poorly for a short

time, while it performs a recalibration.

To avoid inadvertently erasing stored information,

the SAE specifies that scan tools must verify that a

mode 04 is intended (“Are you sure?”) before actually

sending it to the vehicle, as all trouble code

information is immediately lost when the mode is sent.

Remember that the ELM327 does not monitor the

content of the messages, so it will not know to ask for

confirmation of the mode request – this would have to

be the duty of a software interface if one is written.

As stated, to actually erase diagnostic trouble

codes, one need only issue a mode 04 command. A

response of 44 from the vehicle indicates that the

mode request has been carried out, the information

erased, and the MIL turned off. Some vehicles may

require a special condition to occur (eg. the ignition on

but the engine not running) before they will respond to

a mode 04 command.

That is all there is to clearing trouble codes. Once

again, do not accidentally send the 04 code!

22 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Quick Guide for Reading Trouble Codes

If you do not use your ELM327 for some time, this

entire data sheet may seem like quite a bit to review

when your ‘Check Engine’ light eventually comes on,

and you just want to know why. We offer this section

as a quick guide to the basics that you will need.

To get started, connect the ELM327 circuit to your

PC or PDA and communicate with it using a terminal

program such as HyperTerminal, ZTerm, ptelnet, or a

similar program. It should normally be set to either

9600 or 38400 baud, with 8 data bits, and no parity or

handshaking.

The chart at the right provides a quick procedure

on what to do next:

Ignition Key to ON,

but vehicle not running

>0101

to see how many codes

(2nd digit of the 3rd byte)

>03

to see the codes

(ignore the first byte and

read the others in pairs)

>04

to reset the codes

FIX THE VEHICLE!

23 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Wakeup Messages

After an ISO 9141 or ISO 14230 connection has

been established, there needs to be periodic data

transfers in order to maintain that connection, and

prevent it from ‘going to sleep.’ If normal requests and

responses are being sent, that is usually sufficient, but

the ELM327 occasionally has to create its own

messages to prevent the connecton from timing out.

We term these periodic messages that are created

the ‘Wakeup Messages’, as they keep the connection

alive, and prevent the circuitry from going back to an

idle or sleep mode. (Some texts refer to these

messages simply as ‘idle messages.’) The ELM327

automatically creates and sends these for you if there

appears to be no other activity – there is nothing that

you need do to ensure that they occur. To see these,

once a connection is made, simply monitor the OBD

transmit LED – you will see the periodic ‘blips’ created

when the ELM327 sends one. If you are curious as to

the actual contents of the messages, you can then

perform a Buffer Dump to see the bytes. Note that the

ELM327 never obtains or prints a response to any of

the wakeup messages.

The standards state that if there is no activity at

least every five seconds, the data connection may

close. To ensure that this does not happen, and to

provide some margin, the ELM327 will send a wakeup

message after three seconds of inactivity. This time

interval is fully programmable, should you prefer a

different setting (see the AT SW command).

As with the ELM323, the ELM327 allows users to

change the actual wakeup message that is sent. To do

so, simply send the ELM327 a Wakeup Message

command, telling it what you wish the message to be

changed to. For example, if you would like to send the

data bytes 44 55 with the header bytes set to 11 22

33, simply send the command:

>AT WM 11 22 33 44 55

From that point forward, every wakeup message

that the ELM327 sends will be as shown above.

You can change these as often as you want, the

only restriction being that every time you do, you must

provide the complete message – the header bytes and

the data bytes (the current version of the ELM327 only

allows for messages of one to six bytes in length). You

should not provide a checksum byte, as it will be

automatically added for you.

Bus Initiation

Both the ISO 9141-2 and ISO 14230-4 (KWP2000)

standards require that the vehicle’s OBD bus be

initialized before any communications can take place.

The ISO 9141 standard allows for only a slow (2 to 3

second) initiation process, while ISO 14230 allows for

both a slow method, and a faster alternative.

The ELM327 will perform this bus initiation for you,

but not until your request needs to be sent. If the bus

initiation occurs during the automatic search process,

you will not see any status reporting, but if you have

the Auto option off (and are set to protocols 3, 4, or 5),

then you will see a message similar to this:

BUS INIT: ...

The three dots appear only as the slow initiation

process is carried out – a fast initiation does not show

them. This will be followed by either the expression

‘OK’ to say it was successful, or else an error message

to indicate that there was a problem. (The most

common error encountered is in forgetting to turn the

vehicle’s key to ‘ON’ before attempting to talk to the

vehicle.)

Once the bus has been initiated, communications

must take place regularly (typically at least once every

five seconds), or the bus will revert to a low-power

‘sleep’ mode. If you are not sending data requests

often enough, the ELM327 will generate requests for

you to ensure that the bus stays ‘awake’. You will

never see the responses to these, but you may see

the transmit LED flash periodically when these are

being sent.

By default, the ELM327 ensures that these

‘wakeup’ or ‘idle’ messages are sent every 3 seconds,

but this is adjustable with the AT SW command. The

contents of the wakeup message are also user

programmable with the AT WM command, if you

should wish to change them. Users generally do not

have to change either of the above though, as the

default settings work well with almost all systems.

24 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Selecting Protocols

The ELM327 supports several different OBD

protocols (see Figure 2 below). As a user, you may

never have to choose which one it should use (since

the factory settings cause an automatic search to be

performed for you), but while experimenting, you may

want to specify which protocol is used.

For example, if you know that your vehicle uses

the SAE J1850 VPW protocol, you may want the

ELM327 to only try that protocol, and no others. If that

is what you want, simply determine the protocol

number (from the chart below), then use the ‘Set

Protocol’ AT Command as follows:

>AT SP 2

From this point on, the default protocol (used after

every power-up or AT D command) will be protocol 2

(or whichever one that you have chosen). Verify this

by asking the ELM327 to describe the current protocol:

>AT DP

SAE J1850 VPW

Now what happens if your friend has a vehicle that

uses ISO 9141-2? How do you use the ELM327

interface for that vehicle? There are a few choices...

One possibility is to change your protocol selection

to allow for the automatic searching for another

protocol, on failure of the current one. This is done by

putting an ‘A’ with the protocol number, as follows:

>AT SP A2

>AT DP

AUTO, SAE J1850 VPW

Now, the ELM327 will begin by trying protocol 2,

but will then automatically begin searching for another

protocol should an attempt to connect with protocol 2

fail (as would happen when you try to connect to the

friend’s vehicle). If you have the memory function

enabled when you connect to your friend’s vehicle,

their protocol will then be stored in memory as the new

default protocol, but that is only a minor inconvenience

as the next time you connect to your vehicle, it will try

the friends protocol, fail, and search until it finds yours.

Your protocol will then be resaved as the new default.

Perhaps you have disabled the memory function

(set pin 5 to 0V), and have used AT SP 2 to customize

the IC for your vehicle only, and you don’t want it to

search for others? (In effect, you have turned your

ELM327 into an ELM322 type interface.) In this case,

you might want to use the ‘Try Protocol’ command for

your friend’s vehicle, rather than setting it to something

permanently. You can either say:

>AT TP 3

if you already know that your friend’s vehicle uses

protocol 3, or else you can say:

>AT TP 0

which automatically tries all of the protocols (as

allowed by PP 07) looking for one that responds.

In general, users find that enabling the memory

(setting pin 5 to 5V) and choosing the ‘Auto’ option

(the easiest way is to say AT SP 0) works very well.

After the initial search, the protocol used by your

vehicle becomes the new default mode (so it is tried

first every time), and if the interface is used on another

vehicle, there is only a minor delay while it performs an

automatic search.

Figure 2. ELM327 Protocol Numbers

Description

SAE J1850 PWM (41.6 Kbaud)

Protocol

Automatic

SAE J1850 VPW (10.4 Kbaud)

ISO 9141-2 (5 baud init)

ISO 14230-4 KWP (5 baud init)

ISO 14230-4 KWP (fast init)

ISO 15765-4 CAN (11 bit ID, 500 Kbaud)

ISO 15765-4 CAN (29 bit ID, 500 Kbaud)

ISO 15765-4 CAN (11 bit ID, 250 Kbaud)

ISO 15765-4 CAN (29 bit ID, 250 Kbaud)

SAE J1939 CAN (29 bit ID, 250* Kbaud)

User1 CAN (11* bit ID, 125* Kbaud)

User2 CAN (11* bit ID, 50* Kbaud)

*user adjustable

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 is used by 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 checksumPCI

up to 7 data bytes checksum3 header bytes

priority receiver transmitter

TA SA

26 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

standard now allows 29 in total.

The ELM327 does not normally show any of these

extra bytes unless you turn that feature on with the

Headers On command (AT H1). Issuing that allows

you to see the header bytes and the checksum byte

(for the J1850, ISO 9141 and ISO 14230 protocols).

For the CAN protocols, you will see the ID bits, and

other items which are normally hidden such as the PCI

byte for ISO 15765, or the data length codes (if they

are enabled with PP 29). Note that the ELM327 is not

able to display the checksum information for CAN

systems, or the IFR bytes for J1850 systems.

It is not necessary to ever have to set these

header byes, or to perform a checksum calculation, as

the ELM327 will always do this for you. The header

bytes are adjustable however, should you wish to

experiment by using advanced techniques such as

physical addressing. The next section provides a

discussion on how to do this…

OBD Message Formats (continued)

Setting the Headers

The emissions related diagnostic trouble codes

that most people are familiar with are described in the

SAE J1979 standard (ISO15031-5). They represent

only a portion of the data that a vehicle may have

available – much more can be obtained if you are able

to direct the requests elsewhere.

Accessing most OBDII diagnostics information

requires that requests be made to what is known as a

a ‘functional address.’ Any processor that supports the

function will respond to the request (and theoretically,

many different processors can respond to a single

functional request). In addition, every processor (or

ECU) will also respond to what is known as their

physical address. It is the physical address that

uniquely identifies each module in a vehicle, and

permits you to direct more specific queries to only one

particular module.

To retrieve information beyond that of the OBDII

requirements then, it will be necessary to direct your

requests to either a different functional address, or to

an ECU’s physical address. This is done by changing

the data bytes in the message header.

As an example of functional addressing, let us

assume that you want to request that the processor

responsible for Engine Coolant provide the current

Fluid Temperature. You do not know its address, so

you consult the SAE J2178 standard and determine

that Engine Coolant is functional address 48. SAE

standard J2178 also tells you that for your J1850 VPW

vehicle, a priority byte of A8 is appropriate. Finally,

knowing that a scan tool is normally address F1, you

have enough information to specify the three header

bytes (A8 48 and F1). To tell the ELM327 to use these

new header bytes, all you need is the Set Header

command:

>AT SH A8 48 F1

The three header bytes assigned in this manner

will stay in effect until changed by the next AT SH

command, a reset, or an AT D.

Having set the header bytes, you now need only

send the secondary ID for fluid temperature (10) at the

prompt. If the display of headers is turned off, the

conversation could look like this:

>10

10 2E

The first byte in the response echos the request,

as usual, while the data that we requested is the 2E

byte. You may find that some requests, being of a low

priority, may not be answered immediately, possibly

causing a “NO DATA” result. In these cases, you may

want to adjust the timeout value, perhaps first trying

the maximum (ie use AT ST FF). Many vehicles will

simply not support these extra addressing modes.

The other, and more common method of obtaining

information is by physical addressing, in which you

direct your request to a specific device, not to a

functional group. To do this, you again need to

construct a set of header bytes that direct your query

to the physical address of the processor, or ECU. If

you do not know the address, recall that the sender of

information is usually shown in the third byte of the

header. By monitoring your system for a time with the

headers turned on (AT H1), you can quickly learn the

main addresses of the senders. The SAE document

J2178 assigns address ranges to these devices if you

are unsure of which might be most appropriate.

When you know the address that you wish to

‘speak to,’ simply use it for the second byte in the

header (assume an address of 10 for this example).

Combine that with your knowledge of SAE J2178 to

choose a priority/type byte (assume a value of E4 for

this example, as if the vehicle is J1850 PWM). Finally,

you need to identify yourself to the target, so that

responses can be returned to you. As is customary for

diagnostic tools, we’ll use an address of F1. As before,

these three bytes are then assigned to the header with

the set header command:

>AT SH E4 10 F1

From this point on, all messages that the ELM327

sends will use these three bytes for the header. All that

needs to be done now is to request data from the

vehicle. For physical addressing, this is often done

using mode 22:

>22 11 6B

62 11 6B 00 00

The response to this command is of the same

format to those seen for ‘standard’ OBD requests. The

request has been repeated (with 40 added to the

mode value in order to show that this is a response),

and this is followed by the actual data (0000 in this

case). The PIDs used with mode 22 are usually

proprietary to each manufacturer and are generally not

published widely, so you may have difficulty in

determining the ones to use with your vehicle. Elm

27 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Setting the Headers (Cont’d)

28 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

>AT SH xx yy zz>AT CP vv

vv xx yy zz

5 bits only

xx yy zzvv

29 bit ID

Figure 5. Setting a 29 bit CAN ID

Electronics does not maintain lists of this information,

and cannot provide any further details for you. Mode

22 and others are described in more detail in SAE

document J2190, “Enhanced E/E Diagnostic Test

Modes”.

The ISO14230-4 standard defines its’ header

bytes a little differently. Advanced experimenters will

be aware that for ISO 14230-4, the first header byte

must always include the length of the data field, which

varies from message to message. From that, one

might assume that the you would need to redefine the

header for every message that is to be sent – not so!

The ELM327 always determines the number of bytes

that you are sending, and inserts that length for you, in

the proper place for the header that you are using. If

you are using the standard ISO 14230-4 header, the

length will be put into the first header byte, and you

need only provide the two (most significant) bits of this

byte when defining the header. What you place in the

rest of the byte will be ignored by the ELM327 unless

you set them all to 0’s. If they are all 0, it is assumed

that you are experimenting with KWP four byte

headers, and the ELM327 then creates the fourth

header byte for you. Again, you do not need to provide

any length to be put into this byte – it is done for you.

Addressing within the CAN (ISO 15765-4)

protocols is quite similar in many ways. First, consider

the 29 bit standard. The ELM327 splits the 29 bits into

a CAN Priority byte and the three header bytes that we

are now familiar with. Figure 5 shows how these are

combined for use by the ELM327.

The CAN standard states that for diagnostics, the

priority byte (‘vv’ in the diagram) will always be 1B (this

>AT SH xx yy zz

xx yy zz

11 bit ID

Figure 6. Setting an 11 bit CAN ID

is the default value used by the ELM327). Since it is

rarely changed, it is assigned separately from the

other header bytes, using the CP command. Changing

of this value is usually only required if experimenting

with J1939 systems.

The next byte (‘xx’) describes the type of message

that this is, and is set to hex DB for functional

addressing, and to DA if using physical addressing.

The next two bytes are as defined previously for the

other standards – ‘yy’ is the receiver (or Target

Address), and ‘zz’ is the transmitter (or Source

Address). For the functional diagnostic requests, the

receiver is always 33, and the transmitter is F1, which

is very similar to ISO 14230-4.

Those that are familiar with the SAE J1939

standard will likely find this header structure to be very

familiar (J1939 is a CAN standard for use by ‘heavy-

duty vehicles’ such as trucks and buses). We use

slightly different terminology, but there is a direct

parallel between the bytes used by J1939 for the

headers and the grouping of the bytes in the ELM327.

Refer to page 36 for a discussion of the J1939 support

that is provided by the ELM327.

The final header format to discuss is that used in

11 bit CAN systems. They also use a priority/address

structure, but shorten it into roughly three nibbles

rather than three bytes. The ELM327 uses the same

commands to set these values as for other headers,

except that it only uses the 11 least significant (‘right-

most’) bits of the provided header bytes, and ignores

the others (as shown in Figure 6). It quickly becomes

inconvenient to have to enter six digits when only three

are required, so there is a special ‘short’ version of the

29 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Setting the Headers (Cont’d)

AT SH command that uses only three hex digits. It

actually operates by simply adding the leading zeroes

for you.

The 11 bit CAN standard typically makes

functional requests (ID/header = 7DF), but receives

physical replies (7En). With headers turned on, it is a

simple matter to learn the address of the module that

is replying, then use that information to make physical

requests if desired. For example, if the headers are on,

and you send 01 00, you might see:

>01 00

7E8 06 41 00 BE 3F B8 13 00

The 7E8 shows that ECU#1 was the one

responding. In order to talk directly to that ECU, all you

need do is to set the header to the appropriate value (it

is 7E0 to talk to the 7E8 device – see ISO 15765-4 for

more information). From that point on, you can ‘talk’

directly to the ECU using its physical address, as

shown here:

>AT SH 7E0

>01 05

7E8 03 41 05 46 00 00 00 00

Hopefully this has helped to get you started. As we

often tell those that write – if you are planning to do

some serious experimenting with OBD, you should buy

the relevant standards.

Monitoring the Bus

Some vehicles use the OBD bus for information

transfer during normal vehicle operation, passing a

great deal of information over it. A lot can be learned if

you have the good fortune to connect to one of these

vehicles, and are able to decipher the contents of the

messages.

To see how your vehicle uses the OBD bus, you

can enter the ELM327’s ‘Monitor All’ mode, by sending

the command AT MA from your terminal program. This

will cause the IC to display any information that it sees

on the OBD bus, regardless of transmitter or receiver

addresses (it will show all). Note that the periodic

‘wakeup’ messages are not sent while in this mode, so

if you have an ISO 9141 or ISO 14230 bus that had

been initialized previously, it may ‘go to sleep’ while

monitoring.

The monitoring mode can be stopped by putting a

logic low level on the RTS pin, or by sending a single

RS232 character to the ELM327. Any convenient

character can be used to interrupt the IC – there are

no restrictions on whether it is printable, etc. Note that

the character you send will be discarded, and will have

no effect on any subsequent commands. The time it

takes to respond to this interrupting character will

depend on what the ELM327 is doing when the

character is received. The IC will always finish a task

that is in progress (printing a line, for example) before

returning to wait for input, so you should always wait

for the prompt character (‘>’), or the Busy line to go

low, before beginning to send a command.

One unexpected result may occur if you have the

automatic protocol search feature enabled, and you

tell the ELM327 to begin monitoring. If the bus is quiet,

the ELM327 will begin searching for an active protocol,

which may not be what you were expecting. Be aware

also that the ISO 9141 and ISO 14230 protocols look

identical when monitoring, so the ELM327 will likely

stop searching at ISO 9141, even if the actual protocol

is ISO 14230. With the Automatic searching enabled,

this should correct itself, however, when the first OBD

request is made.

If the ‘Monitor All’ command provides too much

information (it certainly does for most CAN systems!),

then you can restrict the range of data that is to be

displayed. Perhaps you only want to see messages

that are being transmitted by the ECU with address 10.

To do that, simply type:

>AT MT 10

and all messages that contain 10 in the third byte of

the header will be displayed.

Using this command with 11 bit CAN systems can

be a little confusing at first. Recall the way in which all

header bytes are stored within the ELM327. An 11 bit

CAN ID is actually stored as the least significant 11

bits in the 3 byte ‘header storage’ location. It will be

stored with 3 bits in the receiver’s address location,

and the remaining 8 bits in the transmitter’s address

location. For this example, we have requested that all

messages created by transmitter ‘10’ be printed, so all

11 bit CAN IDs that end in 10 will be displayed (ie all

that look like ‘x10’).

The other monitoring command that is very useful

is the AT MR command, which looks for specific

addresses in the middle byte of the header. Using this

command, you can look for all messages being sent to

a particular address. For example, to use it to look for

messages being sent to the ECU with address 10,

simply send:

>AT MR 10

and all messages that contain 10 in the second byte of

the header will be displayed.

Using this command with the 11 bit CAN systems

will again need further explanation. It may be helpful to

first picture the hex number ‘10’ in the above example

as the binary number ‘0001 0000’. Recall from above

that 11 bit CAN IDs are actually stored as the least

significant 11 bits in the 3 byte ‘header storage’

locations, and only 3 bits are actually stored in the

middle byte (receiver’s address) position. When

comparing the received CAN ID to the address you

provide with the MR command then, only the right-

most 3 bits of your MR address are considered and

the other 5 bits are ignored. In this example, the

AT MR 10 effectively becomes AT MR 0 for 11 bit

CAN systems, and all messages that begin with ‘0’ as

the first digit will actually be displayed.

In order to use the AT MR command with CAN 11

bit identifiers, you should always try to use the format

‘AT MR 0x’, where ‘x’ is the digit that you want the

identifiers to begin with. To look for all 2xx’s, use the

command ‘AT MR 02’, and to see all of the 7xx’s, you

should use ‘AT MR 07’.

ELM327

30 of 51ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

CAN Messages and Filtering

The ELM327 monitoring commands (AT MA, MR

and MT) usually work very well with the ‘slower’

protocols – J1850, ISO 9141 and ISO 14230. The

CAN systems are a different story, however, as they

often have an order of magnitude more information

passing over them. The relatively small 256 byte buffer

that the ELM327 uses for sending can quickly fill up

when data is arriving at 500 Kbps and leaving at

38.4 Kbps, or even 115.2 Kbps.

To help reduce the amount of information seen by

the ELM327, the internal CAN module has a ‘filter’ that

can be used to pass only messages with specific ID

bits. A range of values can be passed when the filter is

used with what is called a ‘mask’ to say which bits are

relevant.

As an example, consider an application where you

are trying to monitor for 29 bit CAN diagnostic

messages, exactly like the ELM327 does. By

definition, these messages will be sent to the scan tool

at address F1. From ISO 15765-4, you know then that

the ID portion of the reply must be of the form:

18 DA F1 xx

where xx is the address of the module that is sending

the message. To use the filter, then, enter what you

have into it, putting anything in for the unknown portion

(you will see why in a moment). The command to set

the CAN filter is AT CF…

>AT CF 18 DA F1 00

How, you ask, do you tell the ELM327 to ignore

those last two 0’s? You do that with the mask. The

mask is a set of bits that tell the ELM327 which bits in

the filter are relevant. If the mask bit is 1, that filter bit

is relevant, and is required to match. If it is 0, then that

filter bit will be ignored. All bits in the above message

are relevant, except those of the last two digits. To set

the mask for this example then, you would need to use

the CAN Mask command, as follows:

>AT CM 1F FF FF 00

If desired, you can convert the hexadecimal to

binary to see what has been done.

The 11 bit CAN IDs are treated in the same

manner. Recall that they are stored internally in the

right-most 11 bits of the locations used for 29 bit CAN,

which must be considered when creating a filter or

mask. As an example, assume that we wish to display

all messages that have a 6 as the first digit of the 11

31 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

bit ID. We need to set a filter to look for 6 in that digit:

>AT CF 00 00 06 00

The 11 bit ID is stored in the last three locations,

so the 6 would appear where it is shown. Now, to

make that digit relevant, we create the mask:

>AT CM 00 00 0F 00

The system only uses the 11 right-most bits in this

case, so we can be lazy and enter the F as shown (the

first bit of the F will be ignored, and it will be treated as

if we had entered a 7).

Clearly, this can be quite cumbersome if using 11

bit CAN systems routinely. To help with that, the

ELM327 offers some shorter versions of the CF and

CM commands. To use them for the example above,

you need only enter three digit arguments:

>AT CF 600

and

>AT CM F00

As for the full eight digit versions, only the 11 least

significant (right-most) digits are actually used, so you

do not need to take special care with the first bit.

With a little practice, these commands are fairly

easy to master. Initially, try entering the filter and mask

values, then use a command such as AT MA to see

what the results are. The ELM327 knows that you are

trying to filter, and combines the effects of both

commands (it will do that for MR and MT as well). The

MA, MR and MT commands all have the extra benefit

that while they are in effect, the ELM327 will remain

quiet, not sending acknowledgement or error signals,

so anything you do while monitoring should not disrupt

other devices that are on the bus.

Note that if a filter has been set, it will be used for

all CAN messages. Setting filters and masks may

cause standard OBD requests to be ignored though,

and you may begin seeing “NO DATA” responses. If

this happens, and you are unsure of why, you may

want to reset everything to their default values (AT D)

and start over.

32 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Multiline Responses

There are occasions when a vehicle must respond

with more information than one ‘message’ is able to

show. In these cases, it responds with several lines

which must be assembled into one complete message.

One example of this is a request for the serial

number of the vehicle (mode 09, PID 02). This is often

a multiline reply that needs to be joined. In these

situations, you must take care to ensure that all of the

reply has been received and it is in the correct order

before assembling the message. The actual response

usually has a byte that shows the sequence of the

data, to help with this. Here is one example for a

typical SAE J1850 vehicle:

>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

Note that all OBD compliant vehicles do not

necessarily provide this information. Many older ones

do not, but as a rule the newer ones do. If your vehicle

does not support this parameter, you will only see a

“NO DATA” response.

The first two bytes (49 and 02) on each line of the

above response do not show any vehicle information.

They only show that this is a response to an 09 02

request. The next byte on each line shows the order in

which the data is to be assembled. Assembling the

remainder of the data in that order, and ignoring the

first few 00’s gives:

31 44 34 47 50 30 30 52 35 35 42 31 32

33 34 35 36

Using an ASCII table to convert these hex digits

gives the following serial number for the vehicle:

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:

>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

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, so that they clearly stand out (0:, 1:, etc.).

CAN systems add this hex digit (it goes from 0 to F

then repeats), to aid in reassembling the data, just as

the J1850 vehicle did.

The first line of this response says that there are

014 bytes of information to follow. That is 14 in

hexadecimal, or 20 in decimal terms, which agrees

with the 6 + 7 + 7 bytes shown on the three lines.

Serial numbers are generally 17 digits long however,

so how do we assemble the number from 20 digits?

The second line shown begins with the familiar 49

02, as this is a response to an 09 02 request. Clearly

they are not part of the serial number. CAN will

occasionally add a third byte to the response which we

see next (the ‘01’), which shows the number of data

items that are to follow (the vehicle can only have one

VIN, so the response says there is only one data item).

That third byte can be ignored, so this 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.

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. We need to 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 that is valid for them. 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

33 of 51

ELM327

ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Multiline Responses (Cont’d)

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 following

group is very confusing. Why are there two segment

twos? Which ECU do these belong to? The only way

to tell 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. This is the special CAN IDs representing

ECU#1 and ECU#2, respectively. Grouping the

responses from the two ECUs 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

and7E9 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.

Hopefully this has helped you with some of the more

difficult ones. If you are still having trouble, we urge

you to purchase the relevant standard, and study it.

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.

If a Flow Control frame is detected while

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

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

There is a final type of message that is

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 51ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

35 of 51ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

Altering Flow Control Messages

ELM327

ISO 15765-4 (CAN) provides for only eight data

bytes per frame of data. Of course, there are many

cases where the data which needs to be sent is longer

that 8 bytes and CAN has made provision for this,

allowing data to be separated into segments, then

recombined at the receiver.

To send one of these multi-line messages, the

transmitter in a CAN system will send a ‘First Frame’

message, and then wait for a reply from the receiver.

This reply, called a ‘Flow Control’ message contains

information concerning acceptable message timing,

etc., and is required to be sent before the transmitter

will send any more data. For ISO 15765-4, the type of

response is well defined, and never changes. The

ELM327 will automatically send this ISO 15765-4 Flow

Control response for you as long as the CAN Flow

Control option is enabled (CFC1), which it is by

default.

Several users have requested that we provide

more flexibility over the data sent in the Flow Control

message, and as of v1.1, we have provided a means

to do this. In order to change how the ELM327

responds when it needs to send a Flow Control

message, you need to change Flow Control ‘modes’.

The default Flow Control mode is number ‘0’. At

any time while you are experimenting, if you should

wish to restore the automatic Flow Control responses

(for ISO 15765-4), simply set the mode to 0:

>AT FC SM 0

This will immediately restore the responses to their

default settings.

Mode 1 has been provided for those that need

complete control over their Flow Control messages. To

use it, simply define the CAN ID (header) and data

bytes that you require be sent in response to a First

Frame message. If you try to set the mode before

defining these values, you will get an error:

>AT FC SM 1

You must set the headers and data first:

>AT FC SH 7E8

>AT FC SD 00 11 22

then you can set the mode:

>AT FC SM 1

From this point on, every First Frame message

received will be responded to with your custom

message.

The final mode currently supported allows the user

to set the data bytes which are to be sent, but not the

ID bits. The ID bits (header bytes) in mode 2 are set to

those which were received in the First Frame

message, without change. To use this mode, first

define your data bytes, then activate the mode:

>AT FC SD 00 11 22

>AT FC SM 2

For most people, there will be little need to

manipulate these ‘Flow Control’ messages, as the

defaults are designed to work with the CAN OBD

standards. If you wish to experiment, these special AT

commands offer that control for you.

Figure 7 summarizes the currently supported

modes:

Figure 7. Flow Control Mode Numbers

ELM327

Provides

Mode

ID Bits

Data Bytes

User

Provides

ID Bits Data Bytes

no values

ID Bits

Data Bytes

ELM327

36 of 51ELM327DSC Elm Electronics – Circuits for the Hobbyist

www.elmelectronics.com

J1939 Support

The SAE J1939 CAN standard is a relatively new

protocol that is being used in many types of heavy

machinery – trucks, agricultural equipment, and

busses, to name a few. It uses a standard CAN

(ISO 11898) physical interface, and defines its own

format for data transfer (although it is very similar to

the ISO 15765 that is used for automobiles).

The ELM327 offers some support for the J1939

standard in Protocol A. (Protocols B and C can be

selected for J1939 formatting if needed, with

Programmable Parameters 2C and 2E). Although this

is not full support as dictated by the standards, the

ELM327 implementation should at least allow you to

begin experimenting.

The default data rate for Protocol A has been set

to 250 kbps, as set by the SAE J1939-11 standard.

Should your application require a different speed, it is

easily changed with PP 2B.

J1939 messages use 29 bit CAN IDs, and up to 8

data bytes for each message (ISO 15765 always uses

8 bytes). Diagnostics on SAE J1939 are defined by the

J1939-73 standard, and the actual data transfer

protocol is described in J1939-21. If you are going to

do a lot of work with J1939, it may be wise to purchase

these standards documents from the Society of

Automotive Engineers (SAE).

The ELM327 handles the sending of messages

with the J1939 protocol in the same way as any of the

other protocols. The header bytes are predefined for

you and all you need do is provide the data bytes that

you wish to send.

For example, assume that you wish to send a

request for engine temperature (PGN 00FEEE). J1939

specifies a reverse order for the data bytes, so when

you tell the ELM327 what to send, you need to switch

the order of the data bytes, and then send them as you

would any other request:

>EE FE 00

The ELM327 then adds the required header (ID)

bytes, etc. and sends the message for you. (It also

configures itself correctly to be able to receive the

response.) Note that the ELM327 sets the header

bytes to EC FF F9 by default (for global requests from

OBD service tool #1), so if you want something else,

you will have to change the headers, using the AT SH

command.

All responses to a request are printed by the

ELM327, whether they are a single CAN message

transmission, or a multisegment transmission as

defined by the transport protocol (J1939-21). If the

responses are multisegment, the ELM327 handles all

of the negotiation for you (transparently - you won’t

see it happen). If formatting is on (ie CAF1), the output

will resemble the format used to print the ISO 15765-4

multiline responses. Note that if you provide three data

bytes, the ELM327 will assume that you are sending a

PGN, and will look for responses to that. If you send

other than 3 data bytes, it will assume that you are

making a general request, and will only look for

responses to the Source Address (as given in the third

byte of the header).

The SAE J1939 standard predefines several

Diagnostic Messages, and assigns ID values to them.

The first of these (designated ‘DM1’) are reserved for

trouble codes, which are periodically broadcast over

the CAN network. Since these are commonly required,

the ELM327 provides a special command to monitor

for them (aptly named DM1). If you wish to monitor for

all DM1 messages, simply issue:

>AT DM1

and the ELM327 will print out all that it finds.

The DM1 message is the only one that is presently

predefined by the ELM327 for you. To monitor for any

other diagnostic message, you need to know it’s PGN

number (in hexadecimal), and monitor for that using

the AT MP command. For example, the DM2 PGN

number is 65227, or 00FECB in hexadecimal. The

ELM327 requires hexadecimal, and assumes that all

PGNs begin with 00 – so to monitor for DM2s, you

need only send:

>AT MP FECB

and the IC will begin looking for all replies to DM2

requests.

Please note that the ELM327’s support for the

SAE J1939 standard is only basic (it does not support

address negotiation as described in J1939-73, for

example), and it has not undergone the extensive

testing that our automotive protocols have. We simply

have had a large number of requests for support of the

protocol, and wanted to provide something for you to

begin experimenting with. As always, we are quite

open to your feedback and your suggestions for future

upgrades.