Map Input

Applies to: IOcan · Standalone controller. What this means

Overview

A Map Input applies a 1D lookup table to another input and reports the result as a new channel. You give it a list of X breakpoints and the Y value at each one; the source value is located on the X axis and the result is linearly interpolated between the two neighbouring Y values.

Use it for anything a straight line cannot express: an NTC temperature curve, a progressive pedal map, a sensor with a kink in it. It is the standard answer whenever an Analog Input's two-point scaling is not enough.

The value it reshapes comes either from a pin — see the IOcan pinout or the standalone controller pinout — or from a CAN signal an ECU preset decodes for you.

Prerequisites

  • A source input for the X axis, referenced by name. It must exist and be valid — an unassigned source raises fault 0x00E0.
  • Matching lists of X breakpoints and Y values. Different lengths raise fault 0x00E1.

Add it in the app

  1. Add a new input and choose Map Input as the type.
  2. Choose the source input.
  3. Give it a clear name (e.g. Coolant Temp).
  4. Enter the input values (X) and output values (Y).
  5. Check the result against the source across the whole range, not just in the middle.

Settings reference

Setting Meaning Unit Range / values Notes
Source input The input read on the X axis — an existing input Unassigned raises 0x00E0.
Input values (X) The breakpoints source's unit list of sint32 Must be strictly increasing. Not enforced by the firmware — see below.
Output values (Y) The result at each breakpoint your unit list of sint32 Exactly one per X. A mismatch raises 0x00E1.

How it behaves

  • Between breakpoints: linear interpolation, in integer arithmetic. Put breakpoints where the curve bends; a straight section needs only its two ends.
  • Outside the table: the result is clamped to the first or last Y. It does not extrapolate. That is usually what you want, but it also means a source that has drifted out of range looks like a source sitting exactly at the end of it.
  • Exactly on a breakpoint: that breakpoint's Y, exactly.

X values must increase, and nothing checks that they do. The lookup uses a binary search that assumes ordering. Given an out-of-order table it will not fault — it will return confidently wrong numbers, and the error will look like a sensor problem. Enter the table in order and confirm it in the datalogger.

Common settings

Map Input also uses the shared Name setting. See Common IO settings.

Example — NTC coolant sensor to °C

The Analog Input is left with interpolation off, so it reports a 0–1024 proportion of the 5 V range rather than volts, and this map does the curve. The X column is therefore in that domain — 512 is 2.5 V.

  1. Type Map Input, name Coolant Temp.
  2. Source input Coolant Temp Raw.
  3. X — the sensor's readings in that domain, increasing: 80, 150, 260, 420, 600, 780, 900. Take them from the datalogger with the engine at known temperatures rather than converting a data sheet by hand.
  4. Y — the temperature at each, in tenths of a degree so the integer arithmetic keeps a decimal: 1200, 900, 700, 500, 300, 150, 50.

Y decreasing while X increases is fine — an NTC's resistance falls as it heats. Only the X column has to be ordered.

Example — progressive pedal map

  1. Source input Pedal Position (0–1024).
  2. X 0, 200, 500, 800, 1024.
  3. Y 0, 80, 340, 760, 1024 — gentle off idle, steeper near full pedal.

Troubleshooting

  • Output flat at one end: the source is outside the table and is being clamped to the end Y. Extend the table or check the source's scaling.
  • Output plausible but wrong in places: the X column is not strictly increasing. Nothing will fault; re-enter it in order.
  • Fault 0x00E1: X and Y have different numbers of points.
  • Fault 0x00E0: the source input is unassigned or failed to configure.
  • Result rounds badly: the arithmetic is integer. Work the Y column in tenths or hundredths and scale at the consumer.