IOCAN

# 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](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](CAN_Object_Input)) or a

  raw frame ([CAN Bus Input](CAN_Bus_Input));

- **analog inputs** — voltage sensors ([Analog Input](Analog_Input)), digital

  buttons ([Digital Input](Digital_Input)), or resistor-divider switches for

  several buttons on one pin ([Analog Switch Input](Analog_Switch_Input));

- **frequency inputs** ([Frequency Input](Frequency_Input)) — engine speed, wheel

  speed and other pulse-based signals.

Raw values are scaled to engineering units as described in

[Scaling & Maps](Scaling_and_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](Working_with_the_CAN_Bus#can-presets).

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](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](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.