UHD: the open source driver for Ettus USRP radios

What UHD actually is

UHD is the software driver and API for the Universal Software Radio Peripheral platform, the USRP radios created and sold by Ettus Research. The README describes it as free and open source, and the scope is all Ettus Research USRP hardware, including all motherboards and daughterboards and the combinations of them.

A radio like this is not a consumer radio with an antenna connector. It is a computer that transmits and receives, and the value of the software is that you can change what the hardware does: the waveform that is sampled, the filters, the gain distribution, the clocking, and in the limit the FPGA code itself. UHD is the layer that makes that programmable, and it is the layer every framework that talks to a USRP ends up using.

The repository is unusual for a driver because it contains the whole stack. The primary language in the metadata is Verilog, which is the FPGA sources, and the tree also holds C++ for the user space driver, assembly and C for the firmware, and Python for the tooling. The last push to the repository was on 2026-10-13, and the current release is UHD 4.11.0.0, published on 2026-09-09, with release candidates in the weeks before it.

The licence is the one file the repository metadata cannot categorise, LICENSE.md, and the README does not summarise its terms, so anyone redistributing UHD in a product needs to read that file rather than assume a permissive grant.

Six directories, four different pieces of hardware

The README describes the tree in six parts, and the split is the clearest statement of what UHD contains:

host/
mpm/
firmware/
fpga/
images/
tools/

host/ is the user space driver, the C++ library that an application links against. mpm/ is the module peripheral manager, code that runs on the embedded devices in the radio rather than on the host computer, which is how the newer USRP models expose their internal modules. firmware/ holds the source for all the microprocessors in USRP hardware. fpga/ holds the sources for the UHD FPGA images, and it is the directory that makes this more than a driver.

images/ contains the package builder for FPGA and firmware images, and the README notes that the scripts there are mainly relevant for UHD maintainers and developers rather than for users, which is an honest description of a directory that exists because the images have to be assembled into something the radio can boot. tools/ holds additional debugging tools, with a readme in that directory describing each one.

The practical consequence for a user is that the FPGA and firmware are part of the driver project rather than a separate binary blob you download. The radio can be re-imaged with a modified bitstream, which is the single capability that makes USRP a research instrument rather than a commodity.

Installing, building and the documentation split

The README keeps the documentation short and points elsewhere, which is the right call for a project this size. The UHD and USRP Manual is the main reference, and it holds the installation instructions, the guide to building UHD from source on different platforms, development guidelines, the reference documentation and device usage guidance. The Ettus Research FAQ and the Knowledge Base sit alongside it with application notes and tutorials.

The documentation is published at uhd.readthedocs.io, and the.readthedocs.yaml file in the repository root configures its build. The repository also carries a CHANGELOG, a CODING.md with the coding conventions, a CONTRIBUTING.md, and a.pre-commit-config.yaml, so the contribution flow enforces formatting before review. The.clang-format and.clang-tidy files set the C++ style, and.gitmodules shows that the tree pulls in submodules.

Operating system support is stated in the README. UHD is primarily developed on Linux, with Fedora and Ubuntu named, and Mac OS X and Windows 11 are tested and supported. The README adds that other operating systems will most likely work but are not officially supported, which is the usual distinction between tested and merely expected to work.

Because UHD is a driver with a build, the build guide is the document to read first for anyone installing from source, and the packaged installation is the path most users should take.

Where UHD sits in a software radio stack

The README lists the toolkits and frameworks that build on UHD, and the list is a good map of the ecosystem.

GNU Radio is the first entry and the most widely used, and there are USRP specific source blocks for it in the RFNoC out-of-tree blocks repository, which is the FPGA accelerated path that moves sample processing onto the radio's own fabric. NI LabVIEW has both a general USRP driver and a dedicated RFNoC variant. MathWorks Matlab and Simulink have a USRP support package, and REDHAWK is a further framework built on it.

The rest of the list is cellular and 5G research, which is where USRP hardware is most common: OpenBTS and Osmocom for GSM, Amarisoft LTE, Software Radio Systems srsRAN, and the Eurecom OpenAirInterface project. Those are all projects that need to transmit real protocol traffic, not just to receive it, and that is the use case the hardware is designed for.

The division of labour in that stack is worth understanding. UHD is the transport and the control plane: it moves samples, it configures the radio, it manages clocks and it exposes the device tree. The waveform lives above it, in GNU Radio or in the framework of your choice. A project that treats UHD as the thing that produces samples and leaves everything else to the framework above it is using it the way its maintainers intend.

Releases, cadence and the pre-release pattern

The release naming follows a four part version, UHD 4.11.0.0, with release candidates in the same scheme. The recent tags are 4.11.0.0-RC1 on 2026-08-20, 4.11.0.0-RC3 on 2026-09-04 and 4.11.0.0 on 2026-09-09, which gives a picture of the rhythm: a release candidate every couple of weeks, then the final tag.

That pattern matters for anyone who pins a driver. The candidate tags are how a user tests a new version before it becomes the default, and the last push to the repository after the final tag shows the branch is still receiving work, so a specific release should be considered a stable snapshot rather than the current state of development.

The CHANGELOG at the repository root is the authoritative record of what changed between versions, and it is the document to read when a new release breaks a workflow, since driver releases do carry behaviour changes in areas like USB throughput, clocking defaults and device enumeration.

The version scheme also tells you something about compatibility. A fourth component in the version exists because the driver has to track hardware revisions and image builds, and a USRP that ships with an older image may need an older driver to behave predictably.

Where UHD is the wrong tool

The first case is a user who only wants to receive. If the goal is to listen to a local FM station or to record a narrowband signal, a consumer software defined radio with its own vendor driver and a few Python scripts will get there with far less setup than installing a driver stack with a C++ core, an FPGA toolchain and a firmware build.

The second case is a project that is not about radio. UHD is hardware specific, and the driver exists to program Ettus radios. A team doing signal processing on files, or on a signal generator, does not need a driver for a radio it does not own.

The third limitation is the hardware dependency. Everything in the repository assumes Ettus hardware, and while the API is open and documented, a project that needs to support several radio vendors has to deal with the portability layer separately, which is exactly what a vendor-neutral abstraction such as SoapySDR exists for. UHD on its own is the Ettus path, not the portable one.

The fourth is the build weight. A developer who wants to modify the FPGA needs a Verilog toolchain, the UHD FPGA build scripts and usually a supported board, and the images/ tooling is documented as being mainly for maintainers. That is a real cost, and it is the price of the programmability that makes the hardware worth owning in the first place.

Editorial conclusion

UHD fits a team building its own radio application or a research group that needs to change the FPGA or the firmware, because the whole stack is in one tree under its own custom licence. It does not fit someone who only needs to receive a broadcast sample, where a consumer SDR and its own driver are enough. Check first that your USRP model and its daughterboards are supported, since the driver targets Ettus hardware specifically.

Frequently asked questions

Official sources

1. EttusResearch/uhd on GitHub
2. Issues
3. Project website
4. README
5. Releases