Response formats¶
After cleaning up (Communication with the ELM327), hex text remains. How to read it depends on whether
headers are on, whether the vehicle speaks CAN and whether the response fits into one
CAN frame. All examples on this page are checked against the code by
tests/unit/test_docs_examples.py.
Without headers (normal case, ATH0)¶
Single-frame response¶
Each line is the complete response of one control unit. If two control units answer (engine and transmission), there are two lines.
410C1AF8
Bytes |
Meaning |
|---|---|
|
positive response to mode 01 (mode + |
|
PID 0C, engine speed |
|
data A, B: (256 · 26 + 248) / 4 = 1726 rpm |
Multi-frame CAN response (ISO-TP)¶
If a response does not fit into one CAN frame (more than 7 bytes), the ELM327 assembles it itself and writes it like this (datasheet p. 42 ff., “Multiline Responses”):
00A
0: 430404200133
1: 0300C100
Line |
Meaning |
|---|---|
|
length of the payload: 10 bytes (hex) |
|
frame 0: mode byte |
|
frame 1: two more codes; padding would be cut to the length |
Result: four stored codes P0420, P0133, P0300, U0100. The frame numbers run from 0
to F and then start at 0 again. If a frame is missing or the order is wrong,
split_messages raises a FrameSequenceError instead of returning wrong data.
With headers (ATH1)¶
If two control units send multi-frame responses at the same time, the ELM327 mixes
their frames without headers (datasheet p. 45, example 09 04); assigning them is then
impossible. obd-diag detects this from gaps in the numbering or incomplete messages and
repeats the read request once with headers. Afterwards ATH0 is set again; if that
fails, the session aborts so that nobody keeps reading wrongly.
With headers every line carries its sender, and the frames are assembled per control unit according to ISO 15765-2:
7E8 10 0A 43 04 04 20 01 33
7E9 04 43 01 01 71
7E8 21 03 00 C1 00 00 00 00
Part |
Meaning |
|---|---|
|
CAN ID (11 bit) of the responding control unit: engine and transmission |
|
PCI first frame: type 1, length 0x00A = 10 bytes; then 6 data bytes |
|
PCI consecutive frame number 1; up to 7 data bytes, padding at the end is cut off |
|
PCI single frame with 4 data bytes |
Result, ordered by control unit address: 7E8 reports P0420, P0133, P0300, U0100;
7E9 reports P0171.
Format |
Example |
Header |
|---|---|---|
CAN 11 bit |
|
3 hex digits CAN ID |
CAN 29 bit |
|
4 bytes, OBD responses |
J1850, ISO 9141, KWP |
|
3 header bytes (priority, target, source), 1 checksum byte at the end |
The checksum byte of older protocols is removed but not checked; the ELM327 discards
faulty messages itself or reports <DATA ERROR.
Trouble codes: the count byte with CAN¶
With CAN the mode byte is always followed by a count byte (SAE J1979), then two bytes
per code. Bytes after the counted codes are padding and are ignored; if there are too
few, the response is broken (ValueError). Older protocols have no count byte and pad
every line with 00 00 to three codes.
Protocol |
Response to |
Codes |
|---|---|---|
CAN |
|
count byte |
CAN, no codes |
|
count byte |
J1850/ISO 9141/KWP |
|
P0420, P0133; |
Whether it is CAN comes from ATDPN (Communication with the ELM327). A response without count byte
with CAN is deliberately not tolerated. The ELM327-emulator leaves out the count byte;
the tests correct this, not the product code (Testing without a car).
Rejections (7F)¶
A control unit can reject a request with 7F <Mode> <reason> (codes according to
ISO 14229-1 / ISO 15031-5).
Response |
Meaning |
obd-diag |
|---|---|---|
|
mode not supported |
“no codes of this kind from this control unit” |
|
busy, repeat later |
error, never “no codes” |
|
conditions not correct (e.g. engine running) |
clearing aborts, the backup remains |
|
response pending |
keep reading up to 5 s without sending again; any later positive response counts as the announced one |