ISO-TP (ISO 15765-2): how long diagnostic messages travel on CAN

CAN was designed for short, frequent control messages — wheel speed, throttle position, engine RPM. A classic CAN frame carries a maximum of eight data bytes.

Diagnostics needs to move much larger objects: a 17-character VIN, a list of supported PIDs, a calibration verification number, a full list of stored codes. ISO 15765-2, universally called ISO-TP, is the transport layer that makes that possible.

The problem in one line

Eight bytes per frame. A VIN is seventeen characters. Something has to split the message and put it back together.

Single frames

When the payload fits, ISO-TP uses a single frame. The first byte encodes the frame type and the length, leaving seven bytes of data.

That covers most everyday requests. Asking for engine RPM and getting an answer back is a single frame each way, which is why simple live data is fast.

Multi-frame transfers, and the flow control handshake

Anything longer than seven bytes becomes a multi-frame transfer, and the sequence is worth knowing because its failure modes are visible to users.

1. First frame — the sender announces the total length and sends the first chunk.
2. Flow control frame — the receiver replies with three things: whether to continue, the block size (how many frames to send before pausing for another flow control), and the separator time (the minimum gap between consecutive frames).
3. Consecutive frames — the remainder, each carrying a rolling sequence number so gaps are detectable.

The receiver dictating pace is the important bit. A slow module can ask the tester to wait between frames, and a tester that ignores that request causes the module to drop the transfer.

Why this explains real adapter problems

Several familiar complaints are ISO-TP problems wearing a different hat.

“The VIN will not read.” VIN retrieval through Mode 09 is a multi-frame transfer. An adapter with a broken or partial ISO-TP implementation returns simple single-frame values happily and fails on anything longer. This is one of the most reliable ways to catch a poor-quality clone — see how to spot a fake ELM327 clone.

“It reads some data but times out on the code list.” Reading many stored codes at once is multi-frame. Same cause.

“It works on my friend’s car but not mine.” Different modules request different separator times. An adapter that transmits too fast works with tolerant modules and fails with strict ones.

“It was fine, now it drops out.” Interference or a marginal connection corrupts one consecutive frame; the sequence number check fails and the whole transfer is abandoned. Bus integrity matters here — CAN bus fundamentals.

Addressing

ISO-TP defines how tester and module identify each other. In the standard OBD-II arrangement:

• The tester broadcasts a request on a functional address, typically 0x7DF.
• Each ECU responds on its own physical address, in the 0x7E8–0x7EF range.

That range is why a car can have several responding modules and why a tool can show you which one answered. Physical addressing lets a tester talk to one specific module rather than everyone at once, which is how manufacturer tools reach individual controllers.

Where it sits in the stack

Layer	What it does
Application	OBD-II modes, or UDS services
Transport — ISO-TP	Segments and reassembles long messages
Network — ISO 15765-4	OBD-II specific CAN parameters
Data link — CAN	Frames, arbitration, error handling
Physical	Two twisted wires, 120 Ω terminated

Generic OBD-II sits on top of ISO-TP. So does UDS. Understanding the transport explains behaviour in both.

Wider protocol context: OBD-II protocols explained.

CAN FD changes the arithmetic

CAN FD raises the payload from 8 bytes to up to 64 and allows a faster data phase. Multi-frame transfers become far less common, and large objects move much more quickly.

It also means an adapter built only for classic CAN cannot talk to a CAN FD bus at all. On vehicles from roughly 2020 this is a genuine buying consideration — CAN FD explained and how to choose an ELM327 adapter.

And DoIP replaces it entirely

On Ethernet-based diagnostics the whole segmentation problem disappears, because TCP/IP already solves it. See DoIP explained.

What this means for you practically

You will never configure ISO-TP by hand. What the knowledge buys you is interpretation: when an adapter reads RPM perfectly and cannot fetch a VIN, that is a specific, diagnosable limitation rather than a mystery — and it usually means the adapter, not the car.

Try it on the free tier of the app — pair an ELM327 adapter and request the VIN as your first test. It exercises multi-frame transfer end to end, so an adapter that returns it correctly has proved something a simple RPM read never could.