IOCAN

# Build Your First Configuration

This is a guided, start-to-finish walkthrough for your **first** IOcan configuration.

It sits between two other pages: [Getting Started with IOcan](Getting_Started_with_IOcan)

gets the device wired and powered, and [Configuration Concepts](Configuration_Concepts)

explains the model behind everything below. If you have read those two, you are ready.

The goal here is not to document every field — the reference pages do that. The goal

is to give you a **safe, sensible order** to work in, so your first config comes

together predictably instead of by trial and error. Take it one step at a time and

you will end up with a transmission that wakes, communicates, and shifts.

> **Off-road use only.** IOcan does exactly what your configuration tells it to. A

> first config is something you build *and validate* — never a finished tune. Keep the

> car on a bench or in a controlled setting until every check in Step 9 passes.

## What you will build

To keep things concrete, this walkthrough follows one common setup:

- a **BMW ZF 8HP** transmission,

- driven by a **standalone aftermarket ECU** that publishes engine data on CAN,

- with **paddle / sequential** shift input.

Your build may differ — a different transmission, an OEM ECU, an OEM selector. That is

fine. The *order* of the steps is the same for every build; only the specific presets

and signals change. Where your setup differs, follow the linked reference page for that

piece and rejoin the sequence.

## The shape of a configuration

Everything you are about to add fits into one loop (this is the model from

[Configuration Concepts](Configuration_Concepts)):

```

Inputs  →  Controller  →  CAN Presets  →  Transmission

Outputs ←  Controller  ←  CAN Presets  ←  Transmission

```

We will build it roughly in that order: first the plumbing (CAN networks), then the

two ends that talk to the outside world (the transmission preset and your ECU), then

the brain in the middle (inputs and the controller), and finally what the system

reports back out (outputs). Then we validate.

---

## Step 1 — Start from a base configuration, not a blank one

Do not build from nothing. Flash a **base configuration / template** for your

transmission and use it as your starting point. A base config already has the

transmission controller and the OEM emulation wired up correctly, which removes most

of the ways a first attempt can go wrong.

- Connect IOcan to your PC over USB-C and let it come up in **USB safe mode** (no

  transmission power — see [Getting Started](Getting_Started_with_IOcan#4-First-Power-Up-Using-USB-Safe-Mode)).

- Flash the firmware and load the base configuration for your transmission.

- Save a copy under your own name before you change anything, so you always have a

  known-good fallback.

Everything from here is **editing** that base config to match your car.

## Step 2 — Define your CAN networks

A CAN network is just transport — it carries frames, it does not interpret them. Before

you can add anything that talks on CAN, the bus it lives on has to exist. For a typical

build you will have two:

- the **transmission bus** (IOcan ↔ transmission),

- the **vehicle / ECU bus** (IOcan ↔ your standalone ECU and any dash, keypad, etc.).

For each network set the bitrate, CAN FD if used, and termination. IOcan has switchable

on-board 120 Ω termination — enable it only when IOcan is an **end node** on that

bus, and make sure the far end is terminated too. Details and the timeout behaviour you

will need later are on [Working with the CAN Bus](Working_with_the_CAN_Bus).

> A base config usually has the transmission bus defined already. You mainly need to add

> and check the vehicle/ECU bus.

## Step 3 — Confirm the transmission preset

The transmission side is handled by an **OEM emulation preset** — for this example, the

BMW 8HP emulation. It reproduces the OEM communication the transmission expects and

automatically creates the matching CAN objects the controller drives. In a base config

this is already in place; your job is to confirm it is present and assigned to the

**transmission** network from Step 2, not to invent it.

You will not hand-decode any transmission frames. That is the whole point of the preset.

## Step 4 — Bring in your engine signals

Now give the controller something to work with. The transmission controller needs to

know engine and driver state. Common required signals:

- engine RPM,

- throttle position,

- accelerator pedal position,

- fuelling information (fuel pressure / injection timing),

- brake pedal state,

- wheel speed (optional).

You have two ways to get them in, covered on

[Working with the CAN Bus](Working_with_the_CAN_Bus):

1. **A CAN Preset for your ECU** (preferred, if one exists). Add the preset, assign it

   to the vehicle bus, and it publishes named objects you simply reference — no byte

   math.

2. **Raw CAN signals** ([CAN Bus Input](CAN_Bus_Input)),

   when you have a DBC or know the byte layout of your ECU's broadcast.

If a signal is not on the CAN bus at all, you can supply it from a hardware pin instead

— for example an [Analog Input](Analog_Input)

for a 0–5 V sensor, or a [Frequency Input](Frequency_Input)

for a pulse-based speed signal. The full menu of input types is on

[Configuring Inputs](Configuring_Inputs).

## Step 5 — Map signals to the controller (and know what is mandatory)

Adding a signal makes it *available*; it does not yet make it the controller's source.

For each logical input the controller needs, choose the **one** signal that drives it.

You can read extra copies of a signal for logging, but only one can be the active

source — extra ones are logged and ignored.

This is the step where it pays to understand mandatory vs. optional:

- **Missing a mandatory signal** → the controller reports a configuration fault and

  **halts transmission operation**. Logging still works, but the transmission will not

  run. This is intentional, not a bug — it is the device refusing to operate blind.

- **Missing an optional signal** → a safe internal default is used, the device keeps

  running, and the real signal is picked up automatically if it appears later.

For any safety-relevant CAN signal, set a **timeout** (`UsePrevious` / `UseDefault` /

`UseFault`) so a dropped frame is detected rather than silently held at its last value.

If a value needs scaling or a curve before the controller uses it, that is handled with

[Scaling & Maps](Scaling_and_Maps).

## Step 6 — Set up shift input

Decide how the driver requests gears and wire that into the controller:

- **Paddles or a sequential shifter** via a shifter preset, or via

  [Digital Inputs](Digital_Input)

  for simple up/down buttons.

- **An OEM gear selector** (e.g. a BMW GWS) via its preset.

- **A CAN keypad** for mode and range selection.

Keep it minimal for the first config: up, down, and a way to select drive/neutral/reverse

is enough to validate. Add modes and refinements once the basics shift cleanly.

## Step 7 — Configure the outputs you actually need

Outputs expose transmission and controller state back to the rest of the car. For a

first config, less is more — add only what you need to drive and to be safe:

- **reverse light** (so reversing is legal and visible),

- **gear display** (so you can see what gear is engaged while validating),

- **torque-management signal back to the ECU**, if your strategy uses one.

Two rules from [Configuring Outputs](Configuring_Outputs)

worth repeating, because breaking them is a classic first-config mistake:

- an output does nothing on its own — it must be **driven by a controller**;

- assign each output to **one** controller function only. The same output driven by two

  sources gives undefined behaviour.

Mode indicators, dash gauges, and the rest can wait until the car drives.

## Step 8 — Re-read your config before applying power

Before you leave USB safe mode, do a quick self-review. Most first-config problems are

one of these (the full list is under *Common conceptual errors* on

[Configuration Concepts](Configuration_Concepts)):

- two sources assigned to the same input;

- a CAN network defined but with no preset assigned to it;

- an output with no controller driving it;

- assuming a missing **mandatory** signal will be emulated (it will not — it faults);

- transmission and ECU presets on the wrong networks.

Save the config.

## Step 9 — Validate on the bench

Now bring up bench or vehicle power and check, in order. These mirror the checks in

[Getting Started](Getting_Started_with_IOcan#5-First-Power-Up-with-Vehicle-or-Bench-Power):

1. Connect BAT+, GND and KL15. Use a **current-limited supply** on a bench.

2. Assert KL15. IOcan should become visible in the tool and CAN traffic should appear.

3. Confirm **transmission parameters show up in the datalogger** and there are **no

   communication fault codes**.

4. **Current-draw sanity check:** with a full valve body installed and the engine off,

   current through IOcan should not exceed roughly **2 A**. A much higher figure

   means stop and investigate before going further.

5. Exercise your shift inputs and watch the requested vs. actual gear in the datalogger.

6. Check that your outputs behave — reverse light on in R, gear display tracking.

If any of these fail, the cause is almost always in wiring or in one of the steps above

— work back through them rather than pushing on.

## Step 10 — First controlled drive

Only once the bench checks are clean: move to a controlled environment and verify

behaviour under load — clean engagements, sensible shift points, torque handling during

shifts. Keep validating in small increments. This is the point where your first config

stops being a setup exercise and becomes a tune you refine.

---

## Where to go next

- [Configuration Concepts](Configuration_Concepts) — the model behind every step here

- [Configuring Inputs](Configuring_Inputs) and [Configuring Outputs](Configuring_Outputs) — the full reference for every IO type

- [Working with the CAN Bus](Working_with_the_CAN_Bus) — networks, presets, raw frames, timeouts

- [Supported transmissions](Supported_transmissions) — what is supported and transmission-specific notes

- [CAN Gateway Pinout](CAN_Gateway_Pinout) — pinouts for the physical side