Last week I left the Honda dealership with a 2018 Accord Sport - the 1.5-liter turbo model. It came with high mileage and the potential for several well-documented issues. This model’s engine has oil dilution issues.

Honda’s remedy for the fuel-in-oil problem was to bundle an engine software update - because the cause is thermal. The patch was to adjust engine operating temperatures. The obvious question then - does my car warm up adequately in Maryland weather, and what happens when it doesn’t?
Years before I came across this car, it was already grading itself. While driving, modern cars run self-tests on emissions-related hardware - catalyst efficiency, oxygen sensors, etc. Each test produces a measured value, the manufacturer’s own limits for it, and a pass or fail. Some run constantly; others wait for conditions that might not come around for days. Then it writes the new results over the old ones… What if we flipped that dynamic?
I say: keep them, because failure was never the interesting part. A fault code is just a test that finally failed. I want to capture the trendline before that, the result quietly walking towards the test’s failing limit. From what I can tell nobody keeps that walk; the car overwrites the previous result and the scan tool reports the value blindly and moves on. Mechanics have read Mode 06 this way for over a decade, always in the present tense.
What the car measures
A number walks toward its limit for eight months.
Every step is measured. None of it is written down.
What anyone sees
The car keeps one slot, not a history.
The first thing you learn is that it already failed.
Schematic, not measured data - the point is that the measurements aren't kept.
Additionally, the tools barely scratch the surface. Many of them, both commercial and open-source, never leave Mode 01 (live sensor data). Mode 06 sits one channel over, carrying graded self-tests with pass/fail reference ranges. Lower still? Raw frames straight off the CAN bus, manufacturer broadcasts with low/no public documentation; the modules are chattering to each other in a cryptic dialect Honda never published. There are no locks on the door, but no signs on them either. Just how much is down there, how little of it anyone keeps, and what you’d gain by keeping it - that’s the thread I’ll pull in later posts.
So the plan is deliberately scoped: keep every reading my car produces, on a time axis, and watch the margins. Commercial trend tools have to learn what “normal” looks like across thousands of vehicles; this works on a fleet of one precisely because Mode 06 ships the manufacturer’s own limit inside every record. Capture continuously, store durably, reproducible by a stranger. The bet: a monitor drifting toward its limit is visible months before a code sets.
I went looking to buy this before I went looking to build it. No luck there, so I started building it. My first attempt framed the bytes wrong, which I only noticed when I checked my output against python-OBD - a story for the next post. I rewrote my decoder in Rust with equivalence against that same reference as the acceptance bar, packaged so nix build gets you the exact binary I run.
One caveat: the hardware hasn’t arrived, so none of this has met a real car yet. The first thing I’ll learn is whether this ECU volunteers enough Mode 06 to be worth charting; if it doesn’t, whatever’s worth watching may be hiding further down, on channels with no names. The car’s been keeping score since 2018, but this time I’m writing it down.
The full mode map - and the one that isn’t on it
| Mode | Name | What it’s for | Does anything remember it? |
|---|---|---|---|
| 01 | Current data | live sensor PIDs | No - the present tense only |
| 02 | Freeze frame | a snapshot captured when a code set | Yes - one frame, until cleared |
| 03 | Stored DTCs | confirmed check-engine codes | Yes, until cleared |
| 04 | Clear | wipes codes and monitor results | It’s the eraser |
| 05 | O₂ monitor results | pre-CAN only; folded into 06 on CAN cars | Not applicable here |
| 06 | Monitor test results | graded self-tests, with the maker’s limits | Until the next drive cycle. That’s this whole post. |
| 07 | Pending DTCs | codes from this cycle, not yet confirmed | Briefly |
| 08 | Control | commanding components and actuator tests | Not applicable |
| 09 | Vehicle information | VIN, calibration IDs | Identity, not history |
| 0A | Permanent DTCs | codes you are not allowed to clear | Yes - and you can’t erase them |
| 22 | ReadDataByIdentifier | manufacturer-defined identifiers | Whatever the maker decided, documented nowhere |
Two notes. “Mode” is the pre-CAN word; SAE calls them Services on CAN vehicles, which is why you’ll see both, and why Mode 05 is a ghost on anything modern. And Mode 22 isn’t OBD-II at all - it’s a UDS service layered on the same connector, addressing identifiers each manufacturer defines for itself. Manufacturers do expose extra data through it; Honda’s identifiers aren’t publicly documented, and the specific ones you’ll find quoted online are mostly reverse-engineered, frequently borrowed from other makes, and worth trusting only after you’ve watched them come off your own car.
Full mode reference: OBD-II PIDs.