{"id":13419888,"url":"https://github.com/gnss-sdr/gnss-sdr","last_synced_at":"2025-05-14T03:08:40.154Z","repository":{"id":15996847,"uuid":"18740094","full_name":"gnss-sdr/gnss-sdr","owner":"gnss-sdr","description":"GNSS-SDR, an open-source software-defined GNSS receiver","archived":false,"fork":false,"pushed_at":"2025-05-07T15:28:02.000Z","size":91262,"stargazers_count":1790,"open_issues_count":185,"forks_count":639,"subscribers_count":117,"default_branch":"main","last_synced_at":"2025-05-07T16:44:12.307Z","etag":null,"topics":["c-plus-plus","galileo","glonass","gnss","gnss-sdr","gnuradio","gps","rtl-sdr","sdr","signal-processing","software-defined-radio"],"latest_commit_sha":null,"homepage":"https://gnss-sdr.org","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/gnss-sdr.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"COPYING","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":"CITATION.cff","codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2014-04-13T21:11:47.000Z","updated_at":"2025-05-06T06:18:38.000Z","dependencies_parsed_at":"2023-10-03T16:56:39.828Z","dependency_job_id":"ba209d73-856b-4632-a99b-9bfbea8ab07f","html_url":"https://github.com/gnss-sdr/gnss-sdr","commit_stats":null,"previous_names":[],"tags_count":22,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gnss-sdr%2Fgnss-sdr","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gnss-sdr%2Fgnss-sdr/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gnss-sdr%2Fgnss-sdr/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gnss-sdr%2Fgnss-sdr/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gnss-sdr","download_url":"https://codeload.github.com/gnss-sdr/gnss-sdr/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254059507,"owners_count":22007768,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c-plus-plus","galileo","glonass","gnss","gnss-sdr","gnuradio","gps","rtl-sdr","sdr","signal-processing","software-defined-radio"],"created_at":"2024-07-30T22:01:22.385Z","updated_at":"2025-05-14T03:08:40.108Z","avatar_url":"https://github.com/gnss-sdr.png","language":"C++","funding_links":[],"categories":["TODO scan for Android support in followings","Electronics and Mechanics","C++","\u003ca name=\"cpp\"\u003e\u003c/a\u003eC++","Open Source Software, Tools and APIs","Other SDR Software","Space and Aviation"],"sub_categories":["Version Control","C/C++"],"readme":"\u003c!-- prettier-ignore-start --\u003e\n[comment]: # (\nSPDX-License-Identifier: GPL-3.0-or-later\n)\n\n[comment]: # (\nSPDX-FileCopyrightText: 2011-2025 Carles Fernandez-Prades \u003ccarles.fernandez@cttc.es\u003e\n)\n\u003c!-- prettier-ignore-end --\u003e\n\n[![](./docs/doxygen/images/gnss-sdr_logo.png)](https://gnss-sdr.org \"GNSS-SDR website\")\n\n[![License: GPL v3](https://img.shields.io/badge/License-GPL%20v3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)\n[![REUSE status](https://api.reuse.software/badge/github.com/gnss-sdr/gnss-sdr)](https://api.reuse.software/info/github.com/gnss-sdr/gnss-sdr)\n[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](CODE_OF_CONDUCT.md)\n\n**Welcome to GNSS-SDR!**\n\nThis program is a software-defined receiver which is able to process (that is,\nto perform detection, synchronization, demodulation and decoding of the\nnavigation message, computation of observables, and, finally, computation of\nposition fixes) the following Global Navigation Satellite System's signals:\n\nIn the L1 band:\n\n- \u0026#128752; GLONASS L1 C/A (centered at 1602.000 MHz) :white_check_mark:\n- \u0026#128752; GPS L1 C/A (centered at 1575.420 MHz) :white_check_mark:\n- \u0026#128752; Galileo E1b/c (centered at 1575.420 MHz) :white_check_mark:\n- \u0026#128752; BeiDou B1I (centered at 1561.098 MHz) :white_check_mark:\n\nIn the E6 band:\n\n- \u0026#128752; Galileo E6B (centered at 1278.750 MHz) :white_check_mark:\n\nIn the L2 band:\n\n- \u0026#128752; BeiDou B3I (centered at 1268.520 MHz) :white_check_mark:\n- \u0026#128752; GLONASS L2 C/A (centered at 1246.000 MHz) :white_check_mark:\n- \u0026#128752; GPS L2C (centered at 1227.600 MHz) :white_check_mark:\n\nIn the L5 band:\n\n- \u0026#128752; Galileo E5b (centered at 1207.140 MHz) :white_check_mark:\n- \u0026#128752; Galileo E5a (centered at 1176.450 MHz) :white_check_mark:\n- \u0026#128752; GPS L5 (centered at 1176.450 MHz) :white_check_mark:\n\nGNSS-SDR provides interfaces for a wide range of radio frequency front-ends and\nraw sample file formats, generates processing outputs in standard formats,\nallows for the full inspection of the whole signal processing chain, and offers\na framework for the development of new features. Please visit\n[https://gnss-sdr.org](https://gnss-sdr.org \"GNSS-SDR website\") for more\ninformation about this open-source, software-defined GNSS receiver.\n\n:sparkles: See what's new in the [changelog](./docs/CHANGELOG.md).\n\n# Table of Contents\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cb\u003e(click to expand)\u003c/b\u003e\u003c/summary\u003e\n\u003c!-- MarkdownTOC --\u003e\n\n- [Table of Contents](#table-of-contents)\n- [How to build GNSS-SDR](#how-to-build-gnss-sdr)\n  - [GNU/Linux](#gnulinux)\n    - [Alternative 1: Install dependencies using software packages](#alternative-1-install-dependencies-using-software-packages)\n      - [Debian / Ubuntu](#debian--ubuntu)\n      - [AlmaLinux](#almalinux)\n      - [Arch Linux](#arch-linux)\n      - [Fedora](#fedora)\n      - [openSUSE](#opensuse)\n      - [Rocky Linux](#rocky-linux)\n    - [Alternative 2: Install dependencies using PyBOMBS](#alternative-2-install-dependencies-using-pybombs)\n    - [Manual installation of other required dependencies](#manual-installation-of-other-required-dependencies)\n      - [Install Armadillo, a C++ linear algebra library](#install-armadillo-a-c-linear-algebra-library)\n      - [Install Gflags, a commandline flags processing module for C++](#install-gflags-a-commandline-flags-processing-module-for-c)\n      - [Install Glog, a library that implements application-level logging](#install-glog-a-library-that-implements-application-level-logging)\n      - [Install the OpenSSL libraries](#install-the-openssl-libraries)\n      - [Install Matio, MATLAB MAT file I/O library](#install-matio-matlab-mat-file-io-library)\n      - [Install Protocol Buffers, a portable mechanism for serialization of structured data](#install-protocol-buffers-a-portable-mechanism-for-serialization-of-structured-data)\n      - [Install Pugixml, a light-weight C++ XML processing library](#install-pugixml-a-light-weight-c-xml-processing-library)\n      - [Download GoogleTest](#download-googletest)\n    - [Clone GNSS-SDR's Git repository](#clone-gnss-sdrs-git-repository)\n    - [Build and install GNSS-SDR](#build-and-install-gnss-sdr)\n      - [Build OSMOSDR support (OPTIONAL)](#build-osmosdr-support-optional)\n      - [Build FMCOMMS2 based SDR Hardware support (OPTIONAL)](#build-fmcomms2-based-sdr-hardware-support-optional)\n      - [Build OpenCL support (OPTIONAL)](#build-opencl-support-optional)\n      - [Build CUDA support (OPTIONAL)](#build-cuda-support-optional)\n  - [macOS](#macos)\n    - [Macports](#macports)\n    - [Homebrew](#homebrew)\n    - [Other package managers](#other-package-managers)\n    - [Build GNSS-SDR](#build-gnss-sdr)\n  - [Other builds](#other-builds)\n- [Updating GNSS-SDR](#updating-gnss-sdr)\n- [Getting started](#getting-started)\n- [Using GNSS-SDR](#using-gnss-sdr)\n  - [Control plane](#control-plane)\n    - [Configuration](#configuration)\n    - [GNSS block factory](#gnss-block-factory)\n  - [Signal Processing plane](#signal-processing-plane)\n    - [Signal Source](#signal-source)\n    - [Signal Conditioner](#signal-conditioner)\n      - [Data type adapter](#data-type-adapter)\n      - [Input filter](#input-filter)\n      - [Resampler](#resampler)\n    - [Channel](#channel)\n      - [Acquisition](#acquisition)\n      - [Tracking](#tracking)\n      - [Decoding of the navigation message](#decoding-of-the-navigation-message)\n    - [Observables](#observables)\n    - [Computation of Position, Velocity, and Time](#computation-of-position-velocity-and-time)\n- [About the software license](#about-the-software-license)\n- [Publications and Credits](#publications-and-credits)\n- [Ok, now what?](#ok-now-what)\n\n\u003c!-- /MarkdownTOC --\u003e\n\u003c/details\u003e\n\n# How to build GNSS-SDR\n\nThis section describes how to set up the compilation environment in GNU/Linux or\n[macOS / Mac OS X](#macos), and to build GNSS-SDR. See also our\n[build and install page](https://gnss-sdr.org/build-and-install/ \"GNSS-SDR's Build and Install\").\n\n## GNU/Linux\n\n- Tested distributions: Ubuntu 14.04 LTS and above; Debian 9.0 \"stretch\" and\n  above; Arch Linux; Fedora 26 and above; OpenSUSE 42.3 and above.\n- Supported microprocessor architectures:\n  - amd64: also known as x86-64, the 64-bit version of the x86 instruction set,\n    originally created by AMD and implemented by AMD, Intel, VIA, and others.\n  - armel: ARM embedded ABI, supported on ARM v4t and higher.\n  - armhf: ARM hard float, ARMv7 + VFP3-D16 floating-point hardware extension +\n    Thumb-2 instruction set and above.\n  - arm64: ARM 64 bits or ARMv8. Also known as AArch64.\n  - i386: Intel x86 instruction set (32-bit microprocessors).\n  - loong64: 64-bit version of LoongArch, a RISC-style instruction set\n    architecture developed by Loongson Technology.\n  - mips: MIPS architecture (big-endian, such as those manufactured by SGI).\n  - mipsel: MIPS architecture (little-endian, such as Loongson 3).\n  - mips64el: 64-bit version of MIPS architecture.\n  - powerpc: the RISC 32-bit microprocessor architecture developed by IBM,\n    Motorola (now Freescale), and Apple.\n  - ppc64: 64-bit big-endian PowerPC architecture.\n  - ppc64el: 64-bit little-endian PowerPC architecture.\n  - riscv64: 64-bit RISC-V open standard instruction set architecture.\n  - s390x: IBM System z architecture for mainframe computers.\n\nOlder distribution releases might work as well, but you will need GCC 4.7 or\nnewer.\n\nBefore building GNSS-SDR, you need to install all the required dependencies.\nThere are two alternatives here: through software packages or building them from\nthe source code. It is in general not a good idea to mix both approaches.\n\n### Alternative 1: Install dependencies using software packages\n\nIf you want to start building and running GNSS-SDR as quickly and easily as\npossible, the best option is to install all the required dependencies as binary\npackages.\n\n#### Debian / Ubuntu\n\nIf you are using Debian 9, Ubuntu 14.10 or above, this can be done by copying\nand pasting the following line in a terminal:\n\n```\n$ sudo apt install build-essential cmake git pkg-config libboost-dev libboost-date-time-dev \\\n       libboost-system-dev libboost-filesystem-dev libboost-thread-dev libboost-chrono-dev \\\n       libboost-serialization-dev liblog4cpp5-dev libuhd-dev gnuradio-dev gr-osmosdr \\\n       libblas-dev liblapack-dev libarmadillo-dev libgflags-dev libgoogle-glog-dev \\\n       libssl-dev libpcap-dev libmatio-dev libpugixml-dev libgtest-dev \\\n       libprotobuf-dev libcpu-features-dev protobuf-compiler python3-mako\n```\n\nPlease note that the required files from `libgtest-dev` were named `googletest`\nin Debian 9 \"stretch\" and Ubuntu 18.04 \"bionic\", and renamed to `libgtest-dev`\nin Debian 10 \"buster\" and above.\n\nIn distributions older than Ubuntu 21.04 Hirsute / Debian 11, the package\n`libcpu-features-dev` is not required.\n\nIn distributions older than Ubuntu 22.04 Jammy / Debian 12, the package\n`libssl-dev` must be replaced by `libgnutls-openssl-dev`.\n\n**Note for Ubuntu 14.04 LTS \"trusty\" users:** you will need to build from source\nand install GNU Radio manually, as explained below, since GNSS-SDR requires\n`gnuradio-dev` \u003e= 3.7.3, and Ubuntu 14.04 came with 3.7.2. Install all the\npackages above BUT EXCEPT `libuhd-dev`, `gnuradio-dev`, and `gr-osmosdr` (and\nremove them if they are already installed in your machine), and install those\ndependencies using PyBOMBS. The same applies to `libmatio-dev`: Ubuntu 14.04\ncame with 1.5.2 and the minimum required version is 1.5.3. Please do not install\nthe `libmatio-dev` package and install `libtool`, `automake` and `libhdf5-dev`\ninstead. A recent version of the library will be downloaded and built\nautomatically if CMake does not find it installed.\n\nIn distributions older than Ubuntu 16.04 or Debian 9, `python3-mako` must be\nreplaced by `python-mako`. For Ubuntu 14.04, you will need to add the package\n`python-six` to the list of dependencies.\n\nOnce you have installed these packages, you can jump directly to\n[download the source code and build GNSS-SDR](#clone-gnss-sdrs-git-repository).\n\n#### AlmaLinux\n\nIf you are using AlmaLinux:\n\n```\n# dnf update -y\n# dnf install -y 'dnf-command(config-manager)'\n# dnf config-manager --set-enabled powertools\n# dnf install -y epel-release\n# dnf install -y make gcc gcc-c++ kernel-devel cmake git boost-devel \\\n      boost-date-time boost-system boost-thread boost-chrono \\\n      boost-serialization log4cpp-devel gmp-devel uhd-devel gnuradio-devel \\\n      pugixml-devel matio-devel protobuf-devel glog-devel libpcap-devel \\\n      blas-devel lapack-devel armadillo-devel openssl-devel python3-mako \\\n      libarchive\n```\n\nOnce you have installed these packages, you can jump directly to\n[download the source code and build GNSS-SDR](#clone-gnss-sdrs-git-repository).\n\n#### Arch Linux\n\nIf you are using Arch Linux:\n\n```\n$ pacman -S gcc make cmake pkgconf git boost boost-libs libvolk gnuradio \\\n       blas lapack hdf5 openssl pugixml libmatio protobuf libpcap gtest \\\n       python-mako\n```\n\nOnce you have installed these packages, you can jump directly to\n[download the source code and build GNSS-SDR](#clone-gnss-sdrs-git-repository).\n\n#### Fedora\n\nIf you are using Fedora 26 or above, the required software dependencies can be\ninstalled by doing:\n\n```\n$ sudo yum install make automake gcc gcc-c++ kernel-devel cmake git boost-devel \\\n       boost-date-time boost-system boost-filesystem boost-thread boost-chrono \\\n       boost-serialization log4cpp-devel gnuradio-devel gr-osmosdr-devel \\\n       blas-devel lapack-devel matio-devel armadillo-devel gflags-devel \\\n       glog-devel openssl-devel libpcap-devel pugixml-devel python3-mako \\\n       protobuf-devel protobuf-compiler\n```\n\nIn Fedora 33 and above, you will need to add `gmp-devel` to the package list.\nOptionally, you can add `uhd-devel` starting from Fedora 32.\n\nIn Fedora 36 and above, packages `spdlog-devel` and `fmt-devel` are also\nrequired.\n\n#### openSUSE\n\nIf you are using openSUSE Leap:\n\n```\n$ zypper install cmake git gcc-c++ boost-devel libboost_atomic-devel \\\n       libboost_system-devel libboost_filesystem-devel libboost_chrono-devel \\\n       libboost_thread-devel libboost_serialization-devel log4cpp-devel \\\n       gnuradio-devel pugixml-devel libpcap-devel armadillo-devel libtool \\\n       automake hdf5-devel openssl-devel python3-Mako libmatio-devel\n```\n\nIf you are using openSUSE Tumbleweed:\n\n```\n$ zypper install cmake git gcc-c++ boost-devel libboost_atomic-devel \\\n       libboost_system-devel libboost_filesystem-devel libboost_date_time-devel \\\n       libboost_thread-devel libboost_chrono-devel libboost_serialization-devel \\\n       spdlog-devel fmt-devel gtest gnuradio-devel pugixml-devel libpcap-devel \\\n       armadillo-devel libtool automake hdf5-devel libopenssl-devel \\\n       python3-Mako protobuf-devel\n```\n\nOnce you have installed these packages, you can jump directly to\n[download the source code and build GNSS-SDR](#clone-gnss-sdrs-git-repository).\n\n#### Rocky Linux\n\nIf you are using Rocky Linux:\n\n```\n$ dnf install -y 'dnf-command(config-manager)'\n$ dnf config-manager --set-enabled powertools\n$ yum install -y epel-release\n$ yum install -y make gcc gcc-c++ kernel-devel cmake git boost-devel \\\n       boost-date-time boost-system boost-thread boost-chrono boost-serialization \\\n       log4cpp-devel gmp-devel uhd-devel gnuradio-devel pugixml-devel matio-devel \\\n       protobuf-devel glog-devel libpcap-devel blas-devel lapack-devel \\\n       armadillo-devel openssl-devel python3-mako libarchive\n```\n\nOnce you have installed these packages, you can jump directly to\n[download the source code and build GNSS-SDR](#clone-gnss-sdrs-git-repository).\n\n### Alternative 2: Install dependencies using PyBOMBS\n\nThis option is adequate if you are interested in development, in working with\nthe most recent versions of software dependencies, want more fine-tuning on the\ninstalled versions, or simply in building everything from the scratch just for\nthe fun of it. In such cases, we recommend using\n[PyBOMBS](https://github.com/gnuradio/pybombs \"Python Build Overlay Managed Bundle System\")\n(Python Build Overlay Managed Bundle System), GNU Radio's meta-package manager\ntool that installs software from source, or whatever the local package manager\nis, that automatically does all the work for you. Please take a look at the\nconfiguration options and general PyBOMBS usage at\nhttps://github.com/gnuradio/pybombs. Here we provide a quick step-by-step\ntutorial.\n\nFirst of all, install some basic packages:\n\n```\n$ sudo apt install git python3-pip\n```\n\nDownload, build and install PyBOMBS:\n\n```\n$ sudo pip3 install --upgrade git+https://github.com/gnuradio/pybombs.git\n```\n\nApply a configuration:\n\n```\n$ pybombs auto-config\n```\n\nAdd list of default recipes:\n\n```\n$ pybombs recipes add-defaults\n```\n\nDownload, build and install GNU Radio, related drivers, and some other extra\nmodules into the directory `/path/to/prefix` (replace this path by your\npreferred one, for instance `$HOME/sdr`):\n\n```\n$ pybombs prefix init /path/to/prefix -a myprefix -R gnuradio-default\n```\n\nThis will perform a local installation of the dependencies under\n`/path/to/prefix`, so they will not be visible when opening a new terminal. In\norder to make them available, you will need to set up the adequate environment\nvariables:\n\n```\n$ cd /path/to/prefix\n$ . ./setup_env.sh\n```\n\nNow you are ready to use GNU Radio and to jump into building GNSS-SDR after\ninstalling a few other dependencies. Actually, those are steps that PyBOMBS can\ndo for you as well:\n\n```\n$ pybombs install gnss-sdr\n```\n\nBy default, PyBOMBS installs the ‘next’ branch of GNSS-SDR development, which is\nthe most recent version of the source code. This behavior can be modified by\naltering the corresponding recipe at\n`$HOME/.pybombs/recipes/gr-recipes/gnss-sdr.lwr`\n\nIn case you do not want to use PyBOMBS and prefer to build and install GNSS-SDR\nstep by step (i.e., cloning the repository and doing the usual\n`cmake .. \u0026\u0026 make \u0026\u0026 make install` dance), Armadillo, GFlags, Glog, GnuTLS, and\nMatio can be installed either by using PyBOMBS:\n\n```\n$ pybombs install armadillo gflags glog gnutls matio\n```\n\nor manually as explained below, and then please follow instructions on how to\n[download the source code and build GNSS-SDR](#clone-gnss-sdrs-git-repository).\n\n### Manual installation of other required dependencies\n\n#### Install [Armadillo](https://arma.sourceforge.net/ \"Armadillo's Homepage\"), a C++ linear algebra library\n\n```\n$ sudo apt install libblas-dev liblapack-dev       # For Debian/Ubuntu/LinuxMint\n$ sudo yum install lapack-devel blas-devel             # For Fedora/RHEL\n$ sudo zypper install lapack-devel blas-devel          # For OpenSUSE\n$ sudo pacman -S blas lapack                           # For Arch Linux\n$ wget https://sourceforge.net/projects/arma/files/armadillo-14.4.1.tar.xz\n$ tar xvfz armadillo-14.4.1.tar.xz\n$ cd armadillo-14.4.1\n$ cmake .\n$ make\n$ sudo make install\n```\n\nThe full stop separated from `cmake` by a space is important.\n[CMake](https://cmake.org/ \"CMake's Homepage\") will figure out what other\nlibraries are currently installed and will modify Armadillo's configuration\ncorrespondingly. CMake will also generate a run-time armadillo library, which is\na combined alias for all the relevant libraries present on your system (e.g.,\nBLAS, LAPACK, and ATLAS).\n\n#### Install [Gflags](https://github.com/gflags/gflags \"Gflags' Homepage\"), a commandline flags processing module for C++\n\n```\n$ wget https://github.com/gflags/gflags/archive/v2.2.2.tar.gz\n$ tar xvfz v2.2.2.tar.gz\n$ cd gflags-2.2.2\n$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF -DBUILD_gflags_nothreads_LIB=OFF .\n$ make\n$ sudo make install\n$ sudo ldconfig\n```\n\nPlease note that GFlags is replaced by the\n[Abseil Flags Library](https://abseil.io/docs/cpp/guides/flags) if Abseil \u003e=\nv20240116 is available in your system.\n\n#### Install [Glog](https://github.com/google/glog \"Glog's Homepage\"), a library that implements application-level logging\n\n```\n$ wget https://github.com/google/glog/archive/v0.7.1.tar.gz\n$ tar xvfz v0.7.1.tar.gz\n$ cd glog-0.7.1\n$ mkdir build \u0026\u0026 cd build\n$ cmake ..\n$ make\n$ sudo make install\n$ sudo ldconfig\n```\n\nPlease note that Glog is replaced by the\n[Abseil Logging Library](https://abseil.io/docs/cpp/guides/logging) if Abseil \u003e=\nv20240116 is available in your system.\n\n#### Install the OpenSSL libraries\n\n```\n$ sudo apt install libssl-dev             # For Debian/Ubuntu/LinuxMint\n$ sudo yum install openssl-devel          # For Fedora/CentOS/RHEL\n$ sudo zypper install openssl-devel       # For OpenSUSE\n$ sudo pacman -S openssl                  # For Arch Linux\n```\n\n#### Install [Matio](https://github.com/tbeu/matio \"Matio's Homepage\"), MATLAB MAT file I/O library\n\n```\n$ wget https://github.com/tbeu/matio/releases/download/v1.5.28/matio-1.5.28.tar.gz\n$ tar xvfz matio-1.5.28.tar.gz\n$ cd matio-1.5.28\n$ ./configure\n$ make\n$ sudo make install\n$ sudo ldconfig\n```\n\n#### Install [Protocol Buffers](https://protobuf.dev/ \"Protocol Buffers' Homepage\"), a portable mechanism for serialization of structured data\n\nGNSS-SDR requires Protocol Buffers v3.0.0 or later. If the packages that come\nwith your distribution are older than that (_e.g._, Ubuntu 16.04 Xenial came\nwith an older versions), then you will need to install it manually:\n\n```\n$ git clone --recursive https://github.com/protocolbuffers/protobuf.git\n$ cd protobuf\n$ cmake -DABSL_PROPAGATE_CXX_STD=ON -Dprotobuf_BUILD_TESTS=OFF .\n$ cmake --build --config Release --target install .\n$ sudo ldconfig\n```\n\nFor more options, please check the\n[Protocol Buffers' installation instructions](https://github.com/protocolbuffers/protobuf/blob/main/src/README.md/).\n\n#### Install [Pugixml](https://pugixml.org/ \"Pugixml's Homepage\"), a light-weight C++ XML processing library\n\n```\n$ wget https://github.com/zeux/pugixml/releases/download/v1.15/pugixml-1.15.tar.gz\n$ tar xvfz pugixml-1.15.tar.gz\n$ cd pugixml-1.15\n$ mkdir build \u0026\u0026 cd build\n$ cmake ..\n$ make\n$ sudo make install\n$ sudo ldconfig\n```\n\n#### Download [GoogleTest](https://github.com/google/googletest \"Googletest Homepage\")\n\n```\n$ wget https://github.com/google/googletest/archive/refs/tags/v1.16.0.zip\n$ unzip v1.16.0.zip\n```\n\nPlease **DO NOT build or install** Google Test. Every user needs to compile\ntests using the same compiler flags used to compile the Google Test libraries;\notherwise, he or she may run into undefined behaviors (_i.e._, the tests can\nbehave strangely and may even crash for no obvious reasons). The explanation is\nthat C++ has the One-Definition Rule: if two C++ source files contain different\ndefinitions of the same class/function/variable, and you link them together, you\nviolate the rule. The linker may or may not catch the error (in many cases it is\nnot required by the C++ standard to catch the violation). If it does not, you\nget strange run-time behaviors that are unexpected and hard to debug. If you\ncompile Google Test and your test code using different compiler flags, they may\nsee different definitions of the same class/function/variable (_e.g._, due to\nthe use of `#if` in Google Test). Therefore, for your sanity, GNSS-SDR does not\nmake use of pre-compiled Google Test libraries. Instead, it compiles Google\nTest's source code itself, such that it can be sure that the same flags are used\nfor both Google Test and the tests. The building system of GNSS-SDR manages the\ncompilation and linking of Google Test's source code to its own tests; it is\nonly required that you tell the system where the Google Test folder that you\ndownloaded resides. Just type in your terminal (or add it to your\n`$HOME/.bashrc` file for a permanent solution) the following line:\n\n```\nexport GTEST_DIR=/home/username/googletest-1.16.0\n```\n\nchanging `/home/username/googletest-1.16.0` by the actual path where you\nunpacked Google Test. If the CMake script does not find that folder, or the\nenvironment variable is not defined, or the source code is not installed by a\npackage, then it will download a fresh copy of the Google Test source code and\nwill compile and link it for you.\n\n\u003ca name=\"download-and-build-linux\"\u003e\u003c/a\u003e\n\n### Clone GNSS-SDR's Git repository\n\n```\n$ git clone https://github.com/gnss-sdr/gnss-sdr\n```\n\nCloning the GNSS-SDR repository as in the line above will create a folder named\ngnss-sdr with the following structure:\n\n```\n |-gnss-sdr\n |---cmake      \u003c- CMake-related files.\n |---conf       \u003c- Configuration files. Each file defines one particular receiver.\n |---docs       \u003c- Contains documentation-related files.\n |---install    \u003c- Executables will be placed here.\n |---src        \u003c- Source code folder.\n |-----algorithms  \u003c- Signal processing blocks.\n |-----core     \u003c- Control plane, interfaces, systems' parameters.\n |-----main     \u003c- Main function of the C++ program.\n |---tests      \u003c- QA code.\n |---utils      \u003c- some utilities (e.g. Matlab scripts).\n```\n\nBy default, you will be in the 'main' branch of the Git repository, which\ncorresponds to the latest stable release. If you want to try the latest\ndevelopments, you can use the 'next' branch by going to the newly created\ngnss-sdr folder doing:\n\n```\n$ git checkout next\n```\n\nMore information about GNSS-SDR-specific Git usage and pointers to further\nreadings can be found at our\n[Git tutorial](https://gnss-sdr.org/docs/tutorials/using-git/ \"Using Git\").\n\n### Build and install GNSS-SDR\n\nGo to GNSS-SDR's build directory:\n\n```\n$ cd gnss-sdr\n```\n\nConfigure and build the application:\n\n```\n$ cmake -S . -B build\n$ cmake --build build\n```\n\nBy default, CMake will build the Release version, meaning that the compiler will\ngenerate a fast, optimized executable. This is the recommended build type when\nusing an RF front-end and you need to attain real-time. If working with a file\n(and thus without real-time constraints), you may want to obtain more\ninformation about the internals of the receiver, as well as more fine-grained\nlogging. This can be done by building the Debug version, by doing:\n\n```\n$ cmake -S . -B build-debug -DCMAKE_BUILD_TYPE=Debug\n$ cmake --build build-debug\n```\n\nThis will create four executables at gnss-sdr/install, namely `gnss-sdr`,\n`run_tests`, `front-end-cal` and `volk_gnsssdr_profile`. You can run them from\nthat folder, but if you prefer to install `gnss-sdr` on your system and have it\navailable anywhere else, do:\n\n```\n$ sudo cmake --install build\n```\n\nThis will also make a copy of the conf/ folder into\n/usr/local/share/gnss-sdr/conf for your reference. We suggest creating a working\ndirectory at your preferred location and store your own configuration and data\nfiles there.\n\nYou could be interested in creating the documentation (requires:\n`sudo apt install doxygen-latex` in Ubuntu/Debian) by doing:\n\n```\n$ cmake --build build --target doc\n```\n\nThis will generate HTML documentation that can be retrieved pointing your\nbrowser of preference to `build/docs/html/index.html`. If a LaTeX installation\nis detected in your system,\n\n```\n$ cmake --build build --target pdfmanual\n```\n\nwill create a PDF manual at build/docs/GNSS-SDR_manual.pdf. Finally,\n\n```\n$ cmake --build build --target doc-clean\n```\n\nwill remove the content of previously generated documentation.\n\nGNSS-SDR comes with a library which is a module of the Vector-Optimized Library\nof Kernels (so-called\n[VOLK_GNSSSDR](./src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr/README.md))\nand a profiler that will build a config file for the best SIMD architecture for\nyour processor. Run `volk_gnsssdr_profile` that is installed into `$PREFIX/bin`.\nThis program tests all known VOLK kernels for each architecture supported by the\nprocessor. When finished, it will write to\n`$HOME/.volk_gnsssdr/volk_gnsssdr_config` the best architecture for the VOLK\nfunction. This file is read when using a function to know the best version of\nthe function to execute. It mimics GNU Radio's [VOLK](https://www.libvolk.org/)\nlibrary, so if you still have not run `volk_profile`, this is a good moment to\ndo so.\n\n#### Build OSMOSDR support (OPTIONAL)\n\nInstall the [OsmoSDR](https://osmocom.org/projects/sdr \"OsmoSDR's Homepage\")\nlibrary and GNU Radio's source block:\n\n```\n$ git clone git://git.osmocom.org/osmo-sdr.git\n$ cd osmo-sdr/software/libosmosdr\n$ mkdir build\n$ cd build/\n$ cmake ..\n$ make\n$ sudo make install\n$ sudo ldconfig\n$ cd ../..\n$ git clone git://git.osmocom.org/gr-osmosdr\n$ cd gr-osmosdr\n$ mkdir build\n$ cd build\n$ cmake .. -Wno-dev\n$ make\n$ sudo make install\n$ sudo ldconfig\n```\n\nThen, configure GNSS-SDR to build the `Osmosdr_Signal_Source` by:\n\n```\n$ cmake -S . -B build -DENABLE_OSMOSDR=ON\n$ cmake --build build\n$ sudo cmake --install build\n```\n\n(in order to disable the `Osmosdr_Signal_Source` compilation, you can pass\n`-DENABLE_OSMOSDR=OFF` to cmake and build GNSS-SDR again).\n\n#### Build FMCOMMS2 based SDR Hardware support (OPTIONAL)\n\nInstall the [libiio](https://github.com/analogdevicesinc/libiio.git) (\u003e=v0.11),\n[libad9361](https://github.com/analogdevicesinc/libad9361-iio.git) (\u003e=v0.1-1)\nlibraries and [gr-iio](https://github.com/analogdevicesinc/gr-iio.git) (\u003ev0.3)\ngnuradio block:\n\n```\n$ sudo apt install libxml2-dev bison flex\n$ git clone https://github.com/analogdevicesinc/libiio.git\n$ cd libiio\n$ mkdir build\n$ cd build\n$ cmake ..\n$ make \u0026\u0026 sudo make install \u0026\u0026 sudo ldconfig\n$ cd ../..\n$ git clone https://github.com/analogdevicesinc/libad9361-iio.git\n$ cd libad9361-iio\n$ mkdir build\n$ cd build\n$ cmake ..\n$ make \u0026\u0026 sudo make install \u0026\u0026 sudo ldconfig\n$ cd ../..\n$ git clone https://github.com/analogdevicesinc/gr-iio.git\n$ cd gr-iio\n$ mkdir build\n$ cd build\n$ cmake -DCMAKE_INSTALL_PREFIX=/usr ..\n$ make \u0026\u0026 sudo make install \u0026\u0026 sudo ldconfig\n$ cd ../..\n```\n\nThen configure GNSS-SDR to build the `Fmcomms2_Signal_Source` implementation:\n\n```\n$ cd gnss-sdr\n$ cmake -S . -B build -DENABLE_FMCOMMS2=ON\n$ cmake --build build\n$ sudo cmake --install build\n```\n\nor configure it to build `Plutosdr_Signal_Source`:\n\n```\n$ cmake -S . -B build -DENABLE_PLUTOSDR=ON\n$ cmake --build build\n$ sudo cmake --install build\n```\n\nWith `Fmcomms2_Signal_Source` you can use any SDR hardware based on\n[FMCOMMS2](https://wiki.analog.com/resources/eval/user-guides/ad-fmcomms2-ebz),\nincluding the ADALM-PLUTO (PlutoSdr) by configuring correctly the .conf file.\nThe `Plutosdr_Signal_Source` offers a simpler manner to use the ADALM-PLUTO\nbecause implements only a subset of FMCOMMS2's parameters valid for those\ndevices.\n\n#### Build OpenCL support (OPTIONAL)\n\nIn order to enable the building of blocks that use OpenCL, type:\n\n```\n$ cmake -S . -B build -DENABLE_OPENCL=ON\n$ cmake --build build\n$ sudo cmake --install build\n```\n\n#### Build CUDA support (OPTIONAL)\n\nIn order to enable the building of blocks that use CUDA, NVIDIA's parallel\nprogramming model that enables graphics processing unit (GPU) acceleration for\ndata-parallel computations, first you need to install the CUDA Toolkit from\n[NVIDIA Developers Download page](https://developer.nvidia.com/cuda-downloads \"CUDA Downloads\").\nMake sure that the SDK samples build well. Then, build GNSS-SDR by doing:\n\n```\n$ cmake -S . -B build -DENABLE_CUDA=ON\n$ cmake --build build\n$ sudo cmake --install build\n```\n\nOf course, you will also need a GPU that\n[supports CUDA](https://developer.nvidia.com/cuda-gpus \"CUDA GPUs\").\n\n## macOS\n\nGNSS-SDR can be built on macOS (or the former Mac OS X), starting from 10.9\n(Mavericks) and including 14 (Sonoma). If you still have not installed\n[Xcode](https://developer.apple.com/xcode/ \"Xcode\"), do it now from the App\nStore (it's free). You will also need the Xcode Command Line Tools, which do not\ncome by default in macOS versions older than Big Sur. If you are using an older\nversion, please launch the Terminal, found in /Applications/Utilities/, and\ntype:\n\n```\n$ xcode-select --install\n```\n\nAgree to Xcode license:\n\n```\n$ sudo xcodebuild -license\n```\n\nSoftware pre-requisites can be installed using either [Macports](#macports) or\n[Homebrew](#homebrew).\n\n### Macports\n\nFirst, [install Macports](https://www.macports.org/install.php). If you are\nupgrading from a previous installation, please follow the\n[migration rules](https://trac.macports.org/wiki/Migration).\n\nIn a terminal, type:\n\n```\n$ sudo port selfupdate\n$ sudo port upgrade outdated\n$ sudo port install armadillo cmake pkgconfig protobuf3-cpp pugixml openssl3\n$ sudo port install gnuradio +uhd +grc +zeromq\n$ sudo port install boost matio libad9361-iio libiio abseil\n$ sudo port install py313-mako\n$ sudo port install doxygen +docs\n```\n\nFor macOS versions older than Sonoma, you will also need LAPACK:\n\n```\n$ sudo port install lapack\n```\n\nYou also might need to activate a Python installation. The list of installed\nversions can be retrieved with:\n\n```\n$ port select --list python\n```\n\nand you can activate a certain version by typing:\n\n```\n$ sudo port select --set python python313\n```\n\n### Homebrew\n\nFirst, install [Homebrew](https://brew.sh/). Paste this in a terminal prompt:\n\n```\n$ /usr/bin/ruby -e \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)\"\n```\n\nThe script explains what it will do, and then it pauses before doing it. There\nare more installation options [here](https://docs.brew.sh/Installation.html).\n\nInstall the required dependencies:\n\n```\n$ brew update \u0026\u0026 brew upgrade\n$ brew install armadillo cmake hdf5 gnuradio libmatio openssl pkg-config protobuf pugixml boost\n$ brew install --cask mactex  # when completed, restart Terminal\n$ brew install graphviz doxygen\n¢ pip3 install mako\n```\n\nFor macOS versions older than Sonoma, you will also need LAPACK:\n\n```\n$ brew install lapack\n```\n\n### Other package managers\n\nGNU Radio and other dependencies can also be installed using other package\nmanagers than Macports, such as [Fink](https://www.finkproject.org/ \"Fink\").\nSince the version of Python that ships with OS X is great for learning but it is\nnot good for development, you could have another Python executable in a\nnon-standard location. If that is the case, you need to inform GNSS-SDR's\nconfiguration system by defining the `PYTHON_EXECUTABLE` variable as:\n\n```\n$ cmake -S . -B build -DPYTHON_EXECUTABLE=/path/to/bin/python3\n```\n\nIn case you have installed Macports in a non-standard location, you can use:\n\n```\n$ cmake  -S . -B build -DCMAKE_PREFIX_PATH=/opt/local -DUSE_MACPORTS_PYTHON=/opt/local/bin/python\n```\n\nchanging `/opt/local` by the base directory in which your software is installed.\n\nThe CMake script will create Makefiles that download, build and link Armadillo,\nGflags, Glog, Matio, Protocol Buffers, PugiXML and Google Test on the fly at\ncompile time if they are not detected in your machine.\n\n### Build GNSS-SDR\n\nFinally, you are ready to clone the GNSS-SDR repository, configure and build the\nsoftware:\n\n```\n$ git clone https://github.com/gnss-sdr/gnss-sdr\n$ cd gnss-sdr\n$ cmake -S . -B build\n$ cmake --build build\n```\n\nThis will create three executables at `gnss-sdr/install`, namely `gnss-sdr`,\n`run_tests` and `volk_gnsssdr_profile`. You can install the software receiver on\nyour system by doing:\n\n```\n$ sudo cmake --install build\n```\n\nand uninstall it with:\n\n```\n$ sudo cmake --build build --target uninstall\n```\n\nNote, it is advisable not to run the install step in a homebrew environment.\n\nThe documentation can be built by:\n\n```\n$ cmake --build build --target doc\n```\n\nand can be viewed doing:\n\n```\n$ open ./docs/html/index.html\n```\n\nGNSS-SDR comes with a library which is a module of the Vector-Optimized Library\nof Kernels (so-called\n[VOLK_GNSSSDR](./src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr/README.md))\nand a profiler that will build a config file for the best SIMD architecture for\nyour processor. Run `volk_gnsssdr_profile` that is installed into `$PREFIX/bin`.\nThis program tests all known VOLK kernels for each architecture supported by the\nprocessor. When finished, it will write to\n`$HOME/.volk_gnsssdr/volk_gnsssdr_config` the best architecture for the VOLK\nfunction. This file is read when using a function to know the best version of\nthe function to execute. It mimics GNU Radio's [VOLK](https://www.libvolk.org/)\nlibrary, so if you still have not run `volk_profile`, this is a good moment to\ndo so.\n\n## Other builds\n\n- **Docker image**: A technology providing operating-system-level virtualization\n  to build, ship, and run distributed applications, whether on laptops, data\n  center VMs, or the cloud. Visit\n  [https://github.com/carlesfernandez/docker-gnsssdr](https://github.com/carlesfernandez/docker-gnsssdr)\n  or\n  [https://github.com/carlesfernandez/docker-pybombs-gnsssdr](https://github.com/carlesfernandez/docker-pybombs-gnsssdr)\n  for instructions.\n\n- **Snap package**: [Snaps](https://snapcraft.io) are Linux packages aimed for\n  Ubuntu or Ubuntu-like distros. Visit\n  [https://github.com/carlesfernandez/snapcraft-sandbox](https://github.com/carlesfernandez/snapcraft-sandbox)\n  for instructions, or directly\n  [get the software from the Snap Store](https://snapcraft.io/gnss-sdr-next):\n\n\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://snapcraft.io/gnss-sdr-next\"\u003e\u003cimg src=\"https://snapcraft.io/static/images/badges/en/snap-store-white.svg\" alt=\"Get GNSS-SDR from the Snap Store\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n- **GNSS-SDR in embedded platforms**: we provide a Software Development Kit\n  (SDK) based on [OpenEmbedded](https://www.openembedded.org/wiki/Main_Page) for\n  cross-compiling GNSS-SDR in your desktop computer and for producing\n  executables that can run in embedded platforms, such as Xilinx's Zynq and\n  ZynqMP architectures, Raspberry Pi, and many others. Please check\n  [yocto-geniux](https://github.com/carlesfernandez/yocto-geniux) for\n  instructions on how to build bootable images.\n\n# Updating GNSS-SDR\n\nIf you cloned or forked GNSS-SDR some time ago, it is possible that some\ndeveloper has updated files at the Git repository. If you still have not done\nso, add the `upstream` repository to the list of remotes:\n\n```\n$ git remote add upstream https://github.com/gnss-sdr/gnss-sdr.git\n```\n\nand then you can update your working copy by doing:\n\n```\n$ git checkout main        # Switch to branch you want to update\n$ git pull upstream main   # Download the newest code from our repository\n```\n\nor, if you want to test the latest developments:\n\n```\n$ git checkout next\n$ git pull upstream next\n```\n\nBefore rebuilding the source code, it is safe (and recommended) to remove the\nremainders of old compilations, _e.g._:\n\n```\n$ rm -rf gnss-sdr/build/*\n```\n\nIf you are interested in contributing to the development of GNSS-SDR, please\ncheck out\n[how to do it](https://gnss-sdr.org/contribute/ \"How to contribute to GNSS-SDR source code\").\n\nThere is a more controlled way to upgrade your repository, which is to use the\nGit commands `fetch` and `merge`, as described in our\n[Git Tutorial](https://gnss-sdr.org/docs/tutorials/using-git/ \"Using Git\").\n\n# Getting started\n\n1. After building the code, you will find the `gnss-sdr` executable file at\n   gnss-sdr/install. You can make it available everywhere else by\n   `sudo make install`. Run the profilers `volk_profile` and\n   `volk_gnsssdr_profile` for testing all available VOLK kernels for each\n   architecture supported by your processor. This only has to be done once.\n2. In post-processing mode, you have to provide a captured GNSS signal file. 1.\n   The signal file can be easily recorded using the GNU Radio file sink in\n   `gr_complex\u003cfloat\u003e` mode. 2. You will need a GPS active antenna, a\n   [USRP](https://www.ettus.com/products/) and a suitable USRP daughter board to\n   receive GPS L1 C/A signals. GNSS-SDR requires to have at least 2 MHz of\n   bandwidth in 1.57542 GHz. (remember to enable the DC bias with the\n   daughterboard jumper). We use a\n   [DBSRX2](https://www.ettus.com/all-products/DBSRX2/) to do the task, but you\n   can try the newer Ettus' daughter boards as well. 3. The easiest way to\n   capture a signal file is to use the GNU Radio Companion GUI. Only two blocks\n   are needed: a USRP signal source connected to a complex float file sink. You\n   need to tune the USRP central frequency and decimation factor using the USRP\n   signal source properties box. We suggest using a decimation factor of 20 if\n   you use the USRP2. This will give you 100/20 = 5 MSPS which will be enough to\n   receive GPS L1 C/A signals. The front-end gain should also be configured. In\n   our test with the DBSRX2 we obtained good results with `G=50`. 4. Capture at\n   least 80 seconds of signal in open sky conditions. During the process, be\n   aware of USRP driver buffer underruns messages. If your hard disk is not fast\n   enough to write data at this speed you can capture it to a virtual RAM drive.\n   80 seconds of signal at 5 MSPS occupies less than 3 Gbytes using\n   `gr_complex\u003cfloat\u003e`. If you have no access to an RF front-end, you can\n   download a sample raw data file (that contains GPS and Galileo signals) from\n   [here](https://sourceforge.net/projects/gnss-sdr/files/data/).\n3. You are ready to configure the receiver to use your captured file among other\n   parameters:\n   1. The default configuration file resides at\n      [/usr/local/share/gnss-sdr/conf/default.conf](./conf/gnss-sdr.conf).\n   2. You need to review/modify at least the following settings:\n      - `SignalSource.filename=` (absolute or relative route to your GNSS signal\n        captured file)\n      - `GNSS-SDR.internal_fs_sps=` (captured file sampling rate in samples per\n        second)\n      - `SignalSource.sampling_frequency=` (captured file sampling rate in\n        samples per second)\n      - `SignalConditioner.sample_freq_in=` (captured file sampling rate in\n        samples per second)\n      - `SignalConditioner.sample_freq_out=` (captured file sampling rate in\n        samples per second)\n   3. The configuration file has in-line documentation, you can try to tune the\n      number of channels and several receiver parameters. Store your .conf file\n      in some working directory of your choice.\n4. Run the receiver invoking the configuration by\n   `$ gnss-sdr --config_file=/path/to/my_receiver.conf` The program reports the\n   current status in text mode, directly to the terminal window. If all goes\n   well, and GNSS-SDR is able to successfully track and decode at least 4\n   satellites, you will get PVT fixes. The program will write .kml, .geojson and\n   RINEX files in the folder from which `gnss-sdr` was run. In addition to the\n   console output, GNSS-SDR also writes log files at /tmp/ (configurable with\n   the commandline flag `./gnss-sdr --log_dir=/path/to/log`).\n\nFor more information, check out our\n[quick start guide](https://gnss-sdr.org/quick-start-guide/).\n\n# Using GNSS-SDR\n\nWith GNSS-SDR, you can define your own receiver, work with captured raw data or\nfrom an RF front-end, dump into files intermediate signals, or tune every single\nalgorithm used in the signal processing. All the configuration is done in a\nsingle file. Those configuration files reside at the [gnss-sdr/conf/](./conf/)\nfolder (or at /usr/local/share/gnss-sdr/conf if you installed the program). By\ndefault, the executable `gnss-sdr` will read the configuration available at\n`gnss-sdr/conf/gnss-sdr.conf` (or at (usr/local/share/gnss-sdr/conf/default.conf\nif you installed the program). You can edit that file to fit your needs, or even\nbetter, define a new `my_receiver.conf` file with your own configuration. This\nnew receiver can be generated by invoking gnss-sdr with the `--config_file` flag\npointing to your configuration file:\n\n```\n$ gnss-sdr --config_file=/path/to/my_receiver.conf\n```\n\nYou can use a single configuration file for processing different data files,\nspecifying the file to be processed with the `--signal_source` flag:\n\n```\n$ gnss-sdr --config_file=../conf/my_receiver.conf --signal_source=./my_captured_data.dat\n```\n\nThis will override the `SignalSource.filename` specified in the configuration\nfile.\n\n## Control plane\n\n![](./docs/doxygen/images/GeneralBlockDiagram.png)\n\nGNSS-SDR's main method initializes the logging library, processes the command\nline flags, if any, provided by the user and instantiates a\n[ControlThread](./src/core/receiver/control_thread.h) object. Its constructor\nreads the configuration file, creates a control queue, and creates a flowgraph\naccording to the configuration. Then, the program's main method calls the run()\nmethod of the instantiated object, an action that connects the flowgraph and\nstarts running it. After that, and until a stop message is received, it reads\ncontrol messages sent by the receiver's modules through a safe-thread queue and\nprocesses them. Finally, when a stop message is received, the main method\nexecutes the destructor of the ControlThread object, which deallocates memory,\ndoes other cleanup, and exits the program.\n\nThe [GNSSFlowgraph](./src/core/receiver/gnss_flowgraph.h) class is responsible\nfor preparing the graph of blocks according to the configuration, running it,\nmodifying it during run-time, and stopping it. Blocks are identified by their\nrole. This class knows which roles it has to instantiate and how to connect\nthem. It relies on the configuration to get the correct instances of the roles\nit needs and then it applies the connections between GNU Radio blocks to make\nthe graph ready to be started. The complexity related to managing the blocks and\nthe data stream is handled by GNU Radio's `gr::top_block` class. GNSSFlowgraph\nwraps the `gr::top_block` instance so we can take advantage of the\n`gnss_block_factory` (see below), the configuration system, and the processing\nblocks. This class is also responsible for applying changes to the configuration\nof the flowgraph during run-time, dynamically reconfiguring channels: it selects\nthe strategy for selecting satellites. This can range from a sequential search\nover all the satellites' ID to other more efficient approaches.\n\nThe Control Plane is in charge of creating a flowgraph according to the\nconfiguration and then managing the modules. Configuration allows users to\ndefine in an easy way their own custom receiver by specifying the flowgraph\n(type of signal source, number of channels, algorithms to be used for each\nchannel and each module, strategies for satellite selection, type of output\nformat, etc.). Since it is difficult to foresee what future module\nimplementations will be needed in terms of configuration, we used a very simple\napproach that can be extended without a major impact on the code. This can be\nachieved by simply mapping the names of the variables in the modules with the\nnames of the parameters in the configuration.\n\n### Configuration\n\nProperties are passed around within the program using the\n[ConfigurationInterface](./src/core/interfaces/configuration_interface.h) class.\nThere are two implementations of this interface:\n[FileConfiguration](./src/core/receiver/file_configuration.h) and\n[InMemoryConfiguration](./src/core/receiver/in_memory_configuration.h).\nFileConfiguration reads the properties (pairs of property name and value) from a\nfile and stores them internally. InMemoryConfiguration does not read from a\nfile; it remains empty after instantiation and property values and names are set\nusing the set property method. FileConfiguration is intended to be used in the\nactual GNSS-SDR application whereas InMemoryConfiguration is intended to be used\nin tests to avoid file-dependency in the file system. Classes that need to read\nconfiguration parameters will receive instances of ConfigurationInterface from\nwhere they will fetch the values. For instance, parameters related to\nSignalSource should look like this:\n\n```\nSignalSource.parameter1=value1\nSignalSource.parameter2=value2\n```\n\nThe name of these parameters can be anything but one reserved word:\nimplementation. This parameter indicates in its value the name of the class that\nhas to be instantiated by the factory for that role. For instance, if our signal\nsource is providing data already at baseband and thus we want to use the\nimplementation [Pass_Through](./src/algorithms/libs/pass_through.h) for module\nSignalConditioner, the corresponding line in the configuration file would be\n\n```\nSignalConditioner.implementation=Pass_Through\n```\n\nSince the configuration is just a set of property names and values without any\nmeaning or syntax, the system is very versatile and easily extendable. Adding\nnew properties to the system only implies modifications in the classes that will\nmake use of these properties. In addition, the configuration files are not\nchecked against any strict syntax so it is always in a correct status (as long\nas it contains pairs of property names and values in the\n[INI format](https://en.wikipedia.org/wiki/INI_file)).\n\n### GNSS block factory\n\nHence, the application defines a simple accessor class to fetch the\nconfiguration pairs of values and passes them to a factory class called\n[GNSSBlockFactory](./src/core/receiver/gnss_block_factory.h). This factory\ndecides, according to the configuration, which class needs to be instantiated\nand which parameters should be passed to the constructor. Hence, the factory\nencapsulates the complexity of blocks' instantiation. With that approach, adding\na new block that requires new parameters will be as simple as adding the block\nclass and modifying the factory to be able to instantiate it. This loose\ncoupling between the blocks' implementations and the syntax of the configuration\nenables extending the application capacities to a high degree. It also allows\nproducing fully customized receivers, for instance a testbed for acquisition\nalgorithms, and to place observers at any point of the receiver chain.\n\nMore information can be found at the\n[Control Plane page](https://gnss-sdr.org/docs/control-plane/).\n\n## Signal Processing plane\n\nGNU Radio's class `gr::basic_block` is the abstract base class for all signal\nprocessing blocks, a bare abstraction of an entity that has a name and a set of\ninputs and outputs. It is never instantiated directly; rather, this is the\nabstract parent class of both `gr::hier_block2`, which is a recursive container\nthat adds or removes processing or hierarchical blocks to the internal graph,\nand `gr::block`, which is the abstract base class for all the processing blocks.\n\n![](./docs/doxygen/images/ClassHierarchy.png)\n\nA signal processing flow is constructed by creating a tree of hierarchical\nblocks, which at any level may also contain terminal nodes that actually\nimplement signal processing functions.\n\nClass `gr::top_block` is the top-level hierarchical block representing a\nflowgraph. It defines GNU Radio runtime functions used during the execution of\nthe program: run(), start(), stop(), wait(), etc. A subclass called\n[GNSSBlockInterface](./src/core/interfaces/gnss_block_interface.h) is the common\ninterface for all the GNSS-SDR modules. It defines pure virtual methods, that\nare required to be implemented by a derived class.\n\nSubclassing GNSSBlockInterface, we defined interfaces for the GNSS receiver\nblocks depicted in the figure above. This hierarchy provides the definition of\ndifferent algorithms and different implementations, which will be instantiated\naccording to the configuration. This strategy allows multiple implementations to\nshare a common interface, achieving the objective of decoupling interfaces from\nimplementations: it defines a family of algorithms, encapsulates each one, and\nmakes them interchangeable. Hence, we let the algorithm vary independently of\nthe program that uses it.\n\nInternally, GNSS-SDR makes use of the complex data types defined by\n[VOLK](https://www.libvolk.org/ \"Vector-Optimized Library of Kernels home\").\nThey are fundamental for handling sample streams in which samples are complex\nnumbers with real and imaginary components of 8, 16, or 32 bits, common formats\ndelivered by GNSS (and generic SDR) radio frequency front-ends. The following\nlist shows the data type names that GNSS-SDR exposes through the configuration\nfile:\n\n- **`byte`**: Signed integer, 8-bit two's complement number ranging from -128\n  to 127. C++ type name: `int8_t`.\n- **`short`**: Signed integer, 16-bit two's complement number ranging from\n  -32768 to 32767. C++ type name: `int16_t` .\n- **`float`**: Defines numbers with fractional parts, can represent values\n  ranging from approx. 1.5e-45 to 3.4e+38 with a precision of 7 digits (32\n  bits). C++ type name: `float`.\n- **`ibyte`**: Interleaved (I\u0026Q) stream of samples of type `byte`. C++ type\n  name: `int8_t`.\n- **`ishort`**: Interleaved (I\u0026Q) stream of samples of type `short`. C++ type\n  name: `int16_t`.\n- **`cbyte`**: Complex samples, with real and imaginary parts of type `byte`.\n  C++ type name: `lv_8sc_t`.\n- **`cshort`**: Complex samples, with real and imaginary parts of type `short`.\n  C++ type name: `lv_16sc_t`.\n- **`gr_complex`**: Complex samples, with real and imaginary parts of type\n  `float`. C++ type name: `std::complex\u003cfloat\u003e`.\n\nMore information about the available processing blocks and their configuration\nparameters can be found at the\n[Signal Processing Blocks documentation page](https://gnss-sdr.org/docs/sp-blocks/).\n\n### Signal Source\n\nThe inputs of a software receiver are the raw bits that come out from the\nfront-end's analog-to-digital converter (ADC). Those bits can be read from a\nfile stored in the hard disk or directly in real-time from a hardware device\nthrough USB or Ethernet buses.\n\nThe Signal Source module is in charge of implementing the hardware driver, that\nis, the portion of the code that communicates with the RF front-end and receives\nthe samples coming from the ADC. This communication is usually performed through\nUSB or Ethernet buses. Since real-time processing requires a highly optimized\nimplementation of the whole receiver, this module also allows reading samples\nfrom a file stored in a hard disk, and thus processing without time constraints.\nRelevant parameters of those samples are the intermediate frequency (or baseband\nI\u0026Q components), the sampling rate, and the number of bits per sample, which\nmust be specified by the user in the configuration file.\n\nThis module also performs bit-depth adaptation, since most of the existing RF\nfront-ends provide samples quantized with 2 or 3 bits, while operations inside\nthe processor are performed on 32- or 64-bit words, depending on its\narchitecture. Although there are implementations of the most intensive\ncomputational processes (mainly correlation) that take advantage of specific\ndata types and architectures for the sake of efficiency, the approach is\nprocessor-specific and hardly portable. We suggest keeping signal samples in\nstandard data types and letting the compiler select the best library version\n(implemented using SIMD or any other processor-specific technology) of the\nrequired routines for a given processor.\n\n**_Example: File Signal Source_**\n\nThe user can configure the receiver for reading from a file, setting in the\nconfiguration file the data file location, sample format, and the sampling\nfrequency and intermediate frequency at what the signal was originally captured.\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=File_Signal_Source\nSignalSource.filename=/home/user/gnss-sdr/data/my_capture.dat\nSignalSource.item_type=gr_complex\nSignalSource.sampling_frequency=4000000 ; Sampling frequency in samples per second (Sps)\n```\n\nType `gr_complex` refers to a GNU Radio typedef equivalent to\n`std::complex\u003cfloat\u003e`. In order to save some storage space, you might want to\nstore your signal in a more efficient format such as an I/Q interleaved `short`\ninteger sample stream. In that case, change the corresponding line to:\n\n```\nSignalSource.item_type=ishort\n```\n\nIn this latter case, you will need to convert the interleaved I/Q samples to a\ncomplex stream via Data Type Adapter block (see below).\n\n**_Example: Two-bit packed file source_**\n\nSometimes, samples are stored in files with a format that is not in the list of\n_native_ types supported by the `File_Signal_Source` implementation (i.e, it is\nnot among `byte`, `ibyte`, `short`, `ishort`, `float`, or `gr_complex`). This is\nthe case of 2-bit samples, which is a common format delivered by GNSS RF\nfront-ends. The `Two_Bit_Packed_File_Signal_Source` implementation allows\nreading two-bit length samples from a file. The data is assumed to be packed as\nbytes `item_type=byte` or shorts `item_type=short` so that there are 4 two-bit\nsamples in each byte. The two-bit values are assumed to have the following\ninterpretation:\n\n| **b_1** | **b_0** | **Value** |\n| :-----: | :-----: | :-------: |\n|    0    |    0    |    +1     |\n|    0    |    1    |    +3     |\n|    1    |    0    |    -3     |\n|    1    |    1    |    -1     |\n\nWithin a byte the samples may be packed in big-endian `big_endian_bytes=true`\n(if the most significant byte value is stored at the memory location with the\nlowest address, the next byte value in significance is stored at the following\nmemory location, and so on) or little-endian `big_endian_bytes=false` (if the\nleast significant byte value is at the lowest address, and the other bytes\nfollow in increasing order of significance). If the order is big-endian then the\nmost significant two bits will form the first sample output. Otherwise, the\nleast significant two bits will be used.\n\nAdditionally, the samples may be either real `sample_type=real`, or complex. If\nthe sample type is complex, then the samples are either stored in the order:\nreal, imag, real, imag, ... `sample_type=iq` or in the order: imag, real, imag,\nreal, ... `sample_type=qi`.\n\nFinally, if the data is stored as shorts `item_type=short`, then it may be\nstored in either big-endian `big_endian_items=true` or little-endian\n`big_endian_items=false`. If the shorts are big-endian then the 2nd byte in each\nshort is output first.\n\nThe output data type is either `float` or `gr_complex` depending on whether or\nnot `sample_type` is real. Example:\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=Two_Bit_Packed_File_Signal_Source\nSignalSource.filename=/data/my_capture.datz\nSignalSource.item_type=short\nSignalSource.sampling_frequency=60000000\nSignalSource.freq=1575468750\nSignalSource.samples=6000000000  ; Notice that 0 indicates the entire file.\nSignalSource.repeat=false\nSignalSource.dump=false\nSignalSource.dump_filename=./signal_source.dat\nSignalSource.enable_throttle_control=false\nSignalSource.sample_type=iq\nSignalSource.big_endian_items=true\nSignalSource.big_endian_bytes=false\n```\n\n**_Example: UHD Signal Source_**\n\nThe user may prefer to use a [UHD](https://files.ettus.com/manual/)-compatible\nRF front-end and try real-time processing. For instance, for a USRP1 + DBSRX\ndaughterboard, use:\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=UHD_Signal_Source\nSignalSource.item_type=gr_complex\nSignalSource.sampling_frequency=4000000 ; Sampling frequency in [Hz]\nSignalSource.freq=1575420000 ; RF front-end center frequency in [Hz]\nSignalSource.gain=60 ; Front-end gain in dB\nSignalSource.subdevice=B:0 ; UHD subdevice specification (for USRP1 use A:0 or B:0, for USRP B210 use A:0)\n```\n\n**_Example: Configuring the USRP X300/X310 with two front-ends for receiving\nsignals in L1 and L2 bands_**\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=UHD_Signal_Source\nSignalSource.device_address=192.168.40.2 ; Put your USRP IP address here\nSignalSource.item_type=gr_complex\nSignalSource.RF_channels=2\nSignalSource.sampling_frequency=4000000\nSignalSource.subdevice=A:0 B:0\n\n;######### RF Channels specific settings ######\nSignalSource.freq0=1575420000\nSignalSource.gain0=50\nSignalSource.samples0=0\nSignalSource.dump0=false\n\nSignalSource.freq1=1227600000\nSignalSource.gain1=50\nSignalSource.samples1=0\nSignalSource.dump1=false\n```\n\n**_Example: OsmoSDR-compatible Signal Source_**\n\n[OsmoSDR](https://osmocom.org/projects/sdr) is a small form-factor, inexpensive\nsoftware defined radio project. It provides a driver for several front-ends,\nsuch as [RTL-based dongles](https://www.rtl-sdr.com/tag/v3/),\n[HackRF](https://greatscottgadgets.com/hackrf/),\n[bladeRF](https://www.nuand.com/),\n[LimeSDR](https://myriadrf.org/projects/limesdr/),\n[etc](https://github.com/osmocom/gr-osmosdr/blob/master/README). Note that not\nall the OsmoSDR-compatible devices can work as radio frequency front-ends for\nproper GNSS signal reception, please check the specifications. For suitable RF\nfront-ends, you can use:\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=Osmosdr_Signal_Source\nSignalSource.item_type=gr_complex\nSignalSource.sampling_frequency=2000000\nSignalSource.freq=1575420000\nSignalSource.rf_gain=40\nSignalSource.if_gain=30\nSignalSource.enable_throttle_control=false\nSignalSource.osmosdr_args=hackrf,bias=1\n```\n\nFor [RTL-SDR Blog V3](https://www.rtl-sdr.com/tag/v3/) dongles, the arguments\nare:\n\n```\nSignalSource.osmosdr_args=rtl,bias=1\n```\n\nand for [LimeSDR](https://myriadrf.org/projects/limesdr/):\n\n```\nSignalSource.osmosdr_args=driver=lime,soapy=0\n```\n\nIn case of using a Zarlink's RTL2832 based DVB-T receiver, you can even use the\n`rtl_tcp` I/Q server in order to use the USB dongle remotely. In a terminal,\ntype:\n\n```\n$ rtl_tcp -a 127.0.0.1 -p 1234 -f 1575420000 -g 0 -s 2000000\n```\n\nand use the following configuration:\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=RtlTcp_Signal_Source\nSignalSource.item_type=gr_complex\nSignalSource.sampling_frequency=1200000\nSignalSource.freq=1575420000\nSignalSource.gain=40\nSignalSource.rf_gain=40\nSignalSource.if_gain=30\nSignalSource.AGC_enabled=false\nSignalSource.samples=0\nSignalSource.enable_throttle_control=false\nSignalSource.address=127.0.0.1\nSignalSource.port=1234\nSignalSource.swap_iq=false\nSignalSource.repeat=false\nSignalSource.dump=false\nSignalSource.dump_filename=./signal_source.dat\n```\n\nExample for a dual-frequency receiver:\n\n```\n;######### SIGNAL_SOURCE CONFIG ############\nSignalSource.implementation=UHD_Signal_Source\nSignalSource.device_address=192.168.40.2 ; Put your USRP IP address here\nSignalSource.item_type=gr_complex\nSignalSource.RF_channels=2\nSignalSource.sampling_frequency=4000000\nSignalSource.subdevice=A:0 B:0\n\n;######### RF Channels specific settings ######\nSignalSource.freq0=1575420000\nSignalSource.gain0=50\nSignalSource.samples0=0\nSignalSource.dump0=false\n\nSignalSource.freq1=1227600000\nSignalSource.gain1=50\nSignalSource.samples1=0\nSignalSource.dump1=false\n```\n\nMore documentation and examples are available at the\n[Signal Source Blocks page](https://gnss-sdr.org/docs/sp-blocks/signal-source/).\n\n### Signal Conditioner\n\n![](./docs/doxygen/images/SignalConditioner.png)\n\nThe signal conditioner is in charge of resampling the signal and delivering a\nreference sample rate to the downstream processing blocks, acting as a facade\nbetween the signal source and the synchronization channels, providing a\nsimplified interface to the input signal. In the case of multiband front-ends,\nthis module would be in charge of providing a separated data stream for each\nband.\n\nIf your signal source is providing baseband signal samples of type `gr_complex`\nat 4 Msps, you can bypass the Signal Conditioner block by:\n\n```\nSignalConditioner.implementation=Pass_Through\n```\n\nIf you need to adapt some aspect of your signal, you can enable the Signal\nConditioner and configure three internal blocks: a data type adapter, an input\nsignal, and a resampler.\n\n```\n;#[Signal_Conditioner] enables this block. Then you have to configure [DataTypeAdapter], [InputFilter] and [Resampler] blocks\nSignalConditioner.implementation=Signal_Conditioner\n```\n\nMore documentation at the\n[Signal Conditioner Blocks page](https://gnss-sdr.org/docs/sp-blocks/signal-conditioner/).\n\n#### Data type adapter\n\nThis block changes the type of input data samples. If your signal source\ndelivers data samples of type `short`, you can use this block to convert them to\n`gr_complex` like this:\n\n```\n;######### DATA_TYPE_ADAPTER CONFIG ############\n;#implementation: [Pass_Through] disables this block\nDataTypeAdapter.implementation=Ishort_To_Complex\n```\n\nMore documentation at the\n[Data Type Adapter Blocks page](https://gnss-sdr.org/docs/sp-blocks/data-type-adapter/).\n\n#### Input filter\n\nThis block filters the input data. It can be combined with frequency translation\nfor IF signals. The computation of the filter taps is based on parameters of GNU\nRadio's function\n[pm_remez](https://www.gnuradio.org/doc/doxygen/pm__remez_8h.html), which\ncalculates the optimal (in the Chebyshev/minimax sense) FIR filter impulse\nresponse given a set of band edges, the desired response on those bands, and the\nweight given to the error in those bands.\n\nThe block can be configured like this:\n\n```\n;######### INPUT_FILTER CONFIG ############\n;#implementation: Use [Pass_Through] or [Fir_Filter] or [Freq_Xlating_Fir_Filter]\n;#[Pass_Through] disables this block\n;#[Fir_Filter] enables a FIR Filter\n;#[Freq_Xlating_Fir_Filter] enables FIR filter and a composite frequency translation that shifts IF down to zero Hz.\nInputFilter.implementation=Freq_Xlating_Fir_Filter\nInputFilter.dump=false ; #dump: Dump the filtered data to a file.\nInputFilter.dump_filename=./input_filter.dat ; #dump_filename: Log path and filename.\nInputFilter.input_item_type=gr_complex\nInputFilter.output_item_type=gr_complex\nInputFilter.taps_item_type=float\nInputFilter.number_of_taps=5 ; #number_of_taps: Number of taps in the filter. Increasing this parameter increases the processing time\nInputFilter.number_of_bands=2 ; #number_of_bands: Number of frequency bands in the filter.\n; Frequency is in the range [0, 1], with 1 being the Nyquist frequency (Fs/2)\n; The number of band_begin and band_end elements must match the number of bands\nInputFilter.band1_begin=0.0\nInputFilter.band1_end=0.85\nInputFilter.band2_begin=0.90\nInputFilter.band2_end=1.0\n\n;#ampl: desired amplitude at the band edges.\n;#The number of ampl_begin and ampl_end elements must match the number of bands\nInputFilter.ampl1_begin=1.0\nInputFilter.ampl1_end=1.0\nInputFilter.ampl2_begin=0.0\nInputFilter.ampl2_end=0.0\n\n;#band_error: weighting applied to each band (usually 1).\n;#The number of band_error elements must match the number of bands\nInputFilter.band1_error=1.0\nInputFilter.band2_error=1.0\n\n;#filter_type: one of \"bandpass\", \"hilbert\" or \"differentiator\"\nInputFilter.filter_type=bandpass\n\n;#grid_density: determines how accurately the filter will be constructed.\n;The minimum value is 16; higher values are slower to compute the filter.\nInputFilter.grid_density=16\n\n;#The following options are used only in Freq_Xlating_Fir_Filter implementation.\n;#InputFilter.IF is the intermediate frequency (in Hz) shifted down to zero Hz\nInputFilter.sampling_frequency=4000000\nInputFilter.IF=0\nInputFilter.decimation_factor=1\n```\n\nMore documentation at the\n[Input Filter Blocks page](https://gnss-sdr.org/docs/sp-blocks/input-filter/).\n\n#### Resampler\n\nThis block resamples the input data stream. The `Direct_Resampler` block\nimplements a nearest neighbourhood interpolation:\n\n```\n;######### RESAMPLER CONFIG ############\n;#implementation: Use [Pass_Through] or [Direct_Resampler]\n;#[Pass_Through] disables this block\nResampler.implementation=Direct_Resampler\nResampler.dump=false ; Dumps the resampled data to a file.\nResampler.dump_filename=./resampler.dat ; log path and filename.\nResampler.item_type=gr_complex\nResampler.sample_freq_in=8000000 ; sample frequency of the input signal\nResampler.sample_freq_out=4000000 ; desired sample frequency of the output signal\n```\n\nMore documentation at the\n[Resampler Blocks page](https://gnss-sdr.org/docs/sp-blocks/resampler/).\n\n### Channel\n\nA channel encapsulates all signal processing devoted to a single satellite.\nThus, it is a large composite object which encapsulates the acquisition,\ntracking, and navigation data decoding modules. As a composite object, it can be\ntreated as a single entity, meaning that it can be easily replicated. Since the\nnumber of channels is selectable by the user in the configuration file, this\napproach helps to improve the scalability and maintainability of the receiver.\n\nEach channel must be assigned to a GNSS signal, according to the following\nidentifiers:\n\n| **Signal**     | **Identifier** |\n| :------------- | :------------: |\n| GPS L1 C/A     |       1C       |\n| Galileo E1b/c  |       1B       |\n| Glonass L1 C/A |       1G       |\n| Beidou B1I     |       B1       |\n| Galileo E6B    |       E6       |\n| Beidou B3I     |       B3       |\n| GPS L2 L2C(M)  |       2S       |\n| Glonass L2 C/A |       2G       |\n| GPS L5         |       L5       |\n| Galileo E5a    |       5X       |\n| Galileo E5b    |       7X       |\n\nExample: Eight GPS L1 C/A channels.\n\n```\n;######### CHANNELS GLOBAL CONFIG ############\nChannels_1C.count=8 ; Number of available GPS L1 C/A channels.\nChannels_1B.count=0 ; Number of available Galileo E1B channels.\nChannels.in_acquisition=1 ; Number of channels simultaneously acquiring\nChannel.signal=1C ;\n```\n\nExample: Four GPS L1 C/A and four Galileo E1B channels.\n\n```\n;######### CHANNELS GLOBAL CONFIG ############\nChannels_1C.count=4 ; Number of available GPS L1 C/A channels.\nChannels_1B.count=4 ; Number of available Galileo E1B channels.\nChannels.in_acquisition=1 ; Number of channels simultaneously acquiring\nChannel0.signal=1C ;\nChannel1.signal=1C ;\nChannel2.signal=1C ;\nChannel3.signal=1C ;\nChannel4.signal=1B ;\nChannel5.signal=1B ;\nChannel6.signal=1B ;\nChannel7.signal=1B ;\n```\n\nThis module is also in charge of managing the interplay between acquisition and\ntracking. Acquisition can be initialized in several ways, depending on the prior\ninformation available (called cold start when the receiver has no information\nabout its position nor the satellites' almanac; warm start when a rough location\nand the approximate time of day are available, and the receiver has a recently\nrecorded almanac broadcast; or hot start when the receiver was tracking a\nsatellite and the signal line of sight broke for a short period of time, but the\nephemeris and almanac data is still valid, or this information is provided by\nother means), and an acquisition process can finish deciding that the satellite\nis not present, that longer integration is needed in order to confirm the\npresence of the satellite, or declaring the satellite present. In the latter\ncase, the acquisition process should stop and trigger the tracking module with\ncoarse estimations of the synchronization parameters. The mathematical\nabstraction used to design this logic is known as a finite state machine (FSM),\nwhich is a behavior model composed of a finite number of states, transitions\nbetween those states, and actions.\n\nThe abstract class [ChannelInterface](./src/core/interfaces/channel_interface.h)\nrepresents an interface to a channel GNSS block. Check\n[Channel](./src/algorithms/channel/adapters/channel.h) for an actual\nimplementation.\n\nMore documentation at the\n[Channels page](https://gnss-sdr.org/docs/sp-blocks/channels/).\n\n#### Acquisition\n\nThe first task of a GNSS receiver is to detect the presence or absence of\nin-view satellites. This is done by the acquisition system process, which also\nprovides a coarse estimation of two signal parameters: the frequency shift with\nrespect to the nominal frequency, and a delay term that allows the receiver to\ncreate a local code aligned with the incoming code.\n[AcquisitionInterface](./src/core/interfaces/acquisition_interface.h) is the\ncommon interface for all the acquisition algorithms and their corresponding\nimplementations. Algorithms' interface, which may vary depending on the use of\ninformation external to the receiver, such as in Assisted GNSS, is defined in\nclasses referred to as _adapters_. These adapters wrap the GNU Radio blocks\ninterface into a compatible interface expected by AcquisitionInterface. This\nallows the use of existing GNU Radio blocks derived from `gr::block`, and\nensures that newly developed implementations will also be reusable in other GNU\nRadio-based applications. Moreover, it adds still another layer of abstraction,\nsince each given acquisition algorithm can have different implementations (for\ninstance using different numerical libraries). In such a way, implementations\ncan be continuously improved without having any impact neither on the algorithm\ninterface nor the general acquisition interface.\n\nCheck\n[GpsL1CaPcpsAcquisition](./src/algorithms/acquisition/adapters/gps_l1_ca_pcps_acquisition.h)\nand\n[GalileoE1PcpsAmbiguousAcquisition](./src/algorithms/acquisition/adapters/galileo_e1_pcps_ambiguous_acquisition.h)\nfor examples of adapters from a Parallel Code Phase Search (PCPS) acquisition\nblock, and\n[pcps_acquisition_cc](./src/algorithms/acquisition/gnuradio_blocks/pcps_acquisition_cc.h)\nfor an example of a block implementation. The source code of all the available\nacquisition algorithms is located at:\n\n```\n  |-gnss-sdr\n  |---src\n  |-----algorithms\n  |-------acquisition\n  |---------adapters          \u003c- Adapters of the processing blocks to an AcquisitionInterface\n  |---------gnuradio_blocks   \u003c- Signal processing blocks implementation\n```\n\nThe user can select a given implementation for the algorithm to be used in each\nreceiver channel, as well as their parameters, in the configuration file. For a\nGPS L1 C/A receiver:\n\n```\n;######### ACQUISITION GLOBAL CONFIG ############\nAcquisition_1C.implementation=GPS_L1_CA_PCPS_Acquisition ; Acquisition algorithm selection for this channel\nAcquisition_1C.item_type=gr_complex\nAcquisition_1C.coherent_integration_time_ms=1 ; Signal block duration for the acquisition signal detection [ms]\nAcquisition_1C.threshold=2.5 ; Acquisition threshold\nAcquisition_1C.pfa=0.01 ; Acquisition false alarm probability. This option overrides the threshold option.\nAcquisition_1C.doppler_max=10000 ; Maximum expected Doppler shift [Hz]\nAcquisition_1C.doppler_step=500 ; Doppler step in the grid search [Hz]\nAcquisition_1C.dump=false ; Enables internal data file logging [true] or [false]\nAcquisition_1C.dump_filename=./acq_dump.dat ; Log path and filename\n```\n\nand, for Galileo E1B channels:\n\n```\n;######### GALILEO ACQUISITION CONFIG ############\nAcquisition_1B.implementation=Galileo_E1_PCPS_Ambiguous_Acquisition\nAcquisition_1B.item_type=gr_complex\nAcquisition_1B.coherent_integration_time_ms=4\nAcquisition_1B.pfa=0.008\nAcquisition_1B.doppler_max=15000\nAcquisition_1B.doppler_step=125\nAcquisition_1B.dump=false\nAcquisition_1B.dump_filename=./acq_dump.dat\n```\n\nMore documentation at the\n[Acquisition Blocks page](https://gnss-sdr.org/docs/sp-blocks/acquisition/).\n\n#### Tracking\n\nWhen a satellite is declared present, the parameters estimated by the\nacquisition module are then fed to the receiver tracking module, which\nrepresents the second stage of the signal processing unit, aiming to perform a\nlocal search for accurate estimates of code delay and carrier phase, and\nfollowing their eventual variations.\n\nAgain, a class hierarchy consisting of a\n[TrackingInterface](./src/core/interfaces/tracking_interface.h) class and\nsubclasses implementing algorithms provides a way of testing different\napproaches, with full access to their parameters. Check\n[GpsL1CaDllPllTracking](./src/algorithms/tracking/adapters/gps_l1_ca_dll_pll_tracking.h)\nor\n[GalileoE1DllPllVemlTracking](./src/algorithms/tracking/adapters/galileo_e1_dll_pll_veml_tracking.h)\nfor examples of adapters, and\n[Gps_L1_Ca_Dll_Pll_Tracking_cc](./src/algorithms/tracking/gnuradio_blocks/gps_l1_ca_dll_pll_tracking_cc.h)\nfor an example of a signal processing block implementation. There are also\navailable some useful classes and functions for signal tracking; take a look at\n[cpu_multicorrelator.h](./src/algorithms/tracking/libs/cpu_multicorrelator.h),\n[lock_detectors.h](./src/algorithms/tracking/libs/lock_detectors.h),\n[tracking_discriminators.h](./src/algorithms/tracking/libs/tracking_discriminators.h)\nor\n[tracking_2nd_DLL_filter.h](./src/algorithms/tracking/libs/tracking_2nd_DLL_filter.h).\n\nThe source code of all the available tracking algorithms is located at:\n\n```\n  |-gnss-sdr\n  |---src\n  |-----algorithms\n  |-------tracking\n  |---------adapters          \u003c- Adapters of the processing blocks to a TrackingInterface\n  |---------gnuradio_blocks   \u003c- Signal processing blocks implementation\n  |---------libs              \u003c- libraries of tracking objects (e.g. correlators, discriminators, and so on)\n```\n\nThe user can select a given implementation for the algorithm to be used in all\nthe tracking blocks, as well as its parameters, in the configuration file. For\ninstance, for GPS l1 channels:\n\n```\n;######### TRACKING GPS L1 CONFIG ############\nTracking_1C.implementation=GPS_L1_CA_DLL_PLL_Tracking\nTracking_1C.item_type=gr_complex\nTracking_1C.pll_bw_hz=50.0 ; PLL loop filter bandwidth [Hz]\nTracking_1C.dll_bw_hz=2.0 ; DLL loop filter bandwidth [Hz]\nTracking_1C.pll_filter_order=3 ; PLL loop filter order [2] or [3]\nTracking_1C.dll_filter_order=2 ; DLL loop filter order [1], [2] or [3]\nTracking_1C.early_late_space_chips=0.5 ; correlator early-late space [chips].\nTracking_1C.dump=false ; Enable internal binary data file logging [true] or [false]\nTracking_1C.dump_filename=./tracking_ch_ ; Log path and filename. Notice that the tracking channel will add \"x.dat\" where x is the channel number.\n```\n\nand, for Galileo E1B channels:\n\n```\n;######### TRACKING GALILEO E1B CONFIG ############\nTracking_1B.implementation=Galileo_E1_DLL_PLL_VEML_Tracking\nTracking_1B.item_type=gr_complex\nTracking_1B.pll_bw_hz=15.0;\nTracking_1B.dll_bw_hz=2.0;\nTracking_1B.pll_filter_order=3 ; PLL loop filter order [2] or [3]\nTracking_1B.dll_filter_order=2 ; DLL loop filter order [1], [2] or [3]\nTracking_1B.early_late_space_chips=0.15;\nTracking_1B.very_early_late_space_chips=0.6;\nTracking_1B.dump=false\nTracking_1B.dump_filename=./veml_tracking_ch_\n```\n\nMore documentation at the\n[Tracking Blocks page](https://gnss-sdr.org/docs/sp-blocks/tracking/).\n\n#### Decoding of the navigation message\n\nMost of GNSS signal links are modulated by a navigation message containing the\ntime the message was transmitted, orbital parameters of satellites (also known\nas ephemeris), and an almanac (information about the general system health,\nrough orbits of all satellites in the network as well as data related to error\ncorrection). Navigation data bits are structured in words, pages, subframes,\nframes, and superframes. Sometimes, bits corresponding to a single parameter are\nspread over different words, and values extracted from different frames are\nrequired for proper decoding. Some words are for synchronization purposes,\nothers for error control, and others contain actual information. There are also\nerror control mechanisms, from parity checks to forward error correction (FEC)\nencoding and interleaving, depending on the system. All this decoding complexity\nis managed by a finite state machine.\n\nThe common interface is\n[TelemetryDecoderInterface](./src/core/interfaces/telemetry_decoder_interface.h).\nCheck\n[GpsL1CaTelemetryDecoder](./src/algorithms/telemetry_decoder/adapters/gps_l1_ca_telemetry_decoder.h)\nfor an example of the GPS L1 NAV message decoding adapter, and\n[gps_l1_ca_telemetry_decoder_cc](./src/algorithms/telemetry_decoder/gnuradio_blocks/gps_l1_ca_telemetry_decoder_cc.h)\nfor an actual implementation of a signal processing block. Configuration\nexample:\n\n```\n;######### TELEMETRY DECODER CONFIG ############\nTelemetryDecoder_1C.implementation=GPS_L1_CA_Telemetry_Decoder\nTelemetryDecoder_1C.dump=false\n```\n\nIn case you are configuring a multi-system receiver, you will need to decimate\nthe one with the fastest code rate in order to get both data streams\nsynchronized. For instance, for hybrid GPS L1 / Galileo E1B receivers:\n\n```\n;######### TELEMETRY DECODER GPS L1 CONFIG ############\nTelemetryDecoder_1C.implementation=GPS_L1_CA_Telemetry_Decoder\nTelemetryDecoder_1C.dump=false\n\n;######### TELEMETRY DECODER GALILEO E1B CONFIG ############\nTelemetryDecoder_1B.implementation=Galileo_E1B_Telemetry_Decoder\nTelemetryDecoder_1B.dump=false\n```\n\nMore documentation at the\n[Telemetry Decoder Blocks page](https://gnss-sdr.org/docs/sp-blocks/telemetry-decoder/).\n\n### Observables\n\nGNSS systems provide different kinds of observations. The most commonly used are\nthe code observations, also called pseudoranges. The _pseudo_ comes from the\nfact that on the receiver side the clock error is unknown and thus the\nmeasurement is not a pure range observation. High-accuracy applications also use\nthe carrier phase observations, which are based on measuring the difference\nbetween the carrier phase transmitted by the GNSS satellites and the phase of\nthe carrier generated in the receiver. Both observables are computed from the\noutputs of the tracking module and the decoding of the navigation message. This\nmodule collects all the data provided by every tracked channel, aligns all\nreceived data into a coherent set, and computes the observables.\n\nThe common interface is\n[ObservablesInterface](./src/core/interfaces/observables_interface.h).\n\nConfiguration example:\n\n```\n;######### OBSERVABLES CONFIG ############\nObservables.implementation=Hybrid_Observables\nObservables.dump=false\nObservables.dump_filename=./observables.dat\n```\n\nMore documentation at the\n[Observables Blocks page](https://gnss-sdr.org/docs/sp-blocks/observables/).\n\n### Computation of Position, Velocity, and Time\n\nAlthough data processing for obtaining high-accuracy PVT solutions is out of the\nscope of GNSS-SDR, we provide a module that can compute position fixes (stored\nin GIS-friendly formats such as [GeoJSON](https://tools.ietf.org/html/rfc7946),\n[GPX](https://www.topografix.com/gpx.asp), and\n[KML](https://www.opengeospatial.org/standards/kml), or transmitted via serial\nport as [NMEA 0183](https://en.wikipedia.org/wiki/NMEA_0183) messages), and\nleaves room for more sophisticated positioning methods by storing observables\nand navigation data in [RINEX](https://en.wikipedia.org/wiki/RINEX) files (v2.11\nor v3.02), and generating\n[RTCM](https://www.rtcm.org/ \"Radio Technical Commission for Maritime Services\")\n3.2 messages that can be disseminated through the Internet in real-time.\n\nThe common interface is [PvtInterface](./src/core/interfaces/pvt_interface.h).\n\nConfiguration example:\n\n```\n;######### PVT CONFIG ############\nPVT.implementation=RTKLIB_PVT\nPVT.positioning_mode=Single      ; options: Single, Static, Kinematic, PPP_Static, PPP_Kinematic\nPVT.iono_model=Broadcast         ; options: OFF, Broadcast\nPVT.trop_model=Saastamoinen      ; options: OFF, Saastamoinen\nPVT.rinex_version=2              ; options: 2 or 3\nPVT.output_rate_ms=100           ; Period in [ms] between two PVT outputs\nPVT.display_rate_ms=500          ; Position console print (std::out) interval [ms].\nPVT.nmea_dump_filename=./gnss_sdr_pvt.nmea ; NMEA log path and filename\nPVT.flag_nmea_tty_port=false     ; Enables the NMEA log to a serial TTY port\nPVT.nmea_dump_devname=/dev/pts/4 ; serial device descriptor for NMEA logging\nPVT.flag_rtcm_server=true        ; Enables or disables a TCP/IP server dispatching RTCM messages\nPVT.flag_rtcm_tty_port=false     ; Enables the RTCM log to a serial TTY port\nPVT.rtcm_dump_devname=/dev/pts/1 ; serial device descriptor for RTCM logging\nPVT.rtcm_tcp_port=2101\nPVT.rtcm_MT1019_rate_ms=5000\nPVT.rtcm_MT1045_rate_ms=5000\nPVT.rtcm_MT1097_rate_ms=1000\nPVT.rtcm_MT1077_rate_ms=1000\n```\n\n**Notes on the output formats:**\n\n- **GeoJSON** is a geospatial data interchange format based on JavaScript Object\n  Notation (JSON) supported by numerous mapping and GIS software packages,\n  including [OpenLayers](https://openlayers.org),\n  [Leaflet](https://leafletjs.com), [MapServer](https://mapserver.org/),\n  [GeoServer](https://geoserver.org/),\n  [GeoDjango](https://www.djangoproject.com), [GDAL](https://gdal.org/), and\n  [CartoDB](https://cartodb.com). It is also possible to use GeoJSON with\n  [PostGIS](https://postgis.net/) and [Mapnik](https://mapnik.org/), both of\n  which handle the format via the GDAL OGR conversion library. The\n  [Google Maps Javascript API](https://developers.google.com/maps/documentation/javascript/)\n  v3 directly supports the\n  [integration of GeoJSON data layers](https://developers.google.com/maps/documentation/javascript/examples/layer-data-simple),\n  and\n  [GitHub also supports GeoJSON rendering](https://github.com/blog/1528-there-s-a-map-for-that).\n\n- **KML** (Keyhole Markup Language) is an XML grammar used to encode and\n  transport representations of geographic data for display in an earth browser.\n  KML is an open standard officially named the OpenGIS KML Encoding Standard\n  (OGC KML), and it is maintained by the Open Geospatial Consortium, Inc. (OGC).\n  KML files can be displayed in geobrowsers such as\n  [Google Earth](https://www.google.com/earth/),\n  [Marble](https://marble.kde.org),\n  [osgEarth](https://github.com/gwaldron/osgearth), or used with the\n  [NASA World Wind SDK for Java](https://worldwind.arc.nasa.gov/java/).\n\n- **GPX** (the GPS Exchange Format) is a lightweight XML data format for the\n  interchange of GPS data (waypoints, routes, and tracks) between applications\n  and Web services on the Internet. The format is open and can be used without\n  the need to pay license fees, and it is supported by a\n  [large list of software tools](https://www.topografix.com/gpx_resources.asp).\n\n- **NMEA 0183** is a combined electrical and data specification for\n  communication between marine electronics such as echo sounder, sonars,\n  anemometer, gyrocompass, autopilot, GPS receivers, and many other types of\n  instruments. It has been defined by, and is controlled by, the U.S.\n  [National Marine Electronics Association](https://www.nmea.org/). The NMEA\n  0183 standard uses a simple ASCII, serial communications protocol that defines\n  how data are transmitted in a _sentence_ from one _talker_ to multiple\n  _listeners_ at a time. Through the use of intermediate expanders, a talker can\n  have a unidirectional conversation with a nearly unlimited number of\n  listeners, and using multiplexers, multiple sensors can talk to a single\n  computer port. At the application layer, the standard also defines the\n  contents of each sentence (message) type, so that all listeners can parse\n  messages accurately. Those messages can be sent through the serial port (that\n  could be for instance a Bluetooth link) and be used/displayed by a number of\n  software applications such as\n  [gpsd](https://gpsd.gitlab.io/gpsd/index.html \"The UNIX GPS daemon\"),\n  [JOSM](https://josm.openstreetmap.de/ \"The Java OpenStreetMap Editor\"),\n  [OpenCPN](https://opencpn.org/ \"Open Chart Plotter Navigator\"), and many\n  others (and maybe running on other devices).\n\n- **RINEX** (Receiver Independent Exchange Format) is an interchange format for\n  raw satellite navigation system data, covering observables and the information\n  contained in the navigation message broadcast by GNSS satellites. This allows\n  the user to post-process the received data to produce a more accurate result\n  (usually with other data unknown to the original receiver, such as better\n  models of the atmospheric conditions at time of measurement). RINEX files can\n  be used by software packages such as\n  [GNSSTK](https://github.com/SGL-UT/gnsstk), [RTKLIB](https://www.rtklib.com/),\n  and\n  [gLAB](https://gage.upc.edu/en/learning-materials/software-tools/glab-tool-suite).\n  GNSS-SDR by default generates RINEX version\n  [3.02](ftp://igs.org/pub/data/format/rinex302.pdf). If\n  [2.11](ftp://igs.org/pub/data/format/rinex211.txt) is needed, it can be\n  requested through the `rinex_version` parameter in the configuration file:\n\n```\nPVT.rinex_version=2\n```\n\n- **RTCM SC-104** provides standards that define the data structure for\n  differential GNSS correction information for a variety of differential\n  correction applications. Developed by the Radio Technical Commission for\n  Maritime Services\n  ([RTCM](https://www.rtcm.org/ \"Radio Technical Commission for Maritime Services\")),\n  they have become an industry standard for the communication of correction\n  information. GNSS-SDR implements RTCM version 3.2, defined in the document\n  _RTCM 10403.2, Differential GNSS (Global Navigation Satellite Systems)\n  Services - Version 3_ (February 1, 2013), which can be\n  [purchased online](https://ssl29.pair.com/dmarkle/puborder.php?show=3 \"RTCM Online Publication Order Form\").\n  By default, the generated RTCM binary messages are dumped into a text file in\n  hexadecimal format. However, GNSS-SDR is equipped with a TCP/IP server, acting\n  as an NTRIP source that can feed an NTRIP server. NTRIP (Networked Transport\n  of RTCM via Internet Protocol) is an open standard protocol that can be freely\n  downloaded from\n  [BKG](https://igs.bkg.bund.de/root_ftp/NTRIP/documentation/NtripDocumentation.pdf \"Networked Transport of RTCM via Internet Protocol (Ntrip) Version 1.0\"),\n  and it is designed for disseminating differential correction data (_e.g._ in\n  the RTCM-104 format) or other kinds of GNSS streaming data to stationary or\n  mobile users over the Internet. The TCP/IP server can be enabled by setting\n  `PVT.flag_rtcm_server=true` in the configuration file, and will be active\n  during the execution of the software receiver. By default, the server will\n  operate on port 2101 (which is the recommended port for RTCM services\n  according to the Internet Assigned Numbers Authority,\n  [IANA](https://www.iana.org/assignments/service-names-port-numbers/ \"Service Name and Transport Protocol Port Number Registry\")),\n  and will identify the Reference Station with ID=1234. This behavior can be\n  changed in the configuration file:\n\n```\nPVT.flag_rtcm_server=true\nPVT.rtcm_tcp_port=2102\nPVT.rtcm_station_id=1111\n```\n\n**Important note:**\n\nIn order to get well-formatted GeoJSON, KML, and RINEX files, always terminate\n`gnss-sdr` execution by pressing key `q` and then key `ENTER`. Those files will\nbe automatically deleted if no position fix has been obtained during the\nexecution of the software receiver.\n\nMore documentation at the\n[PVT Blocks page](https://gnss-sdr.org/docs/sp-blocks/pvt/).\n\n# About the software license\n\nGNSS-SDR is released under the\n[General Public License (GPL) v3](https://www.gnu.org/licenses/gpl.html), thus\nsecuring practical usability, inspection, and continuous improvement by the\nresearch community, allowing the discussion based on tangible code and the\nanalysis of results obtained with real signals. The GPL implies that:\n\n1.  Copies may be distributed free of charge or for money, but the source code\n    has to be shipped or provided free of charge (or at cost price) on demand.\n    The receiver of the source code has the same rights meaning he can share\n    copies free of charge or resell.\n2.  The licensed material may be analyzed or modified.\n3.  Modified material may be distributed under the same licensing terms but _do\n    not_ have to be distributed.\n\nThat means that modifications only have to be made available to the public if\ndistribution happens. So it is perfectly fine to take the GNSS-SDR source code,\nmodify it heavily and use it in a not distributed application / library. This is\nhow companies like Google can run their own patched versions of Linux for\nexample.\n\nBut what this also means is that non-GPL code cannot use GPL code. This means\nthat you cannot modify / use GNSS-SDR, blend it with non-GPL code, and make\nmoney with the resulting software. You cannot distribute the resulting software\nunder a non-disclosure agreement or contract. Distributors under the GPL also\ngrant a license for any of their patents practiced by the software, to practice\nthose patents in GPL software. You can sell a device that runs with GNSS-SDR,\nbut if you distribute the code, it has to remain under GPL.\n\n# Publications and Credits\n\nIf you use GNSS-SDR to produce a research paper or Thesis, we would appreciate\nif you reference the following article to credit the GNSS-SDR project:\n\n- C. Fern\u0026aacute;ndez-Prades, J. Arribas, P. Closas, C. Avil\u0026eacute;s, and L.\n  Esteve,\n  [GNSS-SDR: an open source tool for researchers and developers](https://www.researchgate.net/publication/233380791_GNSS-SDR_An_open_source_tool_for_researchers_and_developers),\n  in Proceedings of the 24th International Technical Meeting of The Satellite\n  Division of the Institute of Navigation (ION GNSS), Portland, Oregon, Sept.\n  19-23, 2011, pp. 780-794.\n\nFor LaTeX users, this is the BibTeX entry for your convenience:\n\n```\n@INPROCEEDINGS{GNSS-SDR11,\n AUTHOR = {C.~{Fern\\'{a}ndez--Prades} and J.~Arribas and P.~Closas and C.~Avil\\'{e}s and L.~Esteve},\n TITLE = {{GNSS-SDR}: An Open Source Tool For Researchers and Developers},\n BOOKTITLE = {Proc. 24th Intl. Tech. Meeting Sat. Div. Inst. Navig.},\n YEAR = {2011},\n PAGES = {780--794},\n ADDRESS = {Portland, Oregon},\n MONTH = {Sept.} }\n```\n\nThere is a list of papers related to GNSS-SDR in our\n[publications page](https://gnss-sdr.org/publications/ \"Publications\").\n\n# Ok, now what?\n\nIn order to start using GNSS-SDR, you may want to populate `gnss-sdr/data`\nfolder (or anywhere else on your system) with raw data files. By \"raw data\" we\nmean the output of a Radio Frequency front-end's Analog-to-Digital converter.\nGNSS-SDR needs signal samples already in baseband or in passband, at a suitable\nintermediate frequency (on the order of MHz). Prepare your configuration file,\nand then you are ready for running\n`gnss-sdr --config_file=your_configuration.conf`, and seeing how the file is\nprocessed.\n\nAnother interesting option is working in real-time with an RF front-end. We\nprovide drivers for UHD-compatible hardware such as the\n[USRP family](https://www.ettus.com/product), for OsmoSDR and other front-ends\n(HackRF, bladeRF, LimeSDR, and for some DVB-T USB dongles). Start with a low\nnumber of channels and then increase it in order to test how many channels your\nprocessor can handle in real-time.\n\nYou can find more information at the\n[GNSS-SDR Documentation page](https://gnss-sdr.org/docs/) or directly asking to\nthe\n[GNSS-SDR Developers mailing list](https://lists.sourceforge.net/lists/listinfo/gnss-sdr-developers).\n\nYou are also very welcome to contribute to the project, there are many ways to\n[participate in GNSS-SDR](https://gnss-sdr.org/contribute/). If you need some\nspecial feature not yet implemented, the Developer Team would love to be hired\nfor developing it. Please do not hesitate to\n[contact them](https://gnss-sdr.org/team/).\n\n**Enjoy GNSS-SDR!**\n\nThe Developer Team.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgnss-sdr%2Fgnss-sdr","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgnss-sdr%2Fgnss-sdr","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgnss-sdr%2Fgnss-sdr/lists"}