Book a demo

Know-how · Measurement

CAN log formats

Five formats for the same traffic, and the conversion between them is where timestamps and error frames quietly go missing.

By , Founder & Lead Engineer

In short

A CAN recording is normally stored in one of a few formats. ASC is Vector's text-based trace: human-readable, easy to diff, large on disk. BLF is Vector's compressed binary equivalent: far smaller and faster to read, but not inspectable in a text editor. MF4 (ASAM MDF) is the measurement format used across the industry, able to hold bus frames and decoded analogue channels together with metadata in one file. candump is the text output of SocketCAN on Linux. CSV is whatever the exporting tool decided it is. None of them carries signal meaning: a DBC or equivalent description is needed to turn frames into named, scaled signals. Converting between formats is lossy in ways that are easy to miss — timestamp resolution, error frames, bus-status events and CAN FD flags are the usual casualties.

01

What each format actually holds

ASC is a line-per-frame text trace with a timestamp, channel, identifier, direction, data length and payload bytes. Because it is text you can open it anywhere, grep it, and diff two runs. The cost is size — a long recording becomes very large — and parsing speed, since every line has to be read and interpreted.

BLF stores the same information compressed and binary. It is dramatically smaller and much faster to load, which is why long or high-rate recordings are usually captured in it. You cannot inspect it without a tool that understands the container.

MF4 is a different class of file. It can hold raw bus frames and decoded signal channels side by side, with units, conversions, comments and the recording's own metadata, and it is designed for multi-gigabyte measurements read by memory-mapped access rather than loaded whole. When a test produces both bus traffic and analogue measurement, MF4 is what keeps them on one time base.

  • ASCVector text trace. Readable and diffable; large and slower to parse.
  • BLFVector binary log. Compact and fast; needs a tool to read.
  • MF4 / MDF4ASAM measurement file. Frames plus decoded channels plus metadata.
  • candumpSocketCAN text output on Linux. Minimal, ubiquitous in open tooling.
  • CSVAn export, not a standard. Column layout varies by whatever wrote it.

02

What gets lost in conversion

Converting a log is not a neutral operation, and the losses are rarely announced. Timestamp resolution is the common one: a format or exporter that rounds to milliseconds will destroy the ordering of frames that arrived microseconds apart, which is exactly the detail a bus-timing investigation depends on.

Error frames and bus-status events are the next casualty. Many converters carry only data frames, so a recording that documented a bus-off event arrives on the other side looking healthy. CAN FD attributes — the bit-rate-switch flag, the error-state indicator, payload lengths above eight bytes — can be flattened or dropped by a converter written before FD existed.

The practical rule is to keep the original. Convert for a specific tool when you have to, treat the converted file as derived, and go back to the source recording when a result is surprising.

  • Timestamp resolutionRounding destroys ordering of closely spaced frames.
  • Error and status framesOften dropped; a bus-off event disappears silently.
  • CAN FD attributesBRS, ESI and payloads above 8 bytes can be flattened.
  • Channel identityMulti-bus recordings can collapse into one channel.

03

Which format should you record in?

Record in the richest format your logger supports, and convert downstream rather than upstream — you can always produce a CSV from an MF4, and you can never recover what a CSV threw away. For bus-only work BLF is the pragmatic default: compact, fast, and lossless relative to ASC. Use ASC when a human has to read or diff the trace, or when a tool in the chain only accepts text.

When the test also produces analogue or calculated channels, MF4 earns its place, because it keeps the bus traffic and the measured signals on one time base in one file rather than leaving you to align two recordings afterwards.

04

Reading them without converting first

Most of the loss above happens because a tool only accepts one format, so everything gets converted to reach it. MDX opens MDF4, BLF, ASC, CSV and Excel directly and resolves DBC signal aliases on load, which removes the conversion step for the common cases. Multi-gigabyte MDF files are read by memory-mapped access rather than loaded into memory.

DiagAI works on the diagnostic side of the same recording, across UDS, OBD-II and J1939, so a fault and the bus traffic around it can be read together rather than in two tools.

Standards & references

Check the source.

These primary sources define the formats and regulatory context discussed above. They do not certify or endorse VehicleLab products.

Questions

Frequently asked.

What is an ASC file in CAN?

A Vector ASCII trace file: a text log with one line per CAN frame, carrying timestamp, channel, identifier, direction, length and payload. Being text makes it readable and diffable at the cost of size and parsing speed.

What is the difference between ASC and BLF?

They hold the same kind of information. ASC is text, readable anywhere and large; BLF is Vector's compressed binary format, much smaller and faster to read but not inspectable without a tool.

Can I convert a BLF file to MF4?

Yes, and tools exist to do it, but treat the result as derived. Conversion commonly loses timestamp resolution, error and bus-status frames, and CAN FD attributes. Keep the original recording.

Do I need a DBC file to read a CAN log?

To see frames, no. To see named, scaled signals rather than raw identifiers and bytes, yes — the log format carries the traffic, and the DBC carries the meaning.

Which CAN log format is best for long recordings?

BLF for bus-only work, because it is compressed and fast to read. MF4 when the test also produces analogue or calculated channels, because it keeps bus traffic and measured signals on one time base in one file.

Next step

Open one of your own files with us.

Send a measurement, an A2L or an EHANDBOOK container. We will open it in the instruments on a call, with your engineers in the room.