Configuration Concepts¶

This page explains how configuration works at a conceptual level. It describes how
signals flow through the device, what each configuration section represents, and
where user responsibility begins and ends.

It is not a click-through guide to the configuration tool. It explains how the
system is designed to work, so configurations can be created safely and
predictably.

A note on terms: IOcan (or simply the device) is the hardware running the
configuration. A controller is a transmission control strategy that runs on it
(in the schema this is a driver). The two are different things.

What configuration means¶

The device contains no fixed logic for a specific vehicle or transmission. Its
behaviour is defined entirely by configuration, which determines:

• where signals come from,
• how they are processed,
• how they are translated into transmission commands,
• how transmission state is exposed to the rest of the vehicle.

The configuration is executed deterministically. The device does not guess
missing information and applies no hidden defaults beyond explicitly defined
optional behaviour.

Signal flow overview¶

At a high level, signals flow in a loop:

Inputs  →  Controller  →  CAN Presets  →  Transmission
Outputs ←  Controller  ←  CAN Presets  ←  Transmission

Each block has a clearly defined role, described below.

Inputs¶

Inputs describe engine and chassis state — what a controller needs to know to
function. Typical required and optional signals include:

• engine speed
• throttle position
• accelerator pedal position
• fuelling information (fuel pressure, injection timing)
• brake pedal state
• wheel speed (optional)

See Configuring Inputs for the full list of input types.

Input sources¶

A signal can originate from:

• CAN bus messages — via a preset (CAN Object Input) or a
  raw frame (CAN Bus Input);
• analog inputs — voltage sensors (Analog Input), digital
  buttons (Digital Input), or resistor-divider switches for
  several buttons on one pin (Analog Switch Input);
• frequency inputs (Frequency Input) — engine speed, wheel
  speed and other pulse-based signals.

Raw values are scaled to engineering units as described in
Scaling & Maps.

Input assignment rules¶

The device can read any number of signals for logging, but:

• only one signal can be the active source for a given logical input;
• additional signals may appear in the datalogger but are ignored by controllers.

If a mandatory signal is missing:

• the controller reports a configuration fault;
• the device halts transmission operation;
• logging remains available;
• the transmission will not run.

If an optional signal is missing:

• a default internal value is used;
• the device stays operational;
• if the signal later becomes available, it is used automatically.

Controllers¶

A controller is the core decision-making component. It is responsible for:

• processing input signals,
• validating signal availability,
• emulating missing non-critical signals,
• managing transmission behaviour,
• enforcing configuration correctness.

A controller does not send CAN messages or drive hardware outputs directly.
Instead it produces calculated signals that CAN presets and outputs consume.

If a controller is misconfigured, a fault is reported, the device stops operating,
and no transmission control is performed.

Controllers exist so the same device can support different transmission types, OEM
protocols and signal-emulation strategies. Multiple controllers can coexist, but
multi-controller setups are advanced usage.

CAN Presets¶

CAN presets are protocol-level building blocks. They implement reading and writing
CAN frames and the decoding/encoding of OEM or aftermarket protocols, so you don't
configure frames by hand. See
Working with the CAN Bus.

Presets translate controller signals into CAN messages and collect CAN messages
back into signals. Examples: OEM dashboards, OEM shifters, standalone aftermarket
ECUs, OEM transmission protocols.

Presets fall into two general categories:

• OEM emulation presets — e.g. BMW 8HP emulation; they use internally routed
  signals and closely reproduce OEM communication behaviour.
• Signal-exposing presets — most presets; they expose inputs and outputs to the
  controller, allowing signal substitution, scaling, or alternative data sources.
  For example, if pedal position is not on the CAN bus, torque demand can be used
  instead and mapped accordingly.

CAN networks¶

A CAN network defines transport, not logic:

• bitrate,
• termination,
• direction (read/write),
• physical bus properties.

CAN networks do not interpret messages or control behaviour. Presets use them to
send and receive; multiple presets and controllers can share one network. See
Working with the CAN Bus.

Outputs¶

Outputs expose transmission and controller state to the outside world. They can be
CAN messages or hardware outputs — for example reverse-light control, gear display,
transmission-mode indication, or torque-management signals to the ECU. See
Configuring Outputs.

Output rules:

• outputs do nothing on their own — they must be driven by a controller;
• each output must be assigned to a single controller function;
• assigning the same output to multiple controllers gives undefined behaviour.

Outputs reflect the internal state of the controller and the transmission.

Auxiliary controllers¶

Besides the main transmission controller, auxiliary controllers can handle
supporting functions such as vacuum-pump control or auxiliary power management.
These are advanced features and are not required for basic transmission operation.

Configuration responsibility and safety¶

The device guarantees:

• deterministic execution of the configuration,
• fault reporting for missing mandatory signals,
• consistent signal routing.

The device does not guarantee:

• mechanical safety,
• drivability correctness,
• suitability for a specific vehicle.

You are responsible for validating signal correctness, verifying scaling and
ranges, testing behaviour in controlled conditions, and ensuring safety during
operation.

Common conceptual errors¶

• assigning multiple sources to the same input;
• configuring a CAN network without assigning any preset;
• expecting outputs to work without a controller;
• assuming missing mandatory signals will be emulated;
• mismatched CAN network configuration.

Understanding the concepts on this page prevents most configuration issues.

Summary¶

Configuration defines how signals flow from the engine and driver, through
controllers, into the transmission, and back into the vehicle:

• Inputs describe state.
• Controllers define behaviour.
• CAN Presets implement protocols.
• CAN networks transport data.
• Outputs expose results.

Understanding this structure is essential before creating or modifying a
configuration.