[Feature]: Acceleration enrichment table Generator

[SomethingNew71]

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

• I have searched existing issues to ensure this feature hasn't been requested
• I would be willing to help test this feature

[SomethingNew71]

A 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, Speeduino TPS 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 and speeduino.mlg logs Accel 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.