# SDRangel: a Qt5/OpenGL SDR frontend for eight radio families and digital voice modes

> SDRangel is a C++ SDR and signal analyzer frontend that drives Airspy, Airspy HF+, BladeRF, HackRF, LimeSDR, PlutoSDR, RTL-SDR, SDRplay and FunCube hardware. The interesting part is the plugin model and the digital voice decoders; the cost is a large C++ build and a wiki that carries most of the documentation.

**f4exb/sdrangel** — SDR Rx/Tx software for Airspy, Airspy HF+, BladeRF, HackRF, LimeSDR, PlutoSDR, RTL-SDR, SDRplay and FunCube

- Repository: https://github.com/f4exb/sdrangel
- Stars: 4,074 · Forks: 598
- Language: C++
- License: GPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/f4exb-sdrangel

## What SDRangel actually replaces in an SDR workflow

Most SDR software starts as a demodulator for one or two dongles and grows a spectrum display on top. SDRangel starts from the other direction: the README describes it as a "Qt5 / OpenGL 3.0+ SDR and signal analyzer frontend to various hardware", and the hardware list in the repository description is the point. Airspy, Airspy HF+, BladeRF, HackRF, LimeSDR, PlutoSDR, RTL-SDR, SDRplay and FunCube are all named, and the topics list adds D-Star, DMR, dPMR and YSF alongside the device names.

The audience is therefore narrower than a generic listening app. If you own one RTL-SDR stick and want to hear local FM broadcast, SDRangel asks you to accept a Qt5 desktop application, an OpenGL 3.0+ requirement and a plugin tree before you get anything. If you own a HackRF and a PlutoSDR, want to compare them on the same signal, and also want to decode DMR, the same architecture is what makes that possible without installing three separate programs.

The repository layout confirms the scope. Top-level entries include devices/, plugins/, sdrbase/, sdrgui/, sdrsrv/, appsrv/, appbench/, sdrbench/, httpserver/, swagger/, ft8/, modemm17/, modemmeshcore/ and modemmeshtastic/. That is not a demodulator with add-ons; it is a framework with a device layer, a DSP base, a GUI, a server flavor and a set of modem plugins for specific digital modes.

## The plugin and device architecture visible in the repository tree

SDRangel separates hardware access from signal processing. The devices/ directory holds the source for each supported radio family, so adding an Airspy or a LimeSDR means adding a device implementation rather than editing the core. The plugins/ directory holds the processing blocks that sit on top of the sample stream. The sdrbase/ directory is the shared DSP and support layer, and sdrgui/ is the Qt5 user interface that binds the two together.

That split explains several things at once. It is why the same application can present a different set of controls depending on which radio is selected. It is also why the feature set grows through plugins rather than through core releases: the v7.27.0 release notes announce "New MeshCore plugins", and v7.27.1 follows with "Fixed incomplete MeshCore deployment". A plugin can ship, be found incomplete, and be corrected in a patch release without touching the device layer.

The repository also contains two server-side paths. sdrsrv/ and appsrv/ support a headless server flavor, and the README points to SDRangelcli as "a web application that can be used to control a headless (server flavor) instance of SDRangel", adding that it "can also be used as a remote control for the GUI flavor". The httpserver/ and swagger/ directories indicate that this remote control is exposed as an HTTP API with a specification, which is a different integration story from clicking around a desktop window. If your goal is a remote receiver on a machine without a monitor, that is the path the project documents.

## Installing SDRangel on Linux, Windows or macOS and starting a first receive session

The README does not carry installation instructions. It states that "Most of the information and documentation related to SDRangel can be found in the Wiki" and asks you to read at least the Home and Quick Start pages before running the program. So the first step is not a command; it is opening the wiki and matching the page to your platform, because the repository ships separate build and packaging trees for different targets: debian/, flatpak/, snap/, mac/, android/ and an AppVeyor configuration for Windows builds.

For a Linux host, the repository provides a CMake build with presets. The presence of CMakePresets.json means the configure step can name a preset instead of a long list of flags, but the wiki is where the project documents which preset applies to which distribution. A typical source build follows this shape:

```bash
git clone https://github.com/f4exb/sdrangel.git
cd sdrangel
cmake --preset default
cmake --build .
```

Do not treat those preset names as verified: the repository contains the preset file, but the wiki is the authority on the exact preset and on the dependency packages each platform needs. If you would rather not build, the README points to SDRangel-Docker, "a collection of Docker files and scripts to facilitate building and running SDRangel in a Docker container", which it says "Works for either the GUI (only on a Linux host) or the server". That sentence contains the constraint: the containerized GUI needs a Linux host, so a Windows or macOS user going the Docker route is looking at the server flavor plus SDRangelcli, not a windowed application.

Once the application starts, the workflow is device selection followed by plugin selection. You pick the radio from the device list, then add a demodulator or decoder plugin to the sample stream. The README's own advice is to read the Quick Start page first, and given that the GUI changes shape with the selected device, that advice is worth taking literally rather than skimming.

## Where SDRangel gets in your way

The build is the first real limitation. This is a C++ project with a Qt5 and OpenGL 3.0+ frontend, and the README's own framing is that you consult the wiki before posting issues. The existence of FIXME-notes.md at the top level, alongside a CHANGELOG, tells you the maintainers keep a running list of known gaps rather than presenting the tree as finished.

The second limitation is platform asymmetry. The Android directory exists, and the related searches show people looking for an Android version, but the README itself describes a Qt5 desktop frontend and says nothing about what the Android build supports. Treat mobile as unverified until the wiki says otherwise. Similarly, the Docker route is explicitly split: GUI only on a Linux host, server otherwise.

The third is documentation placement. The README is a pointer document. It names the wiki, the discussion group at groups.io, and the ancillary projects, then stops. If you are the kind of user who wants install commands in the README, this project will frustrate you. If you accept that the wiki is the manual, the arrangement is coherent: a project with this many device backends cannot keep per-platform instructions current in a single file.

Finally, consider the wrong-tool case honestly. If you want a lightweight receiver on a Raspberry Pi with minimal dependencies, a desktop Qt5 application with OpenGL requirements is a poor fit, and the related searches for Raspberry Pi installs do not change that. If you only need one narrow mode and one dongle, a smaller dedicated decoder will get you there with less to install.

## SDRangel compared with GQRX and SDR++

GQRX and SDR++ are the obvious alternatives, and the difference is architectural rather than cosmetic. Both are built around a receiver-centric model: you select a device, tune, and demodulate, and the application stays close to that single job. SDRangel is built around a device layer plus a plugin layer plus a server layer, which is why it can carry transmit as well as receive, why it has a headless flavor, and why its release notes talk about plugins such as MeshCore rather than about the receiver window.

The trade shows up in three places. Startup complexity: SDRangel asks you to choose a device and then attach processing plugins, where a receiver-centric tool typically has the demodulator already in the signal path. Dependency weight: a Qt5 and OpenGL 3.0+ C++ application is heavier than the alternatives, which matters on single-board computers. Remote operation: SDRangel is the one of the three that the README pairs with a separate web control application, SDRangelcli, and an HTTP API surface.

None of this makes the alternatives worse at their job. If your work is tuning around the bands with one dongle, a receiver-centric application will be faster to learn. SDRangel earns its complexity when you need several hardware families, digital voice modes, transmit, or a headless instance you drive over HTTP.

## Releases, licence and what an upgrade actually costs

The project is not archived, and the last push was on 2026-09-23, so the repository is current. The release cadence visible in the notes is steady and patch-oriented: v7.27.0 on 2026-07-04 introduced "New MeshCore plugins", v7.27.1 the same day fixed an "incomplete MeshCore deployment", and v7.27.2 on 2026-08-19 lists "Many code fixes and Ubuntu 26.04 release". That last entry is the one to read carefully before upgrading a distribution package, because it ties a code release to a specific Ubuntu version. If you are on an older Ubuntu, the packaged build you install may not correspond to v7.27.2.

Upgrade cost depends on how you installed it. A distribution or Flatpak or Snap package moves at the packager's pace, which may lag the GitHub releases. A source build means re-running the CMake configure and build steps and re-checking dependencies against the wiki for your platform. The Docker route means pulling or rebuilding the container images from SDRangel-Docker. Plugin-level changes, like the MeshCore work in v7.27.0 and v7.27.1, arrive with the application build rather than as separately installable units, so a plugin fix is an application upgrade.

The licence is GPL-3.0, per the LICENSE file and the badge in the README. That matters if you plan to redistribute a modified build or link it into a product; copyleft obligations attach to distributed derivatives. This is not legal advice, and anyone shipping SDRangel inside a commercial product should read the licence text rather than a summary.

## Conclusion

Adopt SDRangel if you run several SDR families, want receive and transmit in one application, and are willing to build C++ or use the Docker and packaged routes listed in the repository. Skip it if you need a small dependency footprint on a Raspberry Pi, or if you only want to listen to FM and never touch a plugin. Before committing, check the wiki's Quick Start page against your exact device, confirm whether your distribution package trails the v7.27.2 release from 2026-08-19, and read the GPL-3.0 terms if you plan to redistribute a modified build.

## FAQ

### Is SDRangel free to use?

Yes. The repository is licensed under GPL-3.0, as shown by the LICENSE file and the licence badge in the README. The copyleft terms apply if you redistribute a modified build.

### How do I install SDRangel on Windows?

The README does not carry install steps and directs readers to the wiki, including the Home and Quick Start pages. The repository includes an AppVeyor configuration, which indicates Windows builds are produced, but the wiki is where the project documents the procedure.

### How do I install SDRangel on Linux?

The README points to the wiki for documentation rather than listing commands. The repository contains debian/, flatpak/ and snap/ packaging directories plus CMakePresets.json for source builds, and the wiki is the authority on which route fits your distribution.

### How do I use SDRangel with an RTL-SDR?

RTL-SDR is one of the named supported hardware families, and the README asks you to read the Quick Start wiki page before running the program. In use, you select the device and then attach demodulator or decoder plugins to the sample stream.

### How do I use SDRangel with a HackRF?

HackRF appears in the project's supported hardware list, and the devices/ directory holds the per-radio implementations. The README does not document a HackRF-specific setup, so the wiki is the place to check for device-specific steps.

### How do I install SDRangel plugins?

Plugins are part of the application build rather than separately installable units. The v7.27.0 release notes announce new MeshCore plugins and v7.27.1 fixes an incomplete MeshCore deployment, so plugin changes arrive through an application upgrade.

## Sources

- [f4exb/sdrangel on GitHub](https://github.com/f4exb/sdrangel)
- [Issues](https://github.com/f4exb/sdrangel/issues)
- [License: GPL-3.0](https://github.com/f4exb/sdrangel/blob/master/LICENSE)
- [README](https://github.com/f4exb/sdrangel/blob/master/README.md)
- [Releases](https://github.com/f4exb/sdrangel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/f4exb-sdrangel