Communication with the ELM327

The ELM327 is a translator between a serial text interface and the OBD-II buses of the vehicle. obd-diag sends it text commands and reads its responses up to the prompt >. The basis is the datasheet ELM327DSJ (firmware v2.1, Sources).

Line

• Serial, 8 data bits, no parity, 1 stop bit; 38400 or 115200 baud.

• Every command is upper-case ASCII without spaces and ends with exactly one CR (\r). A lone CR would repeat the last command and is therefore forbidden (datasheet p. 9, Command reference).

• The adapter answers with lines separated by CR and finishes with >.

• Before every write, SerialTransport empties the input buffer so that no old response is taken for the new one.

Course of a session

        sequenceDiagram
    participant T as obd-diag
    participant E as ELM327
    participant F as Vehicle
    T->>E: ATZ
    E-->>T: ELM327 v1.5 >
    T->>E: ATE0, ATL0, ATS0, ATH0, ATSP0
    E-->>T: OK > (per command)
    T->>E: 0100 (up to 30 s)
    E->>F: protocol search, then 01 00
    F-->>E: 41 00 …
    E-->>T: SEARCHING... 4100BE3FA813 >
    T->>E: ATDPN, ATDP
    E-->>T: A6 > / AUTO, ISO 15765-4 (CAN 11/500) >
    T->>E: ATRV
    E-->>T: 12.4V >
    T->>E: 03, 07, 0A, 0101, 020200, 0902 …
    

Step	Command	Purpose
Reset	ATZ	adapter as after power-on; the last response line is the identification
Echo off	ATE0	the adapter no longer repeats the command
Linefeed off	ATL0	only CR as line end
Spaces off	ATS0	4100BE3FA813 instead of 41 00 BE 3F A8 13
Headers off	ATH0	only the data, without CAN ID
Protocol automatic	ATSP0	the search starts with the first OBD request; does not write to the EEPROM
Negotiate the protocol	0100	supported PIDs; answered by every OBD-II vehicle
Report the protocol	ATDPN, ATDP	number (6 = CAN 11 bit 500 kbit/s) and name
Battery voltage	ATRV	voltage at the OBD socket

All commands with datasheet page and quote are listed in the Command reference.

Timeouts

Case	Timeout	Reason
every command	10 s	if a control unit reports 7F xx 78 (response pending), the ELM327 itself waits up to 5 s and starts again with every further 78 (datasheet p. 45)
first 0100 after ATSP0	30 s	the protocol search tries several protocols; with K-Line a single connection setup already takes 2 to 3 s (p. 33, 36)
trouble codes after 7F <Mode> 78	keep reading up to 5 s	without sending again
clearing after 7F 04 78	keep reading up to 10 s	mode 04 is never repeated

Detecting the protocol

Whether the vehicle speaks CAN decides how trouble code responses are read (Response formats). obd-diag asks ATDPN:

• 6 to C (also with a leading A for “found automatically”) is CAN, 1 to 5 are older protocols (J1850, ISO 9141-2, KWP2000).

• If the adapter reports 0, ? or nonsense, 0100 is repeated once if there was no answer, and ATDPN is asked again.

• If the number remains unclear, 0100 is sent once with headers (ATH1), and their form shows whether it is CAN 11 bit, CAN 29 bit or an older protocol. The protocol name then carries the addition “according to headers …”.

Cleaning up responses

Before evaluating, Elm327.command removes:

• the echo of the command, also in a different spelling (at dpn for ATDPN), but only before the actual response;

• status lines SEARCHING... and BUS INIT: ...OK;

• empty lines, null bytes and lines of pure garbage (some clones send e.g. a byte FC after ATZ).

Then:

Response	Result
NO DATA	no control unit answered; query returns None
?	the adapter does not know the command (UnknownCommandError)
UNABLE TO CONNECT (also BUS INIT: …UNABLE TO CONNECT)	NoConnectionError (an ElmError): no control unit found, usually the ignition is off; command line and user interface say what to do
CAN ERROR, BUS ERROR, BUS BUSY, BUFFER FULL, DATA ERROR, FB ERROR, STOPPED, ERRxx, LV RESET, … <RX ERROR	ElmError, even if partial data has already arrived
hex data	on to Response formats

An unplugged adapter (input/output error) becomes TransportError (“Connection to … lost”), missing responses become TransportTimeout. Both abort the procedure; after that nothing more is sent.