cjcliffe/CubicSDR: a cross-platform software radio receiver whose last release predates its last commit by four years

A release from 2022 and a commit from this month

The most consequential fact about this project is a date comparison, and it takes ten seconds to make.

The release history has three entries, and they are unevenly spaced. A version from May 2018, a version from August of the same year, and then a version from February 2022. The version numbers are all in the zero point two series, and there is a gap in the sequence, so a release was either made and not shown or the numbering skipped one. After February 2022 there is nothing.

The last commit to the default branch is dated the middle of September 2026. The repository is not archived. So for roughly four and a half years this project has been receiving commits and not cutting a release.

There is a plausible innocent explanation, and it is visible in the repository itself. The build for each platform lives in a separate repository, and there are three of them, one per operating system. If the maintainer, or a community member, builds from the current branch and attaches the artefact to a release, then a release can lag the code by however long it takes somebody to run a build on three platforms. What the releases page cannot tell you is which commit any given binary came from.

For a desktop application distributed as a download, that is a real problem, and it is worse here than for most projects because the thing being downloaded is a binary that talks to hardware over a vendor's API. A user who installs the last release gets 2022 code, and a user who builds from source gets 2026 code, and the two will present different device lists and different bugs. The readme points at the releases page for the latest binaries and at the wiki for build instructions, which means the project is asking its users to make that choice for themselves.

The version number is a related signal. A project that has been developed since the early 2010s and is still at zero point two point seven has either decided stability matters more than a one point zero, or has never had a release process that anybody owns. Given the four year gap, the second is the better guess.

The readme is a link hub, and the requirements section has not moved in a decade

The readme is under sixty words of prose and everything else is a pointer. Releases live on one page, build instructions in a wiki, the manual on a hosted documentation site, and the manual's own contributions go to yet another repository. The library list is a link list. The optional library list is a link list. The platform build scripts are three more links.

For a project of this size and this age, that is a documentation strategy that has simply stopped being maintained. The manual has its own repository with its own contribution process, which is a healthy sign that somebody cared about it at some point, and a hosted documentation site that is probably generated from that repository. The reason is structural: the readme in a repository whose build system is CMake and whose dependencies are native libraries is not a good place to put a manual, and the author knew it.

What nobody has updated is the readme's own requirements section, and it is the section a new user reads first. The stated hardware is a multi-core processor with at least a gigabyte of memory, and a graphics card with at least 128 megabytes of video memory supporting a specific OpenGL version or its embedded equivalent. The stated operating system floors are macOS 10.9 for the Mac binaries and Windows 7 for the Windows binaries. Linux is described as supported but not yet indexed, with a note that it is known to work on a particular old Debian and a particular old Ubuntu release.

Every one of those floors belongs to a decade that has ended. A 128 megabyte graphics memory floor is a constraint from before shader models became interesting. A version of macOS from 2013 as a minimum is a floor that excludes almost every Mac sold since 2016. Windows 7 stopped receiving support years ago. The Linux note describing support as not yet indexed reads like a sentence written before anyone asked.

None of this means the software does not work on a current machine. It means the readme is a document from an earlier era that has been left in place while the code moved, and that is worth knowing before you conclude your modern graphics driver is the reason a display is blank.

One abstraction layer explains a topic list that looks like a shopping list

The repository's topic tags include eight different radio brands or device families by name, plus the ham radio and spectrum analysis tags. That is unusual, and it is the clearest statement of the project's architecture available anywhere in the repository.

The reason is the abstraction layer in the dependency list. CubicSDR does not talk to any of those devices directly. It talks to a device abstraction interface, and the drivers behind that interface are supplied by a separate project with several backends. Once a vendor writes a driver for that interface, CubicSDR gains the device for free, and the cost to the application is a line in a list of supported hardware.

That is why the tag list spans the entire price range of the hobby. A television tuner dongle costing about the price of a coffee, a couple of transmit-capable devices in the low hundreds, a Pluto-class device that is both a receiver and a transmitter, a high-performance receiver from a commercial vendor, and a couple of transmit-capable units from other vendors. None of those are the same hardware, they speak different protocols over different transports, and the application treats them interchangeably.

The signal processing sits in the same pattern. A modular digital signal processing library does the filtering, resampling and demodulation work, with a fast Fourier transform library available as an optional addition that can be compiled into the signal processing layer. Audio output goes through a cross-platform audio library rather than a platform API, so the same recording works on three operating systems. Images are handled by a small PNG library, text by a bitmap font library plus a specific open font, and the whole thing is drawn with hardware-accelerated graphics through a versioned graphics interface and a cross-platform widget toolkit.

Nine dependencies, each doing one job, each a mature project with its own release cycle, and one abstraction layer between the application and the hardware. It is a good architecture for a program that has to run on a phone, a laptop and a Raspberry Pi image with the same source. It is also why the readme's list of libraries is effectively the dependency manifest: there is no separate build system documentation in the repository, because the libraries are the design.

Vendored dependencies and an optional library that turns a receiver into a control panel

Two entries in the top level directory deserve a note each.

The first is a vendored third-party source directory. For a native application with nine C and C++ dependencies, checking the sources into the tree rather than resolving them at build time is a legitimate choice: it means a build in 2028 uses the same code that worked in 2024, and it removes a class of supply chain problem. The cost is that somebody now owns the patches. When a dependency has a security advisory, this project has to apply it, and with nine of them plus a build system that has to keep working, that is a maintenance burden that grows silently.

The second is the optional library, and it changes what the application is. Most of the topic tags describe receivers: you plug something in and you watch a waterfall. The optional library is a radio control interface, the kind that talks to an actual transceiver over a serial connection and can change its frequency, mode and power. Add that and CubicSDR is not only a receiver but a control panel, which is why the ham radio tags are there alongside the hardware brand tags.

That distinction matters for anyone evaluating the software, because the two uses have completely different risk profiles. Receiving is passive. Pushing a transmit command to an amplifier or a rig, from a program that also has a keyboard shortcut bound to it, is not, and the readme does not discuss safety limits, interlock behaviour or what happens if a transmission is triggered while the application is in an unexpected state. For a hobbyist with a low power rig, that is a reasonable omission. For a club station or a contest operator, it is a question to ask.

The rest of the repository layout is conventional and tells you the project has outgrown its readme. There is a CMake list file and a CMake directory with helper modules, a resource file for Windows, a font directory, an icon directory, a documentation directory, a source directory, a continuous integration configuration, and a file of agent instructions at the root.

Five repositories and a badge, for a program that does one thing

Count the places this project lives. There is the application repository. There is a manual repository with its own contribution process. There are three build repositories, one each for macOS, for Windows, and for Linux as a self-contained application image. That is five repositories for a single program, plus a hosted documentation site, plus a chat badge for community support, plus a continuous integration badge pointing at a hosted build service.

The split is defensible on its own terms. Binary build artefacts with platform-specific packaging, toolchain pinning and code signing are a different problem from source, and putting them in separate repositories keeps the application repository clean and lets each packager iterate without review from the maintainer. The self-contained Linux image approach in particular is the right answer for a program that should run on a distribution the maintainer does not control, because it removes the distribution's package manager from the equation entirely.

What the arrangement costs is provenance. A user cannot answer a simple question: which commit is in the binary I downloaded. Every build repository is a separate set of scripts written by somebody, and the application repository has no record of what those scripts produce or when. For most software that is tolerable. For a program whose purpose is to receive and decode radio signals on hardware from six different vendors, a mismatch between driver version and application version is the kind of bug that presents as silence, which is the hardest failure mode to diagnose.

The agent instructions file at the root is the one entry that suggests the project is being worked on with current tooling. A repository whose readme recommends a 2013 operating system and whose last release is from 2022 has an instructions file for automated coding assistants sitting next to it, and the juxtaposition says something accurate: the code is being maintained more actively than the project is being published.

Editorial conclusion

CubicSDR is a good choice if you want one program that drives whichever radio hardware you happen to own, and you are prepared to build it yourself or to check whether one of the community build repositories has produced something newer than the last tagged release. It is a poor fit if you need a supported product, because the release history has been frozen for years while the code has kept moving, which means the binary on the releases page is not the code in the repository and neither is guaranteed to match the hardware you buy next. Before you rely on it, work out which source you are actually running, read the build instructions in the wiki rather than the readme, and check the hardware support list against your specific device before you spend an evening on drivers.

Frequently asked questions

Official sources

1. cjcliffe/CubicSDR on GitHub
2. Issues
3. License: GPL-2.0
4. README
5. Releases