SavvyCAN reads twelve CAN log formats, and three of them are read only

A capture device is optional, and that changes who the tool is for

The README is emphatic on one point: use of a capture device is not required to make use of this program. That single sentence decides the audience. Most CAN tooling assumes you own an interface hardware, and the README's own hardware recommendation, the CANDue board from EVTV running GVRET firmware, is a recommendation rather than a requirement.

So the primary workflow is file-first. You have a log, you open it, you look at frames. The hardware path exists for live capture and injection, and it works through QtSerialBus, which the README states means any Qt SerialBus driver works, naming socketcan, Vector, PeakCAN and TinyCAN explicitly. Being able to sit on socketcan is what makes this usable on a Linux machine attached to a live vehicle bus.

The stated purpose is visualization, reverse engineering, debugging and capturing of frames. That word reverse engineering is the honest one. Combined with the DBC support and the example scripts, this is a tool for working out what an undocumented bus is doing, not a diagnostic scanner that knows your car's manufacturer protocol.

Screen requirements are the kind of detail that saves an argument later: at least 1024x768, fully multi-monitor capable, and it works on 4K monitors.

Twelve formats load, three of them only load

The format list is the most concrete thing in the README, and it is where the real cost of switching tools lies. SavvyCAN loads and saves BusMaster log files, Microchip log files, CRTD format, GVRET native format, generic CSV in the shape of ID plus D0 through D7, Vector Trace files, IXXAT Minilog files, CAN-DO logs and Vehicle Spy log files.

Three more are explicitly read only: CANDump or Kayak, PCAN Viewer, and Wireshark socketcan PCAP files. That is a real asymmetry worth planning around. If your capture rig currently writes candump output or a PCAP, you can analyse it here but you cannot round-trip it back out, so the file you hand to a colleague is no longer in the format your pipeline consumes.

The generic CSV shape is also useful to understand precisely, because it is the lowest common denominator: ID, D0 D1 D2 D3 D4 D5 D6 D7. No timestamps beyond whatever the format carries, no signal names, no extensions. If you need to move frames between tools, that format is the safe interchange.

CRTD deserves a note because it is not a vendor format at all. The README identifies it as the OVMS log file format from Mark Webb-Johnson, which is the open source vehicle monitoring project. SavvyCAN reading CRTD means EV telemetry workflows are a first-class case here rather than an accident.

The repository ships real examples of most of these under `examples/`, including BusMasterLog.log, CRTD_Log.txt, CarBusAnalyzer.trc, GVRET_Log.csv, GenericID_Log.csv, MicrochipLog.log, a candump.log and several DBC files.

The DBC files are the difference between frames and signals

A CAN frame is an identifier plus eight data bytes. A DBC file is what gives those bytes names and physical meaning, and the repository ships several: bms.dbc, LeafPowertrainBus.dbc and ThinkCity.dbc in `examples/`. The names alone tell you the intended domain, battery management systems, a Leaf powertrain bus, and the Think City electric vehicle project.

The top-level `dbc/` directory is where decoding lives, and it sits next to the window classes that consume it. `mainwindow.cpp` and `mainwindow.h` are the shell, while `frameplaybackwindow`, `frameplaybackobject`, `framesenderwindow` and `framesenderobject` cover playing a log back and injecting frames onto a bus. That last one is what turns the tool from a viewer into a test rig.

Filtering is separate and deliberately so: `canfilter.cpp`, `canfilter.h` and `filterutility.cpp` exist as their own units, alongside `candatagrid.cpp` and `canframemodel.cpp` for the frame table. Separating the model from the window is what lets the same frame list back the grid, the graph view and the playback source.

Other windows show the scope of the tool: `canbridgewindow` for bridging to another bus, `bisectwindow` for narrowing down a trigger condition, `motorcontrollerconfigwindow` for motor controller setup, `jsedit` for the scripting console, and `mainsettingsdialog`. The `bus_protocols/`, `connections/`, `mqtt/` and `help/` directories at top level suggest protocol decoding, connection handling, MQTT bridging and built-in help respectively.

qmake, make, and the two QtSerialBus failure modes

The build is qmake, not CMake. Clone the repository, run qmake from your Qt bin directory, then make:

cd ~

git clone https://github.com/collin80/SavvyCAN.git

cd SavvyCAN

~/Qt/5.14/gcc_64/bin/qmake

make

The binary lands in the project root and is run as `./SavvyCAN`. On Linux, `./install.sh` creates a desktop shortcut. For a build with more diagnostic output, qmake takes a configuration flag:

qmake CONFIG+=debug

make

The README's first recovery step for a failed compile is to clean and rebuild, which is the honest answer to most qmake problems:

qmake

make clean

make

If that does not work, the stated cause is usually the Qt installation: SerialBus support must have been selected when Qt was installed. On Ubuntu the named error is `Project ERROR: Unknown module(s) in QT: qml serialbus help`, and the fix is a package set:

sudo apt install libqt5serialbus5-dev libqt5serialport5-dev qtdeclarative5-dev qttools5-dev

The missing modules in that error message, qml, serialbus and help, are a good map of what the application actually needs from Qt.

Qt 6 is a beta branch, Qt 5.14 is the supported baseline

Two constraints bracket the supported range and they are easy to confuse. The project requires Qt 5.14.0 or higher because of the QtSerialBus dependency and other newer Qt additions. Separately, the current MacOS binary build appears to require at least MacOS 10.15.

Qt 6 lives on a separate branch. The README describes QT6WIP as a work in progress that can compile with QT6, tested with Qt 6.9 on 2026-03-11, and states that support for QT6 is approximately beta quality with most all functions expected to work. That is the maintainer's wording, and beta quality with a dated test point is not the same as supported. If you are building this for daily use, the branch you want is master on Qt 5.14 or newer.

Dependencies are unusually self-contained, which is a genuine advantage. The README states the code depends on nothing other than what is in the source tree or what is available from the Qt installer. QCustomPlot is used for plotting and is integrated into the source, so you are not required to download it separately from qcustomplot.com. For a project that pulls in a lot of native libraries, having exactly one external dependency surface is worth noting.

The repository also carries `install-qt.sh` and `install-linux.sh` alongside `install.sh`, so Linux setup is partly scripted rather than entirely manual.

Scripting hooks and the release track split

Two capabilities sit outside the obvious GUI surface. The `examples/` directory holds JavaScript files, which lines up with the `jsedit.cpp` and `jsedit.h` window in the source: CaptureAllMsgTypes.js, GetCANandTick.js, RLEC.js and UpdateParameter.js. Scripting is how you automate capture analysis rather than clicking through it, and it is the feature that separates SavvyCAN from a plain log viewer.

The release channel picture is unusual and worth understanding before you pin a version. The most recent tagged build is V220 from 2025-05-09. After that come `continuous` development builds dated 2026-10-13 and `continuous-QT6` dated 2026-10-15, the latter being the Qt 6 development build. The last push was on 2026-10-15, so the repository is being worked on continuously, but the newest stable tag is well over a year older than the development builds.

That gap is the practical upgrade question. If you want the Qt 6 work, you are on the continuous-QT6 build; if you want stability, you are on V220 and its Qt 5 baseline. Nothing in the README explains which changes have shipped between them.

The licence is MIT, which places no restriction on commercial use or redistribution, and the README closes with the required attribution for six icons taken from the Noun Project.

Editorial conclusion

Adopt SavvyCAN if you are reverse engineering a CAN bus without a commercial analyser licence, since it reads twelve log formats, ships example logs, and runs against plain files with no hardware attached. Do not adopt it if you need Qt 6 support you can depend on for production work, because the README describes the QT6WIP branch as approximately beta quality, or if you need to write PCAN Viewer or CANDump/Kayak files, since those are listed as read only. Before building, confirm your Qt installation includes QtSerialBus, because the specific failure you will hit otherwise is `Project ERROR: Unknown module(s) in QT: qml serialbus help`, fixed on Ubuntu with `sudo apt install libqt5serialbus5-dev libqt5serialport5-dev qtdeclarative5-dev qttools5-dev`.

Frequently asked questions

Official sources

1. collin80/SavvyCAN on GitHub
2. Issues
3. License: MIT
4. README
5. Releases