GNU Radio on Everything

4 minute read

The majority of my work at Trabus Technologies involves implementing and creating signal processing capabilities for various DoD contracts and internal tools. The center of it all was GNU Radio since it’s both free and easy to start working with.

Although, it’s no surprise that some open source projects are difficult to interpret or work with and GNU Radio, in my experience, is no exception. I figured writing down some processes I had to go through would be useful for those going down the path of least resistence to DSP and software defined radio (SDR) work.

credits to :

What I mean by “working with GNU radio” is essentially developing blocks, or out-of-tree modules (OOT modules); i.e, implementing custom DSP processes and integrating any radios that isn’t supported by Osmosdr.

On Windows

Since there are explicit Cyber Security standards to adhere to when working with the DoD the main OS environment of choice is Windows, since Windows is the one best documented and easy to ‘lock down’. This presents a particularly difficult hurdle to begin with, mainly because Windows is not explicitly stated as a supported OS for GNU Radio for out-of-tree modules. I found the best approach to OOT development on Windows is to get it working as similarly to Linux as you can, and that involves:

  1. Using package manager(s) to obtain the necessary dependencies
  2. Setting the correct environment variables
  3. Avoid using the Visual Studio GUI to configure projects

The last point is important if you plan to cross-compile any projects you are working with, since Visual Studio creates an environment best used with Windows (and hard to reconfigure for anything else). Visual Studio comes with a command-line friendly executable that calls the compiler witout all the GUI requirements. More info here.

1C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30037\bin\Hostx64\x64\cl.exe

Assuming you’ve already installed GNU radio using your preferred method, the next thing is to obtain a package manager that cmake will correctly reference.

VcPkg & Environment

Microsoft created a very friendly package manager called VcPkg. With it you can use it as similarly to Linux’s apt-get tooling as you can. The main purpose of this is to ensure that cppunit and boost are linked when the OOT module attempts to configure the project.

When installing, ensure that you create a C:\src\ directory and install it there. This is to ensure the environment is set properly.

1cd /src
2git clone
3cd vcpkg
5.\vcpkg install integrate

Next is to modify the environment variables PATH to include C:\src\vcpkg\ and add the variable VCPKG_DEFAULT_TRIPLET and set it to x64-windows, so when installing a package it is for your system’s architecture. Other TRIPLET flavors include arm-uwp, arm64-windows, and x86-windows. More can be found in \src\vcpkg\triplets directory.


Once these are set, install the packages:

1vcpkg install cppunit boost 


I use Chocolatey to handle all my installations on Windows, ranging from the simple 7zip app to developer tools like cmake. Follow their installations instructions and get the following packages:

1choco install git cmake doxygen graphviz swig 

Building the OOT

If you’re working with a GNU radio OOT module and followed the above recommendations all you simply need to do set where GNU Radio is installed and call cmake with the right flags.

Ensure the following is set:


The path is wherever you installed GNU Radio. This is usually some C:\Program Files\ path.

Build your OOT module with the traditional cmake instructions!

1mkdir build
2cd build
3cmake ../ -DCMAKE_TOOLCHAIN_FILE=C:\src\scripts\buildsystems\vcpkg.cmake
4cmake --build . --config <BUILD_TYPE>
5cmake --install . --config <BUILD_TYPE>

The -DCMAKE_TOOLCHAIN_FILE ensures that the cppunit and boost you’ve installed is linked. The --config argument is a Windows-specific build type. Most people on Linux use the -DCMAKE_BUILD_TYPE flag, but this oddly doesn’t work with this on Windows…

WSL, MINGW, and Virtual Machines

Either option would work if you choose to virtualize your GNU radio installations, and would probably make it a lot easier. However, if you plan to interface with any hardware devices like software defined radios WSL does not allow this (yet), and Virtual Machines use a ton of resources that would otherwise be needed for DSP computes and timing requirements. If you just need to research that doesn’t require hardware, I would opt for this environment.

MINGW would possible be the best alternative, since it executes the Windows-native instruction set and would best utilize the compute resources. Although, I’m unaware of any package managers for it.

On Everything Else

On Linux/UNIX systems it’s fairly straight-forward: there are plenty of documentation available how-tos for getting it to work in a Linux environment, even macOS. To summarize most of it is to either use the apt-get tool on Linux or the brew tool on macOS.