Read CAN / CAN FD Logs in Your Browser — BLF, MF4, ASC + DBC

If you work in automotive diagnostics, validation, or calibration, you already know the ritual. Someone hands you a BLF or MF4. You need to see frames, decode signals with a DBC, plot a few traces, maybe export CSV for a report. The classical answer is a heavyweight Windows toolchain with a seat license. That answer is excellent when you have it. It is awkward when you are on a loaner Mac, a locked-down laptop, or a quick review that does not deserve a full CANoe session.

I built Canmetry for that gap: a browser CAN / CAN FD log viewer that opens common Vector/ASAM-style formats, attaches DBC per channel, and keeps parsing on your machine.

What it is (and what it is not)

Canmetry is an online viewer in the sense that you open a website. It is not a generic "log analytics SaaS" that insists every file must live in a cloud project before you can scroll a trace. Core viewing runs locally in the browser (parsing in a Web Worker). You open BLF, MF4, ASC, CSV, or candump-style input, map DBC where you have it, filter frames, plot signals, and export CSV when needed.

It is also not an AI copilot for vehicles. The value is boring and sharp: formats, decode, graphs, trace — without installing a desktop stack for every quick look. If a product leads with AI summaries of your bus traffic, ask whether it still lets you verify the underlying frames. Engineers still need to see the data.

A realistic first session

1. Open canmetry.com and load a log you already trust. Start with a file you have opened before in another tool so you can sanity-check counts and timestamps. First sessions should reduce doubt, not introduce a new unknown file.

2. Attach DBC per channel when you have definitions. Decode quality depends on the database you bring. Wrong DBC, wrong engineering values — the viewer will not magically invent the network. Keep the DBC revision that matches the software build under test.

3. Filter before you drown. Busy buses are noisy. Narrow by ID, time range, or signal interest before you stare at a wall of frames. Most bug reports already hint at a window; use it.

4. Plot the signals that answer the question. Most reviews are not "show everything." They are "did this temperature climb" or "did that flag chatter." Build the smallest graph that decides the next action. Extra traces feel thorough and slow everyone down.

5. Export CSV only for the slice you need. Reports love tables. Full-log dumps are rarely the helpful artifact. Export the incident window with clear naming: log id, time span, DBC revision.

Offline-style viewing does not require an account. Sign-in exists for optional cloud projects and team workspaces — useful when you choose collaboration, not as a tollbooth to scroll a trace.

Why local decode matters

Logs can contain IP-sensitive behavior, pre-production signals, or customer-vehicle context. A default-upload architecture forces a policy discussion before the engineering discussion. Local decode flips that order: you can look first, and upload only if you explicitly want a shared project later.

Cross-platform access matters too. Not every engineer who needs a quick BLF peek has a licensed Windows seat nearby. A browser tab on Mac or Linux is often enough for triage, especially when the alternative is waiting until someone frees a lab machine.

There is also a human factor: people take shortcuts with sensitive files when the "proper" tool is unavailable. Giving them a local browser path reduces the temptation to drop logs into random personal cloud drives.

Who gets value quickly

• Diagnostics engineers reviewing field logs
• Validation teams checking whether a test produced the expected signal activity
• Calibration folks who want a graph/trace/DBC loop without standing up a full local install for every machine
• Partners exchanging measurements who do not share the same desktop toolchain
• Anyone doing after-hours triage on whatever laptop is open

If you need the deepest vendor-specific automation and hardware-in-the-loop control, keep your primary toolchain. Canmetry is the sharp knife for viewing and decode when speed and access matter.

Practical tips that save time

• Keep DBC versions next to the logs they belong to; mismatched generations waste hours
• Name exports with log + DBC revision so reports stay reproducible
• Confirm CAN vs CAN FD expectations before you blame the viewer
• Treat cloud projects as opt-in collaboration, not as the only way to open a file
• When a plot looks impossible, verify byte order and signal scaling assumptions in the DBC before rewriting the test plan

A short story from review culture

A partner sends a measurement at the end of the day. The question is narrow: did a particular signal exceed a threshold during a drive cycle? Opening a full desktop project can be the right long-term move. Opening a browser viewer can be the right ten-minute move. Teams that only have the first option often delay answers until the next morning. Teams that also have a local viewer unblock the conversation while details are fresh.

That is the niche. Not "replace the suite." Unblock the look.

Closing

I wanted CANoe-adjacent graph/trace/DBC reading without assuming every quick look deserves a full seat install. If that matches your week, open a BLF/MF4/ASC on https://canmetry.com, attach your DBC, and see whether local browser decode gets you to the answer faster.

When not to use a browser viewer

There are honest limits. If you are driving hardware, running complex simulations, or depending on vendor-specific automation hooks, stay in the primary suite. If a log is enormous beyond what a tab should hold, slice it first. If your organization forbids any web tooling for vehicle data regardless of local processing, follow policy — architecture arguments do not override compliance.

Canmetry is for the large middle: competent engineers who need a trustworthy look now, on the machine in front of them, with the DBC they already have.

— Tom Wang