What the device transmits
Applies to: IOcan · Standalone controller. What this means
There is no single "device CAN stream" to point a decoder at. What appears on the bus depends entirely on what you configured, and it comes from four different mechanisms. Knowing which one you are looking at answers most questions about a frame you did not expect.
| Mechanism | Frames | Who defines the layout |
|---|---|---|
| CAN objects you define | Whatever you configure | You |
| Third-party device emulation | Fixed, per preset | That vendor |
| Transmission emulation | Fixed, extensive | The vehicle manufacturer |
| The display protocol | One frame | Us — specified below |
1. CAN objects you define
The normal way to get data out. You create a CAN object output or CAN output, choose the ID, choose which values go in which bytes, and choose the rate.
This is why there is no fixed output stream and no single DBC. The frame layout is a configuration choice, so it is different on every car. If you need a DBC for your logger, generate it from your own configuration — you defined it.
2. Third-party device emulation
Several presets do not just read an ECU, they also transmit back to it, by masquerading as a device that ECU already understands. This is how gear, temperature, cut and blip get onto a dash or into an ECU's own logging without any hand-mapping.
| Preset | Transmits on | Note |
|---|---|---|
| Ecumaster EMU Black | 0x640, 0x641, 0x642 |
As an Ecumaster CAN switch board v3 — see ADU integration |
| Ecumaster gear display | 0x600, 0x604 |
|
| MaxxECU | 0x600, 0x603, 0x604, 0x605 |
|
| Haltech v2 | 0x2C1, 0x2C3, 0x2C7 |
|
| MoTeC M1 ProDrag | Configurable base ID, plus +1, +2, +3 |
|
| SCS Delta | 0x700, 0x701 |
|
| Bosch MS6 | 0x100, 0x610 |
Output only — this preset reads nothing back |
| GM LS E38 PCM | The PCM's own frames | Factory protocol — see below |
| Ford Falcon | The ECU's own frames | Factory protocol — see below |
The byte layouts are those vendors' protocols, not ours, so they are not reproduced here — your ECU or dash already knows them, which is the entire point of emulating a device it recognises. What each preset sends is on its own ECU integration page.
Where the preset speaks a factory protocol rather than an aftermarket one, the frame identifiers are not published either. The IDs above are from protocols their vendors document openly; the GM and Ford presets talk to a factory ECU, and those definitions are the vehicle manufacturer's — the same position taken for transmission emulation below. You do not need them: select the preset for your ECU and it handles the conversation.
⚠️
0x641has two possible owners. The Ecumaster EMU Black preset uses0x640–0x642, and the display protocol below also transmits on0x641. Enable both on the same bus and two nodes transmit the same ID with different data — which produces bit errors that look like random corruption. Every transmitted ID must have exactly one owner; see CAN Bus Diagnostics.
3. Transmission emulation
The transmission-side presets recreate the CAN environment the factory control unit expects. This is the largest set by far — the G-series 8HP Gen 2 preset alone transmits more than fifty distinct frame IDs across two buses.
These are the vehicle manufacturer's frame definitions, reconstructed. They are not published, and they are not something you need: you select the preset matching your transmission and platform, and it handles the conversation. See the configuration page for your transmission (8HP · PDK).
If a frame on your transmission bus is unexpected, it is almost certainly from this layer, and the thing to check is that you paired the right preset for your platform and generation.
4. The display protocol
The one stream that is ours to specify. A single frame carrying the values a gear display needs.
| Preset | Control strategy display |
| CAN ID | 0x641 — standard, not extended |
| Length | 8 bytes |
| Rate | 100 ms |
| Byte | Field | Type | Note |
|---|---|---|---|
| 0 | Transmission temperature | uint8 |
|
| 1 | — | Unused, transmitted as zero | |
| 2 | Gearbox mode | uint8 |
|
| 3 | Current gear | int8 |
Signed — reverse is negative |
| 4–5 | — | Unused, transmitted as zero | |
| 6–7 | Vehicle speed | uint16 |
Little-endian |
Values are transmitted as the outputs produce them — the preset applies no scaling of its own, so whatever scaling you set on the source output is what appears on the bus. An unassigned output transmits zero rather than being omitted.
This is enough to decode the frame or build a display against it. If you want it in a DBC, it is four signals — quicker to write by hand than to download.
The 100 ms is confirmed against the firmware: the CAN task runs on a 1 ms tick and this frame's entity counts 100 of them between transmissions.
Getting data into a logger
The practical question behind most of this. Three routes, in order of ease:
- Your ECU already receives it. If your ECU has a preset in section 2, gear, temperature and the cut/blip levels are already reaching it — log them there.
- A dash that speaks a supported protocol. The Ecumaster ADU integration is a fully worked example, screenshot by screenshot, and the same pattern applies to any dash reading the emulated device.
- Define your own frame. A CAN object output with the channels you want, at the rate you want. Most flexible, and the only option for a logger with no supported preset.