live_decode_rules.json currently covers 20 ECUs (52b804e, 7751b4a, 9ef2d38). Every other imported catalog's live-data rows read as MeasuringBlockDecoder.NO_DATA (-) whenever their DPID falls back to the raw positional path and the byte grouping doesn't happen to line up — see DiagnosticsManager.decodeReading() / LiveMeasuringBlockDecoder.kt.
Current alignment state
Source: OpelObdToolExploration/reverse-engineering/decompiled/measblock_handlers_index.json (alignment key), the mechanical row-count gate described in COVERAGE-clean-room.md. 192 catalog↔ECU-ID= pairings total:
- 21 pass (20 shipped in the asset) — full named row-by-row decode.
- 15 are close misalignments, extracted row count off from the catalog's real count by 1–5 (e.g.
HASTRAUEC.MBF.txt 33/34, HASTRAENGZ18XE.MBF.txt 97/98, four engine variants all short by exactly 4).
- 156 extract zero rows — the extractor finds no DPID branch at all in the decompiled handler.
Two follow-up tracks
- Close-mismatch bucket (15). Same bug class as the two fixes already landed: the row-grouping mid-group boundary edge case (REC) and the float32-vs-x87-80-bit float-constant bug (9ef2d38, Hardtop — confirmed on real hardware: idle ~12.6V rising to ~14.xV on engine start). A shared extractor fix here likely flips several ECUs to "ok" at once rather than needing 15 separate fixes.
- Zero-row bucket (156).
COVERAGE-clean-room.md guesses "mostly multi-block engine ECUs" but this is unverified. Needs sampling a handful of the decompiled handlers before committing effort — could be a different codegen shape the pattern-matcher (reverse-engineering/extract_measblock_handlers.py) doesn't recognize (e.g. jump table vs if/else chain), fixable in bulk like track 1, or genuinely per-ECU manual work.
Notes for whoever picks this up
- All extraction/alignment work happens in the separate
OpelObdToolExploration repo (proprietary-catalog RE track) — this repo only ever receives the regenerated live_decode_rules.json asset.
- The alignment gate only checks row count, not value correctness — the Hardtop bug passed alignment but still returned a wrong value. Confirm any newly-covered ECU's readings against real hardware (e.g. a physically-forced delta like ignition-on vs engine-running voltage), not just the gate, before shipping.
- Keep the shipped asset numeric-only (
row/dpid/byte/factor/mask/offset) as coverage grows — no catalog label text — to stay inside the no-vendor-data policy.
live_decode_rules.jsoncurrently covers 20 ECUs (52b804e, 7751b4a, 9ef2d38). Every other imported catalog's live-data rows read asMeasuringBlockDecoder.NO_DATA(-) whenever their DPID falls back to the raw positional path and the byte grouping doesn't happen to line up — seeDiagnosticsManager.decodeReading()/LiveMeasuringBlockDecoder.kt.Current alignment state
Source:
OpelObdToolExploration/reverse-engineering/decompiled/measblock_handlers_index.json(alignmentkey), the mechanical row-count gate described inCOVERAGE-clean-room.md. 192 catalog↔ECU-ID=pairings total:HASTRAUEC.MBF.txt33/34,HASTRAENGZ18XE.MBF.txt97/98, four engine variants all short by exactly 4).Two follow-up tracks
COVERAGE-clean-room.mdguesses "mostly multi-block engine ECUs" but this is unverified. Needs sampling a handful of the decompiled handlers before committing effort — could be a different codegen shape the pattern-matcher (reverse-engineering/extract_measblock_handlers.py) doesn't recognize (e.g. jump table vs if/else chain), fixable in bulk like track 1, or genuinely per-ECU manual work.Notes for whoever picks this up
OpelObdToolExplorationrepo (proprietary-catalog RE track) — this repo only ever receives the regeneratedlive_decode_rules.jsonasset.row/dpid/byte/factor/mask/offset) as coverage grows — no catalog label text — to stay inside the no-vendor-data policy.