0 codes across 0 modules is not proof of a clean car

When a scan tool finishes reading codes module by module, it prints a summary line. Lane Pilot's used to say "0 code(s) across 0 module(s)" on a clean car, because the second number counted modules that had codes. It printed exactly the same line when no module had answered at all. "No codes" and "no module answered" produce the same empty list, and a tool that only looks at the list will call an unread car clean. Here is what that looked like on three cars, and how to tell the two apart.

The 2015 Odyssey: a green tick over nothing

Early in the scan, the identity read (Mode 09, sent as a broadcast) got answers from two modules. On this Odyssey the bus uses 29-bit addressing, and the replies came from 18DAF111 and 18DAF11D: the engine computer at address 11 and the transmission at 1D.

Later in the same scan, the module-by-module code read finished with:

Deep scan complete: 0 code(s) across 0 module(s)

And the screen showed a green tick. The logic behind the tick was "the list of module codes is empty, so there are no codes". But the list was empty because no module had answered the code read at all, even though two of them had identified themselves earlier in the same scan.

The same scan shows a related trap. The odometer request for Honda was aimed at the engine computer at address 10, the address published for other Honda models. This Odyssey's engine computer is at 11, an address the scan had already printed.

The 2010 Impreza: silence is not absence

The Impreza's engine and transmission computers answered the identity read from 7E8 and 7E9. They also answered the standard broadcast code read, Mode 03, with two 43 00 lines: two modules, zero stored codes each.

Then the module walk asked each computer directly for its codes with the UDS request 19 02 FF. They did not refuse it. They stayed silent: no data, no negative response. The scan treated that silence as "module not present", and the summary again read 0 codes across 0 modules.

Compare a module that says no. When an older module answers the UDS code request with a negative response (7F 19 11, service not supported), the tool knows it is there and can fall back to the older request. Silence gives you nothing to act on unless you remember what answered earlier.

What a scan should do instead

Lane Pilot now works like this:

• It remembers who answered. The addresses that replied to the identity read are kept for the rest of the scan.
• It counts what it actually read. The summary line now always says how many modules were actually read. When that number is zero, the line says NO MODULE READ and is logged as a warning, never as a success.
• It marks a walk that read nothing. If the identity read found modules and the module walk read no module at all, the scan sent to the diagnosis and stored with the job is marked partial, the diagnosis is told that module-level faults are unread, and the Share button refuses its ready-made "No faults detected" customer summary. On the review screen, a walk that read nothing is never shown as "no codes found", whether or not the identity read ran.
• It retries the old way, only where it makes sense. When a module that answered identity goes silent on the UDS code request, the scan retries that module with the older code request, Mode 03. Addresses that never answered anything keep their single quick timeout, so a scan does not slow down chasing modules that are not there.
• It says where an answer came from. On a car with standard 11-bit addresses, if the module still will not answer directly but the broadcast Mode 03 read found zero stored codes, the log says exactly that: "no stored codes per this scan's broadcast Mode 03 — module does not answer physically-addressed DTC reads (pre-UDS). Pending/permanent status not read." The module's row reads no stored codes — via broadcast Mode 03. It is a different status from a direct read, so nothing downstream mistakes it for one.

What the honest version looks like: a 2008 Wrangler

The check engine light was on, and the standard broadcast read found four stored codes. The module walk then tried 13 modules and read none of them. The summary line began:

Deep scan complete: NO MODULE ANSWERED — 0 of 13 module(s) read. This is not a clean vehicle, it is an unread one.

The rest of the line accounted for all 13: 11 addresses silent, and 2 that answered but could not be read. That is the line the Odyssey should have had, with one flaw: its headline overstated the silence, because 2 of the 13 did answer, with refusals. On the Wrangler, a green "0 codes" would have sat on top of a lit check engine light and four real codes.

Since 2026-10-02, the same 13 module results produce a line whose headline agrees with its own count:

Deep scan complete: NO MODULE READ — 0 of 13 module(s) read, 11 address(es) silent, 2 answered but unreadable (no DTC verdict), 1 discovered beyond the static map. This is not a clean vehicle, it is an unread one.

When the Wrangler was scanned, the rest of the app did not treat its walk as unread. This scan was marked partial anyway, because its permanent-code read went unanswered, not because of the walk. The deep-scan line on the review screen could still say no codes were found in any module, and the diagnosis did not get the warning that module-level faults were unread. The check meant to catch a walk like this looked for an empty list of modules, and in practice a walk does not return one: every address it tries leaves a row, even a silent one. Across the 110 module walks in Lane Pilot's stored debug captures, not one came back empty, and no stored diagnosis carries the flag. Since 2026-10-01 the check asks whether any module was actually read. On the review screen, this Wrangler's walk now reads "No module was read — 11 address(es) silent, 2 answered but could not be read. This is not a clean result. Re-scan to confirm." The change is covered by tests built from this Wrangler's own walk, and has not yet been seen on a live scan.

What to look for in your own tool

1. Read the module count, not just the code count. "0 codes" means something only next to how many modules actually answered.
2. Compare against identity. If the tool printed calibration IDs or ECU names from modules that later "weren't found", the code read failed. The car did not lose a computer.
3. Silence and a negative response are different answers. A negative response proves the module is there. Silence proves nothing on its own.
4. "Pending and permanent not read" is information. A tool that cannot read those statuses should say so instead of leaving them blank.