Core Reference

Control Logic and Calculations

Mode semantics, gate behavior, interpolation strategy, and lock request conversion.

Mode output model

Mode Source Output type Typical use
STOCK / OFFNo active requestController inactive pathBypass/stock behavior
FWDPreset0 lock targetFront-biased behavior
5050, 6040, 7030, 8020, 9010PresetFixed lock targetSimple fixed split operation
SPEEDSpeed curveInterpolated lockSpeed-governed lock response
THROTTLEThrottle curveInterpolated lockPedal-driven lock response
RPMRPM curveInterpolated lockEngine-speed-driven lock response
MAP2D tableBilinear interpolated lockCombined speed x throttle shaping

Gate behavior

Preset modes

Dynamic modes (SPEED / THROTTLE / RPM / MAP)

Global interaction

Dynamic pages write global controls through POST /api/settings. Mode-specific lock shape data (curve points/map table) is written via dedicated curve/map endpoints.

Interpolation mechanics

Curve modes

Map mode

  1. Locate neighboring throttle bin indices and throttle ratio.
  2. Locate neighboring speed bin indices and speed ratio.
  3. Interpolate speed within each of the two throttle rows.
  4. Interpolate between row results by throttle ratio.

Lock request conversion

Final lock request is converted to generation-specific byte-space by get_lock_target_adjusted_value() before frame shaping in frames.cpp.

Debug capture safety override

When debug capture profile is active, settings logic forces stock/controller-off mode to prevent combined heavy diagnostics and active drivetrain control.

Integration implication: UI should always re-read /api/status after writes instead of assuming the requested mode remained active.

Try the OpenHaldex Firmware Demo

Preview the real OpenHaldex firmware UI in your browser with simulated live CAN traffic and interactive pages for tuning, diagnostics, logs, setup, and OTA workflows.

Open firmware demo