Using CanLab

This is the loop the application is built around. It works start to finish on the bundled sample capture, so you can follow it without any hardware.

The short version

Load a capture. Let the offline analysis tell you which bytes are counters and checksums so you can ignore them. Look at what is left, guess a field, write it down as a signal, and check the decoded value against reality. When it holds up, export.

1. Load a capture

File → Open Log, or the toolbar button. CanLab reads SavvyCAN CSV, candump logs, pcap, Vector BLF and ASC, MDF4 and openpilot rlog; the full list with caveats is in the reference. To follow along without a capture of your own, open canlab/sample_data/sample_kona_drive.csv.

The FRAMES tab fills with every frame in time order. A byte lights up when it changes from the previous frame with the same ID, which is the single most useful thing on the screen early on: the parts of a message that move are the parts worth investigating.

2. See which IDs exist

The panel on the left lists every arbitration ID in the capture with its rate and frame count. This tells you the shape of the bus: a 100 Hz message is almost certainly a control or sensor message, a 1 Hz one is more likely status or diagnostics.

Select an ID and the inspector on the right shows the last frames in hex, a per-byte activity bar, and minimum, maximum and mean for each byte. A byte that never changes is padding or a constant. A byte that changes every single frame is a counter, a checksum, or a fast-moving value.

3. Remove what is not a signal

Two of the eight bytes in a typical message are often not data at all. Go to AUTO-RE → COUNTER/CHECKSUM and run detection. It sweeps every message and reports rolling counters and checksum bytes.

Then ENTROPY BOUNDARIES measures per-bit entropy across a message to suggest where one field ends and the next begins: bits that never change are padding, bits that change together tend to belong to the same value.

How the analysis works explains what these methods actually test, and how much to trust the numbers. The short answer is that they narrow the search; they do not finish it.

4. Guess a field and write it down

Go to DBC BUILDER and create a signal. You need a message ID, a start bit, a length, a byte order and a scale. The bit grid underneath shows the live payload with your selected field highlighted, and converts between grid position and DBC bit numbering, which is the part that is easy to get wrong by hand.

Byte order is the usual trap. If a value looks like it jumps wildly when it should move smoothly, try the other endianness before you conclude the field is wrong.

5. Check it against real frames

The live decode preview under the editor runs real frames from your capture through the definition you just wrote and shows the physical value. This is the moment of truth: a wheel speed that reads 60 to 80 km/h is plausible, one that reads 4,000 is not.

Then plot it. PLOT draws the decoded value over time next to the raw bytes it came from. A physical quantity moves smoothly. A wrong byte order shows up as a sawtooth, because the high and low halves are swapped and the value wraps every time the low byte rolls over.

6. Calibrate against something real

If you have an independent measurement of the same quantity, a GPS speed log for instance, you do not have to guess the scale. Tools → Calibrate signals from a reference file (CSV, GPX) takes a CSV with a time column and any value columns, or a GPX track, finds the clock offset between the reference and the capture, and searches for the CAN field whose values best fit each series by least squares, reporting scale, offset and an R² verdict of PASS or UNCONFIRMED. The rows you pick become DBC signals. See reference calibration.

7. Export

When the definitions hold up, get them out. File → Export DBC, or one of the other formats from the DBC BUILDER: openpilot DBC, Vector CANdb++, AUTOSAR ARXML, or a Wireshark Lua dissector so your signals appear by name in a packet capture. CODE GEN will write Python or C that opens the bus and decodes them. The formats and their caveats are on the exports page.

Working with a live bus

Everything above works on a file. Connecting to hardware adds two things: frames arrive continuously, and you can transmit.

Pick the adapter in Settings → CAN ADAPTERS and use the toolbar's Connect CAN. Frames stream into the same FRAMES tab and every analysis works on what has been captured so far. The Freeze button stops the table scrolling while you read something, without stopping capture.

Transmitting requires arming first, deliberately. Read Safety before you do; it explains what the gate covers and what it does not.

A worked example on the sample

1. Open the sample

   canlab/sample_data/sample_kona_drive.csv, 6,610 frames, 10 IDs.

2. Run counter and checksum detection

   AUTO-RE finds the rolling counters and the trailing checksum bytes, so you know which bytes to ignore.

3. Look at ID 0A6

   It runs at 50 Hz and its bytes move smoothly, which is what a wheel-speed message looks like.

4. Define a 16-bit big-endian signal

   Start bit 7, length 16, scale 0.03125, on message 0A6.

5. Read the preview

   Values in the 60 to 80 range with a unit of km/h. That is the right order of magnitude for a wheel speed, so the scale is plausible.

6. Plot it

   A smooth rise and fall, not a sawtooth. The byte order is right.

7. Export the DBC

   And load it in any tool that reads DBC to confirm it round-trips.