GNSS-SDR: An Open Source Tool For Researchers and Developers
GNSS-SDR: An Open Source Tool For Researchers and Developers
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
PVT
EPHEMERIS
QUEUE
OUTPUT
FILTER NMEA
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.
[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.