xTools: a Qt workbench for serial, Modbus, CAN and network traffic

What xTools is

xTools is a user-friendly, open-source, cross-platform debugging tool set built on Qt and written in C++. The README summarises its scope in one line, and the list is what makes the project unusual: serial port, HID, BLE, UDP, TCP, WebSocket, Modbus and CAN bus.

That combination describes a hardware bench tool rather than a developer utility. Most of these protocols appear in a lab, a factory line or a device bring-up, where the question is what bytes went over the wire and when. xTools gives one window for that, with chart views and the ability to send data, rather than a separate tool per protocol.

The other axis of the project is extensibility. The README calls it easily extendable using Lua and JavaScript, and the scripting is a first-class feature rather than a plugin afterthought. The repository is a Qt project with a CMakeLists.txt, a src/ tree, a libs/ directory for the bundled dependencies, a 3rd/ directory, cmake/ modules, xapps/ for the individual applications, and a docs/ folder that carries the documentation site at x-tools-author.github.io.

The licence is LGPL-3.0, and the last push to the repository was on 2026-10-10. Releases are tagged, with v7.7.1 on 2026-04-17 and v7.7.0 the day before, alongside a continuously updated daily build tag named continuous.

Separate applications for separate protocols

The screenshots in the README name the applications the project ships: xTools itself, xModbus, xCANBus, xMQTT and xFlow. That is the most useful structural fact about the project, because it shows the split between the general tool and the protocol specific ones.

xTools is the general workbench, the one that handles the serial port, HID, BLE and the socket protocols with a shared interface and a chart view. xModbus is a dedicated Modbus environment, which matters because Modbus is a request and response protocol with registers, function codes and a transaction model, and driving it needs more than a byte stream. xCANBus does the same for CAN bus, where frame identifiers, extended versus standard frames and bitrate are the working vocabulary. xMQTT targets the publish and subscribe protocol, with topic and payload structure rather than a flat stream. xFlow appears in the list as the fifth application, and the README does not describe it in the visible text.

The design consequence is that a user who works with one protocol gets an application built around that protocol's data model, while a user who crosses protocols gets the general tool. The same Lua and JavaScript extension mechanism and the same charting apply across them, which is what stops the project from being five unrelated programs.

Extending xTools with Lua and JavaScript

The scripting support is the reason xTools can cover protocols the author did not anticipate, and the reason the project describes itself as easily extendable.

Two languages are offered, Lua and JavaScript, and both are used to add behaviour to the existing applications rather than to write a standalone program. A script can react to received data, format it, drive the chart view, or send data back, which turns the tool from a passive viewer into something that can run a test sequence while you watch the bus.

The choice of Lua is not unusual for embedded tooling, and it is consistent with the rest of the project: the third-party list in the README includes the reference Lua interpreter as a bundled library, alongside zint for barcodes, glog for logging, libqrencode for QR codes, qmdnsengine for mDNS, QXlsx for spreadsheet files, hidapi for HID access, libiconv for character set conversion, SingleApplication for the single instance behaviour, and QCRC_Calc for CRC calculation.

That list is worth reading as a description of what the tool actually does on a bench. HID access goes through a C library rather than a platform API, mDNS discovery is built in, spreadsheets are supported for logging and export, and CRC calculation is available because half of the protocols xTools speaks are protected by a checksum.

Installing xTools

There are three routes, and the README is explicit about which is which. The Microsoft Store hosts the build sponsored by Microsoft, the GitHub releases hold the community build, and a daily build is published under the tag named continuous for people who want the newest commit rather than the newest release.

On Arch Linux the package is in the AUR, and the README gives the command:

yay -Syu x-tools

A self-built source package is also linked, hosted in a separate aur-repo repository.

On AlmaLinux the README lists the system dependencies, which show what the build needs on a Red Hat style system:

sudo dnf install systemd-devel systemd-libs libusbx-devel
sudo dnf install libX11-devel
sudo dnf install libxkbcommon-devel
sudo dnf install libxkbcommon-x11-devel

The usbx and systemd packages point at the USB and service integration, the X11 and xkbcommon packages at the display layer, and the README adds a note that suggests installing something more, without spelling out what.

The project also publishes a repology packaging status badge, which tracks how many distributions carry the package, and there is a Gitee mirror alongside the GitHub repository, which matters for users in networks where GitHub is slow.

Qt version requirements and the platform build matrix

xTools is built on Qt, and the README is careful about which version, because the requirements differ by target.

Qt 6.8.x is the recommended version, and the project has continuous integration workflows for Windows, Ubuntu, macOS, Android and a Qt 5 build, so the build matrix is broad. There is also a separate workflow for building the applications and one for daily builds.

The exception is documented. On macOS 26.0 and later, Qt 6.9.2 or newer is required to build xTools. For the Android platform, Qt 6.8.x or newer is required, and the README notes that other versions would be nice but are not tested.

Those two lines are the ones to read before starting a build on a current Mac, because the recommended version and the required version differ and the difference is not cosmetic. A developer on macOS 26 who installs the recommended Qt 6.8.x will hit a build failure that the README has already answered, and the answer is to upgrade Qt rather than to downgrade the operating system.

The applications are distributed as native packages, and the icons in the repository root, xTools.ico, xTools.icns and xTools.png, along with the xTools.qrc resource file and the .rc script, show that the packaging is a first-class part of the project rather than an afterthought.

Where xTools is the wrong tool

The first case is a scriptable pipeline. xTools is a graphical tool, and a CI job that has to open a serial port, send a frame and assert on the reply is not going to be written by driving a GUI. A protocol library in the language of the test harness is smaller, more deterministic and easier to debug when it fails.

The second case is a single protocol that already has a good dedicated tool. A team that only needs to watch CAN traffic does not need the general workbench, and the ecosystem around CAN has its own focused tools. xTools earns its place by covering many buses at once, and by supporting the ones without an obvious specialist tool, which is a large part of the list.

The third limitation is the platform matrix. The Qt version requirements, the per-platform CI workflows and the daily builds all say this is a desktop application with a real maintenance surface. The LGPL-3.0 licence is permissive enough for internal use, and it obliges a distributor to keep the library changes open, which is a consideration for anyone embedding xTools in a product.

The fourth is the undocumented edges. The README in its visible form does not describe what xFlow does, does not document the Lua and JavaScript APIs, and does not list the supported BLE or HID profiles. The documentation site and the in-application examples are where that knowledge lives, so a team that intends to script the tool heavily should budget for reading them before committing to it.

Editorial conclusion

xTools fits an engineer who has to look at device traffic on several buses at once and wants charts, scripting and a GUI instead of a terminal, and the per-protocol apps keep the interfaces small. It does not fit a Linux CI job that needs a scriptable command line, where a protocol library in your own language is more controllable. Check first that your platform's Qt version meets the stated minimum, since macOS 26 builds need newer Qt than the recommended 6.8.x.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. x-tools-author/x-tools on GitHub