In our last article we covered CAN bus itself: the two wires, CAN High and CAN Low, that let your ECU, ABS, dash, and TPMS all share one network instead of needing a dedicated wire for everything.

That explains how the devices are connected. It doesn't explain what's actually flowing back and forth between them once they're wired up.

If you went looking at real CAN traffic, you'd see something like this:

To someone who reads this stuff every day, that line means something specific. To everyone else, it's a wall of nonsense. What is 0x24A supposed to represent? Why is the data written in little pairs like that? Does 40 1F mean 40.1 degrees, or 1,615 RPM, or nothing at all? That's what this article is for. You don't need to become a CAN engineer to follow along. By the end, you'll be able to look at a line like the one above and understand what you're looking at, what's still missing, and how it eventually becomes a real number like "82.5 mph" on a dash.

A CAN Message Is Not a Sensor Reading

When you look at a CAN message, you are not looking at a value like "82.5 mph." You're looking at a small packet of digital information that has to be interpreted before it means anything at all.

A given message ID might carry engine RPM in its first two bytes, throttle position in the next two, and oil pressure after that, according to whoever designed that system:

A completely different manufacturer could use that exact same ID number for a completely different set of information. So if you captured eight bytes of raw data on a network you didn't already know, you genuinely could not look at those bytes and know what they mean. You'd need the actual definition behind them, usually called a CAN protocol document, or in more standardized form, a DBC file. We'll get to that shortly.

A real CAN message has more going on underneath the ID, DLC, and data bytes (a CRC, an acknowledgment bit, some framing bits). All of that is handled automatically by the CAN hardware built into every device. Nobody sets it up by hand, and you don't need to think about it. The three parts that actually matter are the ID, the DLC, and the data bytes.

The ID: More of a Broadcast Than an Address

A standard CAN ID is 11 bits long, which works out to 2,048 possible ID values on a given network. Some systems use an extended 29 bit ID instead, allowing for a much larger number of unique values. Either way, the basic idea is the same.

A CAN ID is not really an address, not in the way you'd normally think of one. It doesn't route a message to one specific recipient. CAN doesn't work by saying:

It's closer to a device announcing:

...out onto the network, without knowing or caring who's listening. Every device on that bus can see the message go by, and each one individually decides for itself whether that ID is something it cares about. It works a lot like a radio broadcast: a station doesn't know who owns a receiver, it just transmits and lets anyone tuned in pick it up. That's also why your dash can quietly listen in on an ABS system's wheel speed messages without the ABS unit needing to know your dash exists at all.

If two devices try transmitting at the exact same instant, the one using the lower numerical ID wins and keeps going. The other backs off and quietly retries a moment later. Nothing gets corrupted, nothing crashes, it's a bit like two people starting to speak at once, the more important thing gets said first and the other person just finishes their sentence right after. This is called arbitration. CAN itself doesn't know which data matters, engineers decide that: something time-critical, like wheel speed feeding an ABS system, usually gets assigned a low ID so it wins arbitration and gets onto the bus promptly. Something less urgent, like an odometer value, can afford a higher ID and a slightly longer wait if the bus is busy.

Bytes Are Just Numbers, Written in a Shorthand

The data field of a CAN message holds up to 8 bytes. It helps to actually understand what a byte is rather than just accept it as a technical term.

A byte is 8 bits, and a bit is nothing more than a tiny switch that's either off or on. Picture 8 light switches in a row. Every unique way those 8 switches could be flipped gives you exactly 256 possible combinations:

That's all a byte is: one number, picked out of 256 possibilities. CAN data is almost always written using hexadecimal instead of a long string of switches. Hex is nothing more than shorthand for the exact same number, the same way a price tag reads "$1,240" instead of spelling out "one thousand two hundred forty individual dollars." Once you know the shorthand, it's faster to read, but it's the identical value underneath.

On their own, none of those bytes say what they represent. A byte doesn't come labeled "wheel speed." That meaning has to come from somewhere else entirely, which is really the whole point of everything that follows.

One Message Can Carry More Than One Piece of Information

A single 8 byte message rarely carries just one measurement. It's extremely common for several separate values, called signals, to be packed together into the same message.

Picture a delivery truck making one stop instead of four. Rather than sending a separate truck for each of the four wheel speeds, one CAN message can carry all four in a single delivery, each one living in its own dedicated pair of bytes:

The message is the truck. The signals are the individual packages riding inside it. This is a big part of why CAN is efficient on a race car: instead of flooding the network with a separate message for every single measurement, related values get bundled together and sent as one unit. This is also why "message" and "signal" aren't interchangeable words to anyone who works with CAN regularly. The message is the whole delivery. A signal is one specific item inside it.

Where the Meaning Actually Comes From

CAN itself has no idea what any message means. It reliably moves bytes from one device to another, and that's the entirety of its job. The meaning, which bytes belong to which signal, and how to turn raw bytes into a real number, is defined completely separately, in what's usually called a CAN database or, in MoTeC's case, a communication template.

That conversion almost always comes down to one formula:

An old-fashioned thermostat dial is a good way to picture this. Imagine a dial with notches numbered 1 through 10 instead of actual degrees. Nobody can tell what notch "4" means unless someone has separately said each notch equals 2 degrees, starting from a baseline of 60:

Take that rule away, and the number 4 on its own means nothing. That's the exact relationship between a raw CAN value and its scale and offset.

Here's a made-up but realistic example to show the math, clearly labeled as illustrative rather than pulled from a real device: say a wheel speed signal is sent as a raw whole number, and the database says the scale is 0.1 with an offset of 0.

Change the scale or offset even slightly, and that same raw number would mean something completely different.

That's why "it has CAN" was never a real answer to whether two products would work together, something we touched on in the last article. Without the correct database entry for a given ID, a perfectly good CAN message is just a stream of numbers with nothing attached to explain what they mean.

What Is a DBC File?

You'll hear this term the moment you're working with anyone who deals in CAN data regularly: "do you have the DBC?" A DBC file is one common, standardized way of storing a CAN database, the ID, byte positions, byte order, signed or unsigned, scale, offset, and units for every message on a network, all in one file that compatible software can read automatically.

Not every manufacturer publishes their definitions as an actual DBC file specifically. Some publish a written protocol document instead, and MoTeC builds its own version as a communication template. The format differs, but the underlying idea is identical: it's the dictionary that turns raw bytes into something you can actually read.

A Real Bosch Motorsport Example, Kept Honest

It's worth grounding all of this in something real rather than only hypothetical. Here's what we could actually confirm rather than estimate.

That list comes straight from Bosch's own ABS M5 and M4 protocol documentation, along with third-party integration guides written for connecting the ABS to a data logger. What we won't do is hand you an exact message ID, byte position, and scaling factor and present it as verified fact, unless we've confirmed it against Bosch's protocol documentation for your specific kit. The list of what's broadcast is public and well documented. The precise bits and scaling for a given firmware version is the kind of detail you confirm against the actual protocol document, never something to guess at and call fact.

To show the process without inventing numbers we can't back up, here's a generic, clearly illustrative walkthrough of what any device receiving one of those wheel speed signals would actually be doing:

Two Different Problems, Often Confused With Each Other

This is a genuinely useful way to think about troubleshooting, and it deserves its own section because mixing these two things up wastes more time than almost anything else.

Can the devices physically talk to each other? CAN High and CAN Low wired correctly, proper termination, matching baud rate, solid power and ground.

Do they actually understand each other's data? Correct CAN IDs, correct byte positions, correct scaling, correct byte order, message definitions that genuinely match.

Picture two people on a perfectly clear phone line who happen to be speaking different languages. The call quality is excellent, every word comes through, and neither person understands a thing the other is saying. That's what a CAN system looks like when it's physically working but not decoding correctly. "The dash is seeing the CAN message" does not mean "the dash is correctly interpreting the CAN message."

Two More Terms, and What Goes Wrong Without Them

Two more concepts worth knowing, because getting either one wrong is a genuinely common source of a dash or logger showing numbers that are obviously, sometimes hilariously, incorrect.

Byte order. Whenever a signal spans more than one byte, the documentation has to specify which byte gets read first. The exact same two bytes can represent two different numbers depending on the order. You've actually run into this exact kind of ambiguity before, just not with CAN:

Both readings use the same two numbers. Only one is correct, and it depends entirely on which convention the document is using. CAN byte order works the same way, labeled Intel (little-endian) or Motorola (big-endian) in real documentation. The practical rule: never assume the byte order, always read what the documentation says.

Signed vs. unsigned. An unsigned number can never go negative, an 8 bit unsigned value only runs from 0 to 255. A signed value can represent negative numbers too, which matters for anything that swings in two directions, like lateral acceleration or a temperature that can drop below zero. If a device reads a signed signal as though it were unsigned, a negative value doesn't disappear, it wraps around into an enormous positive number instead:

Your engine hasn't quietly developed the hydraulic force of an industrial press. A value got read using the wrong assumption, and the display is showing the mathematical consequence of that mistake. Wiring problems tend to show up as no data at all. Decoding problems like this one tend to show up as data that's very much present, and very much wrong.

Why This Matters When You're Actually Setting Up a Dash or Logger

You won't be writing CAN databases from scratch for most motorsport builds. Understanding that this exists is really the point, because it explains why the setup software you'll actually use behaves the way it does.

When you configure a MoTeC dash to read a Bosch ABS system, you're not typing raw IDs and byte positions by hand. MoTeC calls its pre-built version of this a communication template, a ready-made database for a specific integration that's already been worked out and tested. Manufacturers publish CAN documentation so this can be done correctly by someone else, and a lot of the plug-and-play feel of modern motorsport electronics comes directly from templates like these already existing.

Where this becomes something you actually need to pay attention to is custom integration: wiring in a device that doesn't already have a template, or building a message definition yourself for a sensor you added on your own. That's when someone needs the manufacturer's actual CAN protocol documentation, the exact thing this article just walked through.

What You Genuinely Don't Need to Worry About

The CRC, the acknowledgment bit, and the framing around every CAN message are real parts of the standard, but they're handled entirely and automatically by the CAN controller hardware in every device on the market. You normally won't manually calculate a CAN CRC, and you don't need to understand arbitration at the electrical level to make good decisions about your car's electronics. Understanding the ID, the DLC, the data bytes, the fact that one message can carry several signals, and the fact that meaning always comes from a separate database, gets you real, useful comprehension without turning this into homework.

The Beginner's CAN Decoding Checklist

If someone hands you a CAN protocol document, here's what to actually look for:

You won't need to work through this list by hand for most plug-and-play motorsport parts, the manufacturer's template already answers it. It's most useful the moment you're troubleshooting a mismatch or integrating something custom.

The Bottom Line

A CAN message is a small packet with an ID that doubles as both its identity and its priority, a DLC that states how many data bytes are included, and up to 8 bytes of raw payload that can carry more than one signal at a time. On its own, that payload means nothing. A CAN database, or a manufacturer's communication template, maps a given ID and byte position to an actual signal, complete with the scaling and offset needed to turn a raw number into something recognizable like km/h, psi, or degrees.

Two devices can both speak CAN and still fail to understand one another, the same way two people can both speak English without sharing the same technical vocabulary. They're speaking the same language without necessarily reading from the same dictionary.

Frequently Asked Questions