0% found this document useful (0 votes)
124 views15 pages

GNSS-SDR: An Open Source Tool For Researchers and Developers

This document introduces GNSS-SDR, an open source software-defined Global Navigation Satellite System (GNSS) receiver created by researchers at CTTC and UPC in Spain. GNSS-SDR allows for customization of signal sources, processing algorithms, and system interoperability. It is released under the GNU GPL license to encourage use and improvement by the research community. The project aims to create a testbed for exploring new GNSS signal structures and frequencies through a software-defined approach.

Uploaded by

Sam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
124 views15 pages

GNSS-SDR: An Open Source Tool For Researchers and Developers

This document introduces GNSS-SDR, an open source software-defined Global Navigation Satellite System (GNSS) receiver created by researchers at CTTC and UPC in Spain. GNSS-SDR allows for customization of signal sources, processing algorithms, and system interoperability. It is released under the GNU GPL license to encourage use and improvement by the research community. The project aims to create a testbed for exploring new GNSS signal structures and frequencies through a software-defined approach.

Uploaded by

Sam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

GNSS-SDR: an Open Source Tool For

Researchers and Developers


Carles Fernández–Prades, Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain.
Javier Arribas, Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain.
Pau Closas, Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), Spain.
Carlos Avilés, Carlos Avilés Software (CAS), Germany.
Luis Esteve, Universitat Politècnica de Catalunya (UPC), Spain.

BIOGRAPHY the GNSS-SDR project.

Mr. Luis Esteve is a Telecommunications Engineering stu-


Dr. Carles Fernández–Prades is a Research Associate at
dent at UPC. He is working on his MSc Thesis in collabora-
the Centre Tecnològic de Telecomunicacions de Catalunya
tion with CTTC within the GNSS-SDR project. He is teacher
(CTTC), where he holds a position as a Coordinator of the
and co-owner at Epsilon Formación SL since 1999.
Communications Subsystems Area. He received the PhD
degree from Universitat Politècnica de Catalunya (UPC) in
2006. His primary areas of interest include signal processing,
estimation theory, GNSS synchronization, and the design of ABSTRACT
RF front-ends.
This paper introduces GNSS-SDR, an open source Global
Mr. Javier Arribas is a PhD Candidate at the Centre Navigation Satellite System software-defined receiver. The
Tecnològic de Telecomunicacions de Catalunya (CTTC). He lack of reconfigurability of current commercial-of-the-shelf
received the BSc and MSc degree in Telecommunication receivers and the advent of new radionavigation signals and
Engineering in 2002 and 2004 respectively at La Salle systems make software receivers an appealing approach to de-
University in Barcelona, Spain. He is currently involved in sign new architectures and signal processing algorithms. With
the SalleSat Cubesat picosatellite development project. His the aim of exploring the full potential of this forthcoming sce-
primary areas of interest include statistical signal processing, nario with a plurality of new signal structures and frequency
GNSS synchronization, estimation theory and the design of bands available for positioning, this paper describes the soft-
RF front-ends. ware architecture design and provides details about its im-
plementation, targeting a multiband, multisystem GNSS re-
ceiver. The result is a testbed for GNSS signal processing that
Dr. Pau Closas received the MSc and PhD degrees in allows any kind of customization, including interchangeabil-
Electrical Engineering from the Universitat Politècnica de ity of signal sources, signal processing algorithms, interop-
Catalunya (UPC) in 2003 and 2009, respectively. Currently erability with other systems, output formats, and the offering
he holds a position as a Research Associate at CTTC within of interfaces to all the intermediate signals, parameters and
the Communications Subsystems Area. His primary areas of variables. The source code release under the GNU General
interest include estimation theory, GNSS synchronization, Public License (GPL) secures practical usability, inspection,
Bayesian filtering and robustness analysis. and continuous improvement by the research community, al-
lowing the discussion based on tangible code and the analysis
Mr. Carlos Avilés is a Software Engineer and develops his of results obtained with real signals. The source code is com-
professional activities mainly in Berlin, Germany. He has plemented by a development ecosystem, consisting of a web-
received a Computer Science Engineering degree from Uni- site (www.gnss-sdr.org), as well as a revision control
versitat Oberta de Catalunya (UOC) in 2011. His Diploma system, instructions for users and developers, and communi-
Thesis was developed as a collaboration with CTTC within cation tools.
1. INTRODUCTION front-end performs the RF to intermediate frequency (or di-
rectly to baseband) conversion prior to the analog-to-digital
Location has become an embedded feature not only on converter (ADC). All remaining signal and data processing,
medium and high-end mobile phones, but also on other including the hybridization with other systems, are defined in
portable devices such as digital cameras and portable gam- the software domain. This approach provides the designers
ing consoles. This massive deployment of GNSS receivers with a high degree of flexibility, allowing full access and pos-
requires a high level of integration, a low cost, a small size sibility of modification in the whole receiver chain.
and a low power consumption, which has pushed the lead-
ing GPS integrated circuit (IC) manufacturers such as Qual- The last decade has witnessed a rapid evolution of GNSS
comm Inc., Broadcom Corporation, Cambridge Silicon Radio software receivers. Since the first GPS Standard Positioning
(CSR, merged with SiRF in 2009), Texas Instruments Inc., Service software receiver described in [2], where the concept
STMicroelectronics, u-Blox AG, Maxim or MediaTek to of- of bandpass sampling (or intentional aliasing) was introduced,
fer single-chip solutions easy to integrate in multi-function several works were devoted to architectural and implemen-
devices. Thus, the radio frequency (RF) front-end and the tation aspects [3, 4, 5, 6, 7, 8, 9, 10, 11]. Textbooks [12]
baseband processing are jointly implemented in monolithic and [13] increased the awareness of the community about the
ICs, tiny black boxes leaving the user no possibility to in- great benefits provided by software receivers with respect to
teract or to modify the internal architecture or the algorith- the traditional hardware-oriented approach, providing Matlab
mics. This approach is very convenient for location based implementations of a complete GPS receiver, and [14, 15]
services and applications, since users and developers are in- provide discussions about high-level architecture design. In
terested in using the location information (eventually taking [16], authors presented an analysis of software design pat-
advantage of complementary information coming from wire- terns and their application to GNSS software receivers.
less network providers) but not in how the position has been
obtained. Good examples of this abstraction can be found in
the application programming interfaces (APIs) of two major Today, there are solutions available at academic and com-
operating systems for mobile devices: Apple’s iOS provides a mercial levels, usually not only including programming solu-
core location framework with objects that incorporate the ge- tions but also the development of dedicated RF front-ends. As
ographical coordinates and altitude of the device’s location examples, we can mention the GSNRx (GNSS Software Nav-
along with values indicating the accuracy of the measure- igation Receiver [14]) developed by the Position, Location
ments, when those measurements were made, and informa- And Navigation (PLAN) Group of the University of Calgary;
tion about the speed and heading in which the device is mov- the ipexSR, a multi-frequency (GPS C/A and L2C, EGNOS
ing. A similar situation is found in Android, which provides a and GIOVE-A E1-E5a) software receiver developed by the
location package that contains classes with descriptive-named Institute of Geodesy and Navigation at the University FAF
methods such as getLatitude(), getLongitude(), getAltitude(), Munich [17, 18]; or N-Gene, a fully software receiver de-
getSpeed(), getAccuracy() and so on. This abstraction layer veloped by the Istituto Superiore Mario Boella (ISMB) and
simplifies a lot the job of the application developer, but leaves Politecnico di Torino that is able to process in real time the
no way to observe or modify any internal aspect of the re- GPS and Galileo signals broadcast on the L1/E1 bands, as
ceiver. well as to demodulate the differential corrections broadcast
on the same frequency by the EGNOS system. This receiver
is able to process in real-time more than 12 channels, using
As an opposite driving force, the advent of a number of
a sampling frequency of approximately 17.5 MHz with 8 bits
new GNSS (Galileo, COMPASS), the modernization of ex-
per sample [19].
isting ones (GPS L2C and L5, GLONASS L3OC) and the
deployment of augmentation systems (both satellite-based,
such as WAAS in the USA, EGNOS in Europe, and MSAS In this paper, we focus on signal processing, understood
in Japan; and ground-based, such as WiFi positioning and as the process between the ADC and the computation of
Assisted GNSS provided by cellular networks) depict an un- code and phase observables, including the demodulation of
precedented landscape for receiver designers [1]. In the forth- the navigation message. We purposely omit data process-
coming years, many new signals, systems and frequency ing, understood as the computation of the navigation solu-
bands will be available for civil use, and their full exploita- tion from the observables and the navigation message, since
tion will require a thoughtful redesign of the receiver’s archi- there are a number of well-established libraries and applica-
tecture and inner algorithms. In addition to being black boxes tions for that (also in the open source side, such as GPSTk
hidden by an abstraction layer, current mass-market GPS ICs [20, 21]). New available signals pose the challenge of mul-
are clearly constrained in terms of configurability, flexibility tisystem, multiband receivers’ design, including issues such
and capacity to be upgraded. This fact has headed receivers’ as interference countermeasures, high-precision positioning
designers to the software radio paradigm, in which an analog for the mass-market, assisted GNSS and tight hybridization
with other technologies. In this context, this paper introduces ogy), and by experimental validation of the complete receiver
an open-source GNSS software defined receiver (so-named using both real and synthetic signals.
GNSS-SDR) released under the GNU General Public License
(GPL), thus ensuring the freedom of modifying, sharing, and 2.1. Signal sources
using the code for any purpose. This secures practical usabil-
ity, inspection, and continuous improvement by the research An appealing feature for a software receiver is the possibil-
community, allowing the discussion based on tangible code ity of working in real-time with real signals, when the pro-
and the analysis of results obtained with real signals. Hence, cessor is fast enough, or in an offline mode (post-processing)
it is also intended to be a framework for algorithm testing and working with raw signal samples stored in a file, when the
an educational tool, since everybody is allowed to peruse the complexity of the implementation prevents from a real-time
source code, see how the receiver is actually implemented, processing. Signals might also need to be created by syn-
and contribute with improvements, bug fixes, and addition of thetic signal generators in order to conduct experiments with
new features. controlled parameters.

The remainder of the paper is as follows: Section 2 Ideally, an all-software receiver should perform digitiza-
sketches the main characteristics and goals of the proposed tion right after the antenna. Due to technological constraints,
software receiver, identifying possible signal sources, briefly there is still the need for amplification and down-conversion
describing the overall receiver architecture and design pat- before the ADC, the so-called RF front-end. We also need
terns, and analyzing which are the most useful formats for an interface between the ADC output and the PC (or other
data output. Then, Section 3 provides architectural and mech- general-purpose processor) in which the software receiver is
anistic details about the different abstraction layers, from running. This “hardware portion” of the receiver can be im-
sample flow management to the actual implementation of sig- plemented with commercial off-the-shelf components or tak-
nal processing algorithms. The Section also describes im- ing advantage of existing RF application-specific ICs. Mod-
portant features beyond the receiver’s source code, such as ern ones feature single-conversion GNSS receivers, including
the development ecosystem, quality assurance, or how we ad- the low noise amplifier (LNA) and mixer, followed by the
dressed portability. Finally, Section 4 concludes the paper. image-rejected filter, programmable gain amplifier (PGA),
voltage-controlled oscillator (VCO), frequency synthesizer,
crystal oscillator, and a multibit (usually up to 3 bits) ADC
2. RECEIVER’S OVERVIEW
equipped with an automatic gain control (AGC) system.
The proposed receiver provides an interface to different suit-
able RF front-ends and implements all the receiver chain up There are several signal grabbers commercially avail-
to the navigation solution. Its design allows any kind of able. For instance, the Universal Software Radio Peripheral
customization, including interchangeability of signal sources, (USRP) [22] is a general-purpose family of computer-hosted
signal processing algorithms, interoperability with other sys- hardware for software radios that, equipped with a DBSRX
tems, output formats, and offers interfaces to all the interme- daughterboard [23] that can be used as a customizable RF
diate signals, parameters and variables. The goal is to write front-end for GNSS receivers. Other more-specific, lower
efficient and truly reusable code, easy to read and maintain, cost solutions are usually composed of an antenna, a RF IC
with fewer bugs, and producing highly optimized executables front-end, a complex programmable logic device (CPLD) that
in a variety of hardware platforms and operating systems. In arranges sample bits in bytes, and a USB 2.0 microcontroller.
that sense, the challenge consists of defining a gentle bal- This is the case of the SiGe GN3S Sampler v2, based on the
ance within level of abstraction and performance. The pro- SiGe 4120 GPS IC [24], that provides a data stream with a
posed software receiver runs in a commodity personal com- sampling frequency of 16.3676 MHz and a bandwidth up to
puter and provides interfaces through USB and Ethernet buses 4.4 MHz; the NSL’s Primo (based on the Maxim’s MAX2769
to a variety of either commercially available or custom-made RF IC front-end [25], that allows to configure a bandwidth of
RF front-ends, adapting the processing algorithms to differ- 2.5, 4.2, 8, or 18 MHz and has a sampling frequency of up
ent sampling frequencies, intermediate frequencies and sam- to 40 MHz) and Primo II (same characteristics but dual band,
ple resolutions. This makes possible rapid prototyping of spe- using a couple of MAX2769); and the IFEN’s NavPort-III,
cific receivers intended, for instance, to geodetic applications, a RF front-end able to work simultaneously in 4 frequency
observation of the ionospheric impact on navigation signals, bands, with a bandwidth of 13 MHz each [26].
GNSS reflectometry, signal quality monitoring, or carrier-
phase based navigation techniques. Testing is conducted both The state-of-the-art RF IC developments for GNSS re-
by the systematic functional validation of every single soft- ceivers in 2011 focus on offering small size (25 mm2 is a typi-
ware block (following a test-driven developing approach and cal footprint), low power consumption (around 20 mA at 3 V),
using unit testing as a verification and validation methodol- broader bandwidths than the commonly encountered 2 MHz
for GPS L1-only receivers in order to allow for the proper re- that decades from now, today’s standard conforming C++ pro-
ception of GLONASS, Galileo, and COMPASS signals, low grams will run with minimal modifications, just as an older
noise figure (around 1.6 dB for the cascaded chain) and low C++ programs do today. It also ensures portability and the
cost (about $5 US for a single unit). The trend is to provide availability of compilers. This new version provides facilities
a programmable IF frequency and to eliminate the need for for writing concurrent code (e.g. for multicore machines) in
external IF filters, allowing low-cost GNSS receiver solutions a type safe-manner, smart pointers, new memory-optimized
that require only a few external components. As examples, we ways of object handling, and tons of new core and library fea-
can mention STMicroelectronics’ implementation in CMOS tures that are very convenient for software radio applications.
65 nm technology [27] and reports of dual-band front-ends
integrated in a single chip [28, 29]. The receiver’s general block diagram is depicted in Fig.
1. It consists of a Control Plane in charge of managing the
In summary, we identified two main requirements for the whole receiver and the interactions with the underlying op-
software receiver in terms of signal sources: erating system, external applications and user-machine inter-
face; and a Signal Processing Plane that extracts information
• It should allow real-time (when possible) and offline
from raw signal samples.
operation.
• It should be able to use a variety of signal sources (files The nature of a GNSS receiver imposes some require-
and RF front-ends). ments in the architecture design. Since the composition of
the received GNSS signals will change over time (initially,
2.2. Receiver architecture some satellites will be visible, and after a while, some satel-
lites will not be visible anymore and new ones will show up),
The software architecture has to resolve design forces that
some channels will loose track of their signals and some new
sometimes can be antithetical, such as flexibility vs robust-
channels will have to be instantiated to process the new sig-
ness, or portability vs efficiency. With the objective of at-
nals. This means that the receiver must be able to activate
taining real-time in mind, efficiency should be addressed spe-
and deactivate the channels dynamically, and it also needs to
cially in those blocks that work with high data rates (mainly,
detect these changes during runtime.
signal conditioning, Doppler removal, and correlation), while
other blocks working at medium rate (tracking, extraction of
navigation parameters) or low rate (measurement generation, There is also a need to design the communication mech-
navigation solution) can be implemented targeting robustness anism within the signal processing blocks and the Control
and reliability. Plane. The Message Queueing pattern [31] approach is very
flexible and can be adapted to almost any control we need
The chosen programming language is C++. The rationale to implement. There is a control thread that runs in parallel
not only relies on the fact that C++ is a dominant language, to the flowgraph, receiving notifications that trigger changes
but also that it makes it much easier to recruit experienced in the application. Some of these notifications will be sent
programmers, and a number of well-written, peer-reviewed directly from the processing blocks. For instance, an acquisi-
libraries (a crucial aspect in avoiding the reinvention of the tion block that finishes its processing and detects a satellite’s
wheel) and advanced compilers are available. Although it al- signal, will send a notification to the control thread via a mes-
lows close to the metal programming (thus addressing effi- sage queue indicating its success. The control thread will then
ciency), C++ also adds layers of abstraction that make possi- change the internal configuration of the channel and pass the
ble the use of templates (i.e., functions and classes written results of the acquisition process (i.e., detection of in-view
in terms of to-be-specified-later types that are then instan- satellite and rough estimations of its code delay and Doppler
tiated when needed for specific types provided as parame- shift) to the tracking blocks. Since GNSS-SDR is a multi-
ters). Templates are used by a compiler to generate tempo- threaded application, the control thread will receive messages
rary source code, which is merged by the compiler with the from many sources and probably at the same time. The mech-
rest of the source code and then compiled. This mechanism, anism for sending and reading these messages must guarantee
known as static polymorphism, along with being a way of that only one thread reads or writes the shared data at a time, a
pre-evaluating some of the code at compile-time rather than condition known as thread-safety. The control thread requires
at run-time, also reverts in more optimized machine code, a thread-safe queue; it shares an instance of this queue with
smaller executables, shorter run-times, and lesser memory all other modules that require sending messages.
requirements, avoiding the overhead of run-time polymor-
phism. Moreover, a new version of the language, named Signal processing blocks process the input data stream,
C++11, has been recently approved as an ISO (International concurrently applying the same set of operational transfor-
Organization of Standardization) standard [30]. This ensures mations, such as acquiring or tracking the signal of different
satellites. Hence, it is desirable an structure that improves the stream. As long as there is data, the working threads will
capacity (i.e., the number of satellites to be tracked) with run the code of the different blocks.
the replication of architectural units, allowing efficient par-
allel processing of data. The solution follows the Channel A key principle of reusable object-oriented design is: Pro-
Architecture pattern [31], grouping all the signal processing gram to an interface, not an implementation [33]. This prin-
related to a single satellite into a channel subsystem. A chan- ciple is really about dependency relationships which have to
nel can be thought of as a pipe that sequentially transforms be carefully managed in a complex application. It is easy
data from input values to output values, possibly at a differ- to add a dependency on a class; however, the inverse is not
ent rate. The Channel Architecture pattern is well suited to that easy and getting rid of an unwanted dependency can turn
the sequential transformation of data from one state or form into complicated refactoring work or even worse, blocking the
to another. It simplifies algorithms that can easily be decom- user from reusing the code in another context. Isolating the
posed into a series of steps operating on isolate elements from interface from the implementation means the implementation
a data stream. Instances of channel subsystems can be added can vary, and that is a healthy dependency relationship. This
to enlarge the number of processed satellites. The architecture approach gives the developer flexibility, but it also separates
is easily adaptable to handle multiple elements of the data the really valuable part, the design, from the implementation,
stream in parallel, even when they are at different stages of which allows clients to be decoupled from the implementa-
processing. tion. In fact, an abstract class gives you more flexibility when
it comes to evolution. You can add new behavior without
The architecture of the Signal Processing Plane is heavily breaking clients.
based on GNU Radio [32], a well-established framework that
provides the signal processing runtime and processing blocks One of the most attractive features of a software receiver
to implement software radio applications. Frameworks are a is the possibility of interchanging algorithms (for instance,
special case of software libraries – they are reusable abstrac- different implementations of signal acquisition and tracking)
tions of code wrapped in a well-defined API, yet they con- and observe its impact on the whole system, or establish fair
tain some key distinguishing features that separate them from comparisons among them. Moreover, these algorithms should
normal libraries: the overall program’s flow of control is not be selectable at runtime. This kind of problem can be solved
dictated by the caller, but by the framework; and it can be by means of the Strategy pattern [33], which defines a family
extended by the user usually by selective overriding or spe- of algorithms, encapsulates each one, and makes them inter-
cialized by user code providing specific functionality. Soft- changeable, letting the algorithms vary independently from
ware frameworks aim to facilitate software development by clients that use them. The complexity in the instantiation of
allowing designers and programmers to devote their time to objects (for instance, concrete acquisition and tracking imple-
meeting software requirements rather than dealing with the mentations) when only abstract interfaces are known can be
more standard low-level details of providing a working sys- addressed via the Factory Method pattern [33]. It consists in
tem, thereby reducing overall development time. the encapsulation of the processes involved in the creation of
objects, defining an interface for creating an object, but let-
ting subclasses decide which class to instantiate. The Factory
GNU Radio’s class hierarchy imposes a thread-per-block Method lets a class defer instantiation to subclasses. This ap-
architecture that allows automatic scheduling in multicore proach eliminates the need to bind application-specific classes
processors, hiding all the complexity behind a simple and ro- into the code, provides hooks for subclasses (thus making
bust API. It uses shared memory to manage efficiently the more flexible the creation of objects inside a class with a
flow of data between blocks, and offers a large set of well- factory method than creating an object directly, for instance
programmed blocks that provide implementations for very the addition of a new tracking method), and connects parallel
common signal processing tasks. In contrast, GNU Radio class hierarchies (thus localizing knowledge of which classes
does not provide any standard way to provide control over belong together). A potential disadvantage of factory meth-
the blocks. ods is that client applications might have to subclass the cre-
ator class just to create a particular concrete-product object.
The user can build a receiver by creating a graph where the
nodes are signal processing blocks and the lines represent the In summary, we identified these requirements and features
data flow between them. Conceptually, blocks process infinite in terms of software architecture:
streams of data flowing from their input ports to their output
• We found C++ a convenient programming language for
ports. The blocks’ attributes include the number of input and
the implementation.
output ports they have as well as the type of data that flows
through each one of them. Once they are connected and form • The software receiver should address parallelization via
a flowgraph, the application can run and data will be put into multithreading.
CONTROLTHREAD

FLOWGRAPH

CHANNEL N
CHANNEL 2
RINEX
CHANNEL 1 NAV

Fs ≤ Fs

SIGNAL SAMPLES ACQUISITION


RINEX
OBS
~ kHz
SIGNAL SIGNAL
SOURCE CONDITIONER OBSERVABLES

HARDWARE NAV. MSG.


TRACKING
FRONT-END DECODER

PVT

EPHEMERIS
QUEUE
OUTPUT
FILTER NMEA

CONFIGURATION CONFIGURATION MSG QUEUE


FILE

Fig. 1. Diagram of the modules that form the GNSS software receiver. Each module accepts multiple implementations, which
can be selected by the user.

• It should perform reconfiguration during runtime. between the received carrier of the satellite signal and
a receiver-generated reference frequency), and
• We need a thread-safe communication mechanism be-
tween processing modules. • the observation time being the reading of the receiver
clock at the instant of validition of the carrier-phase
• Decoupling between interfaces and implementations is and/or the code measurements.
crucial.

• We want to add new algorithms and to improve existing Receiver Independent Exchange Format (RINEX) is a
implementations without breaking anything. data interchange format for raw satellite navigation system
data, covering observables and the information contained in
2.3. Data sinks the navigation message broadcast by satellites. The most
common version at present is 2.10, which enables stor-
Most geodetic processing software for GNSS data use a well- age of measurements from pseudorange, carrier-phase and
defined set of observables: Doppler systems for GPS or GLONASS, along with data
• the pseudorange (code) measurement, equivalent to the from EGNOS and WAAS satellite based augmentation sys-
difference of the time of reception (expressed in the tems (SBAS), simultaneously. The need for improving the
time frame of the receiver) and the time of transmis- handling of the data files in case of files containing tracking
sion (expressed in the time frame of the satellite) of a data of more than one satellite system, each one with differ-
distinct satellite signal, ent observation types, led to significant modifications of the
structure of data record. At this time of writing, the newest
• the carrier-phase measurement of one or more carriers version is 3.01 [34], and includes defined formats for the mod-
(actually being a measurement on the beat frequency ernized GPS signals, GLONASS, Galileo and SBAS. Hence,
observable and navigation RINEX files are one of the output custom receiver by specifying the flowgraph (type of signal
formats of the proposed software receiver. source, number of channels, algorithms to be used for each
channel and each module, strategies for satellite selection,
Commercial receivers usually do not provide access to type of output format, etc.). Since it is difficult to foresee
such intermediate information but offer direct access to the what future module implementations will be needed in terms
position, velocity and time (PVT) solution and almanac data. of configuration, we used a very simple approach that can be
The National Marine Electronics Association (NMEA) 0183 extended without a major impact in the code. This can be
is the standard output format for commercial GPS receivers, achieved by simply mapping the names of the variables in the
and there is a plethora of compliant software available for modules with the names of the parameters in the configura-
handling and displaying such information. GNSS-SDR pro- tion.
vides this output format for the PVT block module.
Properties are passed around within the program using
Finally, another interesting format to export geographic the ConfigurationInterface class. There are two implementa-
data is KML, directly importable by software applications tions of this interface: FileConfiguration and InMemoryCon-
such as Google Earth, Google Maps, and Google Maps for figuration. FileConfiguration reads the properties (pairs of
mobile. KML is an open standard officially named the property name and value) from a file and stores them in-
OpenGIS KML Encoding Standard (OGC KML), and it is ternally. InMemoryConfiguration does not read from a file;
maintained by the Open Geospatial Consortium, Inc. (OGC). it remains empty after instantiation and property values and
names are set using the set property method. FileConfigura-
In summary, we found useful the following formats for tion is intended to be used in the actual GNSS-SDR applica-
data output: tion whereas InMemoryConfiguration is intended to be used in
tests to avoid file-dependency in the file system. Classes that
• RINEX. need to read configuration parameters will receive instances
of ConfigurationInterface from where they will fetch the val-
• NMEA. ues. For instance, parameters related to SignalSource should
look like this:
• KML.
SignalSource.parameter1=value1
SignalSource.parameter2=value2
3. IMPLEMENTATION DETAILS
The name of these parameters can be anything but one re-
GNSS-SDR’s main method initializes the logging library, served word: implementation. This parameter indicates in its
processes the command line flags, if any, provided by the value the name of the class that has to be instantiated by the
user and instantiates a ControlThread1 object. Its construc- factory for that role. For instance, if we want to use the imple-
tor reads the configuration file, creates a control queue and mentation DirectResampler for module SignalConditioner,
creates a flowgraph according to the configuration. Then, the the corresponding line in the configuration file would be
program’s main method calls the run() method of the instan-
SignalConditioner.implementation=DirectResampler
tiated object, an action that connects the flowgraph and starts
running it. After that, and until a stop message is received, it
reads control messages sent by the receiver’s modules through Since the configuration is just a set of property names and
a safe-thread queue and processes them. Finally, when a stop values without any meaning or syntax, the system is very
message is received, the main method executes the destructor versatile and easily extendable. Adding new properties to
of the ControlThread object, which deallocates memory, does the system only implies modifications in the classes that will
other cleanup and gracefully exits the program. make use of these properties. In addition, the configuration
files are not checked against any strict syntax so it is always
As shown in Fig. 1, the software receiver is split into a in a correct status (as long as it contains pairs of property
Control Plane and a Signal Processing Plane. In the following names and values in INI format2 ).
subsections we provide details about their implementation.
Hence, the application defines a simple accessor class to
3.1. CONTROL PLANE fetch the configuration pairs of values and passes them to a
factory class called GNSSBlockFactory. This factory decides,
The Control Plane is in charge of creating a flowgraph ac-
cording to the configuration and then managing the modules. 2 An INI file is an 8-bit text file in which every property has a name and

Configuration allows users to define in an easy way their own a value, in the form name = value. Properties are case-insensitive, and
cannot contain spacing characters. Semicolons (;) indicate the start of a com-
1 Actual name classes are denoted in sans–serif. ment; everything between the semicolon and the end of the line is ignored.
according to the configuration, which class needs to be in- Once the flowgraph is defined an its blocks connected, it starts
stantiated and which parameters should be passed to the con- to process the incoming data stream. The ControlThread ob-
structor. Hence, the factory encapsulates the complexity of ject is then in charge of reading the control queue and pro-
blocks’ instantiation. With that approach, adding a new block cessing all the messages sent by the the processing blocks via
that requires new parameters will be as simple as adding the the thread-safe message queue.
block class and modifying the factory to be able to instantiate
it. This loose coupling between the blocks’ implementations 3.2. SIGNAL PROCESSING PLANE
and the syntax of the configuration enables extending the ap-
plication capacities in a high degree. It also allows to produce A key aspect of an object-oriented software design is the class
fully customized receivers, for instance a testbed for acqui- hierarchy, depicted in Fig. 2. The notation is as follows: we
sition algorithms, and to place observers at any point of the used a very simplified version of the Unified Modeling Lan-
receiver chain. guage (UML), a standardized general-purpose modeling lan-
guage in the field of object-oriented software engineering. In
this paper, classes are described as rectangles with two sec-
The GNSSFlowgraph class is responsible for preparing tions: the top section for the name of the class, and the bot-
the graph of blocks according to the configuration, running tom section for the methods of the class. A dashed arrow
it, modifying it during run-time and stopping it. Blocks are from ClassA to ClassB represents the dependency relation-
identified by its role. This class knows which roles it has to ship. This relationship simply means that class A somehow
instantiate and how to connect them to configure the generic depends upon class B. In C++ this almost always results in a
graph that is shown in Fig. 1. It relies on the configuration to #include. Inheritance models “is a” and “is like” relation-
get the correct instances of the roles it needs and then it ap- ships, enabling you to reuse existing data and code easily.
plies the connections between GNU Radio blocks to make the When ClassA inherits from ClassB, we say that ClassA is the
graph ready to be started. The complexity related to manag- subclass of ClassB and ClassB is the superclass (or parent
ing the blocks and the data stream is handled by GNU Radio’s class) of ClassA. The UML modeling notation for inheritance
gr top block class. GNSSFlowgraph wraps the gr top block
is a line with a closed arrowhead pointing from the subclass
instance so we can take advantage of the GNSS block fac- to the superclass.
tory, the configuration system and the processing blocks. This
class is also responsible for applying changes to the configu-
As shown in Fig. 2, gr basic block is the abstract base
ration of the flowgraph during run-time, dynamically recon-
class for all signal processing blocks, a bare abstraction of
figuring channels: it selects the strategy for selecting satel-
an entity that has a name and a set of inputs and outputs. It
lites. This can range from a sequential search over all the
is never instantiated directly; rather, this is the abstract par-
satellites’ ID to smarter approaches that determine what are
ent class of both gr hier block2, which is a recursive container
the satellites most likely in-view based on rough estimations
that adds or removes processing or hierarchical blocks to the
of the receiver position in order to avoid searching satellites
internal graph, and gr block, which is the abstract base class
in the other side of the Earth.
for all the processing blocks. A signal processing flow is con-
structed by creating a tree of hierarchical blocks, which at any
This class internally codifies actions to be taken on the level may also contain terminal nodes that actually implement
graph. These actions are identified by simple integers. GNSS- signal processing functions.
Flowgraph offers a method that receives an integer that codi-
fies an action, and this method triggers the action represented Class gr top block is the top-level hierarchical block rep-
by the integer. Actions can range from changing internal resenting a flowgraph. It defines GNU Radio runtime func-
variables of blocks to modifying completely the constructed tions used during the execution of the program: run(), start(),
graph by adding/removing blocks. The number and complex- stop(), wait(), etc. As shown in Fig. 3, a subclass called
ity of actions is only constrained by the number of integers GNSSBlockInterface is the common interface for all the
available to make the codification. This approach encapsu- GNSS-SDR modules. It defines pure virtual methods, that
lates the complexity of preparing a complete graph with all are required to be implemented by a derived class. Classes
necessary blocks instantiated and connected. It also makes containing pure virtual methods are termed “abstract;” they
good use of the configuration system and of the GNSS block cannot be instantiated directly, and a subclass of an abstract
factory, which keeps the code clean and easy to understand. class can only be instantiated directly if all inherited pure vir-
It also enables updating the set of actions to be performed to tual methods have been implemented by that class or a parent
the graph quite easily. class.

The ControlThread class is responsible for instantiating Subclassing GNSSBlockInterface, we defined interfaces
the GNSSFlowgraph and passing the required configuration. for the receiver blocks defined in Fig. 1. This hierarchy,
gr_basic_block GNSSBlockInterface
std::string)name() ...
gr_io_signature_sptr)input_signature() The C++
gr_io_signature_sptr)output_signature() class
... gr_block is
the base of
all signal
processing ChannelInterface Acquisition Tracking TelemetryDecoder Observables
blocks in ... Interface Interface Interface Interface
GNU Radio ... ... ... ...
gr_hier_block2
connect(gr_basic_block_sptr)block) gr_block
disconnect(gr_basic_block_sptr)block) virtual general_work()
virtual lock() ...
gr_block
virtual unlock() AcqA AcqA AcqA ...
... adapter adapter adapter
... ... ...
general_work()
does the actual
signal
gr_top_block processing Trk3
run() Trk1 Trk2 Trk3
GNURadio
start() adapter adapter adapter
Your_signal_processing block
stop() ... ... ...
_blocks_here ...
wait()
Your_flowgraph_here general_work()
virtual)lock()
... ...
virtual)unlock()
dump()
...
Fig. 4. Receiver’s class hierarchy.

Fig. 2. Class hierarchy for the Signal Processing Plane. nicates with the RF front-end and receives the samples com-
ing from the ADC. This communication is usually performed
gr_top_block
through USB or Ethernet buses. Since real-time processing
... requires a highly optimized implementation of the whole re-
ceiver, this module also allows to read samples from a file
stored in a hard disk, and thus processing without time con-
GNSSBlockInterface straints. Relevant parameters of those samples are the inter-
Public:
mediate frequency (or baseband I&Q components), the sam-
virtual!~GNSSBlockInterface() pling rate and number of bits per sample, that must be speci-
virtual)std::string!role()!=!0;
virtual!std::string!implementa>on()!=!0;
fied by the user in the configuration file.
virtual!size_t!item_size()!=!0;
virtual!void!connect(gr_top_block_sptr!top_block)!=!0;
virtual!void!disconnect(gr_top_block_sptr!top_block)!=!0; This module also performs bit-depth adaptation, since
virtual!gr_basic_block_sptr!get_leC_block()!=!0; most of the existing RF front-ends provide samples quan-
virtual!gr_basic_block_sptr!get_right_block()!=!0; tized with 2 or 3 bits, while operations inside the processor
are performed on 32- or 64-bit words, depending on its ar-
chitecture. Although there are implementations of the most
intensive computational processes (mainly correlation) that
Fig. 3. General interface for signal processing blocks. take advantage of specific data types and architectures for
the sake of efficiency (such as the Single–Input Multiple–
Data (SIMD)-based correlators presented in [6], exploiting a
shown in Fig. 4, provides the definition of different algo- specific subset of assembly instructions for Intel processors
rithms and different implementations, which will be instanti- that allows parallel computing), the approach is processor-
ated according to the configuration. This strategy allows mul- specific and hardly portable. We suggest to keep signal sam-
tiple implementations sharing a common interface, achieving ples in standard data types and letting the compiler select the
the objective of decoupling interfaces from implementations: best library version (implemented using SIMD or any other
it defines a family of algorithms, encapsulates each one, and processor-specific technology) of the required routines for a
makes them interchangeable. Hence, we let the algorithm given processor.
vary independently from the program that uses it.

3.2.2. SIGNAL CONDITIONER


Hereafter, we describe GNSSBlockInterface subclasses.
They are, again, abstract interfaces that defer instantiation to The signal conditioner is in charge of resampling the signal
their own subclasses. and delivering a reference sample rate to the downstream pro-
cessing blocks, acting as a facade between the signal source
3.2.1. SIGNAL SOURCE and the synchronization channels, providing a simplified in-
terface to the input signal. In case of multiband front-ends,
The Signal Source module is in charge of implementing the this module would be in charge of providing a separated data
hardware driver, that is, the portion of the code that commu- stream for each band.
3.2.3. CHANNEL gr_top_block
...

A Channel encapsulates all signal processing devoted to a sin-


gle satellite. Thus, it is a large composite object which encap- GNSSBlockInterface
virtual(...
sulates the acquisition, tracking and decoding modules. As a
composite object, it can be treated as a single entity, meaning gr_block
that it can be easily replicated. Since the number of channels AcquisitionInterface ...
virtual(...
is selectable by the user in the configuration file, this approach
helps improving the scalability and maintainability of the re- AcqA
ceiver. AcqA
adapter
GNURadio
block
...
...

This module is also in charge of managing the interplay AcqB


AcqB
GNURadio
between acquisition and tracking. Acquisition can be ini- adapter
block
...
tialized in several ways, depending on the prior information ...

available (called cold start when the receiver has no informa-


tion about its position nor the satellites almanac; warm start
when a rough location and the approximate time of day are Fig. 5. Class hierarchy for the Acquisition module. AcqA
available, and the receiver has a recently recorded almanac and AcqB adapter classes wrap your custom acquisition block
broadcast; or hot start when the receiver was tracking a satel- to the common interface expected by AcquisitionInterface.
lite and the signal line of sight broke for a short period of AcqA and AcqB GNU Radio blocks are different implemen-
time, but the ephemeris and almanac data is still valid, or this tations of acquisition. Actual signal processing is done here.
information is provided by other means), and an acquisition You can use existing GNU Radio blocks or implement a new
process can finish deciding that the satellite is not present, one by yourself.
that longer integration is needed in order to confirm the pres-
ence of the satellite, or declaring the satellite present. In the
latter case, acquisition process should stop and trigger the
tracking module with coarse estimations of the synchroniza- the receiver to create a local code aligned with the incoming
tion parameters. The mathematical abstraction used to de- code.
sign this logic is known as finite state machine (FSM), that
is a behavior model composed of a finite number of states,
AcquisitionInterface is the common interface for all the
transitions between those states, and actions. For the imple-
mentation, we used the Boost.Statechart library [35], which acquisition algorithms and their corresponding implementa-
provides desirable features such as support for asynchronous tions. Algorithms’ interface, that may vary depending on the
state machines, multi-threading, type-safety, error handling use of information external to the receiver, such as in Assisted
and compile-time validation. GNSS, is defined in classes referred to as adapters (see Fig.
5). These adapters wrap the GNU Radio blocks interface into
a compatible interface expected by AcquisitionInterface. This
At the time of writing, we provide an implementation that allows the use of existing GNU Radio blocks derived from
works with the GPS L1 C/A signal. More complex chan- gr block, and ensures that newly developed implementations
nel implementations could accommodate more sophisticated will also be reusable in other GNU Radio-based applications.
strategies such as vector tracking loops involving signals from Moreover, it adds still another layer of abstraction, since each
more than one satellite and optimizations performed directly given acquisition algorithm can have different implementa-
in the position domain [36]. tions (for instance using different numerical libraries). In such
a way, implementations can be continuously improved with-
out having any impact neither on the algorithm interface nor
the general acquisition interface.
3.2.4. ACQUISITION
Software-based acquisition methods can consist of a serial
The first task of a GNSS receiver is to detect the presence or search, a parallel frequency search based on the Fast Fourier
absence of in-view satellites. This is done by the acquisition Transform [13] (that can be implemented with specialized and
system process, which also provides a coarse estimation of highly optimized libraries such as FFTW [37]), using coher-
two signal parameters: the frequency shift fd with respect to ent or non-coherent integration [12], or even taking advantage
the nominal IF frequency, and a delay term ⌧ which allows of signals from different frequency bands [38].
3.2.5. TRACKING DecoderInterface provides a single interface for decoding the
navigation message of different systems.
When a satellite is declared present, the parameters estimated
by the acquisition module are then fed to the receiver track-
3.2.7. OBSERVABLES
ing module, which represents the second stage of the signal
processing unit, aiming to perform a local search for accurate GNSS systems provide different kinds of observations. The
estimates of code delay and carrier phase, and following their most commonly used are the code observations, also called
eventual variations. Possible algorithms for code delay track- pseudoranges. The pseudo comes from the fact that on the
ing include the Delay Lock Loop (DLL) and its multiple vari- receiver side the clock error is unknown and thus the mea-
ants, along with code lock detectors that decide whether the surement is not a pure range observation. High accuracy ap-
tracking loop is effectively locked to the code phase of the re- plications also use the carrier phase observations, which are
ceived signal or a loss-of-lock has occurred, while Phase Lock based on measuring the difference between the carrier phase
Loops (PLL) and Frequency Lock Loops (FLL) are the usual transmitted by the GNSS satellites and the phase of the car-
approaches for carrier tracking (also encompassing different rier generated in the receiver. Both observables are computed
carrier phase loop discriminators and carrier lock detectors from the outputs of the tracking module and the decoding of
[39]). Since the time spent in the transition from acquisition the navigation message.
to tracking is unknown, a counter is implemented in order to
estimate on which sample the spreading code sequence begins This module collects all the data provided by every
after a certain period of time. tracked channel, aligns all received data into a coherent set,
and computes the observables. Mathematical details can be
Again, a class hierarchy consisting of a TrackingInter- found in [48]. The output format for this data is in form of
face class and subclasses implementing algorithms provides RINEX file, as described in Section 2.3. RINEX files pave
a way of testing different approaches, with full access to the way to high accuracy positioning, since they can be di-
their parameters. In additional to classical tracking loops, rectly used by applications and libraries that implement the
this architectures leaves room for other approaches such as corresponding algorithms.
the block adjustment of synchronizing signal (BASS) method
[12], strategies based on combinations of signals in different 3.2.8. PVT
bands [40] or ultra-tight hybridization schemes with inertial
measurement units [41]. Although data processing for obtaining high–accuracy PVT
solutions is out of the scope of GNSS-SDR, we provide a
module that can compute a simple least square solution and
3.2.6. DECODING OF NAVIGATION MESSAGE leaves room for more sophisticated positioning methods. The
integration with libraries and software tools that are able to
Most of GNSS signal links are modulated by a navigation deal with multi-constellation data such as GPSTk or gLAB
message containing the time the message was transmitted, [49] appears as a viable solution for high performance, com-
orbital parameters of satellites (also known as ephemeris) pletely customizable GNSS receivers.
and an almanac (information about the general system health,
rough orbits of all satellites in the network as well as data re-
3.3. OTHER FEATURES
lated to error correction). Navigation data bits are structured
in words, pages, subframes, frames and superframes. Some- • Development ecosystem. Infrastructure for project
times, bits corresponding to a single parameter are spread management, code development and efficient commu-
over different words, and values extracted from different nication among users and developers is a key aspect in
frames are required for proper decoding. Some words are for software projects. The website should be well designed
synchronization purposes, others for error control an others in terms of usability, functionality and extendability,
contain actual information. There are also error control mech- ensuring an enjoyable and appealing user experience.
anisms, from parity checks to forward error correction (FEC) We used Drupal [50] as a content management system.
encoding and interleaving, depending on the system. All this The result can be found at www.gnss-sdr.org. For
decoding complexity is managed by a finite state machine im- the source code, an application that automates the pro-
plemented with the Boost.Statechart library [35]. Details on cess of keeping an annotated history of the project, al-
the structure of the navigation message are reported in the lowing reversion of code changes, change tracking, and
related interface specification documents: see [42] for GPS bug tracking is essential. We used the service provided
L1 C/A and L2C, [43] for GPS L1C, [44] for GPS L5, [45] by SourceForge, which allows access to the code using
for GLONASS, [46] for Galileo and [47] for SBAS. Class two major revision control systems such as Subversion
hierarchy for these implementations mimics the architecture [51] and git [52], along with a distribution list that fa-
already presented for acquisition and tracking: a Telemetry- cilitates communication among users.
• Documentation. This is of paramount importance for Messages can be logged by severity level, and the users
users, developers, testers, software architects and stu- can control logging behavior from the command line,
dents. We used Doxygen [53], a tool for writing soft- log based on conditionals, abort the program with stack
ware reference documentation. The documentation is trace when expected conditions are not met, and intro-
written within the C++ code, in form of comments, and duce their own verbose logging levels.
is thus relatively easy to generate (since it can be writ-
ten along with the source code) and keep up to date. • Profiling. We used Google Performance Tools
Doxygen scans the code, extracts the documentation (google–perftools) [58], a collection of a high–
and dumps it in HTML, LATEX, RTF or XML formats, performance multi–threaded memory allocators imple-
cross-referencing documentation and code, so that the mentation, plus some performance analysis tools that
reader of a document can easily refer to the actual code. allow to automatize the profiling process, identify com-
It also automatically generates dependency graphs, in- putational bottlenecks, and help the developers to focus
heritance diagrams, and collaboration diagrams. In ad- their optimization efforts.
dition to code documentation, the project web page pro-
vides with detailed instructions about the installation,
usage, coding style and general information about the 4. CONCLUSIONS
program.
This paper presented an open source GNSS software de-
• Building tool. The build process should be easily fined receiver, discussing aspects about its design and
maintained and highly portable. When not thought implementation. The proposed software receiver targets
out well, development time shifts towards build sys- multi-constellation/multi-frequency architectures, pursuing
tem tweaking instead of source file coding. We used the goals of efficiency, modularity, interoperability, and flex-
Boost.Build [54], a tool that takes care about compiling ibility demanded by user domains that require non-standard
the sources with the right options, creating static and features. The source code was released under the GNU Gen-
shared libraries, making executables, using a variety of eral Public License (GPL), thus ensuring the freedom of mod-
compilers on the most common operating systems. The ifying, sharing, and using the code for any purpose. This se-
developer is only required to provide a simple and high cures practical usability, inspection, and continuous improve-
level building description (naming executables and li- ment by the research community, allowing the discussion
braries and listing their sources) and Boost.Build pro- based on tangible code and the analysis of results obtained
vides many built-in features that can be combined to with real signals. Hence, it is also intended to be a frame-
produce arbitrary building configurations, such as de- work for algorithm testing and an educational tool. The web-
bug and release variants or single- and multi-threaded site available at www.gnss-sdr.org provides information
builds, automatically translating the requested proper- and detailed instructions, as well as a link to the source code.
ties into appropriate command-line flags for invoking
toolset components like compilers and linkers. Regard- Although GNSS-SDR is still far from full-featured com-
ing the compiler, we used the GNU Compiler Collec- mercial software receivers, it constitutes a free platform that
tion [55]. can be continuously improved by peer-reviewing and contri-
butions from users and developers around the world, unleash-
• Testing. We suggest a test–driven development ap- ing the potential of collaborative research in the field of GNSS
proach. This methodology is claimed to offer valu- software receivers.
able benefits to software development: it facilitates
change, simplifies integration, automatizes documenta-
tion, helps separate the interface from the implementa- 5. ACKNOWLEDGEMENTS
tion, increases developers productivity, and plays a cen-
tral role in the software quality assurance process. For Authors want to thank the whole open source community,
unit testing, we found the Google C++ Testing Frame- and specifically to other pioneering open source projects
work (gtest) [56] useful and lightweight. that have inspired this work: C. Kelley’s OpenSource GPS
[59, 60], a software for x86 PCs that allows acquisition, track-
• Logging. Logging is important for debugging and trac- ing and demodulation of signals from GPS satellites (requir-
ing purposes. The developer might also want to run ing a Zarlink’s GP2021 GPS correlator chip) and G. Heckler’s
some interesting statistics on logs, and study usage pat- gps-sdr [61], which implemented a x86 Linux-based GPS
terns. In GNSS-SDR, logging is handled by Google software receiver, including correlators using SIMD tech-
Logging Library (google-glog) [57], a library that im- nology [6]. This work has been partially supported by the
plements application-level logging. It provides simple Spanish Science and Technology Commission under Project
yet powerful APIs to various log events in the program. TEC2008-02685/TEC (NARRA) and by the European Com-
mission in the framework of the COST Action IC0803 (RFC- [11] X. Li and D. Akos, “Implementation and performance
SET). of clock steering in a software GPS L1 single frequency
receiver,” Navigation: Journal of The Institute of Navi-
REFERENCES gation, vol. 57, no. 1, pp. 69–85, Spring 2010.

[12] J. Bao-Yen Tsui, Fundamentals of Global Positioning


[1] C. Fernández-Prades, L. Lo Presti, and E. Falleti, “Satel-
System Receivers. A Software Approach, John Wiley &
lite radiolocalization from GPS to GNSS and beyond:
Sons, Inc., Hoboken, NJ, 2nd edition, 2005.
Novel technologies and applications for civil mass-
market,” Proceedings of the IEEE, Nov. 2011, In Press. [13] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, and S. H.
DOI: 10.1109/JPROC.2011.2158032. Jensen, A Software–Defined GPS and Galileo Receiver.
[2] D. Akos, A Software Radio Approach to Global Navi- A Single–Frequency Approach, Applied and Numerical
gation Satellite System Receiver Design, Ph.D. thesis, Harmonic Analysis. Birkhäuser, Boston, MA, 2007.
College of Engineering and Technology, Ohio Univer- [14] M. G. Petovello, C. O’Driscoll, G. Lachapelle, D. Bo-
sity, Aug. 1997. rio, and H. Murtaza, “Architecture and benefits of an
[3] K. Krumvieda, P. Madhani, C. Cloman, E. Olson, advanced GNSS software receiver,” Positioning, vol. 1,
J. Thomas, P. Axelrad, and W. Kober, “A complete no. 1, pp. 66–78, 2009.
IF software GPS receiver: A tutorial about the details,”
[15] F. Principe, G. Bacci, F. Giannetti, and M. Luise,
in Proc. of the 14th International Technical Meeting of
“Software-defined radio technologies for GNSS re-
the Satellite Division of the Institute of Navigation (ION
ceivers: A tutorial approach to a simple design and im-
GPS’01), Salt Lake City, UT, Sept 2001, pp. 789–829.
plementation,” International Journal of Navigation and
[4] V. Chakravarthy, J. Tsui, D. Lin, and J. Schamus, “Soft- Observation, vol. 2011, pp. 1–27, 2011, Article ID
ware GPS receiver,” GPS Solutions, vol. 5, no. 2, pp. 979815, DOI:10.1155/2011/979815.
63–70, Oct. 2001.
[16] C. Fernández–Prades, C. Avilés, L. Esteve, J. Ar-
[5] B. M. Ledvina, S. P. Powell, P. M. Kintner, and M. L. ribas, and P. Closas, “Design patterns for GNSS soft-
Psiaki, “A 12–channel real–time GPS L1 software re- ware receivers,” in Proc. of the 5th ESA Workshop
ceiver,” in Proc. of the National Technical Meeting of the on Satellite Navigation Technologies (NAVITEC’2010),
Institute of Navigation (ION NTM’03), Anaheim, CA, ESTEC, Noordwijk, The Netherlands, Dec. 2010,
Jan. 2003, pp. 767–782. DOI:10.1109/NAVITEC.2010.5707981.
[6] G. W. Heckler and J. L. Garrison, “SIMD correlator [17] M. Anghileri, T. Pany, D. Sanromà-Güixens, J.-H. Won,
library for GNSS software receivers,” GPS Solutions, A. Sicramaz-Ayaz, C. Stöber, I. Krämer, D. Dötterböck,
vol. 10, no. 4, pp. 269–276, Nov. 2006. G. W. Hein, and B. Eissfeller, “Performance evalua-
[7] H. Hurskainen, J. Raasakka, T. Ahonen, and J. Nurmi, tion of a multi–frequency GPS/Galileo/SBAS software
“Multicore software–defined radio architecture for receiver,” in Proc. of the 20th International Technical
GNSS receiver signal processing,” EURASIP Journal on Meeting of the Satellite Division of the Institute of Navi-
Embedded Systems, vol. 2009, 2009, Article ID 543720. gation (ION GNSS’07), Fort Worth, TX, Sept. 2007, pp.
2749–2761.
[8] T. E. Humphreys, J. A. Bhatti, T. Pany, B. M. Ledvina,
and B. W. O’Hanlon, “Exploiting multicore technology [18] C. Stöber, M. Anghileri, A. Sicramaz Ayaz,
in software–defined GNSS receivers,” in Proc. of the D. Dötterböck, I. Krämer, V. Kroppand J.-H. Won,
22nd International Meeting of the Satellite Division of B. Eissfeller, D. Sanromà Güixens, and T. Pany,
The Institute of Navigation (ION GNSS’09), Savannah, “ipexSR: A real-time multi-frequency software GNSS
GA, Sept. 2009, pp. 326–338. receiver,” in Proc. of the 52nd International Symposium
ELMAR-2010, Zadar, Croatia, Sept. 2010, pp. 407–416.
[9] A. Mitelman, J. Almqvist, R. Håkanson, D. Karlsson,
F. Lindström, T. Renström, C. Ståhlberg, and J. Tidd, [19] M. Fantino, A. Molino, and M. Nicola, “N–Gene
“Testing software receivers,” GPS World, vol. 20, no. GNSS receiver: Benefits of software radio in navi-
12, pp. 28–34, Dec. 2009. gation,” in Proc. of the European Navigation Con-
[10] T. Hobiger, T. Gotoh, J. Amagai, Y. Koyama, and ference - Global Navigation Satellite Systems (ENC-
T. Kondo, “A GPU based real–time GPS software re- GNSS), Naples, Italy, May 2009.
ceiver,” GPS Solutions, vol. 14, no. 2, pp. 207–216,
Mar. 2010.
[20] B. W. Tolman, R. B. Harris, T. Gaussiran, D. Munton, [30] ISO/IEC 14882:2011(E) Programming Languages –
J. Little, R. Mach, S. Nelsen, B. Renfro, and D. Schloss- C++, Third Edition, 2011.
berg, “The GPS toolkit - open source GPS software,”
in Proc. of the 17th International Technical Meeting [31] B. P. Douglass, Real–Time Design Patterns: Robust
of the Satellite Division of the Institute of Navigation Scalable Architecture for Real–Time Systems, Addison
(ION GNSS’04), Long Beach, CA, 21–24 Sept. 2004, Wesley, Upper Saddle River, NJ, 2002.
pp. 2044–2053. [32] “GNU Radio,” http://gnuradio.org, Retrieved: August
[21] D. Salazar, M. Hernández-Pajares, J. M. Juan, and 29, 2011.
J. Sanz, “GNSS data management and processing with
[33] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, De-
the GPSTk,” GPS Solutions, vol. 14, no. 3, pp. 293–299,
sign Patterns: Elements of Reusable Object–Oriented
June 2010.
Software, Addison Wesley, Upper Saddle River, NJ,
[22] Ettus Research, “USRP motherboard datasheet. 1995.
Universal Software Radio Peripheral. The foun-
[34] W. Gurtner and L. Estey, RINEX. The Receiver Indepen-
dation for complete software radio systems,”
dent Exchange Format Version 3.01, June 2009.
http://www.ettus.com/downloads/ettus ds usrp v7.pdf,
Retrieved: October 21, 2010. [35] “The Boost Statechart Library,”
[23] Ettus Research, “TX and RX daughterboards www.boost.org/doc/libs/release/libs/statechart/doc/index.html,
for the USRPT M software radio system,” Retrieved: August 29, 2011.
http://www.ettus.com/downloads/ettus daughterboards.pdf, [36] P. Closas and C. Fernández-Prades, “Bayesian nonlinear
Retrieved: August 29, 2011. filters for Direct Position Estimation,” in Proc. of IEEE
[24] SiGe Semiconductor, “SE4120L GNSS receiver IC Aerospace Conference, Big Sky, MT, March 2010, pp.
datasheet,” May 26, 2009, Ottawa, ON, Canada. 1–12, DOI: 10.1109/AERO.2010.5446676.

[25] Maxim Integrated Products, Sunnyvale, CA, MAX2769 [37] M. Frigo and S. G. Johnson, “The design and implemen-
Universal GPS Receiver, June 2010, Ref. 19-0791; Rev tation of FFTW3,” Proceedings of the IEEE, vol. 93, no.
2. 2, pp. 216–231, 2005, Special issue on “Program Gen-
eration, Optimization, and Platform Adaptation”.
[26] N. Falk, T. Hartmann, H. Kern, B. Riedl, T. Pany,
R. Wolf, and J. Winkel, “SX-NSR 2.0 A multi- [38] C. Gernot, K. O’Keefe, and G. Lachapelle, “Assess-
frequency and multi-sensor software receiver with a ing three new GPS combined L1/L2C acquisition meth-
quad-band RF front end,” in Proc. of the 23rd Inter- ods,” IEEE Transactions of Aerospace and Electronic
national Technical Meeting of The Satellite Division of Systems, vol. 3, no. 47, pp. 2239–2247, July 2011, DOI:
the Institute of Navigation (ION GNSS 2010), Portland, 10.1109/TAES.2011.5937297.
OR, Sept. 2010, pp. 1395–1401.
[39] E. D. Kaplan and C. J. Hegarty, Eds., Understanding
[27] G. Rivela, P. Scavini, D. Grasso, M. Castro, GPS. Principles and Applications, Artech House, Nor-
A. Calcagno, G. Avellone, A. Di Mauro, G. Cali, and wood, MA, 2nd edition, 2006.
S. Scaccianoce, “A low power RF front-end for L1/E1
GPS/Galileo and GLONASS signals in CMOS 65nm [40] D. Megahed, C. O’Driscoll, and G. Lachapelle, “Per-
technology,” in Proc. of International Conference on formance evaluation of combined L1/L5 Kalman filter-
Localization and GNSS (ICL-GNSS), Tampere, Find- based tracking versus standalone L1/L5 tracking in chal-
land, June 2011, pp. 7–12. lenging environments,” in Proc. of the 22nd Interna-
tional Meeting of the Satellite Division of The Institute
[28] M. Detratti, E. López, E. Pérez, and R. Palacio, “Dual- of Navigation (ION GNSS), Savannah, GA, Sept. 2009,
frequency RF front end solution for hybrid Galileo/GPS pp. 2591–2601.
mass market receiver,” in Proc. of the IEEE Consumer
Communications and Networking Conference (CCNC [41] C. Fernández-Prades, P. Closas, and J. Vilà-Valls, “Non-
’08), Las Vegas, NV, Jan. 2008, pp. 603–607. linear filtering for ultra-tight GNSS/INS integration,” in
Proc. of the IEEE International Conference on Commu-
[29] J. Wu, P. Jiang, D. Chen, and J. Zhou, “A dual-band
nications (ICC 2010), Cape Town (South Africa), May
GNSS RF front end with a pseudo-differential LNA,”
2010, pp. 1–5, DOI: 10.1109/ICC.2010.5502037.
IEEE Transactions on Circuits and Systems II: Express
Briefs, vol. 58, no. 3, pp. 134–138, March 2011.
[42] Science Applications International Corporation, Inter- [50] “Drupal,” http://drupal.org, Retrieved: August 29, 2011.
face Specification IS-GPS-200 Revision E. Navstar GPS
Space Segment/Navigation User Interfaces, El Segundo, [51] “Apache Subversion,” http://subversion.apache.org, Re-
CA, June 8, 2010. trieved: August 29, 2011.

[43] Science Applications International Corporation, Inter- [52] “git. The fast version control system,” http://git-
face Specification IS-GPS-800 Revision A. Navstar GPS scm.com, Retrieved: August 29, 2011.
Space Segment/User Segment L1C Interfaces, El Se- [53] “Doxygen,” http://www.stack.nl/ dimitri/doxygen/, Re-
gundo, CA, June 8, 2010. trieved: August 29, 2011.
[44] Science Applications International Corporation, Inter- [54] “Boost.build v2,” http://www.boost.org/boost-
face Specification IS-GPS-705 Revision A. Navstar GPS build2/doc/html/index.html, Retrieved: August
Space Segment/User Segment L5 Interfaces, El Se- 29, 2011.
gundo, CA, June 8, 2010.
[55] “GCC, the GNU Compiler Collection,”
[45] Russian Institute of Space Device Engineering, http://gcc.gnu.org, Retrieved: August 29, 2011.
Moscow, Russia, Global Navigation Satellite System
GLONASS. Interface Control Document. Navigational [56] “Google C++ Testing Framework (googletest),”
radiosignal in bands L1, L2, 2008, Version 5.1 http://code.google.com/p/googletest/, Retrieved:
downloadable from http://www.glonass-ianc.rsa.ru. August 29, 2011.

[46] European Union, European GNSS (Galileo) Open Ser- [57] “Google logging library (google-glog). Logging library
vice. Signal In Space Interface Control Document. Ref: for C++,” http://code.google.com/p/google-glog/, Re-
OS SIS ICD, Issue 1, February 2010. trieved: August 29, 2011.

[47] RTCA, Washington, DC, Minimum Operational Per- [58] “Google Performance Tools (google-perftools),”
formance Standards for Global Positioning System/Wide http://code.google.com/p/google-perftools/, Retrieved:
Area Augmentation System Airborne Equipment, DO– August 29, 2011.
229D, Dec. 13 2006.
[59] C. Kelley, J. Barnes, and J Cheng, “OpenSource GPS.
[48] A. Leick, GPS Satellite Surveying, John Wiley & Sons, Open source software for learning about GPS,” in
Inc., Hoboken, NJ, 3rd edition, 2004. Proc. of the 15th International Technical Meeting of the
Satellite Division of the Institute of Navigation (ION
[49] M. Hernández-Pajares, J. M. Juan, J. Sanz, P. Ramos- GPS’02), Portland, OR, Sept. 2002.
Bosch, A. Rovira-Garcı́a, D. Salazar, J. Ventura-
Traveset, C. López-Echazarreta, and G. Hein, “The [60] “OpenSourceGPS,” http://sourceforge.net/projects/osgps/,
ESA/UPC GNSS-Lab Tool (gLAB),” in Proc. Retrieved: August 29, 2011.
of the 5th ESA Workshop on Satellite Naviga-
[61] “GPS-SDR,” https://github.com/gps-sdr, Retrieved: Au-
tion Technologies (NAVITEC’2010), ESTEC, No-
gust 29, 2011.
ordwijk, The Netherlands, Dec. 2010, DOI:
10.1109/NAVITEC.2010.5708032.

You might also like