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.
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.
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:
- Using package manager(s) to obtain the necessary dependencies
- Setting the correct environment variables
- 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
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 https://github.com/microsoft/vcpkg 3cd vcpkg 4.\bootstrap-vcpkg.bat 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
x86-windows. More can be found in
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
1mkdir build 2cd build 3cmake ../ -DCMAKE_TOOLCHAIN_FILE=C:\src\scripts\buildsystems\vcpkg.cmake 4cmake --build . --config <BUILD_TYPE> 5cmake --install . --config <BUILD_TYPE>
-DCMAKE_TOOLCHAIN_FILE ensures that the
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.