IOCAN

# Configuration Concepts

This page explains how configuration in IOcan 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.

This page does not describe how to click through the configuration tool. It explains how the system is designed to work so that configurations can be created safely and predictably.

⸻

What Configuration Means in IOcan

IOcan does not contain fixed logic for a specific vehicle or transmission. Instead, its behavior is entirely defined by configuration.

Configuration 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

IOcan executes the configuration deterministically. It does not guess missing information and does not apply hidden defaults beyond explicitly defined optional behavior.

⸻

Signal Flow Overview

At a high level, signal flow inside IOcan follows this structure:

Inputs → Controller → CAN Presets → Transmission

Transmission → CAN Presets → Controller → Outputs

Each block has a clearly defined role.

⸻

Inputs

Inputs describe the engine and chassis state. These signals represent what the transmission needs to know in order to function correctly.

Typical required and optional input signals include:

	•	engine speed

	•	throttle position

	•	accelerator pedal position

	•	fueling-related information (fuel pressure, injection timing)

	•	brake pedal state

	•	wheel speed (optional)

Input Sources

Signals can originate from:

	•	CAN bus messages

	•	analog inputs

	•	frequency inputs

Analog inputs can be configured for signal processing functions, including:

	•	voltage-based analog signals

	•	digital button inputs

	•	resistor divider modes for multiple buttons on a single input

Frequency inputs are typically used for:

	•	engine speed

	•	wheel speed

	•	other pulse-based signals

Input Assignment Rules

IOcan can read any number of signals for logging purposes, but:

	•	only one signal can be assigned as the active source for a given logical input

	•	additional signals may be visible in the datalogger but are ignored by controllers

If a mandatory signal is missing:

	•	the controller reports a configuration fault

	•	IOcan halts operation

	•	logging remains available

	•	the transmission will not run

If an optional signal is missing:

	•	a default internal value is used

	•	IOcan remains operational

	•	if the signal later becomes available, it is used automatically

⸻

Controllers

The controller is the core decision-making component of IOcan.

Controllers are responsible for:

	•	processing input signals

	•	validating signal availability

	•	emulating missing non-critical signals

	•	managing transmission behavior

	•	enforcing configuration correctness

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

If a controller is misconfigured:

	•	a fault is reported

	•	IOcan stops operating

	•	no transmission control is performed

Controllers exist to allow:

	•	different transmission types

	•	different OEM protocols

	•	different signal emulation strategies

Multiple controllers can exist, but multi-controller setups are considered advanced usage.

⸻

CAN Presets

CAN presets are protocol-level building blocks.

They implement:

	•	reading CAN frames

	•	writing CAN frames

	•	decoding and encoding OEM or aftermarket protocols

The purpose of presets is to:

	•	hide protocol complexity

	•	eliminate manual frame configuration

	•	provide reusable protocol implementations

Examples include:

	•	OEM dashboards

	•	OEM shifters

	•	standalone aftermarket ECUs

	•	OEM transmission protocols

Presets translate controller signals into CAN messages and collect CAN messages back into signals.

Preset Categories

Presets fall into two general categories:

OEM Emulation Presets

For example, BMW 8HP emulation presets use internally routed signals and closely reproduce OEM communication behavior.

Signal-Exposing Presets

Most presets expose inputs and outputs to the controller. This allows:

	•	signal substitution

	•	signal scaling

	•	using alternative data sources

For example, if pedal position is not available on the CAN bus, torque demand may be used instead and mapped accordingly.

⸻

CAN Networks

CAN networks define transport configuration, not logic.

A CAN network specifies:

	•	bitrate

	•	termination

	•	direction (read/write)

	•	physical bus properties

CAN networks do not interpret messages and do not control behavior.

Presets use CAN networks to send and receive messages. Multiple presets and controllers can use the same CAN network.

⸻

Outputs

Outputs expose transmission and controller state to the outside world.

Outputs can be:

	•	CAN messages

	•	digital outputs

Examples include:

	•	reverse light control

	•	gear display

	•	transmission mode indication

	•	torque management signals sent to the ECU

Output Rules

	•	Outputs do nothing on their own

	•	Outputs must be driven by a controller

	•	Each output must be assigned to a single controller function

	•	Assigning the same output to multiple controllers results in undefined behavior

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

⸻

Auxiliary Controllers

In addition to the main transmission controller, auxiliary controllers can be configured for supporting functions, such as:

	•	vacuum pump control

	•	auxiliary power management

These are advanced features and are not required for basic transmission operation.

⸻

Configuration Responsibility and Safety

IOcan guarantees:

	•	deterministic execution of configuration

	•	fault reporting for missing mandatory signals

	•	consistent signal routing

IOcan does not guarantee:

	•	mechanical safety

	•	drivability correctness

	•	suitability for a specific vehicle

The user is responsible for:

	•	validating signal correctness

	•	verifying scaling and ranges

	•	testing behavior in controlled conditions

	•	ensuring safety during operation

⸻

Common Conceptual Errors

Common configuration mistakes include:

	•	assigning multiple sources to the same input

	•	configuring CAN networks without assigning presets

	•	expecting outputs to work without a controller

	•	assuming missing mandatory signals will be emulated

	•	mismatched CAN network configuration

Understanding the concepts described on this page prevents most configuration issues.

⸻

Summary

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

Inputs describe state.

Controllers define behavior.

Presets implement protocols.

CAN networks transport data.

Outputs expose results.

Understanding this structure is essential before creating or modifying configurations.