CAN4 · the CAN bus
CAN, and what differs between ECUs
Among aftermarket ECUs that read a user-defined CAN frame, what differs from one to the next is not the protocol but a handful of numbers: which identifiers it listens for, how fast the bus runs, which byte comes first, and what a count means. Each of those is a setting on the CAN4's page, so one firmware can be set up for each ECU that reads a user-defined frame of 8- or 16-bit values.
Written from ISO 11898, the ECU makers' own CAN documentation, and the module's firmware, September 2026.
00The same two wires
CAN is one bus: two wires, CAN H and CAN L, twisted together, with a 120 Ω terminator at each end. Every device on the bus hears every frame. There are no addresses and no master. A device puts a frame on the bus when the bus is free, and every other device decides for itself whether that frame is one it cares about.
A Link, a Haltech, a MoTeC, an ECUMaster, a dash and a logger all attach to that pair the same way. The wiring, the voltages and the frame format are the standard's, CAN 2.0B, and nothing about them belongs to a vendor.
01What a frame is
An identifier, up to eight bytes, and a checksum the hardware handles. The identifier says what the frame is; the bytes mean whatever the sender and the receiver agreed. That agreement is the whole of a "CAN protocol": when a vendor publishes one, it is a list of identifiers and what the bytes in each mean. The CAN4's default layout uses two identifiers.
02What differs between ECUs
| Setting | What it decides | The CAN4's default |
|---|---|---|
| Bit rate | How fast the bus runs. Every device on one bus must agree; a device at the wrong rate corrupts every frame on it. | 500 kbit/s, from 50 kbit/s to 1 Mbit/s |
| Identifier | Which frame is which. 11-bit on most buses, 29-bit on some. It must be one that nothing else on the bus uses. | 0x6E0 data, 0x6E1 status |
| Byte order | Whether a 16-bit value's high byte comes first (MS first, big-endian, Motorola) or last (LS first, Intel). Link's module streams and Haltech's CAN protocol put it first; Link's configurable Generic Dash stream puts it last. | MS first, settable per value |
| Sign and width | Whether a value can be negative, and whether it takes one byte or two. | Signed, 16 bits |
| Scale and offset | What one count means: 0.1 °C, 0.1 kPa, 1 mV, 0.01 AFR. The receiver multiplies back. | 0.1 °C, 0.1 kPa, 1 mV, 0.01 AFR, 0.001 λ or 0.1 % per count, by the sensor's unit |
| Position and rate | Which bytes hold which value, and how often the frame is sent. | Bytes 0, 2, 4 and 6; 20 Hz data, 5 Hz status |
| ECU | Reads a user-defined frame as | Where it stands |
|---|---|---|
| Link G4X, G5 | A Receive User Stream in PCLink, onto CAN Analog channels | Guide, from Link's documentation; not yet run on an ECU |
| Haltech Nexus, not the Rebel | Generic CAN, in NSP 1.48 or later | Guide, from Haltech's documentation; not yet run on an ECU. Haltech has not published which signal formats Generic CAN takes |
| Haltech Nexus Rebel, Elite | Nothing: neither takes a user-defined CAN frame | Not supported |
| ECUMaster, MoTeC, RaceCapture | A user-defined CAN input, each in its own software | Not yet written up |
| AEM | AEMnet, 29-bit identifiers at 500 kbit/s | Unconfirmed |
| Dashes and loggers | Most import a DBC file, which the module writes for its own layout | By the DBC |
03What the module does about it
Every row of the first table is a setting on the CAN tab of the module's page, and the table behind it goes further: up to four frames, each with its own identifier, length and rate, and up to eight values in each, every value with its own position, width, sign, byte order, scale and offset. So the module's frames are set to what the ECU expects, on the page, with no firmware per ECU. The layout comes out as text and as a DBC file.
Out of the box the module is set up for a Link: 500 kbit/s, identifiers 0x6E0 and 0x6E1, MS first, four signed readings at 20 Hz. For a Haltech Nexus with Generic CAN, set the bit rate to that of the bus the module joins: 1 Mbit/s on the Haltech bus, or on a second bus the rate that bus runs at. Whether Generic CAN takes these values as they are is not yet confirmed. Neither setup has run on an ECU yet. For another ECU, set the CAN tab's fields to what it expects.
04How the module protects the bus
A device that transmits can take a bus down. This is how the firmware is written to avoid it; none of it has been tried on a bus yet.
- Silent at power-on. It listens first, and does not transmit while it hears bus errors, as traffic at another bit rate gives. On a silent bus there is nothing to check the rate against, so it transmits on probation, backs off if nothing acknowledges it, and stops after eight tries.
- It goes quiet on an identifier in use. One it hears another device sending on, it stops sending, and its Bus tab says so.
- A change is on probation. A new bit rate, identifier, frame length or rate that the bus never acknowledges is undone after 30 seconds.
- Bus load is capped. The page shows what the frame table takes of the bus at the chosen bit rate, and the module refuses a table above 30 %.
05What it does not reach
- CAN FD. The module is classic CAN 2.0: eight bytes a frame, 1 Mbit/s at most.
- Protocols that talk back. J1939 address claiming, OBD-II requests, and posing as a vendor's own expander box. The module only transmits.
- Bit-level fields, 32-bit and floating-point values, multiplexed frames. Every value it sends is byte-aligned, 8 or 16 bits wide.
- Receiving. The module reads the bus only to protect it: to check the rate, to spot its own identifiers in use, and to count the traffic.
Full specifications, wiring and the frame layout are in the datasheet (PDF); the headline specs are on the CAN4 page. Setup on each ECU: the guides.
The CAN4 isn't on sale yet. Leave your email on the store page to hear when it ships.
Written from:
- ISO 11898-1, the CAN data link layer and physical signalling, and CAN 2.0B
- Link: CAN Setup (archived copy)
- Haltech: Introducing Generic CAN
- Haltech technical library: CAN protocol information