ECU Map Comparison: How Automatic Stage Detection Works on a Tuned BIN

A workshop receives a “tuned” file from a sub-tuner. The customer paid for Stage 2 with DPF delete. The sub-tuner delivered something. The workshop owner needs to verify, in 60 seconds, that the deliverable matches the brief — without opening WinOLS, scrolling through 50 maps, and eyeballing torque limiters.

This is the map comparison problem, and a good implementation turns a 30-minute audit into a 30-second one. The same tooling also lets a workshop verify their own engineers’ work, catch a wrong-file mix-up before the customer gets it, and detect when a third-party file someone uploads is mislabelled (“they said it’s a Stage 1 but it’s actually Stage 2”).

This post explains how automatic map comparison works at the byte level, how stage classification is derived from the diff pattern, and what’s NOT solvable by automation alone.

What “comparing two BINs” actually means

The naive view: open BIN A in a hex editor, open BIN B, look at the differences. Cells that differ are “edits”. Job done.

That’s roughly right for the visualisation. But meaningful comparison needs three layers on top of the raw byte diff:

1. Map awareness — group differing cells into the maps they belong to. “12 cells of fuel quantity map at offset 0x3C200 differ” means much more than “12 random bytes differ”.
2. Magnitude awareness — a cell that moved from 200 to 220 (10% increase) is different from a cell that moved from 200 to 800 (4× increase). The former might be a Stage 1 fuel tweak; the latter is a Stage 3 boost edit.
3. Pattern awareness — Stage 1 modifications follow predictable patterns (low-rpm fuel + mid-rpm boost). Stage 2 adds high-rpm extras. DPF delete touches specific exhaust-flap maps. Recognising these patterns is what turns “diff” into “Stage 2 + DPF Off”.

A modern portal does all three.

The byte-level diff

The base operation: walk both BINs byte by byte. Record offsets where bytes differ. For typical ECU calibrations:

• A clean Stage 1 file might have 200-600 differing bytes
• A Stage 2 file might have 600-1500
• A Stage 3 + delete combination can hit 5,000+
• A completely different file (wrong SW number) has tens of thousands

The differing-byte count alone gives a rough sanity check. If a sub-tuner delivers a “Stage 1” with 8,000 differing bytes, something is wrong — either they did more than Stage 1, or they delivered the wrong file entirely.

Mapping bytes to maps

The next step requires knowing the map locations within the BIN for the ECU family. Bosch EDC17 has fuel quantity at one offset, boost pressure at another, torque limiter at another. The portal needs an ECU definition file (DAMOS, A2L, or an internal database) that maps offsets to map names.

With map awareness, the diff becomes:

fuel_quantity_main          : 48 cells changed, avg Δ +18%
boost_pressure_target       : 32 cells changed, avg Δ +24%
torque_limiter_n_per_gear   : 16 cells changed, avg Δ +14%
egr_position_target         : 64 cells changed, avg Δ +100% (zeroed)
dpf_regen_target_soot       : 24 cells changed, avg Δ +999% (disabled)

A workshop owner reading that summary in 5 seconds knows: this is Stage 1+2 plus EGR Off plus DPF Off. They don’t need to open WinOLS to confirm.

Magnitude classification

Per map, the comparison engine classifies the change magnitude:

The “noise” classification is important — manufacturers ship calibrations with minor revisions between production batches. A file from a 2018 Audi A4 might differ from a 2019 Audi A4 of the same model by 50-200 bytes for no tuning reason. The comparison engine should filter these as “manufacturer fingerprint, not a tune”.

Stage detection from the pattern

The portal can derive a stage label from the combination of maps touched:

The labels are descriptive, not authoritative — a real tune may include modifications outside this pattern set (manual map edits the classifier doesn’t recognise). The label tells you what the engine thinks happened; the engineer still needs to verify edge cases.

What automation cannot do

Three things stage detection cannot replace:

1. Drive-feel verification. Two files with identical map edits can drive differently on different cars. Aftermarket intakes, downpipes, exhaust changes interact with the tune in ways no diff tool sees. Final verification is always on the dyno or on a test drive.

2. Safety check. A tune that pushes boost to 30 psi has the right “Stage 3” label but might be unsafe for the specific engine. The classifier doesn’t know whether the engine has reinforced rods. A human still has to decide whether the file is safe to deliver.

3. Checksum validation. A tuned file that fails checksum validation will not flash to the ECU — the ECU will reject it. The comparison engine should also verify checksum integrity, but the actual fix is a separate operation (see checksums explained).

Automation gives you the “what changed” picture. The “should we deliver this” decision is still human.

The visual side — heat-mapped delta view

The most useful interface for a tuner verifying their own work is a heat map: every cell in every map coloured by its delta. Green = small positive change, amber = large positive, red = very large or unsafe. The tuner scrolls the map grid; their eye catches the cells they touched (and the cells they didn’t realise they touched).

Compared to the alternative (opening WinOLS, loading both files side by side, manually navigating to each map and checking) the heat map is the difference between 30 seconds of verification and 15 minutes.

What this looks like in TunerSuite

TunerSuite’s Map Comparison feature loads both original and tuned BIN, runs the diff, classifies modifications against the ECU’s DAMOS / A2L definition (if available), and produces:

• Cell-level heat map per map
• Per-map summary (cells changed, average Δ, magnitude class)
• Stage detection label
• “Compatible delivery format” check (does the tuned file pass checksum and round-trip through the customer’s vendor envelope cleanly?)
• Export to PDF for inclusion in the customer’s delivery package

The tool works on plain BINs and on vendor-decrypted slave files. It’s bundled in the TunerSuite licence — £699 setup + £49.99/month — no per-comparison fee, no add-on. The AI ECU Analyzer feature handles the upstream identification side (what’s in the file before you compare).

FAQ

Can I compare two tuned files from different sub-tuners?
Yes. The comparison is symmetric — any two BINs from the same ECU family can be compared. Useful for spotting why one sub-tuner’s tune drives differently from another’s on the same SW/HW.

Does this need a DAMOS / A2L file to work?
Map-level analysis needs the ECU’s map definition. For mainstream ECU families (Bosch EDC17, MED17, MD1, Continental Simos18), definitions are widely available. For exotic ECUs, the comparison falls back to byte-level diff without map names.

What if the customer’s file fails the stage detection?
“Failed” usually means modifications don’t match a known pattern. The cause is typically: very old ECU family with non-standard maps, a third-party tune with custom maps the classifier doesn’t recognise, or a corrupted file. Inspect manually.

Can I detect tampering (someone modified a delivered tune)?
Yes — if you keep the original delivery’s SHA-256 in the customer’s job record, comparing the file the customer returns against the delivered SHA detects any modification. Useful for warranty disputes.

Does this work on encrypted slave files?
No — comparison runs on plain BINs. Both files must be decrypted first (via vendor API or because they were master files to begin with).

Next step

If you’re running TunerSuite, map comparison is available on every file request’s detail page. Open original + tuned side-by-side; the heat map renders inline.

For the upstream identification side (what’s in the file before comparison), see the Quick File Tool guide. For the conceptual side of why Stage 1 ≠ Stage 2 ≠ Stage 3, the stage comparison guide covers what each label means in real tuning practice.