OBD data: how to read it

What we learned about talking to the car, so anyone with a scan tool, an ELM327 adapter or their own code can read the same items. Everything below is read-only.

The connection

Socket: the normal OBD port (IP25). Pins 6 CAN-H and 14 CAN-L carry the diagnostic CAN, 4 and 5 are ground, 16 is 12 V, there all the time. The port also carries Ethernet (pins 3, 11, 12, 13, wake on 8); we don't use it. IP25 pins
Bus: ISO 15765-4 CAN, 11-bit identifiers, 500 kbit/s (ELM327 protocol 6).
No standard OBD-II data. The usual mode 01 and 09 requests (speed, VIN…) get nothing useful. Everything comes through UDS diagnostic requests, which the car's gateway passes on to each module.

Reading an item

Use UDS service 22, "read data by identifier", sent to one module at a time (a physical request). The broadcast address 7DF works too, but busy modules miss it, so per-module requests are more reliable.
Reply address: the request address + 8 for 7E2–7E6, 760 and 765 (7E2 → 7EA), and + 80 (hex) for the rest (720 → 7A0). The module map lists all 22.
Item numbers (DIDs) are 2 bytes, 0000–FFFF. The meaning of each is the maker's own; the item list has ours.
Several items per request work on most modules: 22 1477 1478 1479 returns all three wheel speeds in one reply. The brake module (710) refuses this; ask it one item at a time. We group up to three items per request.
The default session is enough. The extended session (10 03) unlocked nothing extra.

An exchange on the bus (hex; the first byte of each frame is the ISO-TP length / frame type):

→ 7E2  03 22 11 1A              read item 111A from the battery module
← 7EA  05 62 11 1A 00 57        positive reply (62 = 22 + 40): 0057 hex = 87, battery charge 87 %
→ 7E2  03 22 99 99              an item that doesn't exist
← 7EA  03 7F 22 31              negative reply, code 31: no such item
→ 7E3  07 22 14 77 14 78 14 79  three wheel speeds in one request
← 7EB  10 0D 62 14 77 00 00 14  first frame of a 13-byte reply …
→ 7E3  30 00 00                 flow control: send the rest
← 7EB  21 78 00 00 14 79 00 00  … and the rest

Negative replies

Code	Meaning	What we do
7F 22 31	Request out of range: the item doesn't exist.	The usual answer while exploring; move on.
7F 22 78	Response pending: the module is busy and will answer.	Wait up to about 3 seconds. Module 705 answers this to almost everything.
7F xx 11	Service not supported.	The old KWP service 21 gets this on every module.
7F 22 12 / 13	Not supported in this form / wrong length.	Ask one item per request on that module.

With an ELM327 adapter

Any ELM327-style adapter can do this. Set it up once, then send each request:

ATZ             reset
ATE0  ATL0      echo and line feeds off
ATH1            show the reply address
ATSP6           ISO 15765-4 CAN, 11-bit, 500 kbit/s
ATSH 7E2        send to the battery module
ATCRA 7EA       listen only for its replies
22 11 1A        read item 111A

Some clones need raw frames. Our GODIAG GD101 (ELM327 v1.3a) answered NO DATA to every physical request in the normal mode. What worked: ATCAF0 (no automatic formatting) and writing the length byte ourselves, 03 22 11 1A. It still sent the flow control for long replies by itself.

Speed: give the reply count. An ELM327 waits for its timeout after the last reply frame. Adding the number of frames you expect as a last digit (03 22 11 1A 1) makes it return as soon as they arrive: on our adapter one read went from 76–96 ms to 17–24 ms. The CAN bus itself is under 1 % busy, so the adapter is the limit; wiring a CAN chip straight to the port (see building a logger) would be faster still.

Finding new items

We sweep item numbers per module with service 22 and keep everything that doesn't answer 31: so far 0000–2FFF and F0xx on the main modules, over 95,000 numbers in all. 3000–EFFF is still to do. To learn what an item means, read it before and after doing one thing (lock the car, open a window), or record a drive and compare it with signals you already know: see what it can do.