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.

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 11 Big Sur. 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: At this time of writing, GNSS-SDR cannot be built natively on Microsoft Windows. As far as authors’ knowledge, nothing prevents it but their own ignorance on Microsoft’s building tools. Users have reported successful buildings of GNU Radio on Windows systems, so there should be not serious caveats building GNSS-SDR as well. However, GNSS-SDR is not blocked for Windows users. There are several virtualization tools that work well. Here we suggest Oracle’s VirtualBox, a professional solution that can be installed on Windows XP and later and it is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 2. Users can install VirtualBox on their Windows machine, and then install the ultimate Linux version as a guest operating system. Another possibility is to 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 install a virtual machine running the ultimate Ubuntu or Debian releases.

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.
glog, a C++ implementation of the Google logging module.
gflags, a C++ library that implements command-line flags processing.
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 wideband transceiver that covers from 300 MHz to 3.8 GHz, delivering 12-bit quadrature sampling at a rate of up to 40 MS/s. The host connection is via USB 3.0 Superspeed, and GNSS-SDR integration is provided via gr-osmosdr.

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.