A late OK from the ELM327: one answer behind, phantom modules

A scan tool talking through an ELM327-style adapter has to match every reply to the command it belongs to, and the simple way is to take whatever arrives next as the answer to the command just sent. That works until the adapter answers late. Then every reply after that point belongs to the command before it, and the tool starts drawing conclusions from the wrong answers. This note shows the exact moment it happened on two cars, and the one rule that untangles it.

The 2015 Prius: a healthy car, an adapter reset for no reason

The adapter on this scan was slow. The Bluetooth connection took 12 seconds, ATZ took 1.2 seconds, and ordinary adapter commands were taking 600 to 800 ms against about 100 ms on other scans that day. The car itself was fine and answering everything.

The scan had just finished trying the odometer and was switching back to broadcast requests (AT SH 7DF), then sending 01 00 to check the switch worked. Here is the log, with what each line really was:

+01:28.487  TX  ATH0
+01:29.288  TX  AT SH 7DF
+01:29.986  RX  OK
+01:29.986  TX  0100
+01:30.632  RX  OK
+01:30.632  TX  ATWS
+01:31.111  RX  4100BE3FA813
+01:31.141  RX  4100983A8013

OK is not a possible answer to 01 00, so the scan decided the bus had failed and sent ATWS, a warm start. The log said so in plain words: "broadcast restore failed verification — performing Warm Start (ATWS)". The adapter lost its configuration and the scan re-initialized it from scratch. The two real replies at +01:31 are byte-identical to the same request at the start of the scan. Nothing on the bus had failed.

The reset did not fix the pairing, either. About four and a half seconds after it, 01 42 was answered by OK, and its real reply, 41 42 2E C4, arrived after the next command had gone out.

Phantom modules

The quieter damage was in the module list. That scan reported these as confirmed present:

ECM (first responder), ECM,
700, 747, 7C0

Addresses 700 and 747 never sent any data. Each was asked 22 01 03, and what landed in their reply slots was the late OK from the AT CRA command before them, followed by STOPPED. Only 7C0 really replied.

So a late OK can make an absent module look present. That is the mirror image of the usual trap, where a silent address looks the same as a missing module. Anything built on "which modules are there" inherits the error.

Not just a slow adapter: the 2013 MINI R56

It would be easy to blame the failing adapter. A second capture shows the same pattern on good hardware. On a 2013 MINI R56 with a healthy adapter reporting ELM327 v2.2, AT CEA 60 got no reply within its timeout. The scan gave up on it after about 1.3 seconds and moved on. From then on every reply ran one slot behind:

• The slot for 22 D1 0D got a bare OK, most likely the late answer to AT CEA 60.
• Its real answer, 660 F1 03 7F 22 12 (a negative response from the instrument cluster, 12: sub-function not supported), landed in the slot for the next adapter command, AT CRA 618, followed by STOPPED.
• The same stale bytes showed up again in the slot for 22 DA 23.

The scan behaved honestly there: no mileage was decoded from the wrong bytes, and nothing was reset. But it shows a slow adapter is not the only trigger: an adapter command that misses its timeout does the same thing, on good hardware.

Why a longer timeout is not the fix

The tempting fix is to wait longer for each reply. That only moves the race. The next adapter that is slower than the new timeout lands in the same place, and in the meantime every scan is slower. The problem is pairing replies by arrival order, so the fix has to be in the pairing.

The rule that untangles it

An ELM327 only ever answers a bare OK to its own adapter (AT) commands. A request to the vehicle never gets a bare OK back. So when a bare OK shows up in a vehicle request's slot, it is the late acknowledgement of an earlier adapter command. What Lane Pilot does now, on both its Bluetooth and its USB/serial paths:

• A reply made up only of OK (once, or repeated) in a vehicle request's slot is discarded, and the scan keeps waiting for the real answer on the request's original deadline. The next reply re-pairs the stream instead of shifting everything after it.
• Adapter commands still accept OK as their answer, and a reply that mixes OK with data is parsed as before.
• The deadline is never extended.
• If the deadline runs out after a discarded OK, the module is shown as undetermined, never as absent, because the adapter clearly did answer something.
• The log records each one as Stale adapter "OK" discarded, naming the command whose slot it landed in.

The fix is covered by tests that drive the real receive code with these patterns. We have not yet recorded it firing on a real scan with a slow adapter, so that log line from a real car is still owed.

What to look for

• An adapter reset (ATWS or ATZ) in the middle of a scan on a car that has no communication fault.
• A module list that includes addresses which never returned any data.
• The same reply bytes appearing in two slots in a row, or real data arriving just after the next command went out.
• A slow adapter. On the Prius, ordinary AT commands were taking 600 to 800 ms, against about 100 ms on other scans that day.

If you build scan software: pair by content, not by order, and only count a module as present when it answered with data.