Dev
blog

2 November 2026 On the bench Not in a release

A simpler ME7.5: one VE table, and a boost controller you can reason about

ME7.5 is a very good engine management system that is hard to tune. Not because any one map is complicated, but because the answer to "how much air is in the cylinder" and "how much wastegate duty do I need" is spread across a dozen maps that all lean on each other. Change one and three others move. That is fine for a factory with a calibration team and a dyno cell. It is not fine for someone with a laptop and one car.

This is the start of a simplified ME7.5. Not a rewrite. Knock control, closed-loop fuelling, adaptation, the torque model and every fault reaction stay exactly as Bosch wrote them. What changes is how you tell the ECU about air and boost.

Air: one table

The factory works out cylinder filling from manifold pressure through several maps of conversion factors and temperature corrections. That becomes a single table of volumetric efficiency, in percent, against rpm and manifold pressure. Air temperature is corrected for in the calculation, not in another map.

The scale is chosen so 100 % VE means the same thing as 100 % load does to ME7: a cylinder filled at sea-level pressure and 0 °C. Every factory function downstream keeps receiving the number it already understands, so fuelling, ignition and knock control do not know anything has changed.

It goes in in two steps, on purpose:

• First, logging only. The VE load is calculated and logged next to the factory's own load, and the engine keeps running on the MAF. Wherever the two disagree, the log says by how much, and the table can be filled from real driving with the MAF as the reference.
• Then, driving. With a manifold pressure sensor fitted, the VE table takes over and the MAF comes off.

Filling a VE table from logs against a sensor you already trust is a lot safer than guessing one and finding out on the road.

Boost: base duty, plus a little correction

The factory boost controller is a full PID with a linearisation map in front of the output, an adaptive limit on the integral, and a pile of conditions. It works. Tuning it is mostly trial and error.

The new one is the controller most people actually want:

Tuning order is the order you would guess: get the base table landing close on its own, add proportional gain until it holds target without hunting, then a touch of integral for the last bit of steady error. The boost target itself stays the factory one, driven by the torque model, so the car still asks for boost the way it always did. Everything after the controller, including the fault reactions that shut the wastegate valve off, is untouched.

It ships switched off, and with the base table at zero. Turning it on before it is tuned gives you no boost, not too much.

Tuned live

All three new tables sit on the live tuning work: they can be held in RAM and edited with the engine running, no flash cycle between changes. That is most of the point. A VE table and a base duty table are exactly the kind of thing you want to adjust while watching the log move.

How it was checked

The new code was run in simulation, inside the factory code around it, on the built file: 36 checks covering the table layouts, interpolation, the load calculation against the formula across pressure, VE and air temperature, each mode, the controller's gains and limits, and the off state being byte-for-byte factory behaviour.

The tooling earned its keep along the way. A test that compares our assembler's output against instructions taken from the factory image caught a wrong encoding on the divide instructions. None of the shipped patches had used them, and none will with it wrong.

Where it stands

• VE load  simulated; logging mode ready to go on a car
• Boost controller  simulated; not on a car
• Live editing  firmware side ready; the tuner's editor for the new tables is next
• Driving on VE  needs the pressure sensor step, after the table has been filled from logs

2 November 2026 On a car Not in a release

Antilag on a 2.0, rotational idle on a V8, and a trace that tells the truth

A round-up of the smaller pieces from the last week.

Rolling antilag on a 2.0

The 2.0 work from last month puts 1.8T software on a 2.0 8v ECU. The current rolling antilag and launch build went straight onto that file, on a naturally aspirated 2.0, and it works: it latches and holds rpm on the brake the way it does on the 1.8T. Antilag on an engine with no turbo is mostly a party trick, but it proves the 1.8T patch carries across to the 2.0 hardware unchanged, which is the part that matters. Rotational idle has gone onto the same file and is next to be logged.

Rotational idle on the 4.2 V8

Rotational idle has been ported to the 4.2 V8 on ME7.1.1, as a standalone test file kept separate from the live tuning work on that car. Same gesture, three brake taps, same bounce behaviour. The differences are the ones you would expect from twice the cylinders:

• Four of eight cut by default. That is the same half of the engine as two of four on the 1.8T.
• Two banks. Each has its own lambda target and its own closed loop, so both are held while it runs.
• The cut rotates through all eight, so it is never the same cylinders going cold.

86 checks in simulation, including every hook run inside the factory code around it. It is with a tester and has not run yet.

Map switching on the 1.8T

The two-mode switching from the B6 is now on the 1.8T. Engine off, ignition on, hold the throttle down and press the brake: the tach needle shows which mode you are in, 1000 or 2000 rpm, and pressing again switches. Mode 1 holds the wastegate at a fixed low duty; mode 2 is the tune as written. Every key-on starts in mode 1, so the car is never left in the high mode by accident.

In mode 1 the underboost diagnosis is told everything is fine and the boost adaptation does not learn, so a pinned duty neither stores a fault nor teaches the ECU anything that carries into mode 2. Simulated, not yet on a car.

The live trace, corrected

The live tuner traces which cells of a map the ECU is reading as you drive. On four of the maps the trace was following the wrong input on one axis, so it was confidently highlighting cells the ECU was not using. Each of those now follows the input Bosch's own documentation says that map is looked up with, and several axes that were read one position off are fixed. A map where only one axis can be traced now draws nothing rather than half a guess. Seven maps are live: both ignition maps, target lambda, the boost linearisation and limit maps, and two fuelling corrections.

This is the same principle as the original trace post: a trace that looks plausible and is wrong is worse than no trace.

Starting on the cam sensor alone

ME7.5 has a factory fallback for a failed crank sensor: it can run from the cam signal. It is hard to make it happen on purpose, because it drops back out the moment any crank signal appears before the cam sync completes, which on a cranking engine is almost immediately. For testing, a file now forces it on from key-on. It keeps Bosch's own limits for that mode, including a 4600 rpm limit and a raised idle, so it is a test tool, not something to drive on. Simulated against the factory decision code; on a car next.

Where it stands

• Rolling antilag on the 2.0  run on a car
• Rotational idle, 2.0 and V8  simulated; with testers
• Map switching on the 1.8T  simulated
• Trace fixes  in the live tuner build; not yet driven
• Cam-only start  simulated; test file only

28 October 2026 In testing Not in a release

Rolling antilag: its own timing, a fuel-cut mode, and rotational idle

The ME7.5 launch work has been split across the two pedals for a while now. The clutch does launch control and no-lift shift. The brake does rolling antilag: hold the brake, floor the throttle, and the ECU latches the rpm you are at and holds it there while the turbo builds. This month it picked up three things.

Its own ignition timing

Until now rolling antilag and launch control shared one timing value. That was a compromise nobody wanted: launch and no-lift shift like heavy retard, around −20°, while rolling antilag holds better nearer 0°. They now have a value each, set separately in the patcher, and older files load with the shared value carried into both so nothing changes until you change it.

First run on a car: it held rpm as it should. The one odd result, antilag dropping out under hard braking, turned out to be the car running out of fuel. A re-test on a full tank is next.

Cutting fuel instead of spark

Rolling antilag held rpm by cutting spark. That works and it is loud, but every cut cylinder still gets its fuel, and that fuel ends up burning in the manifold and the turbo. Hard on both.

There is now a second mode: whole cylinders have their fuel cut instead, more of them as rpm climbs past the latch. It uses the ECU's own cylinder-cut mechanism, the one the factory rev limiter already uses, so the firing order and the pattern of which cylinders go are Bosch's, not a guess. It is a tick box; spark cut is still there.

The trade is the obvious one. Fuel cut is smoother and easier on the exhaust side; it may build boost more softly than spark cut does. That is the comparison the next logs are for.

Simulation caught a bug before any of this got near a car: in one path, rpm falling below the latch asked for all four cylinders to be cut instead of none. An engine would have stalled every time someone came off the throttle while still on the brake.

Rotational idle

The same cylinder-cut path, used at idle, for the sound. Tap the brake three times within five seconds while stopped, warm and off the throttle, and one cylinder stops firing. Every cycle or so the cut moves to the next cylinder. Left alone, the ECU would cut the same cylinder every time; the patch keeps it moving.

While it runs, closed-loop fuelling is suspended, so the trims do not try to correct a lean reading the cut cylinder is causing, and the firing cylinders run a little rich. That richness meeting the cut cylinder's fresh air is where the pops come from. Three more taps, any throttle, pulling away, the engine dipping towards a stall, or a timeout all end it.

One idea that did not survive: running it to cool the engine down. It does the opposite. The firing cylinders work harder, and rich exhaust meeting fresh air burns in the manifold. It is for the sound.

Misfire detection and knock control were the other worry. Both turned out to be handled already: the ECU pauses misfire detection while it is deliberately cutting cylinders, and knock control does not run at idle load. The test log watches both rather than adding code to switch them off.

Where it stands

• Separate timing  run on a car
• Fuel-cut antilag  every path simulated, not yet on a car
• Rotational idle  every path simulated, including against the factory code around it; not yet on a car
• Testers  earlier versions are out with testers in two countries

Both new modes go on a car next, with logs: which cylinders are cut, what the lambda reads, whether the misfire counter stays still.

27 October 2026 On a car Not in a release

1.8T software on a 2.0 ECU

1.8T ME7.5 ECUs are getting harder to find and dearer when you do. The 2.0 8v ECUs from the same family are everywhere, they are the same hardware generation, and they come with the wideband front oxygen sensor setup that is the reason to want one. So: put 1.8T software on 2.0 hardware, and find out what does not carry across.

The intake air temperature pin

The wiring diagrams disagree between the two. On the 2.0 the intake air temperature sensor lands on pin 26; on the 1.8T it is pin 85. The long-standing assumption is that the 1.8T software reads the wrong pin on a 2.0 box and needs patching.

It does not. Both builds were traced to the same input in software, which already suggested it, and then a sensor on the bench settled it: on the 2.0 ECU, pins 26 and 85 are tied together inside the box. The 1.8T software reads the sensor wherever the harness puts it. Nothing to patch.

Getting there took longer than it should have, partly because one test went onto the wrong pin. It is recorded here because "it needs a patch" is the answer that usually gets repeated.

Oxygen sensor heaters and unused outputs

The heater control for the front sensor is calibrated differently on the 2.0, and running it with 1.8T values is not right. Those values were carried across from a known-good 2.0 calibration rather than worked out from scratch. The output-stage diagnostics were set the same way, so outputs a swap does not use, the turbo's boost valve among them, do not set faults.

Running without the boost sensor

1.8T software expects a charge pressure sensor and complains without one. That matters for the cases this is actually for: a 2.0 that stays naturally aspirated, or a swap where boost is controlled by something other than the ECU. The file now runs without the sensor, takes its air from the MAF, and stays quiet about the missing input.

That one has been on a car, and it ran as it should.

It is not meant for a turbo car where the ECU runs the boost. The ECU needs a real pressure reading to control boost, so on those the sensor stays.

Next

Injector constants for the injectors actually fitted, so the fuel trims stop doing the work, and then logs across the rev range.

29 September 2026 On the bench

Chasing a programming fault that nobody had root-caused

A thread on NefMoto this week: crossflash an ME7.5 and the ECU sets P0602, "control module programming error". It sticks through a key cycle. Nobody had a root cause, and the usual answer is an assembly patch that stops the code being logged.

It is a long-standing annoyance with no good explanation behind it, and the bench here has both ECU generations on it. Seemed worth pointing at. What follows is what fell out over about a day, some of it useful, some of it wrong.

Naming the thing

The function everyone was patching writes one of two constants, 0xA5F0 or 0x5A0F, into a word of RAM and reads it back later. An A2L for a related ECU names that word outright: Status der Flashprogrammierung: 0xA5F0 bedeutet Fehler, sonst fehlerfrei. Flash programming status, A5F0 means error.

So the patch that had been circulating was not disabling a check. It was forcing the clean value to be written every time.

A question that turned out not to be a question

Part of the thread was about why the A-chassis ECUs report P0602 while the B-chassis ones report P1681, and whether that was a chassis split or a generation split.

It is neither. Every fault path in these ECUs carries several code words as ordinary calibration constants — a customer code and a CARB code among them. For the flash-programming path:

Two different images from two different part numbers carry byte-identical blocks. P0602 and P1681 are the same fault with two names, and which one a scan tool shows depends on which set it reads. That closed off a line of investigation rather than opening one, which is still worth something.

Where the bench came in

The flag itself lives in the EEPROM, and it was already set in ECUs that had never been touched by the tool under suspicion. So the question became: why does one flasher leave it set and another not?

Same ECU, same file, same baud rate, two writes back to back. Nine fault codes one way, eleven the other, with P0602 only in the second. Then the EEPROM read out after each:

Six bytes in the middle of that record are the flash tool code, sent as a parameter in the erase request. The byte immediately after it is the flag. Whatever the ECU makes of that field, it decides the outcome.

Two wrong turns worth recording

The first guess was that verifying particular flash sectors cleared the flag and that our flasher happened to do it. That died when both tools turned out to verify the same nineteen sectors in the same order.

The second was that some intermediate probe was resetting progress. That died too, once a third tool code was tried and behaved like the first, which ruled out the sequence and pointed squarely back at the field contents.

Both were reasonable and both were wrong, which is roughly the normal ratio.

One thing that saves everyone time

Checking that flag had meant reading the EEPROM. It does not have to. The ECU returns it over K-line in a single request:

Byte for byte the same as the EEPROM location everyone had been pulling chips to read. Our own flasher had been requesting it on every connection for months without anyone noticing what the first byte meant.

None of this is a UGTuner feature and none of it needs to be — our flasher never produced the fault. It is written up because the answer was worth having and nobody had it, and because a bench with two ECU generations on it is worth more pointed at a real problem than sitting idle.

28 September 2026 On the bench Not in a release

Teaching a bench ECU that it has an engine

Most of what is left to prove on the flex and speed-density work needs the ECU's crank-synchronous code to be running. With nothing on the crank input it never starts, so an ignition angle sits still, injection is never scheduled, and half the interesting variables never change. That is why several bench sessions could only confirm that a number existed, not that it moved.

The fix was a 60-2 crank wheel generated by a microcontroller: fifty-eight teeth, two missing, driven as a differential pair through AC coupling because the ECU's input expects a variable-reluctance sensor rather than a logic level.

With that running, an ECU on a bench behaves enough like one in a car to answer questions that previously needed a car.

The first thing it answered

ME7.5 has a factory limp mode for a failed cam sensor: it fires each cylinder every 360 degrees instead of every 720, which is wasted spark, implemented by Bosch and present in every one of these ECUs. Enabling it is one codeword. That matters for engine swaps where no usable cam signal exists.

The flag that reports it is active was not in any definition file we had, and the A2L we did have gave an address that turned out to be wrong for this software — of 270 flags shared between that file and ours, 206 sit at different positions. Guessing would have produced a plausible-looking log channel pointing at nothing.

Instead: log the raw flag words, change the one codeword, run the same test again, and diff. One bit appears in the second run and in no sample of the first. A DAMOS obtained later agreed, independently, to the same word and the same bit.

The cam side, honestly

Simulating the cam sensor took three attempts. A single symmetrical window never synchronised, because these wheels have four windows of unequal width and the ECU reads the signal level at the reference mark to work out which revolution of the cycle it is on. A symmetrical pulse cannot express that.

The pattern was eventually measured off a scope capture of a real sensor and reproduced as a tooth table. It is close, not exact, and the tooth positions carry perhaps a degree of uncertainty. For the cam-less work that does not matter, which is the case the bench is actually for.

The wasted-spark side is proven on the bench and has not run on an engine. As with everything else here, it says so until it does not.

27 September 2026 In the logger

A power curve from a log, with the word “estimate” left in

A dyno pull costs money and a booking. A third-gear pull on a quiet road costs nothing, and the ECU is already measuring the air going into the engine several hundred times a second. That is enough to draw a curve that is useful for tuning decisions, as long as nobody pretends it is a measurement.

Logger — Power chartEstimated from logged airflow

One third-gear pull, 2320 to 6800 rpm over fourteen seconds. The chart says what it is across the top, every time.

Airflow gives torque directly if you know how efficiently the engine is turning that air into work. The tool asks for that efficiency rather than guessing it, and then de-rates for the two things that most often make a log flatter than the engine really is: ignition pulled below optimum, and a mixture that is not where the tuner thinks it is.

That de-rate reads the measured channels, not the targets. Asking the ECU what lambda it wanted tells you nothing about what the engine got. On the pull above, using the target instead of the measurement would have moved the peak by a useful amount in the wrong direction.

What it is good for

• Comparing two files on the same car — the errors are mostly constant, so the difference is meaningful even when the absolute number is not.
• Finding where a curve stops climbing and whether that is the turbo, the fuel system, or a map.
• Checking a dyno sheet against what the ECU thought was happening. That has already caught one sheet run in the wrong gear with the wrong drivetrain selected.

What it is not

It is not a dyno, and the window says so in three places on purpose. Efficiency and driveline loss are inputs, which means anyone can produce whatever number they want by moving two sliders. That is exactly why the figure belongs next to the assumptions that produced it rather than on its own in a screenshot.

24 September 2026 On the bench Not in a release

Flex fuel for ME7.5: fuelling, ignition and cold start

Running E85 on an ME7.5 car usually means picking a blend and tuning for it. Put something different in the tank and the calibration is wrong until someone edits it again. A flex setup reads what is actually in the fuel and adjusts as it goes — which on these ECUs means adding code, not just changing maps.

This is the state of that work. It runs on the bench. It has not run on an engine.

Reading the sensor

A standard GM-style flex sensor sends ethanol content as a frequency and fuel temperature as a pulse width. An ESP32 converts that to a voltage the ECU can read on the downstream oxygen sensor input — an input most tuned cars have already stopped using.

The mapping from that voltage to what the ECU actually sees was measured rather than assumed: a stepped sweep through the whole input range, logged from inside the ECU, giving a straight line with under one count of scatter and no hysteresis. The converter is then calibrated against that, not against a meter reading at the pin.

Flex Fuel — Sensor WindowE0 point · valid range

The valid window sits clear of both the input’s open-circuit bias and its saturation point, so a disconnected converter reads as a fault rather than as petrol.

Fuelling

Ethanol needs roughly half again as much fuel as petrol for the same air. The patch scales the ECU's own fuel constant continuously with ethanol content — 1.00× on pump gas up to 1.49× at E100.

That 1.49 is the real stoichiometric ratio, 14.70 against 9.86. The 1.40 figure often quoted is right for E70, which is what winter pump E85 frequently turns out to be — and not depending on what the pump claims is the entire point of fitting a sensor.

If the sensor fails, the patch holds the last good reading rather than reverting to petrol. Reverting is the common approach and it is backwards: the fuel in the tank does not change composition when a sensor dies, so fuelling for petrol with E85 in the tank runs 33% lean. The filter is asymmetric for the same reason — rising ethanol tracks quickly, falling ethanol lags, so it errs rich in both directions.

Ignition

Ethanol resists knock, so it will take more advance — but how much more is not a constant, it varies across the whole load and rpm range. The approach here is the one GM used on its own flex calibrations: two complete timing tables and a blend between them.

The stock tables stay exactly as they are and become the petrol tables. Two new E85 tables are added, and timing is blended between them by ethanol content along a ramp the tuner sets — typically nothing extra below E20, full advance by E70, since ignition stops changing much past the middle of the range.

Flex Fuel — Timing BlendRamp start · span to full advance

Where the blend starts and how far it runs. The patch’s internal slope constant is derived from these on save, so the two cannot be set inconsistently.

The new tables are written as copies of the stock ones, so a freshly patched file behaves identically to an unpatched one at every ethanol content until someone calibrates them on a dyno. Nothing happens by accident.

Flex Fuel — E85 TimingDZWE85 · 16 × 12 · ° added

Degrees added on top of whichever pump map the cam path is using, so one table covers both. Zero everywhere on a freshly patched file.

An earlier version reused the ECU's existing optimum-spark tables instead of adding new ones, which is tempting because it needs no extra space. It was dropped: the torque model reads those tables to work out how much torque the engine is making, so filling them with E85 numbers quietly shifts throttle response, idle control and the torque figure sent to the gearbox. Separate tables leave all of that alone.

Cold start

This is the part everyone warns about, and the old threads all describe the same failure: the engine fires cleanly, then dies the moment the throttle is touched in the first minute.

The cause is not a shortage of fuel. Ethanol barely vaporises when cold, so it needs far more enrichment than the stoichiometric difference — but enrichment that is not cleared again builds up in the intake and drowns the engine on the first throttle opening. So the patch scales both: the enrichment the calibration already has, and the rate at which it decays.

It scales what the factory maps already describe rather than adding new tables, so the temperature shape a tuner has already dialled in is kept, and it switches itself off the moment the ECU enters closed loop — no fighting with the fuel trims.

Flex Fuel — Cold StartEnrichment · decay

Two numbers, because both halves matter: more fuel when cold, and clearing it again quickly enough that the engine does not drown on the first throttle opening.

What the bench says

A fifteen-minute logged sweep across the whole ethanol range, checked against what the code should produce in every cell:

Along the way the bench also caught a bug worth mentioning: the first version stored its state in a byte of RAM that the factory code reads a flag out of. It worked on the bench and would have quietly interfered with something else on a running car. It was found by checking every instruction in the firmware that touches that address, not by testing.

What is not done

• No engine has run it. Everything above is bench work.
• Cranking fuel is still stock; the after-start and warm-up phases are the ones handled so far.
• Boost is untouched — ethanol will usually take more, and that is the next piece.
• The E85 tables need calibrating on a dyno with knock monitoring. The patch provides the mechanism, not the numbers.

The editor side is already in place: the E85 tables, the blend ramp, the cold-enrichment scaling and the sensor window all live on their own tab, with the ramp's internal constant derived automatically so it cannot be set inconsistently.

Running E85 on an ME7.5 car in a cold climate and interested in being a test bed? Get in touch — the cold-start side in particular needs winter and a real engine, not a bench.

23 September 2026 Published

Motronic M5.9 checksums, worked out and given away

Older Motronic ECUs — M5.9 and M3.8, the 1990s VW and Audi stuff — have a checksum layout that has never been properly documented in public. Tools that correct them exist, but nobody says how.

Starting from a controlled experiment rather than guesswork: take a stock file, change a known set of bytes across the calibration, correct it with a known-good tool, and compare. What the difference proves:

That last point matters to anyone patching code rather than editing maps: nothing is fixing that word for you.

The scripts — a verifier and corrector, plus the probe method used to work it out — are on GitHub, with the reasoning written out so it can be checked rather than trusted. One region is still open, and what would settle it is written down there too.

Code and working: github.com/ugtuner05-sys

22 September 2026 On the bench Not in a release

Speed density: running ME7.5 without a MAF

The air meter is the limit on a lot of built engines. Past a certain airflow it reads flat, and no amount of rescaling fixes a sensor that has run out of range. The usual answer is to delete it and work out the air from manifold pressure, rpm and temperature instead — speed density.

ME7 makes this awkward, because the manifold pressure the ECU uses is not measured on most of these cars. It is modelled: the ECU runs an internal estimate of manifold pressure, corrected by what the air meter reports. Delete the meter and the correction has nothing to work from.

The approach

Rather than replacing the model, the patch feeds it. A 3-bar pressure sensor goes where the air meter was, and the patch replaces the ECU's own pressure-correction step with one driven by the real sensor — writing the correction, not the pressure itself.

That matters. An early version wrote the pressure directly as well, which double-counted: in simulation the modelled pressure jumped from 500 to 2000 mbar in a single step. Feeding the existing correction path keeps the model's own filtering and limits doing their job.

The sensor's transfer function did not have to be guessed either. The factory calibration already contains the gradient and offset for the 1.8T boost sensor, because the ECU has always known how to read one — so the patch uses Bosch's own numbers rather than a bench calibration of a sensor that is already characterised.

When the sensor fails

A pressure sensor that fails on a speed density car is not a check-engine light, it is an engine that has no idea how much air it is breathing. The patch detects an out-of-range reading and falls back to the ECU's existing throttle-angle-based air estimate — a path that is already in the firmware for exactly this kind of failure, and is being reused rather than reinvented.

Where it stands

The remaining work is a filter that varies with rpm and load rather than a single constant, a limit for real transients, and the part no bench can do: a first crank. The code that does the work runs on the crank-synchronous task, which does not run at all with the engine stopped — so unlike the flex work, there is no half-measure available here. It either goes in a car or it stays theoretical.

A VR6 port is planned. The structure is the same but every address differs, so it is a separate piece of work rather than a recompile.

20 September 2026 In the VR6 beta

Watching the ECU read a map

Everyone tuning ME7 has had the same argument with a map: you change a cell, drive the same road, and nothing happens. Either the ECU was not using that cell, or it was not using that map at all.

The VR6 build answers it by replaying a log against the binary. The axis channels come off the wire, the breakpoints and cells come out of the file, and the tool works out exactly what the ECU was reading, cell by cell, as the log plays back.

Four corners, not one

Most tools that do this show a single active cell. That is wrong almost all of the time: unless the engine is sitting exactly on a breakpoint, the ECU is interpolating between four cells, and naming one of them leads you straight into the trap — you edit a cell that contributed a fifth of the output and conclude the map does nothing.

So all four corners are shown, with the weight each one carried. There is a single-cell view on top for convenience, and it is labelled the dominant corner rather than the active one, because that is what it is.

Proving it is right

A trace that looks plausible and is wrong is worse than no trace. The check is that the ECU publishes the output of the very maps being traced — base ignition, optimum ignition, target lambda — so the trace can be compared against what the ECU said it did.

That last case is the useful one. The two base ignition maps differ in 107 of their 192 cells on a stock file, so comparing both traces against what the ECU actually did identifies which map is in force far more reliably than reading the selection logic and hoping.

Dwell, not just position

Playback runs at adjustable speed with a scrub bar, and cells accumulate a dwell shade as the log plays — so a drive leaves a heat map of where the engine actually spent its time. That is usually more useful than any single frame: it shows which cells are worth tuning and which have never been visited.

None of it changes anything in the ECU. It is a host-side tool: the ECU is logged, not modified, and nothing is written to the car.

Next

The obvious companion is editing a map and seeing the effect without a flash cycle each time. That is in progress and not in a build yet — tracing came first because a live editor that writes to the wrong cell is a considerably worse idea than a viewer that reads one.