Understanding CAN DBC files
A DBC file is the key that turns raw CAN bytes into named values like engine speed and temperature. Here is what is inside one, and how the decoding actually works.
A DBC file is a plain-text database that tells software how to read a CAN bus. On its own, a CAN frame is just an identifier and up to eight bytes of raw data, with nothing to say what those bytes mean. The DBC describes where each value sits inside the frame, how to scale it and what unit it is in, so a tool can turn the raw bytes into something readable like 2,000 rpm or 87 degrees. It works as a signal library that travels with your project.
| The DBC records | So that a tool knows | Example |
|---|---|---|
| The message CAN ID | Which frame the signal lives in | 256 (0x100) |
| The bit position | Where the signal starts and how long it is | start 24, 16 bits |
| The byte order | How to read multi-byte values | Intel or Motorola |
| The conversion | How to scale raw bits to a real value | factor 0.125, offset 0 |
| The unit | What the number represents | rpm |
Why raw CAN needs a DBC
Capture traffic from a CAN bus and you get rows of identifiers and hex bytes. A frame might read ID 0x100 with data 00 00 00 80 3E 00 00 00. That is correct and complete, but it tells you nothing about what is happening in the vehicle. Hidden in those eight bytes could be engine speed, a temperature, a few status flags, or all of them at once.
The DBC is the missing description. It says, for this identifier, bits 24 to 39 are the engine speed, read little-endian, multiply by 0.125, and the unit is rpm. Apply that and 0x3E80 becomes 2,000 rpm. The same file can describe hundreds of messages and thousands of signals, which is why one DBC can decode an entire network.
What is inside a DBC
A DBC is just text, and it is built from two main kinds of line. A message line, beginning with BO_, defines a frame: its CAN ID, a name, how many bytes it carries and which node sends it. Beneath each message sit one or more signal lines, beginning with SG_, and each one describes a single value packed into that frame.
CAN ID
Which message the signal belongs to, written in decimal in the file.
Bit position
The start bit and length that mark out the signal inside the payload.
Byte order
Whether multi-byte values are stored Intel or Motorola first.
Conversion
The factor and offset that scale the raw bits into a real value.
Unit
What the decoded number means, such as rpm, degrees or volts.
Nodes
Which control unit sends a message, and which ones receive it.
The signal is not an electrical input or output. It is a physical parameter, such as temperature, engine speed or a voltage, described well enough that any tool reading the same DBC will decode it the same way.
Reading a DBC line, piece by piece
The format looks cryptic at first, but every part has a clear job. Below is a real message and one of its signals. Tap any highlighted part to see what it means. Nothing here is memorised in practice, an editor fills it in, but knowing how to read it makes decoding problems far easier to spot.
Decoding a value yourself
Once you know where a signal sits, decoding it is two steps. First, pull the signal's bits out of the frame to get a raw whole number. Second, apply the linear conversion from the DBC: the physical value equals the factor times the raw value, plus the offset. That is the whole formula, and it is the same one every CAN tool uses under the bonnet.
For the engine speed example, the raw 16-bit value 0x3E80 is 16,000. With a factor of 0.125 and an offset of 0, the physical value is 0.125 times 16,000, which is 2,000 rpm. The decoder below does both steps for any little-endian signal. Change the bytes or the signal definition and watch the highlighted bits and the result update.
Byte order: Intel vs Motorola
Most decoding mistakes come down to byte order, also called endianness. When a value spans more than one byte, the two conventions disagree on which byte comes first. Intel, or little-endian, stores the least significant byte first. Motorola, or big-endian, stores the most significant byte first. In the DBC, @1 means Intel and @0 means Motorola.
The practical advice is simple: take the byte order straight from the DBC and do not second-guess it. If a decoded signal looks wildly wrong, swapped byte order is the first thing to check. Tools handle the conversion automatically once the DBC is correct, which is the main reason to keep a tidy, accurate file.
A DBC turns raw frames into real values with one formula: factor times raw, plus offset. Get the byte order right and the rest follows.
CAN DBC FAQ
What is a DBC file used for?
It tells software how to decode a CAN bus. A DBC describes which message each signal belongs to, where the signal sits in the frame, how to scale it and what unit it is in, so raw bytes become readable values like engine speed or temperature.
What does a DBC file contain?
Messages, defined by lines beginning with BO_, and signals, defined by lines beginning with SG_. Each message records its CAN ID, name, length and transmitting node. Each signal records its start bit, length, byte order, factor, offset, range and unit.
How do you decode a CAN signal from a DBC?
Extract the signal's bits from the frame to get a raw whole number, then apply the linear conversion: physical value equals factor times raw value, plus offset. The DBC supplies the bit position, factor and offset.
What is the difference between Intel and Motorola byte order?
They disagree on which byte of a multi-byte value comes first. Intel, or little-endian, stores the least significant byte first. Motorola, or big-endian, stores the most significant byte first. In the DBC, @1 is Intel and @0 is Motorola.
Can I open a DBC file in a text editor?
Yes. A DBC is plain ASCII text, so it opens in any editor such as Notepad. Editing by hand is possible but fiddly, which is why dedicated tools are usually used to create and maintain them.
Which tools can read DBC files?
Many, including DIALOG, Module Analyser and REXDESK from Influx Technology, as well as MATLAB Vehicle Network Toolbox and CANdb++ from Vector. DIALOG is also an efficient tool for creating and editing a DBC.
Written by the engineering team at Influx Technology. The decoder handles unsigned little-endian signals for teaching. Always validate decoded data against a known reference.
From raw CAN to engineering values
Loading a DBC into software from Influx Technology turns raw frames into named signals automatically. REXDESK and DIALOG read and apply your DBC files, and DIALOG can also create and edit them, so your logged data arrives ready to analyse.
