A Browser CAN Log Viewer for BLF/MF4/ASC with Local DBC Decode

Automotive tooling has a long memory: excellent desktop suites, Windows-leaning workflows, and license models that assume a dedicated seat. Those suites earn their place on vehicle programs. They are still awkward for a huge set of everyday tasks — open a partner's BLF, attach a DBC, plot three signals, export a CSV slice, move on.

Canmetry is my attempt to put that everyday loop in the browser without turning it into a generic cloud-logging SaaS or an AI demo. Parsing runs in a Web Worker on your machine. Logs stay local unless you explicitly push them into optional cloud projects.

Problem framing

The recurring job looks like this:

1. Receive BLF / MF4 / ASC / CSV / candump-style data
2. Understand bus load and frame traffic
3. Decode with DBC (often per channel)
4. Filter to the incident window
5. Plot signals that answer a yes/no engineering question
6. Share a CSV or screenshot, not necessarily the raw log

Step 1–6 should not require installing a multi-gigabyte suite on every review laptop. They also should not require uploading proprietary logs to a third party just to scroll.

Notice what is missing from that list: training a model on your fleet, auto-writing a root-cause essay, or centralizing every measurement your company has ever captured. Those can be separate products. Mixing them into a viewer tends to muddy incentives — suddenly the "free look" wants your corpus.

Formats and decode

Canmetry targets the formats engineers already pass around — including Vector/ASAM-familiar paths like BLF and MF4 — plus ASC and simpler text captures. DBC mapping is first-class because raw IDs without a database are only half a conversation.

CAN FD matters here too. A viewer that pretends FD is "just more CAN" will confuse length, bitrate, and payload expectations. The UI and decode path need to respect that distinction even when the human is in a hurry.

Per-channel DBC is not a nicety. Mixed networks and gateway logs show up constantly. If the tool only allows one global database, people will silently decode the wrong island of the bus and trust the chart anyway.

Local-first architecture (product, not buzzword)

When people hear "online CAN tool," they imagine forced upload. I use a different default:

• Open file → parse locally → visualize
• Account optional for offline-style viewing
• Cloud projects / team workspaces optional when collaboration is intentional

That default changes procurement and security conversations. You can evaluate the tool on a sanitized log without inventing a data-residency exception on day one. If a team later wants shared projects, that is an explicit mode — not the tax to draw a plot.

Web Workers are the practical enabler: keep UI responsive while binary logs parse, and avoid freezing a tab on a long measurement. The browser is not a toy runtime anymore; treat it like one and users feel it.

What I am not building

• A warehouse for every vehicle log your company has ever collected
• An AI that "explains the car" from a random MF4
• A replacement for full hardware-in-the-loop or vendor automation stacks
• A generic observability product that happens to accept CAN as one log flavor among dozens

Canmetry aims at graph / trace / DBC readability in a tab. Depth elsewhere can stay in the primary toolchain.

A triage playbook I actually use

1. Open the log on canmetry.com
2. Confirm timestamp span and rough frame activity match expectations
3. Attach the DBC revision that belongs to that software build
4. Filter to the suspect ID range or time window from the bug report
5. Plot two or three signals that would falsify the hypothesis
6. Export CSV for the window if the report needs numbers

If decode looks nonsense, stop and check DBC lineage before blaming the recorder. Most "viewer bugs" I see in the wild are version skew, byte-order assumptions, or the wrong channel mapping.

Collaboration without default surveillance

Teams still need shared context. Optional cloud projects exist for that. The important product rule is sequencing: local understanding first, upload later if you choose. That sequencing is how you avoid becoming a generic log SaaS that happens to parse BLF.

When collaboration is needed, upload the minimum: the incident slice, the DBC revision identifier, and the question you are answering. Full-raw dumps into shared folders are how access reviews get ugly.

Engineering caveats worth stating publicly

• Garbage DBC in, garbage engineering values out
• Huge logs will stress memory; slice when you can
• Browser capability varies; treat extreme files with the same respect you would on desktop
• Always record which DBC hash/revision produced a decoded chart
• CAN vs CAN FD mismatches present as "the tool is wrong" long before anyone checks the capture setup

Honesty here builds more trust than a feature matrix with fifty checkmarks.

Why indie tooling still belongs in this space

Large suites optimize for complete program lifecycles. Indie viewers can optimize for time-to-first-plot. Both matter. The industry benefits when a field log is not stuck behind a single license server at 1 a.m. A browser path does not diminish the suite; it reduces the number of blocked conversations waiting on the suite.

Try it on a log you already understand

Take a BLF or MF4 you have previously reviewed elsewhere. Open it on https://canmetry.com, attach the same DBC, and compare a known signal plot. If the shapes match, you have a portable triage tool. If they do not, you found a decode assumption worth fixing before you trust a new file.

Browser-native CAN viewing sounds almost too plain. Plain is what you want when a partner drops a log and asks whether the flag ever set.

Mapping product decisions to engineering constraints

A few constraints shaped Canmetry more than feature requests did:

• Binary formats are non-negotiable. If BLF/MF4 support is shallow, the tool is a toy for people who already converted everything to CSV.
• Decode must be inspectable. Users should be able to relate a plotted signal back to frame data when something looks off.
• Performance must degrade gracefully. Progress and partial results beat a silent hang.
• Collaboration must be explicit. Hidden background sync of logs would violate the local-first story even if it were convenient for engagement metrics.

Those constraints are why the marketing stays narrow. "Browser CAN log viewer with local DBC decode" is not a huge addressable-market slogan. It is an accurate one. Accurate slogans attract the right overnight triage use cases and repel people looking for a fleet-wide AI lakehouse.

Testing against known-good captures

My favorite validation approach is boring: keep a small corpus of logs previously reviewed in a desktop suite, with screenshots of expected plots and note the DBC revision. When decoder or parser code changes, re-open the corpus in the browser and compare. If indie tooling skips this, it eventually ships confident wrongness — the worst kind for automotive reviews.

Onboarding without automotive cosplay

I avoid dressing the landing page like a sci-fi HUD. Engineers evaluating a viewer want: formats supported, DBC behavior, local default, export options. Flashy chrome that implies AI omniscience tends to attract the wrong trial and scare the right one. Plain onboarding — open file, attach DBC, plot — converts better with this audience than a feature fireworks show.

— Tom Wang