Configuration Concepts

Applies to: IOcan · Standalone controller. What this means 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.

Which device has which IO

Every page in the Software section opens with an Applies to badge, because the two devices do not have the same hardware and several pages describe IO that only one of them has.

Full detail: IOcan technical specifications and IOcan pinout · standalone controller pinout.

Two consequences worth stating outright:

• The standalone controller's outputs are built to drive transmission solenoids — 3 A, current-regulated, with peak-and-hold. IOcan's are protected 0.9 A low-side switches for relays and indicators. A page written around solenoid drive does not describe IOcan hardware.
• IOcan has no analog voltage output and no tacho output. Where a page tells you to send a scaled voltage or a tacho signal to another device, on IOcan the equivalent is a CAN message.

Everything above the pin level — controllers, CAN presets, scaling, maps, virtual inputs — is the same on both.

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:

Each block has a clearly defined role, described below.

That diagram is the summary. What makes it unusual is that the blocks are not fixed stages — inputs compose into other inputs, and any source can reach any consumer through as many stages as the job needs. That is worth understanding before you build anything: the signal path.

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

A controller reads each of its signals from exactly one input. Each element in a controller's configuration — engine speed, brake status, oil temperature — holds a single reference, so a second source for the same element is not something the configuration can express. Nothing is arbitrated at run time and nothing is ignored, because nothing else can be assigned in the first place.

You can still create as many inputs as you like, and they all appear in the datalogger whether or not a controller reads them — logging an extra sensor costs a controller nothing.

To combine two sources, combine them upstream and assign the result. That is what the computed inputs are for: a Mux Input to switch between them, a Compare or Math input to derive one from both. The controller element points at that single result. See the signal path.

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;

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.