A reproducible analysis pipeline for MBE ECU data

Working with the MBE ECU on the 620R involves two very different data sources. One is the high-rate runtime log recorded from the running engine. The other is the .ecc file, which is the ECU’s instruction set, the calibration it runs to, and it can be exported straight from the tuning software, well if you have an unlocked ECU.

This blog is how I turned both into consistent, evidence led diagnostics with two purpose built tools, and why making the output reproducible mattered as much as the analysis itself. Hope you enjoy!

---

The MBE ECU and Easimap platform expose engine data in two distinct ways, each serving a different purpose.

Easimap can log a running engine at up to one sample per millisecond and export that data as a .CSV file. This shows what the engine actually did.

The .ecc file is different. It is the ECU’s instruction set. It contains the calibration, maps, thresholds, and control logic the engine is expected to run against. It can be exported directly from the tuning software and shows what the engine was instructed to do.

Analysing either file by hand is slow. More importantly, it is inconsistent. The conclusion can depend on which channels are plotted, how carefully they are reviewed, and what the person analysing the data happens to notice. I wanted a workflow that produced the same defensible answer every time, so I built two tools around that goal. This post explains what each tool checks, how it works, and why reproducibility was a primary requirement rather than an afterthought.

Tool one, the log analyser

The log analyser takes an Easimap CSV export and returns a complete report as a colour PDF, a Markdown version, a machine-readable JSON file, and a folder of figures. The pipeline is deliberately simple and runs in four stages.

1. Column resolution. Easimap headers are inconsistent between exports, so every column is resolved to a canonical signal by pattern rather than by position. The analyser is therefore independent of column order and of how the unit symbols were encoded.

2. State segmentation. The data is divided into the states that matter, including engine-running, closed-loop, the coolant temperature bands, and any warm or hot section that follows a suspend and resume. Every statistic downstream is then measured on exactly the right samples.

3. Analysis. A fixed battery of diagnostics runs over those states, each producing tables and figures. These are described below.

4. Severity and reporting. Every finding is assigned a severity, an overall assessment is formed, and the whole thing is laid out with the headline first and the supporting evidence behind it.

Scope of the analysis

The strength of the tool lies in the breadth and consistency of what it evaluates on every run. The diagnostics are grouped as follows.

Capture and data quality

• Sample rate and capture window. It establishes the true sample interval, compares captured sample time against elapsed time, and lists any unlogged suspend or resume gaps.

• Running segments. It identifies each contiguous period the engine was genuinely running, so nothing is later averaged across a stall or a logging gap.

  
  

Lambda and closed-loop control

• Control status durations. The time spent in each lambda control state, such as All Conditions OK against Sensor Too Cold, which quantifies how much of the log constitutes usable closed-loop data.

• Lambda value summaries. Percentile summaries of lambda while running, while in closed loop, and within the warm or hot section considered separately.

• Lean and rich exposure. How long lambda spent beyond a set of thresholds, each qualified by the control status at that moment, so transient out-of-control spikes are not mistaken for steady-state mixture.

• Short-term trim. Percentile summaries and threshold exposure for the closed-loop fuel trim, including time spent at the negative and positive limits.

• Control quality. The RMS lambda error from target, the proportion of time held within two and five per cent of stoichiometric, the time saturated on each trim limit, and the closed-loop limit-cycle rate.

Fuelling and enrichment

• Coolant temperature assessment. A comparison of rich-running behaviour below and above 70°C, the same data broken into 10°C bands, and any sustained periods held at the negative trim limit while still cold.

• Enrichment decomposition. The commanded fuel split into its contributing factors, namely after-start, coolant, air-temperature and barometric, shown alongside the trim for each coolant band, so the cause of any richness is attributed rather than merely observed.

• After-start enrichment. For each start or resume event, the peak magnitude, the active duration, the time taken to decay, and how much of that window overlapped the trim limit.

• Fuel-quantity model. When an injector flow rate is supplied, an estimate of fuel-flow rate and total fuel used, the cold-start extra fuel expressed in millilitres, the trim and factors converted to a volume, and an airflow and volumetric-efficiency cross-check derived from fuel mass and lambda.

The stacked bars are the commanded fuel factors, the blue bar is the closed-loop trim, and the black line is measured lambda. It shows precisely which contribution is responsible for the mixture at each temperature.

Idle and throttle

• Idle quality. RPM, lambda and trim stability measured across cold, warming, warm and hot idle regimes.

• Throttle coverage. The distribution of throttle position, how much of the operating map the log exercised, and the number of distinct throttle applications.

• Throttle signal stability. A dedicated spectral check of the throttle voltage at genuine idle, which distinguishes a clean sensor from electrical interference by examining the frequency content rather than the raw noise level.

The time trace, value distribution and amplitude spectrum together confirm the throttle signal holds to within a few millivolts at idle, with no periodic electrical interference.

Engine speed and temperature

• Engine speed. The RPM distribution, warm-idle stability, maximum RPM, and any overrun time on a closed throttle.

• Temperature. Coolant and air ranges, the stabilised operating temperature, and a warm-up profile giving the time to reach each temperature milestone.

• Cooling against engine speed. The smoothed coolant rate-of-change binned by RPM, and detection of idle heat-soak, which reflects the way water-pump flow scales with engine speed.

Ignition, injectors and fuel delivery

• Ignition timing. Idle advance and its stability, and how advance varies with RPM and load across the log.

• Injectors. Idle pulse-width and the effective metering pulse once the dead-time is removed, the battery dead-time compensation checked against voltage, a non-linear-region flag for small pulses, and duty-cycle headroom.

• Fuel pressure. Idle-pressure stability and the pressure-against-demand trend, with detection of any droop that would indicate a supply limit.

Mechanical and electrical health

• Channel audit. Which optional channels are actively contributing against those that are constant, zeroed, or simply not logged, so absent inputs are obvious.

• ECU diagnostics. Engine synchronisation status, the reset counter and the missing-tooth counter, each checked for changes during the run.

• Electrical. Battery and charging behaviour under running conditions, separating a genuine collapse from a normal cranking dip.

Findings on the 620R engine

Applied to a real log, the analyser reported that the lambda sensor was healthy and in control for approximately 94 per cent of running time, which ruled out a sensor fault.

A genuine issue was over-strong warm-up enrichment, where the closed-loop trim was pinned on its negative limit below about 50°C while lambda still could not reach stoichiometric, and the condition cleared by 60°C. The coolant-band view makes the mechanism explicit.

More to following in a future post.