ArticlePDF Available

Abstract and Figures

The aim of this paper is to provide guidelines for developing high–quality, well–written GNSS software receivers. The systematic application of software design patterns and programming methodologies speeds up the development process by providing tested, proven devel-opment paradigms, and improved code readability for coders, receiver architects, and users. This includes unit testing of all the modules, and the use of a code programming style stressing readability and language-specific conventions. All these good practices result in fewer bugs, reduce reinvention–of–the–wheel, and cut long–term maintenance costs. The paper provides an analysis of design patters, good coding practices, and methodologies for the design and implementation of GNSS software receivers, describing a working implementation released under the GNU General Public License.
Content may be subject to copyright.
Design Patterns for GNSS Software Receivers
Carles Fern´
andez–Prades, Carlos Avil´
es, Luis Esteve, Javier Arribas, and Pau Closas
Centre Tecnol`
ogic de Telecomunicacions de Catalunya (CTTC), Castelldefels, Spain.
Email: {carles.fernandez, javier.arribas, pau.closas}@cttc.cat.
Universitat Oberta de Catalunya (UOC), Barcelona, Spain. Email: carlos.avilesr@googlemail.com.
Universitat Polit`
ecnica de Catalunya (UPC), Barcelona, Spain. Email: luis@epsilon-formacion.com.
Abstract—The aim of this paper is to provide guidelines for developing
high–quality, well–written GNSS software receivers. The systematic
application of software design patterns and programming methodologies
speeds up the development process by providing tested, proven devel-
opment paradigms, and improved code readability for coders, receiver
architects, and users. This includes unit testing of all the modules, and
the use of a code programming style stressing readability and language-
specific conventions. All these good practices result in fewer bugs, reduce
reinvention–of–the–wheel, and cut long–term maintenance costs. The
paper provides an analysis of design patters, good coding practices,
and methodologies for the design and implementation of GNSS software
receivers, describing a working implementation released under the GNU
General Public License.
I. INTRODUCTION
In Global Navigation Satellite System (GNSS) receivers, signal
processing techniques dealing with the challenges posed by the multi–
constellation/multi–frequency concept and the requirements of scien-
tific applications should be designed along with the receiver archi-
tecture. The software defined radio approach is a design trend that is
reaching a certain degree of maturity, moving from a strictly–research
orientation to higher levels of performance, reliability, and robustness,
shortening the path to meet the stringent requirements of scientific
and industrial applications. In this sense, a discussion on software
design patterns and their application to multi–constellation/multi–
frequency software receivers appears as a timely, essential task
to achieve the goals of efficiency, modularity, interoperability, and
flexibility demanded by different user domains (aeronautical, land
mobile, maritime, earth observers, geodesy, etc).
In this paper, the approach is based on modern computer science
concepts, ranging from design patterns and template metaprogram-
ming (which shifts complexity to compile time instead of execution
time, giving place to more optimized executables) to agile software
development techniques, including software development cycles con-
sisting in planning, requirements analysis, design, coding, unit testing,
and acceptance testing. All these constitute a set of engineering
best practices intended to allow for rapid delivery of high–quality
software.
In this context, this paper presents an open–source GNSS software
receiver released under the GNU General Public License (GPL), thus
ensuring the freedom of modifying, sharing, and using the code
for any purpose. This secures practical usability, inspection, and
continuous improvement by the research community. The proposed
receiver provides an interface to different suitable radio–frequency
(RF) front–ends and implements all the receiver chain up to the
navigation solution. Its design allows any kind of customization,
including interchangeability of signal sources, signal processing algo-
rithms, interoperability with other systems, output formats, and offers
an interface to all the intermediate signals.
The goal is to write efficient and truly reusable code, easy to
read and maintain, with fewer bugs, and producing highly optimized
executables in a variety of hardware platforms and operating systems.
In that sense, the challenge consists of defining a gentle balance
within level of abstraction and performance. The proposed software
receiver runs in a commodity PC and provides interfaces through
USB and Ethernet to a variety of either commercially available or
custom RF front–ends, adapting the processing to different sampling
frequencies, intermediate frequencies and sample resolution. This
makes possible rapid prototyping of specific receivers intended, for
instance, to geodetic applications, observation of the ionospheric
impact on navigation signals, signal quality monitoring, or carrier-
phase based navigation techniques. It also paves the way to effec-
tive hybridization of GNSS with other technologies (e.g. wireless
communication systems, or inertial measurement units), since open
access and interaction with all receiver stages is provided. Testing is
conducted both by the systematic functional validation of every single
software block (following a test–driven developing approach and
using unit testing as a verification and validation methodology), and
by experimental validation of the complete receiver using synthetic
signal generators with controlled parameters and real signals captured
by a RF front–end.
II. STATEOFT HE ART
Last decade has witnessed a rapid evolution of GNSS software
receivers. Since the first GPS Standard Positioning Service software
receiver described in [1], where the concept of bandpass sampling (or
intentional aliasing) was introduced, several works were devoted to
architectural and implementation aspects. For instance, [2] provided
details about analog–to–digital conversion, high sensitivity signal
acquisition and different tracking loops, and [3] discussed real–time
issues such as the transition from acquisition to tracking. Textbooks
[4] and [5] increased the awareness of the community about the great
benefits provided by software receivers with respect to the traditional
hardware–oriented approach, providing a Matlab implementation of
a complete GPS receiver. In order to accelerate computations and
attain real–time in commodity general–purpose processors, bitwise
operations were introduced in [6]. The use of Single–Input Multiple–
Data (SIMD) parallel computing technology for the correlators and
other time–critical operations is due to [7], a solution that exploited
an extension set of assembly instructions for Intel processors. Both
approaches suffered from being bit–depth dependent, jeopardizing
flexibility since signal quantification cannot be easily changed. Other
recent approaches take advantage of today’s pervasive multicore
architecture processors [8], [9], or of the computational power of
modern Graphics Processing Units (GPUs) [10]. Test procedures
for GNSS software receivers were addressed in [11], and a general
discussion about the architecture is found in [12]. Carrier phase
measurements and clock steering are discussed in [13].
Today, there are available solutions at university and commercial
levels, usually not only including programming solutions but also the
realization of dedicated RF front–ends. As examples, we can mention
the GSNRx (GNSS Software Navigation Receiver) developed by the
Position, Location And Navigation (PLAN) Group of the University
of Calgary [12], the ipexSR, a multi–frequency (GPS C/A and L2C,
EGNOS and GIOVE-A E1-E5a) software receiver developed by the
Institute of Geodesy and Navigation at the University FAF Munich
[14], or N–Gene, a fully software receiver developed by the Istituto
Superiore Mario Boella (ISMB) and Politecnico di Torino that is able
to process in real–time the GPS and Galileo signals broadcast on the
L1/E1 bands, as well as to demodulate the differential corrections
broadcast on the same frequency by the European Geostationary
Navigation Overlay Service (EGNOS) system. This receiver is able
to process in real–time more than 12 channels, using a sampling
frequency of approximately 17.5MHz with 8bits per sample [15].
Regarding observable processing and data management, the GPS
Toolkit (GPSTk) [16], [17] is an open source project that provides
a GNSS computing suite to the satellite navigation community,
consisting of a core library, accessory libraries, and some appli-
cations. It is also worthwhile to mention the NAvigation Package
for Earth Observation Satellites (NAPEOS) software [18], used by
the navigation support office (OPS–GN) at the European Space
Operations Center (ESOC) since January 2008 for all its International
GNSS Service (IGS) activities [19].
III. PROGRAMMING METHODOLOGY
After a brief review of the state–of–the–art, this Section aims
to provide concept definitions, practical guidelines, good coding
practices, and development methodologies to attain the objective of
well–written GNSS software receivers.
A. Design patterns
The concept of software design pattern was firstly introduced
in [20], a book that rapidly became a fundamental reference on
the topic. Software design patterns are descriptions of solutions to
common software problems arising in different contexts, capturing
recurring structures and dynamics among software participants to
facilitate reuse of successful, thoughtfully proven designs. They
generally codify expert knowledge of design strategies, constraints
and best practices. Following a pattern helps to resolve key design
forces such as flexibility, extensibility, dependability, predictability,
scalability, and efficiency. They are not code recipes but generalized
solutions to commonly occurring problems, showing relationships
and interactions between classes or objects but without specifying the
final application instantiations. The work in [21] took these concepts
further, and explored their applicability to real–time systems. Other
references are [22], dealing with concurrency issues, [23], that
introduced the object pool pattern, and [24], that advocates using
patterns for improving an existing design.
Patterns can be classified into architectural, when they apply to
large–scale organization of subsystems and components, how they
are constructed or how are they managed, and mechanistic, when
they are more local in scope and define mechanisms for object
collaboration. This latter type can be subdivided into categories
of creational (patterns that deal with object creation mechanisms),
structural (identifying ways to realize relationships between entities),
or behavioral (identifying common communication patterns between
objects that increase flexibility). Hereafter we provide descriptions of
useful design patterns concerned to GNSS software receivers.
1) Architectural patterns: In GNSS receivers, architectural
patterns are related to the system organization into sets of
sequential transformational elements (where actual signal processing
is performed), and how to handle concurrency and memory
management. They solve and delineate some essential cohesive
elements of the software architecture.
Name: Channel Architecture pattern [21].
Problem: Algorithms process the input data stream, applying
the same set of operational transformations, such as acquiring
or tracking the signal of different satellites. It is desirable an
architectural structure that improves throughput capacity (i.e.,
the number of satellites to be tracked) with the replication of
architectural units, allowing efficient parallel processing of data.
Solution: Group all the signal processing related to a single satellite
into a channel subsystem. A channel can be thought of as a pipe that
sequentially transforms data from an input value to an output value.
Consequences: The Channel Architecture pattern is well suited to
the sequential transformation of data from one state or form to
another. It simplifies algorithms that can easily be decomposed into
a series of steps operating on isolate elements from a data stream.
Instances of channel subsystems can be added to enlarge the number
of processed satellites. The architecture is easily adaptable to handle
multiple elements of the data stream in parallel, even when they are
at different stages of processing.
Name: State Machine pattern [25].
Problem: It should be possible for an object to alter its behavior
when its internal state changes (for instance, a lost of tracking event)
Solution: A State Machine consists of the following parts: i) an
Automata interface implemented by the context that is the only way
of interaction between the automata and a client, ii) a Context class
that encapsulates transition logic, implements the automata interface
and holds an instance of the data model and the current state, iii)
State classes that determine the behavior in a particular state, each
of them implementing the automata interface, iv)Events initiated
by the state classes and passed to the context that does a transition
depending on the event and the current state, v) an Event notification
interface implemented by a context, the only way of interaction
between the state classes and the context, and finally vi) a Data
model, a class to provide a shared storage between the state classes.
Consequences: The State Machine pattern makes the state–dependent
behavior to be localized in the state classes. The transition logic is
separated from the behavior in a particular state. The state classes
should only notify a context of a particular event. This pattern does
not contain redundant interfaces for the context and the state classes
they all implement the same interface. The implementation of an
interface is trivial and could be generated automatically. Transitions
could be implemented as a simple index lookup. Also note that the
automata interface is implemented by the context and by the state
classes. This allows making certain compile–time consistency check.
Name: Message Queueing pattern [21].
Problem: In most multithreaded systems, threads must synchronize
and share information with others. Two primary things must be
accomplished. First, the tasks must synchronize to permit sharing of
the information, for instance concurrent access to the signal sample
flow or the output of an acquisition module. Second, the information
must be shared in such a way that there is no chance of corruption
or race conditions (condition in which a result depends on the order
of execution, but the order of execution cannot be predicted).
Solution: The Message Queuing pattern provides a simple means for
threads to communicate information among one another. Each thread
owns a message queue that stores messages received asynchronously.
When the thread is active, it reads messages from the queue and
processes them, usually by dispatching them to an internal object.
Each queue is protected by a mutual exclusion semaphore, since
the queue itself is a shared resource (shared between the owning
thread and the thread objects that want to send it messages), it
must be protected from simultaneous access. This is a well–known
approach to the producer–consumer problem that frequently arise in
multi–threaded systems, particularly used to decouple processes that
produce and consume data at different rates.
Consequences: This pattern is supported by virtually all real–
time operating systems and multitasking languages. The primary
disadvantages are that it is a relatively heavyweight approach to
information passing among threads, it does not necessarily allow
for highly efficient information sharing (since it is asynchronous,
the receiving thread does not process the incoming message until it
becomes ready to run), and information must be shared by value
instead of by reference. This limits the complexity of the information
sharing possible and does not allow for efficient use of large data
structures.
Name: Smart Pointer pattern [21], [26].
Problem: When dealing with pointers, precise management is easy
to forget about when dealing with all possible execution paths.
Inevitably, somewhere a pointer is destroyed (or goes out of scope),
but the memory is not properly freed (a memory leak), memory is
released but nevertheless accessed (dangling pointer), or memory
is accessed but not properly allocated (uninitialized pointer). These
problems are notoriously difficult to identify using standard means
of testing and peer reviews.
Solution: The basic solution of the Smart Pointer pattern is to reify
the pointer into an object that contains the actual pointer as an
attribute, as well as constructor, destructor, and access operations,
thus preventing inappropriate use.
Consequences: The main advantage of applying this pattern is that
it is a simple means to ensure that objects are destroyed when
they are no longer accessible, for instance the tracking object of a
satellite already lost. To ensure safety, no raw pointers should be used.
2) Mechanistic patterns: In GNSS receivers, we have identified
creational (Factory Method), structural (Facade), and behavioral
(Template Method) patterns, that are described hereafter.
Name: Factory Method pattern [20].
Problem: One of the most attractive features of a software receiver
is the possibility of interchanging algorithms (for instance, different
implementations of signal acquisition and tracking) and observe its
impact in the whole system, or establish fair comparisons among
them. The creation of such objects often requires complex processes
not appropriate to include within a composing object. The object’s
creation may lead to a significant duplication of code, may require
information not accessible to the composing object, or may not
provide a sufficient level of abstraction.
Solution: Encapsulate the processes involved in the creation of
objects. Define an interface for creating an object, but let subclasses
decide which class to instantiate. The Factory Method lets a class
defer instantiation to subclasses (see Figure 1).
Consequences: Factory Methods eliminate the need to bind
application–specific classes into the code, provide hooks for sub-
classes (thus making more flexible the creation of objects inside
a class with a factory method than creating an object directly, for
instance the addition of a new tracking method), and connect parallel
class hierarchies (thus localizing knowledge of which classes belong
acq()
<<utility>>
AbstractAcq
factoryAcq() : AbstractAcq
<<utility>>
AbstractAcqCreator
AcqMethodA
AcqMethodB
factoryAcq() : AbstractAcq
CreatorAcqA
factoryAcq() : AbstractAcq
CreatorAcqB
Fig. 1. Factory Method in Unified Modeling Language (UML)
together). A potential disadvantage of factory methods is that client
applications might have to subclass the creator class just to create a
particular concrete–product object.
Name: Facade pattern [20].
Problem: A common design goal is to minimize the communication
and dependencies between subsystems.
Solution: Provide a unified interface to a set of interfaces in
a subsystem, defining a higher–level interface that makes the
subsystem easier to use.
Consequences: The Facade pattern shields clients from subsystem
components, thus promoting weak coupling among them. This allows
changes in the components of the subsystem without affecting its
clients, reduces compilation dependencies, simplifies portability to
other platforms, and it does not prevent applications from using
subsystem classes if they need to.
Name: Template Method pattern [20].
Problem: We would like to improve the implementation of a certain
part of an algorithm without having to reprogram everything.
Solution: Define the skeleton of an algorithm in an operation,
deferring some steps to subclasses. The Template Method pattern
lets subclasses redefine certain steps of an algorithm without
changing the algorithm’s structure.
Consequences: Template Methods are a fundamental technique
for code reuse. They are particularly important in class libraries,
because they are the means for factoring out common behavior
in library classes. It is important for template methods to specify
which operations are hooks (may be overridden) and which are
abstract operations (must be overridden). To reuse an abstract class
effectively, subclass writers must understand which operations are
designed for overriding.
In summary, using patterns helps in the reuse of proven software
designs and architectures, preserve crucial design information, guide
design choices for application developers, and they create a common
terminology, of importance when working on teams because it sim-
plifies communication between team members. This is of particular
importance in interdisciplinary groups, as is usually the case in the
development of GNSS software receivers.
B. Computer programming style
Since the seminal work by Kernighan et al. in 1974 [27], there is
a clear concern on the style in writing software and its impact in the
final quality of the product. Following programming guidelines and
code conventions not only helps to avoid introducing errors, but cuts
maintenance costs and favours effective code reuse.
Generic programming is a well–established style in which algo-
rithms are written in terms of to–be–specified–later types that are then
instantiated when needed for specific types provided as parameters.
Software entities created under this paradigm are known as parame-
terized types [20], or templates when using C++. Templates are used
by a compiler to generate temporary source code, which is merged by
the compiler with the rest of the source code and then compiled. This
mechanism, known as static polymorphism, along with being a way of
pre–evaluating some of the code at compile–time rather than at run–
time, also reverts in more optimized code, smaller executables, shorter
runtimes, and lesser memory requirements, avoiding the overhead of
run–time polymorphism. Compile–time execution refers to the ability
of a compiler, that would normally compile a function to machine
code and execute it at run time, to execute the function at compile
time. Since in a software receiver working in real–time performance
is critical, we should maximize compile–time work (which usually
is not an issue), and even in an offline, not time–restricted signal
processing this methodology provides benefits such as syntax and
semantic analysis, code generation, timings, and earlier bug detection.
Since programming styles are often designed for a specific pro-
gramming language, let us first discuss the choice of C++ for the
GNSS software receiver presented in this paper. The rationale relies
on the fact that C++ is a dominant language, it is much easier
to recruit experienced programmers, and a number of well–written,
peer–reviewed libraries are available. Besides that, C++ is truly a
language for multi–paradigm development: the language supports
generic, imperative, and object–oriented programming, allowing use
of templates, static polymorphism, and generic programming. In the
absence of instantiation bounds, C++ templates have been shown
to be Turing–complete [28], which, roughly speaking, means that
they are powerful enough to compute anything – any computation
expressible by a computer program.
The evolution of C++ is directly linked to the evolution in the
understanding of design patterns and generic programming concepts.
When the C++ standardization process was started in 1989 by an
international ANSI/ISO committee, it also included the development
of a standard library that extended the core language to provide
some general components, a set of common classes and interfaces:
the standard template library (STL), special containers, strings and
numeric classes, input/output streams, etc. These give programmers
a higher level of abstraction [29]. Textbooks [30] and [26] provide
a number of practical examples of judicious uses of the STL for
producing effective and efficient code. The next step in generic
programming applied to C++ is Boost [31], [32], a set of free, ex-
pertly designed, peer–reviewed portable C++ source libraries. Boost
provides reference implementations that are suitable for eventual
standardization. Actually, some of the Boost libraries are already
included in the current C++ standard and several more are expected
to be included in the new standard now being finalized. The use of
STL and Boost libraries helps to produce better code and to increase
productivity. However, an incorrect or indiscriminate usage could lead
to code bloat, and thus careful selection is strongly encouraged.
As a necessarily non–comprehensive list of good coding practices,
we can mention the need of clear functional and detailed specifica-
tions (requirements, architecture, analysis, design, and testing) before
jumping into programming, the observation of naming conventions
(set of rules for choosing the character sequence to be used for
identifiers which denote variables, types, classes, etc.), code doc-
umentation, and the absence of magic numbers (unnamed or ill–
documented numerical constant values). References [30], [33], [34]
provide a wide–scope list of good coding practices.
C. Software development methodology
This subsection defines the framework that is used to structure,
plan, and control the process of developing a GNSS software receiver.
1) Test–driven development: We propose a test–driven develop-
ment approach [35], [36], consisting in repeating test–case cycles
(sets of conditions or variables under which a tester will determine
whether an application or software system is working correctly
or not) instead of a feature–driven approach. This methodology is
claimed to offer valuable benefits to software development: facilitates
change, simplifies integration, automatizes documentation, helps to
separate the interface from the implementation, increases developers
productivity, and plays a central role in the software quality assur-
ance process. In this methodology, the tests are written before the
functionality that is being tested. This has shown two main benefits.
It helps ensure that the application is written for testability, as the
developers must consider how to test the application from the outset,
rather than worrying about it later. It also ensures that tests for every
feature will be written. There are different testing levels: unit testing
(that checks the functionality of a specific section of code), integration
testing (checks the interfaces between components against a software
design), system testing (tests a completely integrated system to verify
that it meets its requirements), system integration testing (verifies that
a system is integrated to any external or third party systems defined
in the system requirements), regression testing (focuses on finding
defects after a major code change has occurred), and user acceptance
testing.
Unit testing. Understanding unit as the smallest testable part
of an application, unit testing [37] checks the functionality of
source code portions. It consists of three phases: i) perform
the test planning (plan the general approach, resources, and
schedule; determine features to be tested; refine the general
plan), ii) acquire the test set (design the set of tests; implement
the refined plan; and design), and iii) measure the test unit
(execute the test procedures; check for termination; and evaluate
the test effort and unit). Unit testing infrastructure should be
lightweight and allow introspection (a language feature that
allows the state of an object to be observed and altered by means
of a uniform mechanism that is equally applicable to objects of
all classes).
Integration testing. Phase in software testing in which individ-
ual software modules are combined and tested as a group, after
unit testing and before system testing. Integration testing takes
as its input modules that have been unit tested, groups them
in larger aggregates, applies tests defined in an integration test
plan to those aggregates, and delivers as its output the integrated
system ready for system testing.
System testing. Test should also be conducted on a complete,
integrated system to evaluate the compliance level with its
specified requirements. These tests should require no knowledge
of the inner design of the code or logic, and include performance
testing [38] using profiling and logging tools (which is of
relevant importance in applications targeted to work in real–
time).
Higher–level testing. User testing feedback and peer–reviewing
are powerful tools in producing high–quality software. Releasing
the source code under the GPL allows thoughtful inspection not
only of software features but also of how are they implemented.
2) Development ecosystem: Infrastructure for project management
and code development is of equal importance than programming
style. A set of efficient and easy–to–use tools helps managers and
developers to keep tight to objectives and schedule, avoiding improper
communication and facilitating feedback among users and developers.
Project management tool. This includes scheduling, resource
allocation, collaboration software, communication, quality man-
agement and documentation or administration systems. When
web–based, it should be accessed from any type of computer,
ease of access–control, and multi–user. Storage “in the cloud”
of relevant documents is suggested.
Version control system. An application that automates the
process of keeping an annotated history of the project, allowing
reversion of code changes, change tracking, and bug tracking
is essential. As examples we can mention Subversion1[39] and
git [40]. Trac [41] and redmine [42] are web–based tools that
integrates well.
Integrated Development Environment (IDE). Admitting that
each developer has his/her own preference, a full–featured IDE
increases productivity. Usually, an IDE consists of a source code
editor, an interface to a compiler and/or an interpreter, build
automation tools, and a debugger, but modern ones also provide
integration with the version control system, a class browser, an
object inspector, and a class hierarchy diagram. Eclipse [43] is
a free and open source option.
Build tool. The build process should be easily maintained and
highly portable. When not thought out well, development time
shifts towards build system tweaking instead of source file
coding. There are several tools that automatize the process,
such as bjam [44] and CMake [45]. Regarding the compiler,
we suggest the GNU Compiler Collection (gcc) [46], a multi–
platform, world–class optimizing compiler that closely follows
language standards.
Communication. An email distribution list uses to be an ef-
ficient communication tool among developer team members.
When needed, can be complemented with net–meetings and
personal instant messaging. In these cases, emailed minutes of
meeting are useful to keep logging of discussions and decisions.
IV. IMPLEMENTATION
Hereafter we present a software project, so–called GNSS–SDR
and accessible from http://cms.cttc.es/trac/gnss-sdr/wiki, that tries to
implement the concepts presented so far. The implementation is
heavily based on GNU Radio [47], a well–established framework
that provides the signal processing runtime and processing blocks
to implement software radio applications. A framework is a product,
while a design pattern is a specification. Frameworks are a special
case of software libraries – they are reusable abstractions of code
wrapped in a well–defined Application Programming Interface (API),
yet they contain some key distinguishing features that separate them
from normal libraries: the overall program’s flow of control is not
dictated by the caller, but by the framework; and it can be extended
by the user usually by selective overriding or specialized by user code
1Although we provide web references, we suggest readers interested in the
forthcoming mentioned software tools, denoted in sans–serif, to look for the
most updated information in the web search engine of their choice.
providing specific functionality. Software frameworks aim to facilitate
software development by allowing designers and programmers to
devote their time to meeting software requirements rather than dealing
with the more standard low–level details of providing a working
system, thereby reducing overall development time.
In case of GNU Radio, it incorporates many of the design patterns
described in Section III-A. From an architectural point of view, a
GNSS–SDR application can be seen as a factory with different work-
ing lines where we put raw data at the input and we get processed data
at the output. This raw data is, in our case, the continuous stream of
signal samples and the processed data is the position of the receiver
updated constantly and regularly. This simplification describes quite
effectively the GNSS–SDR architecture. Since the designer should
focus in solving the problem of introducing the raw data into the
application, distributing it through the factory line, and gathering the
results at the other end, the Channel Architecture pattern provides a
suitable approach for our needs. Adopting this approach has several
benefits, namely that the architecture can be easily mapped with a
hardware implementation of any signal processing device, it implies a
degree of modularity that is required by software defined radio (SDR)
applications, the concepts involved do not require deep knowledge of
software engineering concepts and can be used in an interdisciplinary
environment, and the fact that using a design pattern introduces a
component of standardization that is always desired for software
design. GNU Radio incorporates a scheduler that assigns working
threads to each block, hiding all the complexity behind a simple and
robust API, uses shared memory to manage efficiently the flow of data
between blocks, and offers a large set of well–programmed blocks
that provide implementations for very common signal processing
tasks. In contrast, GNU Radio does not provide any standard way
to provide control over the blocks. Once they are connected, the
application can run and data will be put into the stream. As long as
there is data, the working threads will run the code of the different
blocks.
A. Control
In practice, the composition of the received GNSS signals will
change over time. Initially, some satellites will be visible and their
signals will be received by the front–end. GNSS–SDR will need
as many channels working in parallel as visible satellites there are.
After a while, some satellites will not be visible anymore and new
ones will show up. Some channels will loose track of their signals
and some new channels will have to be instantiated to process the
new signals. This means that the receiver must be able to activate
and deactivate the channels dynamically, and it also needs to detect
these changes during run–time. We used the Message Queueing
pattern to implement a control architecture to the application. This
approach is very flexible and can be adapted to almost any control
we need to implement. There is a control thread that runs in parallel
to the flowgraph, receiving notifications that trigger changes in
the application. Some of these notifications will be sent directly
from the processing blocks. For instance, an acquisition block that
finishes its processing and detects a satellite’s signal, will send a
notification to the control thread indicating its success. The control
thread will then change the internal configuration of the channel and
pass the estimations to the tracking blocks. Since GNSS–SDR is a
multithreaded application, the control thread will receive messages
form many sources and probably at the same time. The mechanism
for sending and reading these messages must be thread–safe. The
control thread has a thread–safe queue and it shares an instance of
this queue with all other modules that require sending messages to
Fig. 2. Two possible RF front–ends: the Universal Software Radio
Peripheral [48] (left) equipped with a DBSRX daughterboard [49], and
the SiGe GN3S Sampler v2 (right), based on the SiGe 4120 GPS ASIC
[50]. Relevant parameters of RF front–ends are the frequency band, the
sampling frequency, the intermediate frequency, and the number of bits
per sample. The signal source could be also a file stored in a hard disk.
the control thread.
B. Configuration
Configuration is a key feature in SDR applications. We need
to define what signal source we want to use, and what are the
characteristics of the channels (system, band, certain acquisition or
tracking algorithm,...), and to specify parameters to all these modules.
And we want all this to be easy and intuitive. Since it is difficult to
foresee what future block implementations we will need in terms of
configuration, we used a very simple approach that can be extended
without a major impact in the code. This can be achieved by simply
mapping the names of the variables in the blocks with the names of
the parameters in the configuration. The application will only define
a simple accessor class to fetch the configuration pairs of values and
pass them to a factory class. This factory will decide, according to
the configuration, which class needs to be instantiated and which
parameters should be passed to the constructor. With that approach,
adding a new block that requires new parameters will be as simple
as adding the block class and modifying the factory to be able to
instantiate it. This loose coupling between the blocks implementations
and the syntax of the configuration enables extending the application
capacities in a high degree. It also allows to produce fully customized
receivers, for instance a benchmark for acquisition algorithms, and
to place observers at any point of the receiver chain, which is very
useful for debugging, educational, and research purposes.
C. Algorithms
The implementation has to resolve design forces that sometimes
can be antithetical, such as flexibility vs robustness, or portability
vs efficiency. With the objective of attaining real–time in mind,
efficiency should be addressed specially in those blocks that works
with high data rates (mainly, signal conditioning, Doppler removal,
and correlation), while other blocks working at medium rate (tracking,
extraction of navigation parameters) or low rate (measurement gener-
ation, navigation solution) can be implemented targeting robustness
and reliability.
In the implementation of digital signal processing algorithms, the
first step is an obviousness sometimes forgotten: go and find the
standards. There are reference documents available for GPS L1 C/A
[51], the forthcoming civilian–use signal called GPS L1C [52], GPS
L2C [51], GPS L5 [53], the standard precision service of GLONASS
[54], Galileo’s Open Service [55], the Japanese Quasi-Zenith Satellite
System (QZSS) [56], and the definition of the message format for
Satellite–Based Augmentation Systems (SBAS) such as WAAS [57,
Appendix A] or EGNOS [57], [58].
Regarding the signal source, we suggest to implement a driver
compliant with the VITA 49 Radio Transport (VRT) protocol [59],
an emerging standard for SDR applications that was developed to
provide interoperability between a diversity of SDR components by
providing a protocol to convey digitized signal data and sensor set-
tings. These would allow an easy accommodation of signals coming
from a multiband RF front–end, or other sources of information
providing data at different rate, such as Inertial Measurement Units
for GNSS/INS hybridization purposes.
After the signal source (see Figure 2), a signal conditioner is in
charge of resampling the signal and deliver a reference sample rate
to the downstream processing blocks, acting as a Facade between the
signal source and the synchronization channels. These channels can
be managed according to the State Machine pattern. As suggested in
[60], channels can be in one of the following states: idle, acquisition,
confirmation, pull–in, and tracking. Satellite states can be usable and
unusable, according to the knowledge and health of the almanac and
ephemeris data.
Both acquisition and code/phase tracking processes are active fields
of research, and a primary design goal of GNSS–SDR is to allow a
rapid implementation of novel approaches and a smooth embedding
in a complete receiver, as well as allowing fair comparisons and its
impact assessment in the overall performance. The level of abstraction
provided by the Factory Method pattern is intended to hide the low–
level integration work to the programmer, and thus focusing the
efforts in algorithm implementations instead of in the interaction with
the rest of the receiver.
Software libraries for signal processing have to be carefully se-
lected. We have found useful uBLAS [61], a Boost’s C++ template
class library that provides basic linear algebra operations such as
vector and matrix multiplication, and FFTW [62], an efficient im-
plementation of the Fast Fourier Transform commonly used in the
acquisition process.
The output of the tracking and navigation data modules can be
dumped into a file (we suggest to follow the Receiver Independent
Exchange Format RINEX Version 3.01 [63], which allows the accom-
modation of observation, navigation, and meteorological data for GPS
and its modernization plans, GLONASS, and Galileo, and offers a
direct interface to high–precision navigation libraries such as GPSTk)
or directly delivered to another module in charge of computing the
navigation solution, or to another application.
For unit testing, we have found the Google C++ Testing Framework
(gtest) [64] useful and lightweight. Other used tools are the Google
Logging Library (glog) [65] for application–level logging, Google
Commandline Flags (gflags) for command line flags processing, and
Google Performance Tools (google–perftools) [66], a collection of
a high–performance multi–threaded memory allocators implementa-
tion, plus some pretty nifty performance analysis tools that allow to
automatize the profiling process, identify computational bottlenecks,
and help the developers to focus their optimization efforts.
V. CONCLUSIONS
Design patterns encapsulate experience and know–how, alleviating
the lack of a comprehensive quantitative measure of software quality
and formalizing good practices in software development. In this
paper, these concepts have been applied to the specific field of
GNSS software receivers, aiming to discuss some formal aspects,
Signal Source signalConditioner
Atributes
Input Filter
solve
Atributes
Abstract
Navigation
Solution
Application
RINEX file
acquire
Atributes
Abstract Acquisition
pseudoRange
carrierPhase
Atributes
Measurement
Generation
decode
Atributes
Navigation
Message
track
Atributes
Abstract Tracking
Concrete
Acquisition
Concrete
Tracking
Concrete
Navigation
Solution
Satellite Channel
Control Plane
select
Atributes
Abstract Satellite
Selection
select
Atributes
Abstract Signal
Source
configure
Atributes
Abstract
Configuration
Concrete
Source
Driver
Concrete
Selection
Strategy
Concrete
Configuration
Signal Processing Plane
Fig. 3. Software receiver architecture.
associated design, and development methodologies. Besides, this
paper also presents an open source GNSS software receiver that
partially implements the proposed approach and offers a free–access
framework for further development.
ACK NOW LE DG ME NT S
Authors are especially grateful to Christian Pomar i Berry for
his wise recommendations, inspiring advices, and many valuable
discussions in those issues related to Computer Science and high–
performance programming. This work has been partially supported by
the Spanish Science and Technology Commission: CENIT2007-2002
(TIMI) and TEC2008-02685/TEC (NARRA), and by the European
Commission in the framework of the FP7 Network of Excellence in
Wireless COMmunications NEWCOM++ (contract n. 216715) and
COST Action IC0803 (RFCSET).
REFERENCES
[1] D. Akos, A Software Radio Approach to Global Navigation Satellite
System Receiver Design, Ph.D. thesis, College of Engineering and
Technology, Ohio University, Aug. 1997.
[2] K. Krumvieda, P. Madhani, C. Cloman, E. Olson, J. Thomas, P. Axelrad,
and W. Kober, “A complete IF software GPS receiver: A tutorial about
the details,” in Proceedings of the 14th International Technical Meeting
of the Satellite Division of the Institute of Navigation (ION GPS’01),
Salt Lake City, UT, Sept 2001, pp. 789–829.
[3] V. Chakravarthy, J. Tsui, D. Lin, and J. Schamus, “Software GPS
receiver,GPS Solutions, vol. 5, no. 2, pp. 63–70, Oct. 2001.
[4] J. Bao-Yen Tsui, Fundamentals of Global Positioning System Receivers.
A Software Approach, John Wiley & Sons, Inc., Hoboken, NJ, 2nd
edition, 2005.
[5] K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, and S. H. Jensen,
A Software–Defined GPS and Galileo Receiver. A Single–Frequency
Approach, Applied and Numerical Harmonic Analysis. Birkh¨
auser,
Boston, MA, 2007.
[6] B. M. Ledvina, S. P. Powell, P. M. Kintner, and M. L. Psiaki, “A
12–channel real–time GPS L1 software receiver,” in Proceedings of the
National Technical Meeting of the Institute of Navigation (ION NTM’03),
Anaheim, CA, Jan. 2003, pp. 767–782.
[7] G. W. Heckler and J. L. Garrison, “SIMD correlator library for GNSS
software receivers, GPS Solutions, vol. 10, no. 4, pp. 269–276, Nov.
2006.
[8] H. Hurskainen, J. Raasakka, T. Ahonen, and J. Nurmi, “Multicore
software–defined radio architecture for GNSS receiver signal process-
ing,” EURASIP Journal on Embedded Systems, vol. 2009, 2009, Article
ID 543720.
[9] T. E. Humphreys, J. A. Bhatti, T. Pany, B. M. Ledvina, and B. W.
O’Hanlon, “Exploiting multicore technology in software–defined GNSS
receivers, in Proc. of the 22nd International Meeting of the Satellite
Division of The Institute of Navigation (ION GNSS’09), Savannah, GA,
Sept. 2009, pp. 326–338.
[10] T. Hobiger, T. Gotoh, J. Amagai, Y. Koyama, and T. Kondo, “A GPU
based real–time GPS software receiver,GPS Solutions, vol. 14, no. 2,
pp. 207–216, Mar. 2010.
[11] A. Mitelman, J. Almqvist, R. H ˚
akanson, D. Karlsson, F. Lindstr¨
om,
T. Renstr¨
om, C. St˚
ahlberg, and J. Tidd, “Testing software receivers,
GPS World, vol. 20, no. 12, pp. 28–34, Dec. 2009.
[12] M. G. Petovello, C. O’Driscoll, G. Lachapelle, D. Borio, and H. Murtaza,
“Architecture and benefits of an advanced GNSS software receiver,
Positioning, vol. 1, no. 1, pp. 66–78, 2009.
[13] X. Li and D. Akos, “Implementation and performance of clock steering
in a software GPS L1 single frequency receiver,” Navigation: Journal
of The Institute of Navigation, vol. 57, no. 1, pp. 69–85, Spring 2010.
[14] M. Anghileri, T. Pany, D. Sanrom`
a-G¨
uixens, J.-H. Won, A. Sicramaz-
Ayaz, C. St¨
ober, I. Kr¨
amer, D. D¨
otterb¨
ock, G. W. Hein, and B. Eiss-
feller, “Performance evaluation of a multi–frequency GPS/Galileo/SBAS
software receiver, in Proceedings of the 20th International Technical
Meeting of the Satellite Division of the Institute of Navigation (ION
GNSS’07), Fort Worth, TX, Sept. 2007, pp. 2749–2761.
[15] M. Fantino, A. Molino, and M. Nicola, “N–Gene GNSS receiver:
Benefits of software radio in navigation,” in Proceedings of the European
Navigation Conference - Global Navigation Satellite Systems (ENC-
GNSS), Naples, Italy, May 2009.
[16] B. W. Tolman, R. B. Harris, T. Gaussiran, D. Munton, J. Little, R. Mach,
S. Nelsen, B. Renfro, and D. Schlossberg, “The GPS toolkit - open
source GPS software,” in Proceedings of the 17th International Technical
Meeting of the Satellite Division of the Institute of Navigation (ION
GNSS’04), Long Beach, CA, 21–24 Sept. 2004, pp. 2044–2053.
[17] D. Salazar, M. Hern´
andez-Pajares, J. M. Juan, and J. Sanz, “GNSS data
management and processing with the GPSTk,” GPS Solutions, vol. 14,
no. 3, pp. 293–299, June 2010.
[18] M. A. Garc´
ıa-Matamoros, D. Kuijper, and P. L. Righetti, “NAPEOS:
ESA/ESOC Navigation Package for Earth Observation Satellites, in
Proceedings of the European Workshop on Flight Dynamics Facilities,
Darmstadt, Germany, Sept. 2003.
[19] J. M. Dow, R. E. Neilan, and C. Rizos, “The International GNSS Service
in a changing landscape of Global Navigation Satellite Systems,Journal
of Geodesy, vol. 83, no. 7, pp. 191–198, July 2009.
[20] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object–Oriented Software, Addison Wesley, Upper
Saddle River, NJ, 1995.
[21] B. P. Douglass, Real–Time Design Patterns: Robust Scalable Architec-
ture for Real–Time Systems, Addison Wesley, Upper Saddle River, NJ,
2002.
[22] D. C. Schmidt, M. Stal, H. Rohnert, and F. Buschmann, Pattern–
Oriented Software Architecture: Patterns for Concurrent and Networked
Objects, vol. 2 of Wiley Series in Software Design Patterns, John Wiley
& Sons, Chichester, England, 2000.
[23] A. Shalloway and J. R. Trott, Design Patterns Explained: A New
Perspective on Object-Oriented Design, Addison–Wesley Professional,
Reading, MA, 2nd edition, 2004.
[24] J. Kerievsky, Refactoring to Patterns, Addison–Wesley Professional,
Reading, MA, 2004.
[25] A. Shalyto, N. Shamgunov, and G. Korneev, “State machine design pat-
tern,” in Proc. of the 4th International Conference on .NET Technologies,
Plzeˇ
n, Czech Republic, June 2006, vol. of short communication papers,
pp. 51–57.
[26] A. Alexandrescu, Modern C++ Design: Generic Programming and
Design Patterns Applied, Addison Wesley, Upper Saddle River, NJ,
2001.
[27] B. W. Kernighan and P. J. Plauger, The Elements of Programming Style,
McGraw–Hill, New York, 1974.
[28] T. L. Veldhuizen, “C++ templates are Turing complete,” Tech. Rep.,
Indiana University Computer Science, 2003.
[29] N. M. Josuttis, The C++ Standard Library: A Tutorial and Reference,
Addison Wesley Longman, Inc., Reading, MA, 1999.
[30] S. Meyers, Effective STL: 50 Specific Ways to Improve Your Use of
the Standard Template Library, Addison-Wesley Professional, Reading,
MA, 2001.
[31] D. Abrahams and A. Gurtovoy, C++ Template Metaprogramming:
Concepts, Tools, and Techniques from Boost and Beyond, Addison-
Wesley Professional, Reading, MA, 2004.
[32] B. Karlsson, Beyond the C++ Standard Library: An Introduction to
Boost, Addison-Wesley Professional, Reading, MA, 2005.
[33] S. Meyers, Effective C++: 55 Specific Ways to Improve Your Programs
and Designs, Computing Series. Addison–Wesley Professional, Upper
Saddle River, NJ, 3rd edition, May 2005.
[34] S. Meyers, More Effective C++: 35 New Ways to Improve Your Programs
and Designs, Computing Series. Addison–Wesley Professional, Upper
Saddle River, NJ, Sept. 1996.
[35] D. Janzen and H. Saiedian, “Test–driven development concepts, taxon-
omy, and future direction, Computer, vol. 38, no. 9, pp. 43–50, Sept.
2005.
[36] F. Shull, G. Melnik, B. Turhan, L. Layman, M. Diep, and H. Erdogmus,
“What do we know about test–driven development?,” IEEE Software,
vol. 27, no. 6, pp. 16–19, Nov.–Dec. 2010.
[37] ANSI/IEEE Std 1008–1987, IEEE Standard for Software Unit Testing,
1986.
[38] M. J. Johnson, E. M. Maximilien, C.-W. Ho, and L. Williams, “Incorpo-
rating performance testing in test–driven development,IEEE Software,
vol. 24, no. 3, pp. 67–73, May–June 2007.
[39] “Apache Subversion,” http://subversion.apache.org/, Retrieved: October
21, 2010.
[40] “git. The fast version control system,” http://git-scm.com/, Retrieved:
October 21, 2010.
[41] “trac. Integrated SCM & Project Management,” http://trac.edgewall.org/,
Retrieved: October 21, 2010.
[42] “Redmine,” http://www.redmine.org/, Retrieved: October 21, 2010.
[43] “Eclipse,” http://www.eclipse.org/, Retrieved: October 21, 2010.
[44] “Boost.build v2 User Manual,” http://www.boost.org/boost-
build2/doc/html/index.html, Retrieved: October 21, 2010.
[45] “CMake,” http://www.cmake.org/, Retrieved: October 21, 2010.
[46] “GCC, the GNU Compiler Collection,” http://gcc.gnu.org, Retrieved:
October 21, 2010.
[47] “GNU Radio,” http://gnuradio.org/redmine/wiki/gnuradio, Retrieved:
October 21, 2010.
[48] Ettus Research, “USRP motherboard datasheet. Universal Software
Radio Peripheral. The foundation for complete software radio systems,”
http://www.ettus.com/downloads/ettus ds usrp v7.pdf, Retrieved: Octo-
ber 21, 2010.
[49] Ettus Research, “Datasheet for the BasicRX, BasicTX,
LFRX, LFTX, TVRX, and DBSRX daughterboards. TX and
RX daughterboards for the USRP software radio system,”
http://www.ettus.com/downloads/ettus ds USRP TXRX v5b.pdf,
Retrieved: October 21, 2010.
[50] SiGe Semiconductor, “SE4120L GNSS receiver IC datasheet,” May 26,
2009, Ottawa, ON, Canada.
[51] Science Applications International Corporation, Interface Specification
IS-GPS-200 Revision E. Navstar GPS Space Segment/Navigation User
Interfaces, El Segundo, CA, June 8, 2010.
[52] Science Applications International Corporation, Interface Specification
IS-GPS-800 Revision A. Navstar GPS Space Segment/User Segment L1C
Interfaces, El Segundo, CA, June 8, 2010.
[53] Science Applications International Corporation, Interface Specification
IS-GPS-705 Revision A. Navstar GPS Space Segment/User Segment L5
Interfaces, El Segundo, CA, June 8, 2010.
[54] Russian Institute of Space Device Engineering, Moscow, Russia, Global
Navigation Satellite System GLONASS. Interface Control Document.
Navigational radiosignal in bands L1, L2, 2008, Version 5.1 down-
loadable from http://www.glonass-ianc.rsa.ru.
[55] European Union, European GNSS (Galileo) Open Service. Signal In
Space Interface Control Document. Ref: OS SIS ICD, Issue 1, February
2010.
[56] Japan Aerospace Exploration Agency, Quasi–Zenith Satellite System
Navigation Service. Interface Specification for QZSS (IS-QZSS), Draft
V1.2, March 2010, Downloadable from http://qz-vision.jaxa.jp/USE/is-
qzss/index e.html.
[57] RTCA, Washington, DC, Minimum Operational Performance Standards
for Global Positioning System/Wide Area Augmentation System Airborne
Equipment, DO–229D, Dec. 13 2006.
[58] European Commission. Directorate-General for Energy and Transport,
EGNOS Service Definition Document Open Service. Ref: EGN–SDD OS,
Revision 1.0, Oct. 1 2009.
[59] VITA Standards Organization (VSO), VITA Radio Transport (VRT)
Standard, VITA-49.0, October 2007, Draft 0.21.
[60] C. Kelley, J. Barnes, and J Cheng, “OpenSource GPS. Open source
software for learning about GPS,” in Proc. of the 15th International
Technical Meeting of the Satellite Division of the Institute of Navigation
(ION GPS’02), Portland, OR, Sept. 2002.
[61] “Boost C++ libraries. Basic linear algebra library,
http://www.boost.org/doc/libs/1 44 0/libs/numeric/ublas/doc/index.htm,
Retrieved: October 21, 2010.
[62] M. Frigo and S. G. Johnson, “The design and implementation of
FFTW3,” Proceedings of the IEEE, vol. 93, no. 2, pp. 216–231,
2005, Special issue on “Program Generation, Optimization, and Platform
Adaptation”.
[63] W. Gurtner and L. Estey, RINEX. The Receiver Independent Exchange
Format Version 3.01, June 2009.
[64] “Google C++ Testing Framework,” http://code.google.com/p/googletest/,
Retrieved: October 21, 2010.
[65] “Google Logging Library,” http://code.google.com/p/google-glog/, Re-
trieved: October 21, 2010.
[66] “Google Performance Tools,” http://code.google.com/p/google-
perftools/, Retrieved: October 21, 2010.
... Some early advances with this approach were achieved by Akos (1997) and Borre (2003). Later with a similar approach, many software receivers were developed (Anghileri et al., 2007;Fernández-Prades et al., 2010, 2011Ledvina et al., 2003;Molino et al., 2009;Petovello et al., 2008). A MATLAB-based open-source GNSS SDR receiver's collection has been published recently, with a clear description of the code structure and test framework (Bernabeu et al., 2022). ...
... GNSS-SDR can read assistance data such as the satellite's ephemeris and almanacs externally through the Internet for faster time to first fix (TTFF). The detailed GNSS-SDR architecture, framework and modules are described in Fernández-Prades et al. (2010, 2011, 2012. ...
Article
Full-text available
The GNSS software receiver has evolved as a promising tool for researchers and developers because of its flexibility and reconfigurability. As modernized GNSS signals have been emerging day by day, the need to adapt the software receiver to address the upcoming challenges of GNSS navigation has become inevitable. The main aim of this work is to assess the existing Global Navigation Satellite System Software Defined Receiver (GNSS-SDR) tool for Indian Regional Navigation Satellite System (IRNSS) signals using a low-cost RTL-SDR front-end. The IRNSS software receiver chain is developed using GNSS-SDR code and framework. GNSS-SDR is an open-source tool developed by the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC) of Spain. This work is useful for carrying out various GNSS-related applications using IRNSS signals in the future and paves the way for further research and development of the IRNSS system by using it as a research/academic tool.
... GNSS-SDR provides an interface to different suitable RF front-ends and implements all the receiver chain up to the navigation solution. Its design allows any kind of customization, including interchangeability of signal sources, signal processing algorithms, interoperability with other systems, output formats, and offers interfaces to all the intermediate signals, parameters and variables [4]. Code for the platform is mainly developed in C++ as an open source and uses a considerable part of the GNU Radio framework for all signal processing activities of the receivers. ...
... The work described here is only related to the acquisition interface, and more information on it may be found a the next sections. It is outside the range of this report to explain the rest of the interfaces, however documentation for the platform is excellent, and further details on the rest of the main GNSS related interfaces may be found at [6], [4] and [7]. ...
Technical Report
Full-text available
Description and Implementation of the QuickSync ALgorithm in the GNSS-SDR platform to obtain faster GNSS acquisition in GPS and Galileo receivers by means of the Sparse Fourier Transform
... The microcontroller implements high-level matrix operations and orchestrates the acquisition search grid. Once the signal is acquired, the platform activates a real-time beamformer whose output is fed using a Gigabit Ethernet bus to an open-source GNSS Software Defined Receiver (SDR) running on a commodity PC [7, 8] . The platform was validated through several tests, including anechoic chamber measurements. ...
Article
Full-text available
The use of Global Navigation Satellite System (GNSS) technology in safety- and mission-critical services has raised the concern in recent times about possible GNSS Denial of Service (DoS) situations. In that sense, the GNSS vulnerability to interferences could become a real threat to the entire service integrity. In this work the interference mitigation capability of antenna arrays in GNSS signal acquisition process is addressed from a realistic implementation perspective. A two-fold objective is pursued: on one hand, we introduce the design and the implementation of a flexible FPGA-based GNSS antenna-array receiver platform, intended to be used as a reliable research tool tightly coupled with software defined GNSS receivers. In that sense, all the platform components, from the multichannel coherent front-end to the FPGA hardware accelerators and the embedded software defined processor, are presented in detail and validated using RF signal generators with realistic GPS-like waveforms. On the other hand, a novel array-based acquisition algorithm that uses the Generalized Likelihood Ratio Test is implemented using the platform. Statistics extraction modules such as the estimation of the array autocovariance matrix are included. Realistic interference scenarios were tested, including CW jamming and Long Term Evolution (LTE)-like in-band interferences. The results show that the algorithm offers excellent protection against uncorrelated directional interferences, even if the array is moderately uncalibrated.
... Following a thorough study of the literature and related works about SDR for GNSS environment ( [6], [7], [1], [8], [4], [3], [9], [10]), an overview of the most significant implementations and developed techniques is given in this section. Over the past ten/fifteen years a lot of work and effort has been produced around GNSS SDR. ...
Conference Paper
Full-text available
Co-existence of different constellations for Global Navigation Satellite Systems (GNSS) provides new opportunities to improve the services offered to the users, but also poses new challenges and increased complexity in receiver design. To ensure flexibility and dynamic re-configuration, Software Defined Radio (SDR) receivers seem to be the natural solution, both for the research and industrial communities. This paper wants to provide an overview of the solutions proposed until now, trying to highlight what the trend is in SDR GNSS receiver development, and to what extent currently proposed SDR approaches are able to replace traditional hardware-based design.
Article
This paper investigates the design of a potential Software Defined Radio (SDR) based prototype for Filter Bank based Multi-Carrier Transmission. It allows for implementing and testing transmitter and receiver in real-time on Universal Software Radio Peripheral (USRP) by using two USRP boards. Additionally, an implementation of some classic channel models in a separate USRP board has been used for emulating a propagation channel. The presented prototyping system supports FBMC waveform but also Orthogonal Frequency Division Multi-carriers(OFDM) one using MATLAB routines. With this motivation, we propose a study on real-time decoding of Offset Quadrature Amplitude Modulation FBMC (OQAM-FBMC) radio frames. In this system, data recovery at the receiver is very sensitive to time and frequency synchronization of the frames. This problem was addressed in many theoretical research works. However, considering its practical aspects in the context of a realtime radio transmission, a signal processing block is required to satisfy a trade-off between the accuracy and the latency. We especially recognize different limits, imposed by both hardware and software entities, to the real-time system.
Conference Paper
Full-text available
Software defined radio (SDR) technology has become popular for design and implementation of a versatile, modular, and reconfigurable GPS receivers. SDR receiver developers continuously advance algorithmic and/or hardware accelerator integration solutions. There exists a need in fast prototyping and testing instrumentation to shorten development and redesign cycles. This paper demonstrates an integrated instrumentation platform for GPS signal simulation, testing and development, including fast prototyping hardware solutions.
Article
Recent advances in Autonomous Underwater Vehicle (AUV) technology have facilitated the collection of oceanographic data at a fraction of the cost of ship-based sampling methods. Unlike oceanographic data collection in the deep ocean, operation of AUVs in coastal regions exposes them to the risk of collision with ships and land. Such concerns are particularly prominent for slow-moving AUVs since ocean current magnitudes are often strong enough to alter the planned path significantly. Prior work using predictive ocean currents relies upon deterministic outcomes, which do not account for the uncertainty in the ocean current predictions themselves. To improve the safety and reliability of AUV operation in coastal regions, we introduce two stochastic planners: (a) a Minimum Expected Risk planner and (b) a risk-aware Markov Decision Process, both of which have the ability to utilize ocean current predictions probabilistically. We report results from extensive simulation studies in realistic ocean current fields obtained from widely used regional ocean models. Our simulations show that the proposed planners have lower collision risk than state-of-the-art methods. We present additional results from field experiments where ocean current predictions were used to plan the paths of two Slocum gliders. Field trials indicate the practical usefulness of our techniques over long-term deployments, showing them to be ideal for AUV operations.
Article
The National Institute for Aerospace Technology NanoSat-1B Earth orbiting satellite uses Sun sensors as part of the attitude determination and control system. The sensors have a truncated pyramidal structure with five solar cells. To simplify the work of the Sun sensors software, a new solar cell model is introduced. This model allows for a 160 circ^{circ} field of view, and compared with the usual one is simpler and has a similar accuracy. This paper proposes a calibration procedure that estimates the direction of solar cells, once integrated in the truncated pyramid structure. In addition, this paper proposes a space qualification method, with the satellite in orbit. This method does not need a reference sensor, but instead it uses combinations of groups of solar cells to obtain data bands, so averaged results can be obtained. Combining the calibration and qualification procedures, the precision of the Sun sensor improves from the original pm7.5circ{pm}{7.5}^{circ} to pm1.8circ{pm}{1.8}^{circ} . With this precision, it was possible to extend the operational performance of the satellite.
Article
Nonlinear state estimation plays a major role in many real-life applications. Recently, some sigma-point filters, such as the unscented Kalman filter, the particle filter, or the cubature Kalman filter have been proposed as promising substitutes for the conventional extended Kalman filter. For multisensor fusion, the information form of the Kalman filter is preferred over standard covariance filters due to its simpler measurement update stage. This paper presents a new state estimation algorithm called the square root cubature information filter (SRCIF) for nonlinear systems. The cubature information filter is first derived from an extended information filter and a recently developed cubature Kalman filter. For numerical accuracy, its square root version is then developed. Unlike the extended Kalman or extended information filters, the proposed filter does not require the evaluation of Jacobians during state estimation. The proposed approach is further extended for use in multisensor state estimation. The efficacy of the SRCIF is demonstrated by a simulation example of a permanent magnet synchronous motor.
Article
Full-text available
This paper presents a new object-oriented design pattern — State Machine design pattern. This pattern extends capabilities of State design pattern. These patterns allow an object to alter its behavior when its internal state changes. Introduced event-driven approach loosens coupling. Thus automata could be constructed from independent state classes. The classes designed with State Machine pattern are more reusable than ones designed with State pattern.
Article
We discuss GPS receiver architectures based on software defined radio techniques. The reason for doing this is to obtain a reconfigurable receiver with a wide range of ap- plications. There is a need for a unified platform that will allow receiver development and testing for various applica- tions; this speeds the design process and reduces the costs. With the current functionality of the GPS constellation and the promise of the complete Galileo constellation, efforts have been focused on the 1575.42 MHz L1 signals for the software receiver implementation. These single frequency navigation signals, particularly when coupled with space based augmentation such as WAAS or EGNOS are likely to fulfill the navigation needs of most users. In order to develop and test the software algorithms, a com- plete L1-band antenna and RF front-end has been designed capable of processing the wider bandwidth necessary for the Galileo L1 BOC(1,1) signal. This front end provides digital samples to the host computer for the software re- ceiver implementation. In addition, a GNSS signal generator was designed and im- plemented in Simulink to be used for algorithm develop- ment and testing to offer the user the option of using the front-end to collect and process actual GPS data or gener- ate simulated GPS signals. The GPS software receiver was implemented in Matlab and is capable of performing GPS satellite acquisition and tracking on both real GPS data and simulated GPS data with extreme properties. A complete GNSS software receiver was implemented and the receiver is able to perform acquisition, code and carrier tracking, navigation bit extraction, navigation data decod- ing, pseudorange calculations, and position calculations. We have created a pedagogical tool for the GPS newcomer: A front-end which obtains actual GPS data via the USB port, a complete Matlab implementation that provides a real-time GPS and Galileo (as defined by the current ICD) software receiver, and finally a textbook, Borre et al. (2006), that describes the whole thing.
Article
Introducing the Boost libraries: the next breakthrough in C++ programmingBoost takes you far beyond the C++ Standard Library, making C++ programming more elegant, robust, and productive. Now, for the first time, a leading Boost expert systematically introduces the broad set of Boost libraries and teaches best practices for their use.Writing for intermediate-to-advanced C++ developers, Björn Karlsson briefly outlines all 58 Boost libraries, and then presents comprehensive coverage of 12 libraries you're likely to find especially useful. Karlsson's topics range from smart pointers and conversions to containers and data structures, explaining exactly how using each library can improve your code. He offers detailed coverage of higher-order function objects that enable you to write code that is more concise, expressive, and readable. He even takes you "behind the scenes" with Boost, revealing tools and techniques for creating your own generic libraries.Coverage includes Smart pointers that provide automatic lifetime management of objects and simplify resource sharing Consistent, best-practice solutions for performing type conversions and lexical conversions Utility classes that make programming simpler and clearer Flexible container libraries that solve common problems not covered by the C++ Standard Library Powerful support for regular expressions with Boost.Regex Function objects defined at the call site with Boost.Bind and Boost.Lambda More flexible callbacks with Boost.Function Managed signals and slots (a.k.a. the Observer pattern) with Boost.SignalsThe Boost libraries are proving so useful that many of them are planned for inclusion in the next version of the C++ Standard Library. Get your head start now, with Beyond the C++ Standard Library.© Copyright Pearson Education. All rights reserved.
Article
“This is Effective C++ volume three - it's really that good.” - Herb Sutter, independent consultant and secretary of the ISO/ANSI C++ standards committee “There are very few books which all C++ programmers must have. Add Effective STL to that list.” - Thomas Becker, Senior Software Engineer, Zephyr Associates, Inc., and columnist, C/C++ Users Journal C++'s Standard Template Library is revolutionary, but learning to use it well has always been a challenge. Until now. In this book, best-selling author Scott Meyers (Effective C++, and More Effective C++) reveals the critical rules of thumb employed by the experts - the things they almost always do or almost always avoid doing - to get the most out of the library.Other books describe what's in the STL. Effective STL shows you how to use it. Each of the book's 50 guidelines is backed by Meyers' legendary analysis and incisive examples, so you'll learn not only what to do, but also when to do it - and why.Highlights of Effective STL include: Advice on choosing among standard STL containers (like vector and list), nonstandard STL containers (like hash_set and hash_map), and non-STL containers (like bitset). Techniques to maximize the efficiency of the STL and the programs that use it. Insights into the behavior of iterators, function objects, and allocators, including things you should not do. Guidance for the proper use of algorithms and member functions whose names are the same (e.g., find), but whose actions differ in subtle (but important) ways. Discussions of potential portability problems, including straightforward ways to avoid them. Like Meyers' previous books, Effective STL is filled with proven wisdom that comes only from experience. Its clear, concise, penetrating style makes it an essential resource for every STL programmer.