The aim of this project is to provide an open source (and, hopefully, high–quality and well–written) Global Navigation Satellite Systems software defined receiver (GNSS-SDR). Since “well-written software” is an elusive concept, we rely on the systematic application of software design patterns and proven programming methodologies. 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 proposed software receiver targets multi-constellation/multi-frequency architectures, pursuing the goals of efficiency, modularity, interoperability, and flexibility demanded by user domains that require non-standard features, such as earth observers or geodesists, and allowing applications such as the observation of the ionosphere, GNSS reflectometry, signal quality monitoring, space weather, and high-accuracy (cm-level) positioning based on carrier-phase navigation techniques. In this project, we focus on signal processing, understood as the process between the ADC and the computation of code and phase observables, including the demodulation of the navigation message. We purposely omit data processing, understood as the computation of the navigation solution from the observables and the navigation message, since there are a number of well-established libraries and applications for that (also in the open source side, such as GPSTk).
The source code is 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, allowing discussion based on tangible code and the analysis of results obtained with real signals. Hence, GNSS-SDR is also intended to be a framework for algorithm testing and an educational tool, since everybody is allowed to peruse the source code, see how the receiver is actually implemented, and contribute with improvements, bug fixes, and addition of new features.
Although GNSS-SDR is still far from full-featured commercial software receivers, it constitutes a free platform that can be continuously improved by peer-reviewing and contributions from users and developers around the world, unleashing the potential of collaborative research in the field of GNSS software receivers.
Motivation
Location has become an embedded feature not only on medium and high-end mobile phones, but also on other portable devices such as digital cameras and portable gaming consoles. This massive deployment of GNSS receivers requires a high level of integration, a low cost, a small size and a low power consumption, which has pushed the leading GPS integrated circuit (IC) manufacturers to offer single-chip solutions easy to integrate in multi-function devices. Thus, the radio frequency (RF) front-end and the baseband processing are jointly implemented in monolithic ICs, tiny black boxes leaving the user no possibility to interact or to modify the internal architecture or the algorithmics.
This approach is very convenient for location based services and applications, since users and developers are interested in using the location information (eventually taking advantage of complementary information coming from wireless network providers) but not in how the position has been obtained. Good examples of this abstraction can be found in the application programming interfaces (APIs) of two major operating systems for mobile devices: Apple’s iOS provides a core location framework with objects that incorporate the geographical coordinates and altitude of the device’s location along with values indicating the accuracy of the measurements, when those measurements were made, and information about the speed and heading in which the device is moving. A similar situation is found in Android, which provides a location package that contains classes with descriptive-named methods such as getLatitude(), getLongitude(), getAltitude(), getSpeed(), getAccuracy() and so on. This abstraction layer simplifies a lot the job of the application developer, but leaves no way to observe or modify any internal aspect of the receiver.
As an opposite driving force, the advent of a number of new GNSS (Galileo, COMPASS), the modernization of existing ones (GPS L2C and L5, GLONASS L3OC) and the deployment of augmentation systems (both satellite-based, such as WAAS in the USA, EGNOS in Europe, and MSAS in Japan; and ground-based, such as WiFi or cellular-network based positioning) depict an unprecedented landscape for receiver designers. In the forthcoming years, many new signals, systems and frequency bands will be available for civil use, and their full exploitation will require a thoughtful redesign of the receiver’s architecture and inner algorithms. In addition to being black boxes hidden by an abstraction layer, current mass-market GPS ICs are clearly constrained in terms of configurability, flexibility and the capacity to be upgraded. New available signals pose the challenge of multisystem, multiband receivers’ design, including issues such as interference countermeasures, high-precision positioning for the mass-market, assisted GNSS and tight hybridization with other technologies.
These facts have headed receivers’ designers to the software radio paradigm, in which an analog front-end performs the RF to intermediate frequency (or directly to baseband) conversion prior to the analog-to-digital converter (ADC). All remaining signal and data processing, including the hybridization with other systems, are defined in the software domain. This approach provides the designers with a high degree of flexibility, allowing full access and possibility of modification in the whole receiver chain. GNSS-SDR provides an open source framework for such signal processing, from the interface to commercially available RF front-ends to the computation of code and phase observables, the natural inputs of most geodetic processing software. Thus, users are able to inspect and modify every aspect of the signal processing performed by the receiver, something not possible when working with integrated circuits.
Philosophy
We aim to provide a well-written GNSS software receiver. In the absence of a comprehensive quantitative measure of software quality, in this project we try to:
- Follow software design patterns
- Apply good coding practices
- Avoid the reinvention-of-the-wheel
Generic programming is a well–established style in which algorithms 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 parametrized types, 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 programming language, let us first discuss the choice of C++ for GNSS-SDR. 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. Of course, one of its main strengths is that it also allows close to the metal programming, thus addressing efficiency and enabling the squeezing of the underlying hardware processor.
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 higher levels of abstraction. The next step in generic programming applied to C++ was Boost, a set of free, expertly designed, peer–reviewed portable C++ source libraries. 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.
Moreover, a new version of the language, named C++11, was approved in August, 2011 as an ISO/IEC (International Organization of Standardization / International Electrotechnical Commission) standard, and was published with the name ISO/IEC 14882:2011(E) Programming Languages – C++, Third Edition. This ensures that decades from now, today’s standard conforming C++ programs will run with minimal modifications, just as an older C++ programs do today. It also ensures portability and the availability of compilers. This new version provides facilities for writing concurrent code (e.g. for multicore machines) in a type safe-manner, smart pointers, new memory-optimized ways of object handling, and tons of new core and library features that are very convenient for software radio applications.
See also:
Back to articles
Project description, motivation and phylosophy.
