CANtrip v1.3.0 - Yukari

CANtrip v1.3.0 - Yukari

The logging update! Logging finally lands, and the Graph view grows up: export, and real
multi-window support.

Logging

• Capture straight to disk in two formats:
  • .asc — built to be indistinguishable from real Vector CANalyzer
    output structurally (header block, trigger blocks, classic and CAN FD
    frame lines with DBC-resolved names). The one deliberate omission is
    the Length/BitCount telemetry suffix some CANalyzer configs show —
    that field is genuine hardware-measured transceiver timing no vendor
    API exposes, so CANtrip targets the equally-real "baseline" ASC
    variant instead of fabricating a number. Verified by opening a
    stripped real CANalyzer trace back in CANalyzer itself with no visible
    difference.
  • .csv — CANtrip's own schema (time, channel, ID, flags, DLC, data,
    resolved message name).
• Filename templating — [user]/[bus]/[date]/[time] tokens,
  editable live with a preview, default output folder
  Documents/CANtrip/captures.
• Logging options — max file size with auto-split, existing-file
  policy (overwrite/auto-increment/prompt), and auto-start-with-capture.
• Log Replay — load a saved .asc/.csv back in and it feeds the
  Trace and Graph views exactly like a live capture, paced by the
  original timestamps.

Graph view: export + multi-window

• Export any graph to PNG, SVG, or PDF from a new button right on the
  chart's own toolbar. Default output folder Documents/CANtrip/graphs.
• Multiple graph windows — up to 6 at once, each fully independent
  (own signals, own axes), all reading from the same live capture.
• Stacked or Grid layout, toggled with one button — Stacked gives
  every pane a real, readable height and scrolls for the rest rather than
  squishing everything to fit; Grid auto-arranges into a square-ish grid.
• Export All — one click exports every open graph window to its own
  file in a chosen folder.
• .rune config files now save/restore the full multi-window layout
  (old single-graph rune files still load fine).

Also in this release

• No more console window popping up next to the GUI on launch.
• The About dialog now shows the actual running version and codename
  (CANtrip - v1.3.0 "yukari") instead of a static string.
• Logging moved ahead of Stimulation in the ribbon tab order.

Known limitations

• .mf4 export is still a disabled placeholder — real ASAM MDF4 support
  is a bigger undertaking, tracked for later.
• Bus-error frames aren't written to .asc output (no verified mapping
  from CANtrip's error classes to CANalyzer's chip-status convention
  exists yet).
• CAN FD real-hardware logging wasn't field-tested this round (no bus
  stimulus available) — the synthetic test source and structural format
  verification are covered, but treat real-hardware FD logging as
  unverified until confirmed against actual traffic.

Getting started (step by step)

CANtrip doesn't capture CAN traffic itself - it hands that job to
Wireshark's own capture engine, then decodes and displays what comes back.
So there are two things to install, not one. Here's the whole path from
zero to seeing live CAN data, no hardware required:

1. Install Wireshark. Download and install it from
   wireshark.org using the
   defaults. You don't need to know how to use Wireshark itself - CANtrip
   just needs it present on the machine, since it runs Wireshark's tshark
   under the hood instead of talking to hardware directly.

2. Download CANtrip. Grab the latest zip from the
   Releases page and
   extract it anywhere (e.g. your Desktop or C:\CANtrip).

3. Tell Wireshark about CANtrip's capture helper. Inside CANtrip's
   extracted folder there's a file called can2pcap.exe - copy it into
   Wireshark's personal extcap folder: press Win+R, type
   %AppData%\Wireshark\extcap, and press Enter - this opens the exact
   folder directly (Windows creates it automatically if it doesn't exist
   yet). Copy can2pcap.exe into it.

   This is a one-time step. Without it, CANtrip's hardware/test-source list
   will simply be empty.

4. Launch cantrip.exe from the extracted folder.

5. Pick a source. On the Hardware tab, open the "Network Hardware"
   dropdown:

   • No CAN adapter yet, just want to try it out? Pick
     "CANtrip synthetic test source (no hardware needed)" - it fakes
     realistic traffic so you can explore everything below with zero wires.
   • Have a real PEAK or Vector CAN adapter plugged in (with its driver
     installed)? Pick that channel instead - everything else works exactly
     the same way.

6. (Optional) Set the bus speed. Still on Hardware, click
   CAN Controller... if you need to change the bitrate (defaults are
   fine for the synthetic source).

7. (Optional) Load a DBC file so raw frames decode into named signals
   with real units. On the Analysis & Measurement tab, click
   Import DBC... and pick a .dbc file - the bundled sample.dbc
   matches the synthetic source out of the box.

8. Hit Start on the Home tab. Live frames start streaming into the
   table immediately; click the arrow next to a row to expand it into
   decoded signal values (if a DBC was loaded). Try the Graphics button
   to switch to the Graph view and plot a signal over time. On a busy real
   bus, use the Display Rate dropdown (also on Home) if the UI feels
   sluggish - it defaults to 30 Hz, which should be smooth on most buses.

9. (Optional) Log the capture to disk. On the Logging tab, pick a
   format (.asc to open later in real CANalyzer, or .csv for
   spreadsheets/scripts), optionally click Output file... to choose
   where it's saved (defaults to Documents\CANtrip\captures), then hit
   Start Logging - it runs independently of Start/Stop Capture, so you
   can start/stop it whenever you want during a session. Load a saved log
   back in later with Log Replay, on that same tab.

That's the whole loop - swapping the synthetic source for real hardware
later needs no extra setup beyond having that vendor's driver installed.
See the README for further
detail.

CANtrip v1.2.0 - Yukari

CANtrip v1.2.0 - Yukari

Graph view quality-of-life, .rune config files, and bus autodetect.

New: Graph view improvements

• Multi-select drag-and-drop: Ctrl+click / Shift+click to select several
  signals at once in the signal list, then drag the whole selection onto an
  axis in one go.
• Cursors: a new Cursor tool in the Graph toolbar. Hover over the plot
  for a live readout of every visible signal's value at that point in time.
  Click and drag between two points on a curve to see the delta (Δt, Δvalue)
  between them - handy for measuring pulse widths, rise times, etc. without
  doing the math by hand.
• Clear Graph: a new toolbar button that wipes plotted data and restarts
  from t=0, without touching your axis/signal setup.
• Axes survive Start/Stop: set up your axes and signals once - Stop and
  Start a new capture no longer throws the graph away. (Clear Graph is now
  the same operation Start uses internally, just triggered manually.)

New: .rune config files

CANtrip can now save and load .rune files - the equivalent of CANalyzer's
.cfg files. A rune remembers:

• which channel/hardware you had selected,
• bus timing (bitrate, CAN FD settings),
• capture mode and display rate,
• which DBC was loaded,
• and your entire Graph view axis/signal layout (not sample data - that's
  always live).

Save Rune... / Load Rune... live in the Home tab, next to Capture and
Display. Both are disabled mid-capture, same as Import DBC, since opening a
file dialog during a real capture can start a nested event loop that
overwhelms frame processing on a busy bus.

New: Autodetect Bus Config

Hardware tab now has an "Autodetect Bus Config..." button. Click it and
CANtrip scans classic CAN bitrates (125k/250k/500k/1M) against the selected
channel, applies the one that comes back clean, and prompts you to save a
rune with the result. FD autodetect isn't in this pass - classic only for
now.

Under the hood: real bus errors now show up

VectorBackend and PeakBackend were silently swallowing real chip-state
and error events instead of surfacing them - previously the only thing that
ever produced a bus-error row in Trace view was the synthetic test source.
Real hardware errors (bus-off, ACK/form/stuff/bit errors, overrun) now
appear in Trace view like they should. This was also a prerequisite for
Autodetect, which needs to tell "clean bus" apart from "errors happening"
to know a bitrate guess actually worked.

Note: bus-error surfacing and Autodetect have been verified against the
synthetic source and compile-verified against real PEAK/Vector SDKs, but
still need a pass against real hardware with a deliberately-wrong bitrate
before calling them fully field-tested.

Getting started (step by step)

CANtrip doesn't capture CAN traffic itself - it hands that job to
Wireshark's own capture engine, then decodes and displays what comes back.
So there are two things to install, not one. Here's the whole path from
zero to seeing live CAN data, no hardware required:

1. Install Wireshark. Download and install it from
   wireshark.org using the
   defaults. You don't need to know how to use Wireshark itself - CANtrip
   just needs it present on the machine, since it runs Wireshark's tshark
   under the hood instead of talking to hardware directly.

2. Download CANtrip. Grab the latest zip from the
   Releases page and
   extract it anywhere (e.g. your Desktop or C:\CANtrip).

3. Tell Wireshark about CANtrip's capture helper. Inside CANtrip's
   extracted folder there's a file called can2pcap.exe - copy it into
   Wireshark's personal extcap folder: press Win+R, type
   %AppData%\Wireshark\extcap, and press Enter - this opens the exact
   folder directly (Windows creates it automatically if it doesn't exist
   yet). Copy can2pcap.exe into it.

   This is a one-time step. Without it, CANtrip's hardware/test-source list
   will simply be empty.

4. Launch cantrip.exe from the extracted folder.

5. Pick a source. On the Hardware tab, open the "Network Hardware"
   dropdown:

   • No CAN adapter yet, just want to try it out? Pick
     "CANtrip synthetic test source (no hardware needed)" - it fakes
     realistic traffic so you can explore everything below with zero wires.
   • Have a real PEAK or Vector CAN adapter plugged in (with its driver
     installed)? Pick that channel instead - everything else works exactly
     the same way.

6. (Optional) Set the bus speed. Still on Hardware, click
   CAN Controller... if you need to change the bitrate (defaults are
   fine for the synthetic source).

7. (Optional) Load a DBC file so raw frames decode into named signals
   with real units. On the Analysis & Measurement tab, click
   Import DBC... and pick a .dbc file - the bundled sample.dbc
   matches the synthetic source out of the box.

8. Hit Start on the Home tab. Live frames start streaming into the
   table immediately; click the arrow next to a row to expand it into
   decoded signal values (if a DBC was loaded). Try the Graphics button
   to switch to the Graph view and plot a signal over time. On a busy real
   bus, use the Display Rate dropdown (also on Home) if the UI feels
   sluggish - it defaults to 30 Hz, which should be smooth on most buses.

That's the whole loop - swapping the synthetic source for real hardware
later needs no extra setup beyond having that vendor's driver installed.
See the README for further
detail.

Full diff: v1.1.1_yukari...v1.2.0_yukari

CANtrip v1.1.1 - Yukari

CANtrip v1.1.1 - Yukari

CANtrip is a free, open-source alternative to Vector CANalyzer for viewing
CAN / CAN FD bus traffic on Windows, decoding it against DBC files, and
plotting signals over time - built on top of Wireshark's own capture
pipeline rather than reimplementing CAN dissection from scratch.

What's new since v1.1.0_yukari

Naming cleanup, no functional/behavioral changes:

• The vendor-neutral CAN interface's C++ type is renamed ICanBackend →
  IAvlabsCanBackend, matching what it's always been called in prose ("the
  AVlabs CAN backend").
• The extcap binary is renamed pcan2pcap.exe → can2pcap.exe - a
  leftover name from a PEAK-only prototype that no longer reflected a
  vendor-neutral tool. If you're upgrading and already copied the old
  pcan2pcap.exe into Wireshark's extcap folder, delete it and copy the
  new can2pcap.exe there instead - having both installed at once
  registers duplicate capture interfaces.
• Added CONTRIBUTING.md and RELEASING.md documenting project
  conventions (commit style, the AVlabs CAN backend naming rule, when a
  change needs real-hardware testing vs. the synthetic source is enough,
  and the version/codename scheme).

What was new in v1.1.0_yukari (since v1.0.0_yukari)

This release is entirely about real-world hardening: every fix below was
found and confirmed against an actual busy vehicle CAN/CAN FD bus, not a
synthetic or hypothetical scenario.

• Fixed: message ID 0 silently decoded as all-zero. Wireshark's
  autosar-nm dissector claims CAN ID 0 by default - a real automotive
  convention, but not a universal one. Confirmed against a real production
  bus where ID 0 is a plain sensor message (wheel pressures): the payload
  never reached CANtrip's decoder at all, so every signal in that message
  silently read as if every byte were zero. Disabled the dissector outright,
  since CANtrip does its own DBC-based decoding and has no use for it.
• Fixed: UI freeze / memory growth under a busy real bus. This took two
  rounds to fully track down (via ProcDump + WinDbg analysis of live
  repros):
  • Opening the Import DBC file picker while a capture was running let
    live frame processing re-enter and pile up underneath the dialog's own
    modal message loop - now blocked outright (Import DBC is disabled while
    capturing).
  • More generally: any nested Windows message loop (a modal dialog,
    dragging the window itself, a drag-and-drop operation) could let
    incoming frames pile up faster than they could be decoded and painted,
    eventually freezing the UI solid and ballooning memory. Confirmed the
    main thread was CPU-saturated re-processing an ever-refilling backlog,
    not deadlocked - so the real fix had to reduce work-per-second, not just
    batch it.
• New: configurable Display Rate (Home tab - Unlimited/30/10/5 Hz,
  defaulting to 30 Hz). This is the actual fix for the freeze above: full
  decode still happens for whichever frame is shown, but the Trace and
  Graph views are no longer repainted on every single frame on a fast
  bus - only at the configured rate. Since Trace view's decode path is what
  feeds the Graph view's data, throttling it naturally throttles both views
  through one mechanism.
• Fixed: per-frame DBC message lookup was a linear scan through every
  message in the DBC, repeated on every single received frame - now a hash
  map built once when the DBC is imported. A real, avoidable cost on a
  large real-world DBC at real bus rates.
• Two additional Graph view robustness fixes (safe against a signal's
  history growing while its chart is being backfilled; safe against a new
  signal type appearing while the signal list is mid-drag).

Everything CANtrip does today

• Multi-vendor hardware support, with no code changes needed to add a
  new one: PEAK-System PCAN-Basic and Vector XL Driver Library (VN-series),
  both with classic CAN and CAN FD. CANtrip runs fine with only one vendor's
  driver installed, or none (falls back to a built-in synthetic test
  source).
• Real bit-timing control. A CAN Controller dialog computes actual
  BRP/TSEG1/TSEG2/SJW register values live from a target bitrate and sample
  point (classic, ISO CAN FD, or raw Expert mode), rather than relying on
  fixed guesses.
• DBC-based signal decoding of live traffic via dbcppp, with per-frame
  expandable rows showing decoded name/value/unit.
• Trace view with two display modes: Waterfall (newest-first log) and
  Periodic (one row per CAN ID, auto-graying stale rows), plus a
  configurable Display Rate to keep the UI responsive on a busy bus.
• Bus error detection and display, decoded from real SocketCAN-style
  error frames (bit/form/stuff/overload/bus-off/etc.), aggregated per error
  type in Periodic mode - always shown immediately, never rate-limited.
• Graph view: multi-axis time-series signal plotting. Drag any signal
  from a searchable list onto any number of Y axes, each with its own
  color/line-style/bounds, plus zoom/pan.
• Live capture status LED and an Office-style ribbon UI (Home, Hardware,
  Analysis & Measurement, Stimulation, Logging, About tabs).

Known limitations

• No Kvaser, Samtec or ETAS, or other additional vendor backends yet (PEAK
  and Vector are both fully supported, classic and FD).
• Send Message, Gateway (bridging), and Logging (save-to-disk) views are not
  implemented yet - next up on the roadmap.
• Graph view's signal list doesn't yet support Ctrl+click multi-select for
  dropping several signals onto an axis at once - single-signal
  drag-and-drop only, for now.
• Single bus/channel per running instance - multiple physical channels can
  already be monitored today by running multiple CANtrip instances
  side-by-side (confirmed working), but there's no unified multi-bus view
  in a single window yet.
• No automated test suite - verification has been manual (build, run, and
  direct hardware/protocol-level checks against real PEAK and Vector
  interfaces, including a real production vehicle CAN/CAN FD bus for this
  release).

Getting started (step by step)

CANtrip doesn't capture CAN traffic itself - it hands that job to
Wireshark's own capture engine, then decodes and displays what comes back.
So there are two things to install, not one. Here's the whole path from
zero to seeing live CAN data, no hardware required:

1. Install Wireshark. Download and install it from
   wireshark.org using the
   defaults. You don't need to know how to use Wireshark itself - CANtrip
   just needs it present on the machine, since it runs Wireshark's tshark
   under the hood instead of talking to hardware directly.

2. Download CANtrip. Grab the latest zip from the
   Releases page and
   extract it anywhere (e.g. your Desktop or C:\CANtrip).

3. Tell Wireshark about CANtrip's capture helper. Inside CANtrip's
   extracted folder there's a file called can2pcap.exe - copy it into
   Wireshark's personal extcap folder: press Win+R, type
   %AppData%\Wireshark\extcap, and press Enter - this opens the exact
   folder directly (Windows creates it automatically if it doesn't exist
   yet). Copy can2pcap.exe into it.

   This is a one-time step. Without it, CANtrip's hardware/test-source list
   will simply be empty.

4. Launch cantrip.exe from the extracted folder.

5. Pick a source. On the Hardware tab, open the "Network Hardware"
   dropdown:

   • No CAN adapter yet, just want to try it out? Pick
     "CANtrip synthetic test source (no hardware needed)" - it fakes
     realistic traffic so you can explore everything below with zero wires.
   • Have a real PEAK or Vector CAN adapter plugged in (with its driver
     installed)? Pick that channel instead - everything else works exactly
     the same way.

6. (Optional) Set the bus speed. Still on Hardware, click
   CAN Controller... if you need to change the bitrate (defaults are
   fine for the synthetic source).

7. (Optional) Load a DBC file so raw frames decode into named signals
   with real units. On the Analysis & Measurement tab, click
   Import DBC... and pick a .dbc file - the bundled sample.dbc
   matches the synthetic source out of the box.

8. Hit Start on the Home tab. Live frames start streaming into the
   table immediately; click the arrow next to a row to expand it into
   decoded signal values (if a DBC was loaded). Try the Graphics button
   to switch to the Graph view and plot a signal over time. On a busy real
   bus, use the Display Rate dropdown (also on Home) if the UI feels
   sluggish - it defaults to 30 Hz, which should be smooth on most buses.

That's the whole loop - swapping the synthetic source for real hardware
later needs no extra setup beyond having that vendor's driver installed.
See the README for further
detail.

CANtrip v1.1.0 - Yukari

CANtrip v1.1.0 - Yukari

CANtrip is a free, open-source alternative to Vector CANalyzer for viewing
CAN / CAN FD bus traffic on Windows, decoding it against DBC files, and
plotting signals over time - built on top of Wireshark's own capture
pipeline rather than reimplementing CAN dissection from scratch.

What's new since v1.0.0_yukari

This release is entirely about real-world hardening: every fix below was
found and confirmed against an actual busy vehicle CAN/CAN FD bus, not a
synthetic or hypothetical scenario.

• Fixed: message ID 0 silently decoded as all-zero. Wireshark's
  autosar-nm dissector claims CAN ID 0 by default - a real automotive
  convention, but not a universal one. Confirmed against a real production
  bus where ID 0 is a plain sensor message (wheel pressures): the payload
  never reached CANtrip's decoder at all, so every signal in that message
  silently read as if every byte were zero. Disabled the dissector outright,
  since CANtrip does its own DBC-based decoding and has no use for it.
• Fixed: UI freeze / memory growth under a busy real bus. This took two
  rounds to fully track down (via ProcDump + WinDbg analysis of live
  repros):
  • Opening the Import DBC file picker while a capture was running let
    live frame processing re-enter and pile up underneath the dialog's own
    modal message loop - now blocked outright (Import DBC is disabled while
    capturing).
  • More generally: any nested Windows message loop (a modal dialog,
    dragging the window itself, a drag-and-drop operation) could let
    incoming frames pile up faster than they could be decoded and painted,
    eventually freezing the UI solid and ballooning memory. Confirmed the
    main thread was CPU-saturated re-processing an ever-refilling backlog,
    not deadlocked - so the real fix had to reduce work-per-second, not just
    batch it.
• New: configurable Display Rate (Home tab - Unlimited/30/10/5 Hz,
  defaulting to 30 Hz). This is the actual fix for the freeze above: full
  decode still happens for whichever frame is shown, but the Trace and
  Graph views are no longer repainted on every single frame on a fast
  bus - only at the configured rate. Since Trace view's decode path is what
  feeds the Graph view's data, throttling it naturally throttles both views
  through one mechanism.
• Fixed: per-frame DBC message lookup was a linear scan through every
  message in the DBC, repeated on every single received frame - now a hash
  map built once when the DBC is imported. A real, avoidable cost on a
  large real-world DBC at real bus rates.
• Two additional Graph view robustness fixes (safe against a signal's
  history growing while its chart is being backfilled; safe against a new
  signal type appearing while the signal list is mid-drag).

Everything CANtrip does today

• Multi-vendor hardware support, with no code changes needed to add a
  new one: PEAK-System PCAN-Basic and Vector XL Driver Library (VN-series),
  both with classic CAN and CAN FD. CANtrip runs fine with only one vendor's
  driver installed, or none (falls back to a built-in synthetic test
  source).
• Real bit-timing control. A CAN Controller dialog computes actual
  BRP/TSEG1/TSEG2/SJW register values live from a target bitrate and sample
  point (classic, ISO CAN FD, or raw Expert mode), rather than relying on
  fixed guesses.
• DBC-based signal decoding of live traffic via dbcppp, with per-frame
  expandable rows showing decoded name/value/unit.
• Trace view with two display modes: Waterfall (newest-first log) and
  Periodic (one row per CAN ID, auto-graying stale rows), plus a
  configurable Display Rate to keep the UI responsive on a busy bus.
• Bus error detection and display, decoded from real SocketCAN-style
  error frames (bit/form/stuff/overload/bus-off/etc.), aggregated per error
  type in Periodic mode - always shown immediately, never rate-limited.
• Graph view: multi-axis time-series signal plotting. Drag any signal
  from a searchable list onto any number of Y axes, each with its own
  color/line-style/bounds, plus zoom/pan.
• Live capture status LED and an Office-style ribbon UI (Home, Hardware,
  Analysis & Measurement, Stimulation, Logging, About tabs).

Known limitations

• No Kvaser, Samtec or ETAS, or other additional vendor backends yet (PEAK
  and Vector are both fully supported, classic and FD).
• Send Message, Gateway (bridging), and Logging (save-to-disk) views are not
  implemented yet - next up on the roadmap.
• Graph view's signal list doesn't yet support Ctrl+click multi-select for
  dropping several signals onto an axis at once - single-signal
  drag-and-drop only, for now.
• Single bus/channel per running instance - multiple physical channels can
  already be monitored today by running multiple CANtrip instances
  side-by-side (confirmed working), but there's no unified multi-bus view
  in a single window yet.
• No automated test suite - verification has been manual (build, run, and
  direct hardware/protocol-level checks against real PEAK and Vector
  interfaces, including a real production vehicle CAN/CAN FD bus for this
  release).

Getting started (step by step)

CANtrip doesn't capture CAN traffic itself - it hands that job to
Wireshark's own capture engine, then decodes and displays what comes back.
So there are two things to install, not one. Here's the whole path from
zero to seeing live CAN data, no hardware required:

1. Install Wireshark. Download and install it from
   wireshark.org using the
   defaults. You don't need to know how to use Wireshark itself - CANtrip
   just needs it present on the machine, since it runs Wireshark's tshark
   under the hood instead of talking to hardware directly.
2. Download CANtrip. Grab the latest zip from the
   Releases page and
   extract it anywhere (e.g. your Desktop or C:\CANtrip).
3. Tell Wireshark about CANtrip's capture helper. Inside the extracted
   folder there's a file called pcan2pcap.exe - copy it into Wireshark's
   personal extcap folder:

   copy pcan2pcap.exe "$env:APPDATA\Wireshark\extcap\"

   This is a one-time step. Without it, CANtrip's hardware/test-source list
   will simply be empty.
4. Launch cantrip.exe from the extracted folder.
5. Pick a source. On the Hardware tab, open the "Network Hardware"
   dropdown:
   • No CAN adapter yet, just want to try it out? Pick
     "CANtrip synthetic test source (no hardware needed)" - it fakes
     realistic traffic so you can explore everything below with zero wires.
   • Have a real PEAK or Vector CAN adapter plugged in (with its driver
     installed)? Pick that channel instead - everything else works exactly
     the same way.
6. (Optional) Set the bus speed. Still on Hardware, click
   CAN Controller... if you need to change the bitrate (defaults are
   fine for the synthetic source).
7. (Optional) Load a DBC file so raw frames decode into named signals
   with real units. On the Analysis & Measurement tab, click
   Import DBC... and pick a .dbc file - the bundled sample.dbc
   matches the synthetic source out of the box.
8. Hit Start on the Home tab. Live frames start streaming into the
   table immediately; click the arrow next to a row to expand it into
   decoded signal values (if a DBC was loaded). Try the Graphics button
   to switch to the Graph view and plot a signal over time. On a busy real
   bus, use the Display Rate dropdown (also on Home) if the UI feels
   sluggish - it defaults to 30 Hz, which should be smooth on most buses.

That's the whole loop - swapping the synthetic source for real hardware
later needs no extra setup beyond having that vendor's driver installed.
See the README for further
detail.

CANtrip v1.0.0 - Yukari

CANtrip v1.0.0 - Yukari

The first release. CANtrip is a free, open-source alternative to Vector
CANalyzer for viewing CAN / CAN FD bus traffic on Windows, decoding it
against DBC files, and plotting signals over time - built on top of
Wireshark's own capture pipeline rather than reimplementing CAN dissection
from scratch.

What's new since v0.5_Sawako

• Fixed: DBC import failing on real-world DBC files. The bundled DBC
  parser (dbcppp) only recognized the keyword FILTER in all-caps, but
  real DBC files from at least one major OEM toolchain emit Filter in
  mixed case - which silently broke parsing of an otherwise perfectly valid
  file. Confirmed and fixed against real production DBC files.
• DBC import errors are no longer a black box. If a .dbc file still
  fails to import, CANtrip now shows the parser's actual error (which line/
  token it choked on) instead of a generic "failed to parse" message.
• Fixed: CAN FD frames with a data length over 8 bytes were silently
  truncated. Any FD frame using a DLC code of 9-15 (payloads of
  12/16/20/24/32/48/64 bytes) had its real trailing data dropped instead of
  decoded. Confirmed against live traffic on a real CAN FD bus, where the
  majority of frames use exactly this range - this was a significant,
  widespread data-loss bug for real-world FD traffic, not an edge case.

Everything CANtrip does today

• Multi-vendor hardware support, with no code changes needed to add a
  new one: PEAK-System PCAN-Basic and Vector XL Driver Library (VN-series),
  both with classic CAN and CAN FD. CANtrip runs fine with only one vendor's
  driver installed, or none (falls back to a built-in synthetic test
  source).
• Real bit-timing control. A CAN Controller dialog computes actual
  BRP/TSEG1/TSEG2/SJW register values live from a target bitrate and sample
  point (classic, ISO CAN FD, or raw Expert mode), rather than relying on
  fixed guesses.
• DBC-based signal decoding of live traffic via dbcppp, with per-frame
  expandable rows showing decoded name/value/unit.
• Trace view with two display modes: Waterfall (newest-first log) and
  Periodic (one row per CAN ID, auto-graying stale rows).
• Bus error detection and display, decoded from real SocketCAN-style
  error frames (bit/form/stuff/overload/bus-off/etc.), aggregated per error
  type in Periodic mode.
• Graph view: multi-axis time-series signal plotting. Drag any signal
  from a searchable list onto any number of Y axes, each with its own
  color/line-style/bounds, plus zoom/pan.
• Live capture status LED and an Office-style ribbon UI (Home, Hardware,
  Analysis & Measurement, Stimulation, Logging, About tabs).

Getting started (step by step)

CANtrip doesn't capture CAN traffic itself - it hands that job to
Wireshark's own capture engine, then decodes and displays what comes back.
So there are two things to install, not one. Here's the whole path from
zero to seeing live CAN data, no hardware required:

1. Install Wireshark. Download and install it from
   wireshark.org using the
   defaults. You don't need to know how to use Wireshark itself - CANtrip
   just needs it present on the machine, since it runs Wireshark's tshark
   under the hood instead of talking to hardware directly.
2. Download CANtrip. Grab the latest zip from the
   Releases page and
   extract it anywhere (e.g. your Desktop or C:\CANtrip).
3. Tell Wireshark about CANtrip's capture helper. Inside the extracted
   folder there's a file called pcan2pcap.exe - copy it into Wireshark's
   personal extcap folder:

   copy pcan2pcap.exe "$env:APPDATA\Wireshark\extcap\"

   This is a one-time step. Without it, CANtrip's hardware/test-source list
   will simply be empty.
4. Launch cantrip.exe from the extracted folder.
5. Pick a source. On the Hardware tab, open the "Network Hardware"
   dropdown:
   • No CAN adapter yet, just want to try it out? Pick
     "CANtrip synthetic test source (no hardware needed)" - it fakes
     realistic traffic so you can explore everything below with zero wires.
   • Have a real PEAK or Vector CAN adapter plugged in (with its driver
     installed)? Pick that channel instead - everything else works exactly
     the same way.
6. (Optional) Set the bus speed. Still on Hardware, click
   CAN Controller... if you need to change the bitrate (defaults are
   fine for the synthetic source).
7. (Optional) Load a DBC file so raw frames decode into named signals
   with real units. On the Analysis & Measurement tab, click
   Import DBC... and pick a .dbc file - the bundled sample.dbc
   matches the synthetic source out of the box.
8. Hit Start on the Home tab. Live frames start streaming into the
   table immediately; click the arrow next to a row to expand it into
   decoded signal values (if a DBC was loaded). Try the Graphics button
   to switch to the Graph view and plot a signal over time.

That's the whole loop - swapping the synthetic source for real hardware
later needs no extra setup beyond having that vendor's driver installed.

Known limitations

• No Kvaser, Samtec or ETAS, or other additional vendor backends yet (PEAK and Vector
  are both fully supported, classic and FD).
• Send Message, Gateway (bridging), and Logging (save-to-disk) views are not
  implemented yet - next up on the roadmap.
• Single bus/channel per running instance - multiple physical channels can
  already be monitored today by running multiple CANtrip instances
  side-by-side (confirmed working), but there's no unified multi-bus view
  in a single window yet.
• No automated test suite - verification has been manual (build, run, and
  direct hardware/protocol-level checks against real PEAK and Vector
  interfaces).

Then launch cantrip.exe. See the README
for full setup and usage instructions.

CANtrip v0.5 - Sawako

CANtrip v0.5 - Sawako

The Graph view lands in this release - CANtrip's second CANalyzer-style
view after Trace, for plotting decoded signals over time.

Highlights

Graph view. A new "Graphics" button on the Analysis & Measurement tab
opens a full signal-plotting view:

• A searchable list on the left shows every signal decoded from the
  capture so far - drag one onto a Y axis to plot it.
• Add as many Y axes as you want; each axis can hold multiple signals at
  once, sharing that axis's scale.
• Double-click an axis to rename it or set manual min/max bounds (or leave
  it on auto-scale).
• Double-click a signal to pick its color and line style (solid, dashed,
  dotted, or scatter dots).
• Hide an axis (and everything on it) with the eye toggle next to its row.
• Zoom with a drag-to-select rectangle tool, reset back to the full view
  with one click, or just scroll the mouse wheel - over the plot it zooms
  time, over a Y axis's labels it zooms that axis only.

New synthetic test signals. The built-in synthetic test source now also
transmits a sine, sawtooth, and triangle wave (TestWaveforms in
test/sample.dbc), so the Graph view has something meaningful to plot
without needing real hardware.

What's Changed

• Add the Graph view: multi-axis signal plotting with drag-and-drop

Installation

Grab CANtrip-windows-x64-6bba5cf.zip below, extract it anywhere, and
follow the README -
it bundles cantrip.exe, pcan2pcap.exe, and every DLL both need. You'll
still need Wireshark installed (for tshark)
and a driver package for your CAN hardware (PEAK PCAN-Basic or a Vector
driver package) - or skip both and pick the built-in synthetic test source
to try CANtrip with zero hardware.

CANtrip v0.4 - Mai

CANtrip v0.4 - Mai

A ribbon UI overhaul and real CAN FD bit timing land in this release,
alongside Vector CAN FD support and a capture status indicator.

Highlights

New ribbon-style UI. The old single-row control bar is gone. CANtrip
now organizes everything into tabs across the top, Office-style:

• Home - Start/Stop capture, Waterfall/Periodic display mode
• Hardware - pick a channel, open the new CAN Controller dialog
• Analysis & Measurement - Import DBC, CAN Trace, Graphics (coming later)
• Stimulation / Logging - reserved for upcoming message-sending and
  disk-logging features
• About - GitHub link and license info

Real CAN FD bit timing. The CAN Controller dialog replaces the old
free-text "expert init string" field with three proper modes:

• CAN - classic bitrate only
• ISO CAN FD - set a target bitrate + sample point, CANtrip computes the
  actual BRP/TSEG1/TSEG2/SJW register values live and shows the achieved
  sample point
• Expert CAN FD - type the raw register values directly, for full manual
  control

The calculator is ported from python-can's bit-timing implementation and
verified against real PEAK PCAN-USB FD hardware.

Vector CAN FD support. The Vector XL Driver Library backend now
supports CAN FD in addition to classic CAN, verified against a real Vector
VN1640A.

Capture status LED. A small round indicator at the bottom-left of the
window - red when idle, blinking green while a capture is running.

What's Changed

• Add Vector XL Driver Library backend for classic CAN
• Fix erratic Periodic-mode timing caused by tshark stdout buffering
• Add capture status LED indicator
• Add CAN FD support to the Vector backend
• Replace inline controls with a ribbon UI and add real CAN FD bit timing

Installation

Grab CANtrip-windows-x64-1df39f4.zip below, extract it anywhere, and
follow the README -
it bundles cantrip.exe, pcan2pcap.exe, and every DLL both need. You'll
still need Wireshark installed (for tshark)
and a driver package for your CAN hardware (PEAK PCAN-Basic or a Vector
driver package) - or skip both and pick the built-in synthetic test source
to try CANtrip with zero hardware.

CANtrip v0.3 - Miyuki

CANtrip v0.3_miyuki

Highlights

• CAN FD support for the Vector backend. Vector interfaces (VN-series) can now run CAN FD, not just classic CAN. Verified against a real Vector VN1640A: stable capture with no errors. Bit timing uses fixed default values for now; configurable sample point is planned for a future bus-settings UI.
• Capture status indicator. A small round LED at the bottom-left of the window: solid red when idle, blinking green/gray while a capture is running.

Known limitations

• CAN FD sample point/bit timing is not yet user-configurable on either backend (PEAK or Vector) — both use fixed defaults.
• No Samtec or ETAS backend yet.
• Graphing, message transmission, and gateway mode are still deferred to a later phase.
• No automated test suite.
• Only one physical bus can be monitored per running instance (workaround: run multiple instances, one per channel — confirmed working, including two instances on different channels of the same physical device).

What's in the zip

cantrip.exe, pcan2pcap.exe, all required Qt/dbcppp runtime DLLs, and test/sample.dbc for trying DBC decoding immediately.

CANtrip v0.2 - Dawn

CANtrip v0.2 - Dawn

Highlights

• Vector Informatik hardware support. Added a full backend for Vector's XL Driver Library (VN-series interfaces), alongside the existing PEAK backend. Verified against a real Vector VN1640A: all 4 channels plus Vector's virtual channels enumerate correctly, and live capture runs stable through the app.
• Verified against real hardware. Both the PEAK PCAN-USB FD and Vector VN1640A were tested against actual devices this release (previous release was verified only via the synthetic test source).
• Fixed a real correctness bug in the PEAK backend. The vendored PCAN-Basic header had incorrect parameter IDs and forced byte-packing on structs the real driver expects at natural alignment — the latter caused an out-of-bounds write on every real CAN_Read/CAN_ReadFD/channel-enumeration call. Fixed and verified against a real PCAN-Basic 5.1 driver.
• Fixed capture failing against real device names containing spaces. Interface IDs are now sanitized before being used in tshark's -i/-o arguments (a real device name like "PCAN-USB FD" was breaking tshark's preference parser).

New in the trace view

• Sortable columns. Click a column header to sort, click again to reverse. ID/DLC/Data sort by actual value, not text.
• Two display modes, switchable from a dropdown:
  • Waterfall — a scrolling log, newest frame on top.
  • Periodic — one row per CAN ID, updated in place, grayed out after 2 seconds without a new frame.
• Bus error detection. Errors (stuffing, form, bit, overload, etc.) decoded from the real SocketCAN error-frame protocol and shown in red. In Periodic mode, errors aggregate per error type instead of flooding the view.
• Application icon.

Known limitations

• CAN FD has not been tested against real hardware (PEAK supports it in code; Vector does not implement FD yet).
• No Kvaser or ETAS backend yet.
• Graphing, message transmission, and gateway mode are still deferred to a later phase.
• No automated test suite.

What's in the zip

cantrip.exe, pcan2pcap.exe, all required Qt/dbcppp runtime DLLs, and test/sample.dbc for trying DBC decoding immediately.

CANtrip v0.1 - Mugi

CANtrip v0.1 — "it captures CAN frames now, mostly on purpose"

A free alternative to Vector CANalyzer, for people who work with CAN and have a
grudge against paying 60k€ for tooling. This is the first release: it can watch
a bus, decode it against a DBC, and yell at you in red text when something's
wrong. Graphing and transmit/gateway mode are still "later."

What it does

• Vendor agnostic. CAN backends are pluggable behind a
  vendor-neutral interface (colloquially "the AVlabs backend" — one bus to
  sniff them all). PEAK-System's PCAN-Basic is the only one implemented so
  far; Vector/Kvaser/ETAS slot in later without touching the app or extcap.
• Doesn't reinvent CAN dissection. CANtrip launches tshark -T ek
  against a custom Wireshark extcap (pcan2pcap), so you get Wireshark's
  own battle-tested SocketCAN dissector for free — CANtrip's own DBC layer
  just adds signal decoding on top.
• No hardware? No problem. A synthetic test source is always available
  in the channel picker, faking traffic (and, delightfully, fake bus errors)
  so you can try everything below without owning a single wire.
• DBC import and live per-signal decode via dbcppp — expand any frame
  to see its signals unfold into physical values with units.
• Two ways to watch traffic: Waterfall (a scrolling log, newest on top)
  or Periodic (one row per CAN ID, updates in place, grays out when a
  message goes quiet) — because watching the same 4 IDs scroll past forever
  was never anyone's idea of a good time.
• Sortable columns. Click a header, click it again, flip
  ascending/descending. ID/DLC/Data sort by actual value, not string, so DLC
  "10" doesn't awkwardly sort before "2".
• Bus errors in red, decoded from the real SocketCAN error-frame ABI
  (stuff/form/bit/overload/etc, not vibes) and aggregated per error type in
  Periodic mode so a chattering bus fault doesn't flood the screen.

Getting started

1. Extract the zip anywhere.
2. Install Wireshark if you don't have it
   (provides tshark), and copy pcan2pcap.exe into
   %APPDATA%\Wireshark\extcap\.
3. Run cantrip.exe, pick "CANtrip synthetic test source" from the
   channel dropdown, hit Import DBC... and load the bundled
   test\sample.dbc, then Start Capture.
4. Expand a row. Watch numbers happen.

Full instructions in the bundled README.

Known gaps

• Only PEAK-System PCAN-Basic hardware is supported right now (see above —
  architecture's ready for more, nobody's written the Vector/Kvaser/ETAS
  backends yet).
• No graphing, no transmit/gateway mode yet.
• No automated test suite — this has been exercised by hand, thoroughly,
  but there's no CI holding it accountable yet.

What's in the zip

cantrip.exe, pcan2pcap.exe, every Qt/dbcppp DLL both need, and
test\sample.dbc to try DBC decoding immediately