samplez/tunie/research/reference-maps/DEVICES.md

Device-enable flags (SAI / O2 / lambda) — validated

Aug 2026 update: re-fetched 20188Map2009AIRBOXBONNY.hex from its real source — it's in tuneecu.net's own custom-map archive (Twin_Custom_Tune_list.html, not a forum attachment as previously assumed), not gitignore-lost this time. Re-ran the diff against a freshly downloaded stock 20188Map.hex and every claim below reproduced exactly: same 1428-byte diff (0.36%), same three device-flag bytes, same two trim bytes. The file now lives in this directory (20188Map2009AIRBOXBONNY.hex, 20187/88/91/92Map.hex) rather than resting on memory of a prior session. See ../COMMUNITY_TUNING.md for the new composability findings (device flags vs. Arrow exhaust delta) this re-verification enabled.

How they were found

Both stock reference maps (20187, 20188) have SAI and O2 active, so diffing them can't reveal the delete flags. The confirmation came from a community map that explicitly disables them:

20188Map2009AIRBOXBONNY.hex — "Bonneville, aftermarket exhaust, mechanical odometer, NO AIR BOX, K&N, British Custom mufflers, NO SAI, NO O² SENSORS". Same base as stock 20188, so the diff isolates the deletes.

Diff (flat ROM) of that map vs stock 20188 = 0.36%, split into:

• the fuel tables (airbox/K&N enrichment — expected), and
• a small cluster in the device-config region at 0x53801…0x53819.

The flags

They are a byte-boolean array at flat-ROM base + fe[33] (= 0x50000 + 0x3801 = 0x53801), one byte per device, 1 = enabled, 0 = disabled.

The delete map changed exactly three bytes from 1 → 0:

Flat-ROM offset	Stock	Deleted	Device
0x53801	1	0	SAI (Secondary Air Injection)
0x53818	1	0	O2 sensor
0x53819	1	0	O2 sensor (2)

SAI is the first flag in the array; the two O2 sensors are the last two — consistent with the Devices resource order (SAI = index 0; O2 Sensor / O2 Sensor (2)). The three-byte change matching "NO SAI, NO O²" is unambiguous.

To disable a device: set its byte to 0. (The 0x5369C/0x536AB bytes that also changed are idle/open-loop trim that comes with removing the O2 feedback, not device-enable flags.)

Editing / export

The downloaded .hex format's integrity is the dc stream cipher + the unpack directory; the caXX bytes in the header/tail are map-ID metadata, not a calibration checksum. So a device toggle = flip the byte in the flat ROM, re-pack to the decoded layout, and dc-encode back to .hex. (The separate ECU flash checksum is computed at flash time and is out of scope for the read/edit tool.)

Confidence

• SAI = 0x53801: ~90% (high). Two independent confirmations: the device-name logic in l.java lc() resolves Devices[0]=SAI via fe[33] to exactly 0x53801, AND the real NO-SAI map cleared precisely that byte.
• O2 sensors = 0x53818 / 0x53819: ~80% (probable). The map declares "NO O² SENSORS" (the twin has two) and exactly two adjacent boolean bytes cleared beyond SAI; the 865 has no air-flap, so airbox removal is fuel-only (no flag). Not independently isolated — no single-mod reference map exists, and the exact x.a() device-layout branch for this ECU (i27=72) is too deeply nested to trace reliably.

The real-world caveat (more important than the labels)

Correct flags are not a good tune by themselves. Disabling O2 forces the ECU open-loop: it stops live fuel trim and runs entirely on the base fuel map. Stock maps assume closed-loop trim at idle/cruise, so an O2-delete on an otherwise stock map can run lean/rough. A proper delete pairs flags-off with fuel enrichment (which is exactly why the AIRBOXBONNY reference map also changed the fuel tables).

Recommendation: flash a complete, known-good delete map matching the hardware (exhaust/filters), not hand-toggled flags on a stock map. The checkbox editor is for understanding/building a map, not a one-click safe delete.

0x53822 — the extra flag found on the America dyno tune (Aug 2026)

Pushed on identifying this (index 33 past the 0x53801 base, one slot past the two O2 sensors — see COMMUNITY_TUNING.md's original finding on 20184dynoTuneSteveO2-Disable.hex). Real, bounded progress, not a full resolution:

Found the actual device name list — R.array.Devices in arrays.xml:3-18, 15 entries: SAI, Exhaust Valve, O2 Sensor, 2nd Throttle, Air Flap, EPC, O2 Sensor (2), Purge Valve, Idle Speed Control, Traction Control, Immobilizer, Instruments, ABS, Speed Sensor (non ABS), Race ECU. This independently confirms and extends the existing SAI(0)/O2 Sensor(23)/O2 Sensor(2)(24) findings above — matches exactly, real data.

Found the mechanism: l.java's lc() (l.java:5742) resolves the per-device flat-ROM byte-boolean array from three packed nibble-encoded constants (x.t/x.s/x.q in the decompile referenced by docs/ROADMAP.md), looked up against R.array.Devices by index. This confirms flat-ROM byte position and Devices[] array index are not the same thing — SAI (array index 0) sits at byte 0, but O2 Sensor (array index 2) sits at byte 23, O2 Sensor (2) (array index 6) sits at byte 24 — a bike-specific sparse remapping, not a fixed formula.

Where it stops: the specific per-family constants that would decode byte 33 precisely require tracing which branch of x.java's ~46 assignments to the relevant classifier variable applies to Bonneville/T100 specifically. docs/ROADMAP.md's existing note cites i27=72 as the anchor for this ECU family from a prior research pass, but that exact comparison doesn't appear in this decompile snapshot — likely version drift (this decompile's changelog shows APK updates through v6.4.36, June 2026; the i27=72 note may predate that). Didn't find a reliable replacement anchor without a much larger, low-confidence search across all 46 assignment sites.

Best-supported guess, reasoning not proof: narrowing the 12 unassigned Devices[] names by plausibility for a 2010 mechanical-odo Bonneville/ America-class twin — Purge Valve (this project's own system1.html research already documents a "Canister Purge Valve, California models only" on this ECU family — a real, independently-corroborated candidate), Idle Speed Control (the ISC stepper motor genuinely exists on this engine), and Immobilizer (period-correct fuel-injected Triumphs commonly used transponder immobilizers) are the most plausible of the 12; Exhaust Valve, 2nd Throttle, ABS, Traction Control, Race ECU are implausible for this specific bike/era and can likely be ruled out. Not confirmed — a genuine guess ranked by plausibility, not a finding.

Update (Aug 2026) — independently verified, raises confidence further: checked tests.html in this project's own site mirror directly and found a distinct, real testable menu entry: "Purge Control Valve (Only bikes with charcoal canister) — Activate the purge valve, listen for a very quiet noise," listed right alongside its own separate "SAI" test entry. This confirms Purge Valve is a real, independent device on this ECU family with its own dedicated test/enable path, not a guess — genuinely strengthens (does not yet prove) the byte-33 hypothesis. Also confirms from the same list: "Air Flap (675 Daytona)" is explicitly Daytona-675-only, matching this document's elimination reasoning above. (Surfaced by an external research pass, then independently confirmed here directly against this project's own source rather than trusted secondhand — see ../EXTERNAL_RESEARCH_NOTES.md.)

What would actually resolve this: a second real-world reference map where the specific device at byte 33 changes state with a documented description (the same technique that resolved SAI/O2 originally) would settle it definitively without needing the x.t/x.s/x.q trace at all.

Open question raised by community research (unresolved)

Multiple forum threads describe TuneECU's own SAI/O2 checkboxes (the same UI these bytes drive) as only suppressing the fault-code/CEL logic, not actually forcing open-loop fueling — see ../COMMUNITY_TUNING.md. That's in tension with "disabling O2 forces open-loop" above. Possible reconciliation: the three device-enable bytes gate DTC logic only, and the fueling behavior change lives in the other bytes the real delete-map diff also touched (0x5369C, 0x536AB) or in the lambda-target curve (fe[2]/0x52260, TABLES.md). Not yet isolated — needs a second independent delete-map diff to separate device flags from fuel/trim bytes.