What CAN is, and what it isn't

Controller Area Network (CAN) is a message-based bus protocol, not a point-to-point connection. Every node on the network — an engine ECU, an ABS module, a dashboard cluster, a data logger — shares the same two wires and listens to everything sent on them. There's no addressing scheme like an IP network; instead, every message carries an identifier that says what the message is, and any node that cares about that identifier reads it. This is why a single CAN log can contain traffic from a dozen different modules interleaved on the same two wires.

It was developed by Bosch in the 1980s for automotive use specifically because it's robust to electrical noise and degrades gracefully — a single corrupted message gets retried automatically, and a single failing node can be shut out of the bus without taking the rest of the network down with it.

The physical layer

Standard CAN runs over a twisted differential pair — CAN High and CAN Low — with a 120Ω termination resistor at each end of the bus. The differential signalling is what gives CAN its noise immunity: a bit is read by the difference between the two wires, not their absolute voltage, so common-mode electrical noise (picked up equally on both wires) mostly cancels out.

Bits are described as dominant (logical 0, CAN H pulled high and CAN L pulled low — a larger voltage difference) or recessive (logical 1, both wires sit near the same mid-level voltage). This matters more than it sounds like it should — it's the entire mechanism behind arbitration, below.

Baud rateTypical use
125 kbit/sBody/comfort networks (windows, lighting, low-priority modules)
250 kbit/sChassis networks, some diagnostic buses
500 kbit/sPowertrain/engine networks — the most common OBD-II speed
1 Mbit/sHigh-speed motorsport and backbone networks

All nodes on one physical bus must run the same baud rate — this is usually the first thing to check when a logger reports no traffic at all.

Anatomy of a CAN frame

Every data frame follows the same shape, whether it's carrying engine RPM or a diagnostic response:

SOF 1 bit Arbitration ID 11 bit (standard) or 29 bit (extended) RTR 1 bit data/ remote Control incl. DLC 6 bit Data 0–8 bytes the actual payload CRC 15 bit + delim ACK 2 bit EOF 7 bit Lower ID = higher priority Decoded by tools like ONAC Network Studio ACK'd by any valid receiver
A standard CAN data frame. Extended frames add an 18-bit identifier extension after the base 11 bits, for 29 bits of ID space total.

The fields that matter day-to-day

  • Arbitration ID — identifies what the message is (e.g. "engine data"), not who sent it or who it's for. This is what you filter and decode by.
  • DLC (Data Length Code) — how many of the 8 possible data bytes are actually used, from 0 to 8.
  • Data — the payload. On its own it's just bytes; a DBC file is what tells you byte 2, bits 0–7 is "Engine_RPM" scaled by 0.25.
  • CRC — every receiving node checks this and won't ACK a frame that fails it, which is a large part of why CAN is considered reliable at the wire level.

Arbitration: how nodes share one wire without colliding

CAN doesn't have a bus master. Any node can start transmitting the moment the bus is idle, and if two nodes start at the same time, they resolve who wins without corrupting either message — this is the part most protocols can't do.

While a node transmits its arbitration ID, it also reads back what's actually on the bus. Because a dominant bit (0) always overrides a recessive bit (1) electrically, the moment a node sends a recessive bit but reads back a dominant one, it knows another node is sending a lower ID — and it immediately stops transmitting and waits, while the winning node carries on as if nothing happened. No collision, no retransmission of a garbled frame, no random backoff.

The practical upshot: a numerically lower CAN ID always wins arbitration and gets priority on the bus. This is exactly why safety-critical, time-sensitive messages (like engine torque or brake pressure) are almost always assigned low IDs, and comfort/body messages (interior lighting, seat position) get high ones.

Why this matters for logging: a bus under heavy load will still deliver low-ID messages on time — it's the high-ID, low-priority ones that get delayed first. If a capture shows gaps in one signal under load, check its arbitration ID relative to the busier traffic around it before assuming a hardware problem.

Standard vs. extended identifiers

Most passenger vehicle networks use standard (11-bit) identifiers — 2,048 possible IDs, which is normally plenty for one physical bus. Extended (29-bit) identifiers exist for networks that need far more distinct message types (some truck/agricultural/industrial CAN applications, and J1939-based networks), and are structured as an 11-bit base ID plus an 18-bit extension, so they still arbitrate correctly against standard frames on a mixed bus.

Where this fits into the ONAC platform

ONAC Network Studio captures frames exactly as described above — arbitration ID, DLC, and raw data bytes — and applies a DBC file to turn them into named, scaled signals in real time, across whatever combination of interfaces, networks, and devices a given job needs. The same frame structure is what any OBD-II/UDS request/response tooling is built on too (see OBD-II & UDS Diagnostics) — understanding it is what makes the output make sense, rather than just trusting a number on a screen.