Requirements

In order to execute GNSS-SDR, you will need:

A computing platform with some software dependencies installed.
A GNSS signal source:
- can be a file storing GNSS signal samples,
- or a suitable radio frequency front-end, if you want to operate in real-time.

The computing platform

Processor architecture

GNSS-SDR can be built in a variety of processor architectures, covering a wide range of computers such as desktops, laptops, minicomputers, embedded systems, and even mainframes:

Intel/AMD x86 instruction set (32 and 64 bits).
PowerPC: big-endian and little-endian, 32 and 64 bits.
ARM: version v4t and above, including 64-bit ARMv8.
MIPS: big-endian and little-endian, 32 and 64 bits.
IBM System z: IBM’s architecture for mainframe computers.
RISC-V: 64-bit RISC-V open standard instruction set architecture.
LoongArch: 64-bit RISC-style instruction set architecture developed by Loongson Technology.

GNSS-SDR will process incoming raw samples as fast as the computing platform executing it allows. It will automatically take advantage of multi-core architectures, and it will select the fastest SIMD implementation available in your machine (covering technologies such as SSE2, SSE3, SSE4.1, AVX, AVX2, and NEON). It can even offload some of the computing work to the Graphics Processing Unit. If there is computational power enough, GNSS-SDR can be used in real-time, reading raw samples from a radio frequency front-end. In slower machines, GNSS-SDR will execute exactly the same code, for instance reading raw samples from a file stored in a hard drive.

Try the software on your own computer: GNSS-SDR can be executed in a wide range of processor architectures, from the newest ones to those that have been around for a while. Your own computer will probably be among the listed above. The software receiver processes data as fast as it can, taking advantage of the particularities of your processor and dumping messages to the terminal output in case it is not able to perform the required computation in real-time. If your processor is not fast enough to process GNSS signals in real-time, you can still use files and use the software, performing exactly the same processing but at a slower pace, and thus without processing time constraints.

Operating Systems

GNSS-SDR can be run on a variety of operating systems:

GNU/Linux: GNSS-SDR and all its dependencies can be easily installed in most popular distributions, and it is even included as a software package starting in Debian 9 (stretch) and Ubuntu 16.04 LTS (Xenial). Older releases and other distributions might also work well.
macOS / Mac OS X: GNSS-SDR and all its dependencies can be easily installed using Mac OS X 10.9 (Mavericks) and above, including macOS 27 Golden Gate. You will need Xcode and a software package manager such as Macports (there is a gnss-sdr port that will do all the work for you) or Homebrew.
Microsoft Windows: Native Windows builds of GNSS-SDR are currently not supported. For Windows 10 and Windows 11 users, the recommended and simplest option is to use the Windows Subsystem for Linux (WSL) with an Ubuntu distribution, preferably using WSL 2. Both GNU Radio and GNSS-SDR have been successfully built and run under Windows 10/11 using the Ubuntu distributions available through WSL. This provides a straightforward way to run GNSS-SDR on a Windows machine without setting up a VirtualBox virtual machine or a Docker container. Follow Microsoft’s WSL installation instructions linked above, then use the Ubuntu instructions in our building guide from the Ubuntu terminal. As alternatives, you can install a GNU/Linux distribution in a virtual machine using VirtualBox, or run GNSS-SDR as a Docker container.

The Operating System should not be an issue: GNSS-SDR can be executed in GNU/Linux distributions as old as Ubuntu 14.04 LTS, and even in Mac OS X starting from 10.9. You are probably already working with newer versions, or you can use Ubuntu through WSL on Windows 10/11 or install a virtual machine running a recent Ubuntu or Debian release.

Software dependencies

GNSS-SDR builds upon a number of free and open-source software libraries:

GNU Radio, a free and open-source toolkit for software radio. In turn, GNU Radio requires a number of software dependencies, some of which are also used by GNSS-SDR. Notably, Boost, FFTW and VOLK.
Armadillo, a C++ linear algebra library. It acts as a wrapper for all the relevant libraries present on your system, such as LAPACK, BLAS, OpenBlas, ATLAS, and others.
Abseil, an open-source collection of C++ libraries. GNSS-SDR uses its logging and command-line flags libraries, and requires Abseil v20240116 or newer. If Abseil is not available in your system, it is older than that, or your toolchain is too old (GNSS-SDR only uses Abseil when building with C++17 or newer and CMake 3.24 or newer), GNSS-SDR falls back to glog, a C++ implementation of the Google logging module, and gflags, a C++ library that implements command-line flags processing. This fallback can also be forced by passing -DENABLE_GLOG_AND_GFLAGS=ON to CMake.
matio, a MATLAB MAT file I/O library.
PugiXML, a light-weight, simple and fast XML parser for C++.
Protocol Buffers, Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data.
A library implementing some basic SSL functions, such as OpenSSL, GnuTLS, or LibreSSL.

In order to install those dependencies in your system, check out our building guide and find more details at GNSS-SDR’s README.md file.

Availability of automated tools: Building and installing GNSS-SDR and its dependencies is a quite complex process, but there are automated tools that can do most of the work for you. Check out our building guide.

GNSS Signal Sources

The input of GNSS-SDR is a sequence of raw digital samples of GNSS signals. The Signal Source abstraction wraps all kind of sources, regardless of their nature: it can be a file containing a sequence of samples (which can be synthetically generated by a computer program, or real GNSS signals grabbed by an actual antenna and radio frequency front-end, and then translated into the digital domain and stored in a hard disk), or an actual device delivering live signal in real-time. In GNSS-SDR, whatever source delivering GNSS signal samples is a Signal Source.

For more details about the configuration and possible options, please check out the Signal Source documentation.

Files

The stream of raw GNSS signal samples can be stored in a file. Some of such files are freely available on the Internet, so you do not need access to a GNSS front-end for using GNSS-SDR. Only a few basic parameters are needed to be known (file name and path, the sampling frequency, the format in which samples are delivered, the presence of an Intermediate Frequency) in order to configure GNSS-SDR’s Signal Source adequately.

GNSS-SDR consumes data as fast as it can, regardless of the original sample rate in which the signal was captured. Hence, the processing of a file containing captured samples can take less time than the actual recording length.

On the contrary, in multi-system, multi-band configurations using a high number of parallel channels or highly complex algorithms, the host computer could not be able to perform the required processing in due time. While this is an issue in real-time configurations (that would cause buffer overflows and service discontinuity), it is not a problem when processing samples from a file. The software receiver will process samples at its own pace, applying exactly the same processing as it were real-time, and delivering the corresponding outputs as soon as they are available. This is very useful for algorithm prototyping since its functional performance can be checked before code optimization and does not require a powerful computer.

Radio frequency front-ends

For real-time operation with live GNSS signals, you will need an “air-to-computer” interface. That is, a suitable antenna and some hardware providing signal amplification at the appropriate frequency ranges (see our GNSS Signals tutorial for more information about GNSS signals’ center frequencies, modulations, and recommended bandwidths), downshifting, filtering, and conversion to the digital domain, plus some standard connection (usually, through USB or Ethernet) to the host computer in charge of the execution of the software-defined receiver, which will be performing all the baseband processing. Such a computer needs to be powerful enough to sustain the required amount of computational load. For simple configurations, any modern laptop should work well.

It follows a non-exhaustive list of commercially available examples of such general-purpose “air-to-computer” interfaces that are suitable for software-defined GNSS receivers:

Ettus Research USRP family is designed for RF applications from DC to 6 GHz, and provides a wide range of devices. The USRP product line spans from affordable hobbyist SDRs to high-end high-bandwidth radios. All USRPs can be used by GNSS-SDR through the USRP Hardware Driver (UHD).
Fairwaves UmTRX is an open hardware dual-channel wideband transceiver that covers from 300 MHz to 3.8 GHz with a maximum RF bandwidth of 28 MHz, delivering 12-bit quadrature samples up to 40 MS/s, and it is able to operate at industrial temperature ranges. Host connection is via Gigabit Ethernet, and a special version of UHD provides a host driver, along with the firmware.
Great Scott Gadgets HackRF One is an open-source hardware platform for Software Defined Radio that can operate from 1 MHz to 6 GHz, with a maximum quadrature sample rate of 20 MS/s with 8-bit quadrature samples (8-bit I and 8-bit Q). It features a software-controlled port to feed an active antenna and a Hi-Speed USB 2.0 connection. GNSS-SDR integration is provided via gr-osmosdr.
Nuand bladeRF is a family of wideband transceivers with 12-bit quadrature sampling and a USB 3.0 Superspeed host connection. The original bladeRF x40 and x115 cover from 300 MHz to 3.8 GHz at up to 40 MS/s, while the bladeRF 2.0 micro xA4 and xA9 cover from 47 MHz to 6 GHz at up to 61.44 MS/s. Starting from GNSS-SDR v0.0.22, all of them are supported natively through libbladeRF v2.6.0 or newer with the Bladerf_Signal_Source implementation (building GNSS-SDR with -DENABLE_BLADERF=ON). Integration via gr-osmosdr is also available.

For testing purposes, the antenna can be replaced by a radio frequency GNSS signal generator, which can directly feed the front-end and thus provide controlled inputs to the software-defined receiver. In such a case, you might need an attenuator between the signal generator and the antenna input in order to protect the RF circuitry.

If everything is ready, now you can jump into building and installing GNSS-SDR on your own computer.