What the Hex Labs ECU Remap Simulator Actually Simulates

The Hex Labs ECU Remap Simulator is a browser-based illustration of table inputs flowing into simplified arithmetic. It does not load an ECU file, use live vehicle signals, or model a particular make or model. Its scenario names, table values, units and results are synthetic examples—not vehicle presets, manufacturer calibrations or dyno data.

What you can change

The simulator starts at Example A, with the Stock table preset, the Fuel Map visible, no selected fault example and the table view. Each of the three fictional scenarios—Example A, B and C—has five fixed 6 × 6 tables labelled Fuel Map, Boost Map, Ignition Timing, Air/Fuel Target and Torque Limit Example. The row labels are 1,000 through 6,000 RPM and columns are 0 through 100% load; these are example axes, not verified calibration axes.

Each table starts from a fixed base value. The generator adds 5 for each row step and 2 for each column step. The scenario base values are:

• Example A: Fuel 40, boost 45, timing 35, air/fuel target 14, torque limit example 55.
• Example B: Fuel 50, boost 55, timing 40, air/fuel target 14, torque limit example 65.
• Example C: Fuel 45, boost 50, timing 38, air/fuel target 14, torque limit example 60.

The table presets multiply every cell in the selected scenario’s tables by 0.9, 1.0, 1.1 or 1.2, then round to an integer. Their interface labels are Stock, Eco, Stage 1 and Aggressive. Those names are only labels for mathematical presets in this example; they do not correspond to real products, tuning stages or recommended changes. Individual cells can be edited as whole numbers from 0 to 200, an interface limit for the synthetic model.

How the outputs are calculated

For each table type, the simulator adds all 36 cell values and divides that sum by the same table’s fixed sum in the selected scenario. Call those ratios r_fuel, r_boost, r_timing, r_torque and r_afr. The calculation treats the ratios as independent factors. It does not model interactions among maps, sensors or engine systems.

Simulation model

Synthetic table totals feed independent example ratios

1. Inputs Five synthetic 6 × 6 tables

   Fuel, boost, timing, torque-limit and air/fuel examples.

2. Ratios Each table total ÷ its fixed baseline total

   Five separate factors; the model does not calculate map interactions.

3. Outputs Fixed example arithmetic

   Illustrative power, fuel-use, torque, boost and air/fuel figures.

• Power example: scenario power × r_fuel × r_boost × r_timing, rounded to whole hp.
• Difference from example baseline: calculated power minus scenario power, rounded to whole hp.
• Fuel-use example: scenario fuel-use value × r_fuel, shown to one decimal L/100 km.
• Torque example: scenario torque × r_torque × r_boost, rounded to whole Nm.
• Boost example: scenario boost × r_boost, shown to one decimal bar.
• Air/fuel ratio example: 14.7 ÷ r_afr, shown to one decimal or “undefined” when the AFR table sum is zero.

Worked example

The default ratios reproduce the simulator’s baseline constants

At the default Example A / Stock setting, each ratio is 1. The deterministic outputs are therefore 210 hp, +0 hp, 8.0 L/100 km, 250 Nm, 1.0 bar and 14.7. These numbers are the simulator’s chosen baseline constants, not measured or predicted properties of a car.

Compare the synthetic baseline

With Example A and Stock selected, run the simulation and compare the outputs with this guide. The baseline ratios are 1; that confirms only the simulator’s defined arithmetic, not a result for a vehicle.

Open the ECU Remap Simulator

An additional curve is drawn from the simulated torque number using torque × sin(((RPM − 1000) ÷ 5000) × π) at the six example RPM labels, rounded to whole numbers. This creates a smooth display shape; it is not a torque curve model or a measurement. The graph of a selected map simply plots its table values.

The app can also show an illustrative warning if its boost output exceeds 1.5 or its calculated AFR output is below 12. Those are internal thresholds for the teaching interface, not engineering limits or safe targets. The outputs omit the vehicle-specific hardware, actual operating conditions, calibration definitions, control logic and measurement process that real vehicle results depend on. Do not read them as expected power, torque, fuel economy, boost or air/fuel behavior.

Fault examples are selected, not detected

The fault selector offers “No simulated fault,” “Example overboost event,” “Example timing event” and “Example knock-sensor event.” Selecting one adds a warning label to the simulated output. It does not read diagnostic codes, inspect a table for a fault, or model the selected event as a consequence of edited cells. These are fictional display examples, not fault diagnosis or evidence that a vehicle experienced an event.

Profiles and reset behavior

You can save up to 20 named profiles in this browser. A saved profile contains its name, selected synthetic scenario and all five 6 × 6 tables. The browser stores a version-1 validated envelope in local storage; it contains no VIN or vehicle file. Profiles are not uploaded. Clearing site data or using another browser/device does not carry them over. The tool can also download one selected synthetic map as JSON; that file is an example table, not an ECU file or flashable calibration.

Reset returns the active interface to Example A, the Stock preset, Fuel Map, no selected fault, original Example A tables and no current result. It leaves saved profiles in browser storage. Changing the scenario, preset, edited cell, selected map or fault clears the previous result until you run the simulation again. The calculations are synchronous and deterministic: the same scenario, tables and selected fault produce the same outputs.

Keep the model in its learning role

This tool can illustrate that a program might calculate outputs from tabular inputs and that changing an input changes a simplified calculation. It does not model a real vehicle, predict dyno results, diagnose faults, or validate a calibration as safe or suitable. Real calibration work can require vehicle-specific definitions and context, correct calibration data, logging, hardware knowledge, integrity/checksum handling, validation and testing, and applicable legal or emissions considerations. This guide is not a procedure for performing that work.

For related data concepts, read How Byte Data Becomes a Synthetic Table and Understanding Binary Files, Bytes, Hexadecimal and Offsets. The simulator is an optional illustrative model alongside the ECU basics lesson, not a test of tuning competence.