The 16 tabs

Roughly in the order you would use them.

Finding your way around

Sixteen tabs holding 33 sub-tabs is 49 panes, too many for one row. The layout follows Blender: layered greys so nesting reads as depth, blue for selection, and green, amber and red kept only where they mean connected, pending and armed.

The minimum window size is 1124 by 851, so it fits a laptop screen with both sidebars open.

FRAMES

The raw view: every frame in time order with its timestamp, arbitration ID, bus, length, data bytes and the gap since the last frame with the same ID. A byte is highlighted when it differs from the previous frame with that ID, which is how you spot movement at a glance.

Filter by ID (hex substring) or bus. Freeze stops the table updating while you read, without stopping capture. Follow keeps it scrolled to the newest frame. Double-click a row for the full frame detail.

SNIFFER

One row per message instead of one per frame, which is the shape of the question you actually ask at the bench: I pressed the button, what changed. Each byte is coloured by what it just did, green when it rose and red when it fell, fading back after a second. Bytes that have never moved sit dim, so the active ones stand out.

Notch is the reason to use this rather than FRAMES. It records every bit currently in motion and ignores it from then on. Press it a few times while the vehicle idles and the wheel-speed counters, the checksums and the sensor jitter all go quiet; the bit that lights up next is the one you caused. Un-notch forgets the mask. There is also a bit view, an option to keep silent IDs on screen rather than letting them expire after five seconds, and one to blank notched bits entirely.

Modelled on SavvyCAN's sniffer window and on cansniffer. It works on a live bus and on a loaded capture; on a file there is no "now", so nothing expires. Rendering 180 IDs costs about 40 ms, and the table updates in place rather than rebuilding.

SIGNALS

One row per message rather than per frame: frame count, rate, payload entropy and a suspected message type. It is the fastest way to see the shape of a capture. Entropy is the useful column: a message whose payload never changes is not interesting, and one with high entropy across every byte is often a diagnostic or multiplexed message rather than a set of signals.

PLOT

Multi-signal time series. Raw bytes and decoded DBC signals share one time axis, each with its own scale, so you can compare a decoded value against the bytes it came from or against a different message entirely. Mouse wheel zooms.

This is where you confirm a definition. Physical quantities move smoothly; a sawtooth usually means the byte order is wrong.

AI ENGINE

Optional, and off until you configure a provider. Sends one message ID's statistics to Anthropic, OpenAI, Groq or a local Ollama model and asks for an interpretation. What makes it more useful than pasting hex into a chat window is that the offline findings go with the question: the byte roles, the detected checksum, the message period. Memory persists across sessions. See what actually leaves the machine.

DBC BUILDER

Where a guess becomes a definition. A form for the signal fields, a bit grid showing the live payload with your selection highlighted, and a live decode preview running real frames from the capture through the definition.

Imports DBC, ARXML and Excel or CSV CAN matrices. Exports DBC, openpilot DBC, Vector CANdb++, ARXML and a Wireshark Lua dissector. There is also an Auto-Build DBC button that drafts definitions from the detectors, and a cross-reference against opendbc.

CODE GEN

Turns your definitions into a working program. Pick the signals, the interface and the direction, and it writes Python or C that opens the bus and decodes them, or encodes and sends them.

INTELLIGENCE

Looks across messages rather than within one. Its sections are signal periodicity, automatic DBC generation, log diff, an opendbc cross-reference, change-on-action capture, a J1939 and NMEA 2000 PGN decoder, and a value reverse lookup.

The PGN decoder works the protocol out from the identifier: NMEA 2000 uses data page 1 in the 126208 to 130836 range. Multi-frame PGNs are reassembled first, J1939 transport protocol and NMEA 2000 fast packets alike, and decoded whole; one frame of one is never decoded alone, because that gives a confident wrong answer.

Change-on-action is the one worth knowing about: capture a baseline, perform a physical action, capture again, and it shows which bytes changed. That is often the fastest route from "somewhere in these 60 messages" to a candidate.

INJECTION

Everything that transmits, in six sub-tabs: INJECT a signal at a physical value once or in a loop, REPLAY a capture back onto the bus with a scrubber, TRIGGERS that fire on a byte condition, SAFETY SCAN which sweeps an actuator between limits with a watchdog, FUZZ with random, boundary or mutation payloads, and TEST SEQUENCE for scripted inject, wait and assert steps.

The INJECT page previews the frame it would send before anything is armed, colouring each byte by whether the signal or the vehicle profile wrote it, and keeps a log of every send with its result.

DIAGNOSTICS

The request side, in six sub-tabs: OBD-II and UDS, a UDS deep scan, a UDS service scan, security access, bus load and bus health. Full protocol detail is on the diagnostics page.

DASHBOARD

The whole bus at once. A byte-value heatmap across every message, so a dense column is a message worth investigating and a blank one is padding; a message timeline showing when each ID is active; and physical overlay gauges driven by signals you have defined.

AUTO-RE

The tedious part, automated. Six sub-tabs: COUNTER/CHECKSUM detection across every message, ENTROPY BOUNDARIES to suggest where fields begin and end, CORRELATION between bytes, a CHECKSUM GUESSER that takes one message and one byte and tries every algorithm it knows, FLAGS & ENUMS for switches and value tables, and BLOCKS for runs of consecutive IDs that share one layout, with a shared field added to every member at once. Runs in worker threads, so the window stays responsive. See how it works.

TIMELINE

Questions about when. Several signals stacked on one scrubbable axis with a shared playhead, so you can line up the moment a flag flips against the moment a value starts moving. The VIDEO SYNC sub-tab loads a dashcam or bench recording and ties it to the log with an adjustable offset: click a signal spike to seek the video, scrub the video to move the playhead.

OBD-II

The standardised subset any compliant vehicle answers. Discovers which PIDs are supported by walking the continuation windows rather than assuming the first 32, then polls the ones you pick and shows them as live gauges.

ML INTEL

Per-byte rather than per-message. Classifies each byte as a counter, checksum, boolean flag, physical value or padding with a confidence, fits a baseline from normal traffic and scores frames against it for anomalies, and finds messages with similar behaviour by embedding.

The WATCH sub-tab does the scoring live: fit a baseline from the last half minute, start the watch, and each new batch of frames is scored as it arrives. A payload out of band, an ID gone quiet, a burst or an ID the baseline never saw becomes a row, a flash in the status bar and, if you ask, a mark on the timeline.

GATEWAY

Bridges two CAN channels and puts you in between. Rules are applied in order: pass a message through, block it, or modify a byte or the arbitration ID as it crosses. That is how you test what an ECU does when a message it depends on disappears or arrives with a different value.

It needs two hardware channels, and like everything else it forwards nothing until ARM TX is on.