Repository navigation
[Feature]: Acceleration enrichment table Generator #3
Description
Activity
SomethingNew71 commented
on Jul 16, 2026 CollaboratorAuthorMore actionsA design doc covering this feature is now up: docs/plans/2026-07-16-tuning-table-generators.md
This and #4 share ~80% of their machinery, so the doc designs one table-generation framework in
src/analysis/tables/(channel-role mapping with auto-suggestion via the existing normalization system, event detection primitives, 2D binning, heatmap results view with per-cell counts/confidence, CSV + clipboard export, multi-log accumulation) with both features as pluggable analyzers on top.Accel enrichment approach (this issue):
- Detect tip-in events via TPS-dot threshold (default 50 %/s), preferring a native derivative channel when the ECU logs one (Haltech
Throttle Position Derivative, SpeeduinoTPS DOT); MAP-dot (400 kPa/s) is the fallback trigger. Gearshift/clutch events are rejected. - Lambda-delay compensation: the AFR window is shifted by the measured delay from a [Feature]: Lambda delay table geneator #4 table when one exists in the session (the two features compose), else a configurable default — otherwise high-RPM excursions get attributed to the wrong instant.
- Measure the transient lean excursion vs the logged AFR/lambda target (or pre-event baseline): peak depth, duration, and a suggested starting correction % = steady-flow fuel deficit at the excursion peak, clamped and explicitly labeled as a starting point, not a final value.
- Bin by RPM × peak TPS-dot (matching how Speeduino/Haltech axis their AE/transient tables); median per cell, with confidence tiers and blank sparse cells. Depth and duration are selectable alternate views over the same detected events.
Validation is nice here: the Haltech example log contains the
Transient Throttle *channels andspeeduino.mlglogsAccel Enrich/Gammae, so our tip-in detector is tested directly against each ECU's own AE activation — plus synthetic ramp/excursion unit tests with known ground truth.Phasing: the shared framework + lambda delay (#4) land first; this analyzer follows as Phase 2 on top of it. Full algorithm details, tunable thresholds, data structures, and UI flow are in the doc.
- Detect tip-in events via TPS-dot threshold (default 50 %/s), preferring a native derivative channel when the ECU logs one (Haltech
SomethingNew71 commented
on Sep 17, 2026 CollaboratorAuthorMore actionsDesign review + bolstered plan for the accel enrichment generator (2026-09-17)
The shared framework, verification findings against 2.14.1, PR split, and release plan are recorded on #4 (this issue ships in the same 2.15.0 release as Phase 2, in PR 1 commit 4 and the PR 2 surface work). This comment records only the deltas specific to this analyzer, found while re-verifying the 2026-07-16 design doc against current
main. The doc's algorithm (tip-in via TPS-dot, delay-compensated AFR window, excursion depth/duration/area, suggested correction %, RPM × TPS-dot bins) is kept.Additions to the doc
- Sign. Excursions go both ways: too much AE reads rich. Measure the signed peak deviation from reference;
correction_pctis signed and clamped to −50…+50. Selectable views over the same events: correction / depth / duration / area. - "Additional" not "absolute", and multiplicative. If the ECU already applied AE during the event (Haltech
Transient Throttle Load Derivative> 0, rusEFIFuel: TPS AE Active, Speeduino/MSAccel Enrich> 100 %), the excursion is the residual, so the suggestion is a factor on the current AE value: 20 % applied + λ 1.08 residual → total ≈ 1.20 × 1.08 − 1 = 29.6 %, not 28 %. The table'scorrection_kind(additional|absolute) is fixed by whether an AE-activity role is mapped; each event recordsae_active, and an event whoseae_activedisagrees with the table kind is rejected (RejectReason::AeKindMismatch) so one cell never mixes the two. The kind is labelled in the cell tooltip, CSV header, and MCP response. Wiki: MS2/MS3 AE tables are in ms added, so multiply the cell's base PW by the factor instead of pasting a percent. - Dose, not just peak. ECUs apply AE as a dose over a fixed accel time (Speeduino
taeTime, MS3 AE duration, Haltech transient decay). Storearea_lambda_sand exposearea_over_ms(default 300) so the secondary suggestionarea_pct = area / (area_over_ms/1000 × λ_ref) × 100can be compared with the peak-based one. - Native derivative preferred, with detected scale. Haltech
Throttle Position Derivativeis ×10 (3967 = 396.7 %/s, verified in the fixture); SpeeduinoTPS DOTis %/s; METPS Delta. The mapping UI shows the detected scale (median |peak| vs computed derivative of TPS over the same events) with a user override. Fallback:time_derivative(median_filter(tps)). - ECU reference for tests is the load-derivative channel, not the peak-hold channel. Haltech
Transient Throttle Fuel Peak Synchronous Outputholds its last peak (verified: stays at 6014 after the event ends), so it cannot mark active windows. UseTransient Throttle Load Derivative/Transient Throttle Enrichment Load Derivative> 0. - Lambda-delay composition. Look up the session lambda-delay accumulator cell for (RPM, load) at tip-in; if Empty/Low, fall back to
assumed_delay_msand derate quality; each event records which was used. - Gates reuse the shared
RejectReasonenum, addingGearShift(RPM change > 25 % mid-window) andAeKindMismatch;ClutchandColdEnginewhen those roles are mapped; overlapping tip-ins merge into the larger event. - Axes. RPM × peak TPS-dot (geometric 25/50/100/200/400/800 %/s); MAP-dot fallback relabels the axis. Vendor-exact axis shapes are
AxisSpecpresets intable_presets.json, not code. - Channel naming gaps (same finding as [Feature]: Lambda delay table geneator #4 A7):
TPS DOT,Throttle Position Derivative,TPS Deltado not normalize today. PR 1 adds a canonicalTPS Ratebuilt-in; auto-suggestion also scores by OECUA category/unit and name heuristics so unmapped names still resolve.
Fixtures
The Haltech blip log
exampleLogs/haltech/2025-07-18_0215pm_Log1118.csvis the primary AE fixture: 379 rows with the transient load derivative > 0 and 111 rows with TPS-dot > 200 %/s in 17 s (it is useless for lambda delay, which needs steady state, and ideal here). Also rusEFIrusefilog.mlg(Fuel: TPS AE Active) and MegaSquirt2026-04-12_12.49.36.mlg(Accel Enrich,TPS DOT).speeduino.mlgis engine-off and only a naming fixture.Verification
- Synthetic: TPS ramp of known peak rate + lean (and rich) first-order excursion of known depth/duration after a known delay → recovered depth within 0.01 λ, duration within one update interval, signed correction correct; overlapping ramps merge; mid-window RPM collapse →
GearShift; delay compensation picks the session lambda table cell when Medium/High and falls back toassumed_delay_msotherwise. - Real logs: Haltech tip-in windows overlap ≥ 80 % of rows where
Transient Throttle Load Derivative> 0 and none where it is 0;correction_kind == additional; rusEFI againstFuel: TPS AE Active; MegaSquirt againstAccel Enrich> 100. - Composition: run lambda delay then AE on the same rusEFI log in one session; the AE inspector shows "delay from table" on events whose cell is Medium/High.
- Sign. Excursions go both ways: too much AE reads rich. Measure the signed peak deviation from reference;
- added a commit that references this issue
on Sep 18, 2026 SomethingNew71 commented
on Sep 19, 2026 CollaboratorAuthorMore actionsShipped in v2.15.0.
Accel Enrichment is a top-level tool beside Log Viewer, Scatter Plots and Histogram (
⌘5/Ctrl+5). It detects tip-ins from a native throttle-rate channel or a computed derivative, shifts the lambda window by the measured delay (from a Lambda Delay table generated in the same session when the matching cell is trustworthy, else a configurable assumed delay), and reports the signed lean or rich excursion against target with a suggested starting correction, binned by RPM × throttle rate. When the ECU's own AE-activity channel is mapped the table is labelled additional and the suggestion is a multiplier on the current AE value; cells never mix the two kinds. Export as CSV, clipboard, PNG or PDF.What landed from the plan above:
- Framework, both generators, normalization additions, fixture tests — feat(analysis): lambda delay and acceleration enrichment table generators (#3, #4) #90 (@Barneyjm)
- Promotion to top-level tools, PNG/PDF export, release — feat(tables): promote lambda delay and accel enrichment to top-level tools, add PNG/PDF export, release 2.15.0 #91
- Release PR — Release v2.15.0 — lambda delay and acceleration enrichment table generators #92
- Wiki: Tuning Table Generators
Not in this release, deferred to Phase 3 (tracked on #4): MCP tools for the generators and on-disk per-ECU mapping presets.
Feature Category
Chart/Plotting
Problem or Use Case
Currently, generating an accurate lambda delay table involves capturing multiple log files and searching through them to see the time delay between an increase in pulse width and a fall in AFR at various loads and RPMs.
Proposed Solution
TBD
Alternatives Considered
No response
How important is this feature to you?
Nice to have
Additional Context
No response
Checklist