Skip to content

CANtrip v1.1.1 - Yukari

Choose a tag to compare

View all tags
@avmolaei avmolaei released this 07 Jul 16:41
v1.1.1_yukari
0630450

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.

Assets 3
Loading