Abstract
A log-based autotune only corrects the cells you actually drove through, leaving the map full of steps. Those steps don’t just look ugly — they raise the cycle-to-cycle variability of combustion every time you interpolate across them. Smoothing the map with an anchor-aware fit (keep the trusted cells, pull the rest onto a clean surface) measurably lowers combustion CoV. I have the knock-sensor data to prove it.
Why steps hurt
A speed-density map is interpolated continuously as RPM and load move. Where two adjacent cells disagree by a few percent, every transit across that boundary is a small mixture/torque discontinuity. Accelerating through RPM or ramping into boost, you’re always interpolating — so a ragged map shows up as roughness exactly when the engine is working.
The method
Smooth, but don’t throw away what you know. The approach:
- Mark the cells the autotune actually corrected as anchors — they keep their exact value.
- For each row and column, fit a low-order (degree-3) weighted polynomial where the anchors dominate the fit, and replace only the non-anchor cells.
- Bound the fit to the region around the anchors so it never extrapolates wildly into map regions you never visited.
The same idea applies to the ignition surface (e.g. flattening the cruise plateau) and to the VE/fuel-dose table. The on-site skill packages it so you can hand a map to an AI and get a clean surface back.
Paste the autotuned map straight into the chat
You don’t need to attach a tune file or do any setup. Copy the autotuned table out of EMU — as text or even just a screenshot — paste it into the chat, and ask for it smoothed. The assistant reads the grid (and, on a screenshot, reads the little table tabs in the bottom-right corner to recognize which table it is — VE table 1 vs VE table 2 / which set — so it edits the right one), treats the cells the autotune moved as anchors (or you point them out once), applies the anchor-weighted polynomial smooth automatically, and hands back the cleaned grid in the same shape plus a move report. Paste a hit-count/weight grid alongside it and anchor detection is fully automatic. When it looks right it’ll offer the importable
.emubt. The smoothing engine is identical to the file workflow — only the input changes.
Results
I read combustion stability from knock-sensor “chatter.” On no-knock cycles, the cycle-to-cycle scatter of the per-event knock-band energy proxies CoV — but only after two corrections: detrend within fine RPM×MAP cells (the raw signal climbs with RPM and load, which otherwise dominates), and restrict to transitions (smoothness only bites while interpolating). Comparing the hand-built map against the machine-smoothed one, operating-point-corrected CoV (lower = more stable):
| RPM bin | hand-made | machine-smoothed |
|---|---|---|
| 3.5–4k | 30.8% | 11.5% |
| 4–4.5k | 24.1% | 17.2% |
| 4.5–5k | 24.7% | 21.3% |
| 5–5.5k | 28.9% | 16.4% |
| overall | 25.9% | 19.0% |
The machine-smoothed map is tighter in every overlapping bin — a clean confirmation that the algorithm-smoothed surface runs with less knock-sensor chatter and more repeatable combustion than the hand-built one.
The hand-built VE surface versus the machine-smoothed one — the steps that drove the extra combustion variability show up as ridged texture that the smoother removes:
The same two maps compared in the logs the CoV metric was computed from:
Notes
- notes/knock_voltage_cov_combustion_stability.md — the CoV-from-knock-scatter method, the two traps, and the full result
- notes/ve_correctness_from_log_method.md — how to derive the corrections (the anchors) from a log: STFT in steady cells, lambda error in accel cells, coverage everywhere
- On-site: the VE-smoothing skill (anchor-weighted polynomial smoother) and log-based VE correction