Abstract
Taking the work conducted by the global navigation satellite system (GNSS) software-defined radio (SDR) working group during the last decade as a seed, this contribution summarizes, for the first time, the history of GNSS SDR development. This report highlights selected SDR implementations and achievements that are available to the public or that influenced the general development of SDR. Aspects related to the standardization process of intermediate-frequency sample data and metadata are discussed, and an update of the Institute of Navigation SDR Standard is proposed. This work focuses on GNSS SDR implementations in general-purpose processors and leaves aside developments conducted on field programmable gate array and application-specific integrated circuit platforms. Data collection systems (i.e., front-ends) have always been of paramount importance for GNSS SDRs and are thus partly covered in this work. This report represents the knowledge of the authors but is not meant as a complete description of SDR history.
1 INTRODUCTION
Receiver development has always been an integral part of satellite navigation, ever since early studies were conducted for the U.S. Global Positioning System (GPS). The very first receivers were huge devices, enabling a correlation of received satellite signals with internally generated code and carrier replicas by a mixture of digital and analog electronics (Eissfeller & Won, 2017). Advances in semiconductor technology soon enabled signal processing on dedicated chips. This technology was complex to handle and was primarily located within the U.S. industry. Despite the success of GPS and its Russian counterpart globalnaya navigazionnaya sputnikovaya sistema (GLONASS), internal receiver technology was barely accessible to the broader research community for a long time, as it seemed to be impossible to realize global navigation satellite system (GNSS) signal processing on low-cost computers. Even in 1996, a key receiver design pioneer expressed skepticism that general-purpose microprocessors were, or would ever be, a suitable platform for implementing a GNSS receiver (Kaplan, 1996).
The situation radically changed when the algorithms of a GPS receiver were first implemented as MATLAB software on a desktop personal computer (PC) and estimates of digital signal processor (DSP) resources required to run the algorithms in real time were encouraging (Akos & Braasch, 1996; Akos, 1997). Soon after, real-time processing was demonstrated, even on conventional PCs, and the widespread use of software radio technology took off with exponential growth. Interestingly, software radio technology did not replace existing hardware receivers usually realized as one or more application-specific integrated circuits (ASICs), but complemented these receivers, allowing researchers to easily implement and test new algorithms or to develop highly specialized receivers with reasonable effort. Today, this is a well-established approach for military, scientific, and even commercial applications, as described by Curran et al. (2018).
As different research groups developed their own software radios, they used different data collection systems to sample GNSS signals. Whereas the data format of digital GNSS signal streams is comparably easy to describe, the widespread use of software radio technology made it necessary to introduce a certain level of standardization, which was finally achieved by a group of researchers, as documented by Gunawardena et al. (2021). The result was the so-called Institute of Navigation (ION) software-defined radio (SDR) Standard (ION SDR Working Group, 2020).
As technology evolved further, new GNSS software radios emerged, and some deficiencies of the ION SDR Standard became apparent (Clements et al., 2021). These conditions prompted the present paper, whose contributions are four-fold. First, it presents the first history of GNSS SDR development (Section 2). Second, it offers a detailed description of select GNSS SDRs (Section 3). Third, it overviews recent front-end developments (Section 4). Finally, it summarizes the history of the ION SDR Standard and proposes an update thereto (Section 5).
2 GNSS SDR HISTORY
The history of GNSS SDR requires more than a bit of recollection, which can be fraught with inaccuracies, none of which are intentional in the present work. Corrections would always be welcome.
The roots of GNSS SDR can be traced to Ohio University’s Avionics Engineering Center around 1994. Professor Michael Braasch, a newly minted faculty member of the Electrical and Computer Engineering Department and already recognized as an expert in GNSS multipath, was interested in creating a high-fidelity simulation of the internal signal processing within GPS and GLONASS receivers. Dennis Akos, a Ph.D. student in the department, was intrigued by the idea. Already harboring a keen interest in computer science and programming, Akos took on the simulation project at Braasch’s request under the Federal Aviation Administration (FAA)/National Aeronautics and Space Administration (NASA) Joint University Program. Meanwhile, publication of “The Software Radio Architecture” in the 1995 IEEE Communication Magazine (Mitola, 1995) fueled Akos’s and Braasch’s thinking that this “simulation” could instead be targeted toward an actual software radio implementation. The result was the first publication on GNSS SDR, which appeared in the proceedings of the 1996 ION Annual Meeting (Akos & Braasch, 1996).
Development of this initial simulation/implementation was significantly furthered through cooperation with Dr. James B. Y. Tsui of the Wright-Patterson Air Force Base. Well recognized as an expert in digital receivers, Tsui had recently taken an interest in satellite navigation. In 1995, two summer interns, Dennis Akos from Ohio University and Michael Stockmaster from The Ohio State University, worked under Tsui’s guidance to develop a MATLAB implementation of the signal processing required for basic GPS receiver operation. A digital oscilloscope was used to capture the initial intermediate-frequency (IF) data that were critical for developing and debugging those early algorithms. Akos was responsible for the lower-level signal processing (acquisition and code/carrier tracking), while Stockmaster implemented the navigation solution. The cumulative result was the first-ever GPS SDR implementation. Although fully operational, it was “slow as molasses”: processing 30 s of IF data required hours of computation time. Tsui published the first textbook on GPS SDR in 2000 (Tsui, 2000). A parallel contribution of this initial effort was the direct radio-frequency (RF) sampling front-end, which garnered significant interest and pushed advances in analog-to-digital converter (ADC) development (Akos et al., 1999).
After receiving his Ph.D. in 1997, Akos started his academic career as an Assistant Professor in the Systemteknik Department of Luleå University of Technology in Sweden, where he taught a course on computer architecture. It was here that GPS SDR first achieved real-time operation. For a class project, Akos provided a MATLAB-based GPS SDR and challenged a group of students to “get it to run as fast as possible,” subject to the requirement that the complex accumulation products for each channel were within 10% of those produced by the original MATLAB-based GPS SDR. In 1999, the first “real-time” operation was achieved, processing 60 s of IF data in 55 s. This was a notable achievement at the time, given that renowned GPS expert Philip Ward, who was responsible for some of the first GPS receivers, had recently expressed skepticism about the prospect of a fully software-defined real-time GPS SDR, writing “The integrate-and-dump accumulators provide filtering and resampling at the processor baseband input rate, which is around 200 Hz [… and] well within the interrupt servicing rate of modern high-speed microprocessors. But the 5- to 50-MHz rates [of intermediate frequency samples] would not be manageable” (Kaplan, 1996). This real-time implementation effort was headed by student Per-Ludvig Normark and led to the results published by Akos et al. (2001).
In the meantime, Kai Borre, a geodesy professor at Aalborg University, had also developed MATLAB code for GPS receivers in the mid-late 1990s. Borre’s code focused on the navigation block and included functions for the conversion of coordinates and time references, satellite position determination, and atmospheric corrections. The joint efforts of Akos, Borre, and others would later lead to a well-known book (Borre et al., 2007), a primary reference for GNSS SDR over the next years, and the related SoftGPS MATLAB receiver.
Upon graduation, Normark continued his GNSS receiver development with the GPS Laboratory at Stanford University and then returned home to Sweden, where he co-founded NordNav Technologies, which developed the first Galileo SDR, and helped establish the architecture, together with Cambridge Silicon Radio (CSR), to push GNSS to a price point acceptable for mobile phone adoption. CSR, a dominant supplier of Bluetooth hardware to the mobile phone market at the time, acquired NordNav in 2006. NordNav and CSR jointly redesigned the CSR 2.4-GHz radio to multiplex to the 1575.42-MHz GPS L1 band, exploiting the fact that most Bluetooth applications have a relatively low duty cycle. This approach, coupled with the real-time software GPS implementation, provided a near-zero-added-cost GPS receiver.
There have been numerous contributions to GNSS SDR development since these early years, many of which are from the co-authors of this paper. Selected developments by the authors are outlined in Section 3, including a survey of achievements by other researchers in Section 3.11. The authors are aware that many other important contributions are missing and make no claims of establishing a comprehensive description. To provide the reader with a better orientation about the chronological order of all developments, we present Table 1, reiterating that the selection of references is partly subjective and that similar developments have often been carried out by several research groups. The timeline demonstrates the flexibility of SDR technology, i.e., the same code base is used for GPS L1 C/A code signals and for signals of opportunitys (SOPs) from cellular terrestrial transmitters or from communication satellites in low Earth orbits (LEOs).
3 CURRENT STATUS OF GNSS SDRS
In June 2023, a quick internet search did not reveal any comprehensive listing of all GNSS SDRs. Wikipedia (2023) lists seven entries, which is far below the number of receivers known by the authors, even if the following criterion is applied to limit the scope: a GNSS SDR (or software receiver) is defined as a piece of software running on a general-purpose computer converting samples of a received GNSS signal into a position velocity and time (PVT) estimate. It is clearly understood that a front-end including ADC is required to sample the received signal, but other than that, no further functionality is allowed to be realized via hardware. With this definition, three categories of software receivers can be introduced:
Real-time receivers: Monolithic or modular software packages written in an efficient low-level programming language (such as C or C++), typically optimized for run-time efficiency and stability
Teaching/research tools: Software packages written in a high-level programming language (such as Python or MATLAB), optimized for code readability and flexibility
Snapshot receivers: Receivers optimized for very short batches of signal samples
Furthermore, the software package shall allow some configuration flexibility and (at least theoretically) support the ION SDR Standard. The following subsections introduce a few selected developments, emphasizing the rationale behind design choices and current status. Each subsection is represented by one entry in Table 2 to give the reader a quick overview of the main characteristics of each development. Section 3.1 describes the work of Psiaki, Ledvina, and Humphreys and their efforts in real-time processing on DSPs, with the bit-wise-parallel approach proving to be highly successful, even for space applications. Section 3.2 covers the work of Pany and others in their efforts with multi-constellation/multi-frequency GNSS. Section 3.3 and Section 3.4 cover the efforts of Borre and others in a readable open-source MATLAB GPS SDR starting with Borre et al. (2007), with the most recent GNSS update reported by Borre, Fernández-Hernández et al. (2022). Akos has also continued this academic development of a suite of open-source GNSS SDRs (Bernabeu et al., 2022). The widely used open-source receiver GNSS-SDR is described in Section 3.5. The AutoNav receiver used to support the development of the Korean Positioning System (KPS) is discussed in Section 3.6, and Section 3.7 provides a discussion of PyChips, the basis for tutorial classes of the ION. The Universitat Autònoma de Barcelona (UAB) snapshot GNSS software receiver is described in Section 3.8, while Section 3.9 discusses an SDR used, e.g., in authentication schemes or reflectometry or to assess the influence of non-standard GNSS transmissions. Section 3.10 extends the scope of SDR to non-GNSS signals.
At the beginning of GNSS SDR development, different receivers were linked to specific persons or research institutes; in contrast, today different receivers, tools, or code bases are often used at the same institute. Moreover, code bases first developed by a single institute have spread into different institutes. For example, the developments of Borre et al. (2007) forked into several branches (see, e.g., the work by FGI (2022), Bernabeu et al. (2022), and Zhang (2022)), as discussed in Section 3.3 and Section 3.4.
3.1 Bit-Wise Parallelism and the Emergence of GRID
The original real-time GNSS software radio work by Akos (1997) inspired an effort within the Cornell GPS group. Psiaki had been working with non-real-time software GNSS signal processing in MATLAB for about two years when he started to wonder whether the slow MATLAB operations could be translated to run in real time on a general desktop workstation. A bottleneck in GNSS digital signal processing occurs during the performance of operations that initially process the high-frequency RF front-end samples. RF front-ends typically sample at 4 MHz or faster. A 12-channel receiver would have to perform on the order of 400 million operations per second or more to achieve all of the needed signal processing. Psiaki conceived the concept of bit-wise parallel processing as a means of addressing this challenge. He recruited then-Ph.D. candidate Brent Ledvina to make an attempt at implementing these ideas in the C programming language on a real-time Linux desktop workstation. Ledvina succeeded in developing a 12-channel real-time L1 C/A-code receiver after about 6 months of effort (Ledvina et al., 2003).
The main aim of bit-wise parallelism is to work efficiently with RF front-end data that have a low number of quantization bits. If an RF front-end produces a 1-bit digital output stream, then 32 successive sign-bit samples can be stored in a single 32-bit unsigned integer word on a general-purpose processor. Thirty-two successive output samples of a 2-bit RF front-end can be stored in two 32-bit words, one containing the successive sign bits and the other containing the successive magnitude bits. Each channel of the software receiver generates a 1-bit or 2-bit representation of 32 successive samples of its IF carrier replica, both in-phase and quadrature, and the successive samples are stored in parallel in 32-bit unsigned integer words. Similarly, the channel generates a 1-bit representation of 32 successive samples of its prompt pseudorandom noise (PRN) code replica and stores them in parallel in a single 32-bit unsigned integer word. The channel also generates an early-minus-late PRN code replica that requires 1.5 bits per sample, which utilizes two 32-bit unsigned integer words to store 32 samples. These replica signals can be generated very efficiently by using pre-tabulated 32-bit words. The software receiver then performs a series of bit-wise AND, OR, XOR, and similar operations that have the effect of performing PRN code mixing and IF-to-baseband carrier mixing. The outputs of the mixing operations are contained in a small number of 32-bit words, the number of which depends on the number of bits in each RF front-end output sample and the number of bits in the IF carrier replicas.
The final operation is the accumulation of results in the 32-bit words. This operation involves sets of bit-wise Boolean operations, as per Ledvina et al. (2003), followed by a summation of the number of 1-bits in the resulting 32-bit unsigned integer words. Minimizing the execution time of the bit summation operations proved to be a challenge. Ledvina solved this problem by using a pre-computed 1-dimensional data table whose input was the unsigned integer and whose output was the number of 1-bits. To ensure a reasonable table size, only the bits in a 16-bit unsigned integer word were counted. The original receiver’s 32-bit words were split in half, two table look-ups were performed, and the results were summed in order to count all of the 1-bits. The original algorithms were defined by Ledvina et al. (2003), Ledvina, Psiaki, Powell et al. (2004), and Ledvina, Psiaki, Powell et al. (2006).
When using very long PRN codes, such as the L2C CL code, the whole-period PRN code tables of the proper 32-bit words at various code phases in the original method become impractically large. Therefore, a new method was developed for long PRN codes. In this method, 32-bit words of short generic PRN code chip sequences are tabulated, with all possible combinations of short chip sequences considered at various PRN code offsets relative to the start of the samples of the 32-bit word. These methods have been described by Psiaki (2006) and Ledvina et al. (2007). This technique proved invaluable for dealing with long codes.
A processor that can operate on wider segments of data, up to 512 bits for current single instruction multiple data (SIMD) instructions, gains substantial additional increases in signal processing speed (Nichols et al., 2022). However, the speed increase factors over brute-force integer calculations are typically not as high as the number of bits per word. That is, the techniques do not speed up the operations by a factor of 32 when processing 32 samples in parallel by using 32-bit words to represent 32 samples. For a 2-bit RF front-end and a 32-bit processor, the speed-up factor might be only 4 because the bit-wise parallel approach requires multiple operations due to, say, a simple multiplication of one time series by another. If one doubles the number of bits per word, however, then the speed tends to double. A particularly helpful feature of some recent processor designs is their inclusion of a hardwired command to count all of the 1-bits in a word. This “popcount” intrinsic obviates the table look-ups that counted 1-bits in the original bit-wise parallel design. If the number of bits increases in the RF front-end samples and/or the IF carrier replicas, however, then the bit-wise parallel method of signal processing slows down. Signals represented by 3 or 4 bits might cause the processing speed gains of bit-wise parallel algorithms to be limited or even non-existent.
After successfully running the basic algorithms in real time using 32-bit words, the Cornell group showcased the efficacy of real-time GNSS software radio by using the same techniques to develop a dual-frequency L1 C/A and L2C receiver (Ledvina, Psiaki, Sheinfeld, et al., 2004) and a GPS/Galileo L1 civilian receiver (Ledvina, Psiaki, Humphreys, et al., 2006). These real-time software GNSS receivers each required only several person-days to be developed from the original L1 C/A code receiver. Of course, the L1/L2 receiver required a new dual-frequency RF front-end. The GPS/Galileo receiver required knowledge of the civilian Galileo E1 PRN codes, which had not been published at that time. This requirement led to a supporting effort that successfully deduced the E1 PRN codes of the Galileo in-orbit validation (IOV) satellite GIOVE-A by recording their raw RF front-end samples and post-processing those samples using a suite of custom-designed SDR signal-processing algorithms in order to extract the chips from the noise (Psiaki et al., 2006).
The next development was to re-implement the bit-wise parallel code for embedded (low-power, low-cost) processing. Initially targeting a Texas Instruments DSP, this work was accomplished in 2006 by then-Ph.D. candidate Todd Humphreys (Humphreys et al., 2006). Later, as a professor at The University of Texas (UT) at Austin, Humphreys and his students—notably Jahshan Bhatti and Matthew Murrian—undertook a sequence of significant expansions and improvements to this receiver. Called GRID, the C++-based UT Austin receiver is now a highly optimized science-grade multicore GNSS SDR (Humphreys et al., 2009; Nichols et al., 2022). Its main features are summarized in Table 3. This receiver was the first GNSS SDR to be adapted for spoofing (Humphreys et al., 2008), the first GNSS SDR to operate in space (Lightsey et al., 2014), the first receiver of any kind to show that centimeter-accurate GNSS positioning is possible with a smartphone antenna (Pesyna et al., 2014), the first receiver to be used to locate terrestrial sources of GNSS interference from LEOs (Murrian et al., 2021), and the basis of the current state of the art in urban precise (decimeter-level) positioning (Humphreys et al., 2020; Yoder & Humphreys, 2023). As detailed by Nichols et al. (2022), GRID has also reaffirmed the commercial viability of GNSS SDR in widespread low-cost applications: it was recently licensed by a major aerospace company for use across all company operations, including in the thousands of satellites of the company’s broadband internet mega-constellation.
3.2 Multi-Sensor Navigation Analysis Tool
The Multi Sensor Navigation Analysis Tool (MuSNAT) is an object-oriented but monolithic C++ software receiver maintained by the University of the Bundeswehr Munich (UniBwM) and was first mentioned in its present form by Pany et al. (2019). MuSNAT started as an operational real-time receiver development, but currently, it mostly serves to develop and demonstrate innovative signal-processing and navigation algorithms. MuSNAT is also used for teaching. It is freely available as executable for academic purposes from UniBwM (2023). Its main characteristics can be found in Table 4. In contrast to the bit-wise approach of Section 3.1 (which allows the design of very power-efficient implementations), the design idea of MuSNAT and its predecessors was to realize a high-end receiver running on powerful PCs or workstations. The bit-wise approach was replaced by using SIMD instructions of Intel/Advanced Micro Devices central processing units (CPUs). This allows samples to be represented as 8-bit or 16-bit values, and SIMD instructions such as AVX-512 currently allow processing of registers of up to 512 bits (i.e., 32 16-bit samples) in parallel.
GNSS software receiver developments were initiated at UniBwM in 2002, after it became clear that the software radio approach discovered by Akos would provide useful insights into GNSS receiver technology and would thus be indirectly helpful in designing and building the Galileo navigation satellite system. The first software receiver at UniBwM was designed for GPS L1 C/A only and was realized as a MATLAB/Simulink project for post-processing. To sample the GNSS signals, a commercial ADC with a peripheral component interconnect express (PCIe) connector from National Instruments (NI) was used (PXI 5112), which was connected either to a low-bandwidth GPS L1 C/A code front-end based on the Plessey GP 2010 RF chip set or later to one GPS L1/L2 high-bandwidth front-end, which was specifically developed by Fraunhofer IIS (Pany, Förster, et al., 2004). Soon after, the software for communicating with the ADC (written in C++, making use of the Microsoft Foundation classes) was upgraded to a full GPS L1 C/A plus L2CS (only medium-length L2 code was supported, not the long code) receiver. A detailed analysis published by Pany et al. (2003) revealed that both the SIMD instruction set and the size and structure of the CPU caches were important for real-time capabilities. Memory bandwidth is a key issue when representing samples by multiple bits. One of the first achievements with this receiver was the demonstration of vector tracking (Pany et al., 2005).
Based on these results, funding was secured to support a group of five researches over three years. This funding allowed the researchers to start a new software receiver project, this time making full use of C++ features for object-oriented development, and to develop a graphical user interface (GUI) connected to the processing core via a clearly defined interface that also allowed the core to run without a GUI. The overarching development goal at that time was to realize a high-quality multi-GNSS multi-frequency receiver on a desktop PC or powerful laptop that could potentially be operated on a continuous basis to replace the (at that time) rather inflexible and expensive commercial GNSS receivers at continuously operating reference stations. A concise overview of the development during those years was written by Stöber et al. (2010), who described the improvements compared with the start of the project lain down by Pany, Eissfeller, et al. (2004).
A loose cooperation with IFEN GmbH was initiated, which eventually resulted in the SX3 receiver (IFEN GmbH, 2022). IFEN used the processing core as an initial basis, improved the core, replaced the GUI, and developed new dedicated front-ends. The C++ code was further optimized to support more channels at higher bandwidth and almost instantaneous high-sensitivity acquisition with the graphics processing unit (GPU) (Pany et al., 2012). Semi-codeless tracking of GPS L2P(Y) (i.e., P-code aided cross-correlation) was also implemented. The cooperation of UniBwM with IFEN lasted until 2013, when the development directions started to diverge. IFEN used the software primarily as a base receiver platform with an application programming interface (API) to support different applications, whereas UniBwM continued to modify the core, which was not always beneficial for software stability from a commercial viewpoint.
The focus at UniBwM changed in 2017, as the old GUI could no longer be maintained. Furthermore, real-time operation became less important, as most scientific results were obtained in post-processing. Consequently, a new GUI was developed and attached to the proven processing core. Any run-time optimizations within the processing core that degraded the navigation performance (i.e., mostly causing additional noise in the code tracking loop) were removed. The core’s logging output was directed to an SQL database to store all types of intermediate results in a single file (in addition to the legacy ASCII logging into multiple files). A dedicated visualization tool was developed for this database.
The use of Windows and Visual Studio for developing a software radio is slightly unusual, but can be explained as follows. At UniBwM, most researchers use Windows PCs to allow easy document exchange with each other and, most importantly, within the European space industry. For this reason, all software receiver developments were performed for Windows only. In terms of numerical performance and code optimization, with the Intel C++ compiler and the Intel Performance Primitives, Intel provided and still provides the same quality on Windows as for Linux. Over the years, however, it became clear that the potential use of the processing core on embedded devices and long-term stability might have been easier to achieve on the Linux operating system. IFEN ported part of the core to Linux, but not the full software receiver, and showed that conventional desktop CPUs and embedded CPUs already provided an impressive processing capability in 2015 (Dampf et al., 2015).
As already mentioned, code optimization to achieve fast (and real-time) signal tracking was a main research focus in the first years. Different studies on CPU assembler instructions, CPU architecture, and bottlenecks resulted in dedicated assembler implementations. Extensive look-up tables were used, and a highly efficient correlator implementation with the Intel x86 pmaddubsw instructions was based on a signal sample representation as unsigned integers (including the necessary rewriting of the correlation formulae because of the switch from the standard representation of samples as signed integers to unsigned integers). fast Fourier transform (FFT)-based acquisition was already very efficient on the CPU and even more efficient on the GPU. With the use of FFT libraries provided by NVIDIA, porting the acquisition code porting from the CPU to GPU became comparably easy. The situation is different for signal tracking. The tracking code has been transferred to the GPU, and some optimization has been applied to minimize the amount of data transfer between the CPU and GPU. However, because the correlation parameters are slightly different for each signal tracked, the correlation code is called multiple times, and the latency to start one thread on the GPU generates significant overhead. Thus, GPU-based tracking is currently only beneficial if a very large number (several hundreds) of correlators is configured per tracking channel, as pointed out by Pany et al. (2019). As modern desktop and laptop CPUs continue to improve and make use of a many-core structure, the need to port signal tracking to the GPU becomes less important. Furthermore, over the years, the use of dedicated assembler code required continuous adaptation to new CPU instruction sets (e.g., from SSE to AVX instructions). The performance gained by using hand-coded assembler routines instead of using the libraries provided by Intel (Intel Performance Primitives) is not always worth the effort and was not further actively pursued. Instead, dot-product routines (2 × 16-bit signed input to 64-bit output) from the Intel Performance Primitives are employed for signal tracking.
The C++ universe is huge, and it is easy to integrate external source code. For example, the famous RTKLIB and the ION SDR sample reader code have been integrated. The current research work with MuSNAT focuses on GNSS/INS/lidar integration, support of massive antenna arrays (Dötterböck et al., 2023), vector tracking and deep GNSS/inertial navigation system (INS) coupling, support for long term evolution (LTE)/5G signals, and GNSS signal simulation. Notably, the maintenance of the huge C++ code base of MuSNAT at a university institute with a high fluctuation of researchers is demanding. The learning curve for good C++ development in this context is steep and is often inefficient for the purposes of obtaining a PhD degree. Therefore, interfaces from the C++ code to MATLAB were established; for example, open service navigation message authentication (OSNMA) decoding, precise point positioning computation for high accuracy service (HAS), and lidar odometry have been implemented in MATLAB. Another development is to use MuSNAT to generate multi-correlator values that are then used within a full MATLAB-based receiver to emulate signal correlation via interpolation (Bochkati et al., 2022). Bochkati et al. (2023) used this for ease in developing synthetic aperture algorithms.
UniBwM initially used front-ends from Fraunhofer IIS, and the software receiver included low-level universal serial bus (USB) drivers for real-time data transfer. The same approach was used to connect the front-ends from IFEN GmbH to the processing core. The effort required to write stable high-data-rate low-level drivers is significant and introduces a dependency on libraries and support from the USB chip manufacturers. To reduce these types of development efforts, the decision was made to connect front-ends via TCP/IP. This approach is powerful in terms of bandwidth and is also generic; a first version of this approach has been described by Arizabaleta et al. (2021). Furthermore, with, e.g., LabVIEW from NI, it is comparably easy to develop a simple TCP/IP signal source for universal software radio peripheral (USRP) front-ends. At the time of writing this paper, a more efficient firmware for USRPs with direct field programmable gate array (FPGA) programming is being developed, which will allow data to be synchronously captured from an inertial measurement unit (IMU) together with GNSS signal samples.
3.3 SoftGPS, SoftGNSSv3.0, and Derivatives
As mentioned above, the work by Borre et al. (2007) and the associated MATLAB receiver provided a cornerstone for GNSS SDR development. This receiver, initially called SoftGPS and then SoftGNSS (usually referred to as SoftGNSSv3.0), included the basic processing functions for GPS L1 C/A in a readable format and was useful for educational purposes. These functions included signal FFT-based acquisition, frequency, carrier phase, and code phase tracking, data synchronization and demodulation, pseudorange generation, and eventually PVT estimation. The MATLAB code, together with some samples, was provided in a CD with the book and was also available at Aalborg University’s Danish GPS Lab website. In addition to Borre and Akos, SoftGNSS included relevant contributions by Plausinaitis and others. Unfortunately, Kai Borre passed away in 2017, and the Danish GPS Lab was discontinued. However, SoftGNSS and its derivatives remain quite alive, as described below.
A new SDR GNSS book (Borre, Fernández-Hernández et al., 2022), extending SoftGPS functionality to several frequencies, GNSS, and architectures, can be considered as the successor of Borre et al. (2007). A main building block of this book is the GNSS software receiver (GSRx) developed at the Finnish Geospatial Research Institute (FGI) (FGI-GSRx), described in the following section, but the book also includes other MATLAB receivers. In particular, the dual-frequency GSRx (DF-GSRx), developed by Borre’s PhD student P. Bolla, is a dual-frequency GPS L1/L5 receiver that includes dual-frequency acquisition techniques, measurement combination (including ionosphere-free measurements), and positioning. The book also includes a GPS L1 C/A snapshot receiver developed by Borre’s former PhD student I. Fernandez-Hernandez, which is more modest than that described in Section 3.8, but simple and quick to execute and therefore possibly useful for educational purposes.
The Easy Suite libraries (Borre, 2003, 2009), still publicly available and used, provide an excellent educational tool for diving into the basic functions of GNSS receivers, such as calculating satellite positions from the ephemerides, performing datum conversions, or computing the receiver position and its accuracy in multiple ways (least squares, Kalman filter, carrier phase ambiguity resolution, etc.).
Bernabeu et al. (2022), as above mentioned, have provided a collection of open-source SDRs developed at University of Colorado Boulder based on SoftGNSS.
Zhang (2022) has provided a repository with adaptations of SoftGNSS for different front-ends.
3.4 Finnish Geospatial Research Institute’s Multi-GNSS Software Receiver
The software receiver developed by the FGI is known as the FGI-GSRx. The development of the FGI-GSRx started in 2012 from the open-source GNSS software receiver released in 2007 by Prof. Borre and his colleagues (Borre et al., 2007). The software receiver was able to track two IOV satellites (GIOVE A and GIOVE B) from the European GNSS system, Galileo. Since then, the researchers at FGI have been continuously developing new capabilities for the software receiver, with the inclusion of Galileo in 2013 (Söderholm et al., 2016), the Chinese satellite navigation system BeiDou in early 2014 (Bhuiyan et al., 2015; Bhuiyan et al., 2014), the Indian regional satellite navigation system NavIC in late 2014 (Thombre et al., 2015), and the Russian satellite navigation system GLONASS in 2015 (Honkala, 2016).
The FGI-GSRx software receiver has been extensively used over the last decade as a research platform in different national and international research and development projects to develop, test, and validate novel receiver processing algorithms for robust, resilient, and precise positioning, navigation, and timing. At present, the FGI-GSRx can process GNSS signals from multiple constellations, including GPS, Galileo, BeiDou, GLONASS, and NavIC. The software receiver is intended to process raw IF signals in post-processing. The processing chain of the software receiver consists of GNSS signal acquisition, code and carrier tracking, decoding of the navigation message, pseudorange estimation, and PVT estimation. The software architecture is built such that any new algorithm can be developed and tested at any stage in the receiver processing chain without requiring significant changes to the original codes. FGI-GSRx provides a unique and easy-to-use platform not only for research and development, but also for those interested in learning about GNSS receivers. Some of the main features of FGI-GSRx are listed in Table 5.
The software receiver was released as open source in February 2022 (FGI, 2022). FGI-GSRx was also accompanied by the book GNSS Software Receivers, a next edition of one of the fundamental GNSS textbooks, published in 2022 by Cambridge University Press (Borre, Fernández-Hernández et al., 2022). This book systematically introduces software receiver processing functionalities, with experimental results for the GPS L1 C/A signal in Section 2 (Borre, Bhuiyan et al., 2022), GLONASS L1OF signal in Section 3 (Bhuiyan, Honkala et al., 2022), Galileo E1 OS signal in Section 4 (Bhuiyan, Söderholm, Ferrara et al., 2022), BeiDou B1I signal in Section 5 (Bhuiyan, Söderholm, Thombre et al., 2022), NavIC L5 signal in Section 6 (Thombre et al., 2022), and a single-frequency multi-constellation solution with three GNSS signals in Section 7 (Söderholm et al., 2022). The readers can easily follow the fundamental receiver processing chain for each individual GNSS signal, with the distinctive changes among those signals discussed and highlighted in figures. One noteworthy contribution of this book is a method for integrating several GNSS signals to form a single-frequency multi-GNSS PVT solution, presented in Section 7.
The FGI-GSRx can be utilized at universities and other research institutes as a tool for training graduate-level students and early-stage researchers and for providing hands-on experience in GNSS receiver development. This receiver can also be utilized in the vast GNSS industry as a benchmark software-defined receiver implementation. The software receiver is already being used in the “GNSS Technologies” course offered widely in Finland at the University of Vaasa, Tampere University, Aalto University, and the Finnish Institute of Technology.
3.5 GNSS-SDR, an Open-Source Software-Defined GNSS Receiver
The software receiver developed by the Centre Tecnològic de Telecomunicacions de Catalunya (CTTC), named GNSS-SDR (but not related to the ION SDR Standard), is another example of a multi-band, multi-system receiver. This receiver has been constantly evolving since 2010, keeping pace with the newest GNSS algorithms and signals over more than a decade. The GNSS-SDR originated as a by-product of a CTTC research staff initiative, with the aim of providing a framework for collaborating with other researchers seeking to accelerate research and development of software-defined GNSS receiver technology. The receiver focuses on baseband signal processing, although it has the ability to run a navigation engine (refer to Table 6). The early stages of development progressed slowly under a personal side-project scheme with no funding, but with the purely exploratory objective of designing an optimal architecture specifically suitable for GNSS signal processing, where concepts such as testability, extensibility, reusability, scalability, maintainability, portability, adaptability to new non-standard requirements, and adoption of computer science best practices were considered from the start.
The GNSS-SDR first became popular in August 2012, with reports of GNSS usage via extremely cheap (about $25) digital video broadcast-terrestrial (DVB-T) receivers based on Taiwan’s Realtek RTL2832U chipset, sold in the form of USB dongles that allow users to watch over-the-air DVB-T European broadcast television on their PCs. These devices typically send partially decoded MPEG transport frames over the USB; however, by exploiting an undocumented mode of operation of the demodulator chip, the user was able to obtain raw in-phase and quadrature samples, stream them through the USB to a PC, and then apply the GNSS-SDR software processing, turning the DVB-T receiver into a GNSS receiver and delivering the position in real time (see Fernández–Prades et al. (2013)). In a parallel development, in November 2013, the European Space Agency (ESA) acknowledged GNSS-SDR as one of the first 50 receivers worldwide to achieve a successful Galileo position fix.
The project gained momentum and maturity over the years, and it currently has a solid and valuable user base that continuously provides feedback, enhancements, and new features. Current versions are included in major GNU/Linux distributions, such as Debian and Ubuntu, and in Macports for Apple’s macOS. The software package has been used in several publicly and privately funded research projects (including the European Union Agency for the Space Programme [EUSPA], ESA, National Science Foundation [NSF], and NASA activities, as well as educational programs such as Google’s Summer of Code), and it has been reportedly used for research purposes worldwide. The authors opened a discussion of quality metrics and key performance indicators for any generic software-defined receiver (Fernández–Prades et al. (2016b) provided an extended online version available at https://gnss-sdr.org/design-forces/) and proposed the concept of continuous reproducibility in GNSS signal processing (Fernández–Prades et al., 2018).
The full project and source code documentation can be found online at https://gnss-sdr.org, a website with over 5000 unique visitors per month, which contributes to raising awareness on GNSS technology. The website content is also available on a GitHub repository at https://github.com/gnss-sdr/geniuss-place, hence undergoing public scrutiny. The project is also well connected to its software ecosystem and existing SDR platforms. It builds on a wide range of GNU/Linux distributions and versions (ranging from those released in 2014 to the most recent releases), and it provides a Yocto/Openembedded layer, which allows its portability to a wide range of embedded platforms (see Fernández–Prades (2022)).
The software produces standard outputs for observables and navigation data (RINEX files and RTCM-104 v3.2 messages as defined by the Networked Transport of RTCM via Internet Protocol), as well as position fixes in application-specific messages (e.g., NMEA 0183), a variety of geographic information system-oriented file formats (KML, GeoJSON, GPX), and custom binary outputs that allow the observability of internal signal-processing subproducts.
3.6 AutoNav SDR
The AutoNav SDR is a MATLAB-based multi-GNSS, multi-frequency software receiver that was developed by the Autonomous Navigation Laboratory of Inha University, South Korea (Song et al., 2021). Its main features are presented in Table 7. The critical point considered in the design phase of this SDR is the maximization of reconfigurability. Because South Korea is developing its own satellite navigation system, KPS, which is targeted to operate from 2035 as reported by Ministry of Science and ICT of Korea (2021), a flexible receiver that can process not-yet-existent signals is required. The AutoNav SDR is designed to provide full reconfigurability in terms of target signal combinations and signal characteristics, especially for the easy addition of new signal proposals. To achieve this, a basic framework of software receiver was designed with an appropriate processing functional architecture and data structure in consideration of signal expandability. This framework was then applied to realize an SDR for GPS L1 C/A code signal as a first realization example by reconfiguring a configuration file via a GUI. Then, different signals of the other constellations (GLONASS, Galileo, BeiDou navigation satellite system (BDS), Quasi-Zenith Satellite System (QZSS), NavIC) and frequencies (L1, L2, L5) were quickly added by utilizing this expandability. In this way, KPS signal candidates can be easily added to the SDR to evaluate and compare the performance of each candidate in the signal design phase. Similarly, a reconfigurable GNSS simulator was developed at the same time with the same idea. This MATLAB-based IF-level GNSS/KPS simulator can be ideally suited to test the navigation performance of any GNSS signal as well as new KPS signals by reconfiguring signal design parameters via a GUI.
Although the AutoNav SDR is targeted for post-processing only, the original correlation operation in MATLAB with variables of double precision was too slow at the beginning of its design phase. Hence, two simple accelerations were applied to the SDR: a GPU-based acquisition module and a MEX correlator for tracking. The GPU-based signal acquisition module was implemented in a simple way using the Parallel Computing Toolbox of MATLAB. If the GPU is usable, local variables for the correlation (i.e., code and carrier replicas) are generated in the GPU memory using the gpuArray function. Then, FFT, inverse FFT, and correlations are automatically performed in the GPU. Finally, the correlation results are extracted via a gather function. With this simple approach, the execution time is reduced by a factor of approximately 2.12 compared with the general CPU-based acquisition, without the relatively complex development using CUDA.
Because the most time-consuming process of the receiver is the correlation in the signal tracking, a MEX function is employed to reduce the computational burden. The MEX function connects the MATLAB environment to the external function written in C/C++ language with an appropriate wrapper function so that the user can call it within MATLAB. The MEX correlator was written in the standard C language and uses integer-based variables. The SDR pre-generates the code and carrier replica tables in the initialization process with resolutions of 18 bits and 8 bits, respectively. The code and carrier numerically controlled oscillators (NCOs) have a resolution of 32 bits; thus, the indices of the tables for current code and carrier replica generation are calculated via bit shift operations of 14 bits and 24 bits, respectively. With these implementations, the overall execution time became much faster (approximately five-fold faster) than the original double precision-based code, but it still cannot operate in real time. Currently, Inha University is developing an FPGA-based real-time GNSS receiver in which only the correlator is substituted by the FPGA board at the original AutoNav SDR.
To further enhance its flexibility, the AutoNav SDR also provides APIs at each part of the signal processing chain (such as the ring buffer, acquisition, tracking, navigation message extraction, position calculation, etc.). The API design was influenced by the ipexSR of Stöber et al. (2010) and was implemented in a similar manner with the dynamic link library (DLL). Because MATLAB can load a library from DLL and call a function within the library, the API concept of the C/C++-based software can also be used analogously in the MATLAB environment. If the SDR is converted to an executable file (.exe) and provided to a user, the user can freely modify functions or develop algorithms by generating the DLL, without the need for the whole source code.
3.7 PyChips
PyChips is a relatively new object-oriented satnav SDR that has been developed from scratch since 2018. It is based on the experience gained from two previous implementations, namely, the MATLAB SDR that was distributed with the Wideband Transform-domain Instrumentation GNSS Receiver (TRIGR) (see Section 5) and the ChameleonChips GNSS SDR Toolbox for MATLAB (Gunawardena, 2014).
One of the key promises of SDRs is their flexibility and, hence, their utility as an education and research tool. In the satnav context, various publicly available SDRs can be used to teach basic courses on satnav systems, signal processing, and receiver design. However, there is an implicit assumption that students have the relevant programming language skills for a particular SDR. Students are expected to understand the inner workings of the SDR in detail and, more importantly, to make modifications to the code to add advanced capabilities and/or revisions as part of their graduate research projects. While somewhat valid, this assumption of programming language proficiency may not always hold true. Further, depending on the situation, it may be more efficient and beneficial for graduate students to make deeper progress on their research instead of spending time in becoming programming language experts. PyChips was developed from the ground up to support this notion. A more detailed introduction to PyChips has been provided by Gunawardena (2021). The main features of PyChips are summarized in Table 8. This receiver is implemented in Python with C++ bindings, where performance is absolutely essential for reasonably fast execution.
The current version of PyChips supports the creation and definition of entire constellations of satellites with advanced next-generation signal structures, along with interference sources and channel effects. The simulation portion of PyChips (comprising numerous source objects) synthesizes these signals at the sample level onto one or more sample streams that are grouped into objects called stream containers. A stream container is an abstraction of a satnav receiver’s antenna(s) and RF front-end subsystem. The stream container can be multi-frequency or multi-element, can have different sample rates and bandwidths, and can have an IF or baseband sampling architecture and any and all combinations thereof. If the use case involves live-sky signal processing, then one or more sampled SDR data files can be specified to instantiate a stream container object that is functionally identical and imperceptible from a simulated one. PyChips uses the ION SDR Standard to determine the appropriate C/C++ decoder/unpacker/re-quantizer kernel to use for reading and parsing these SDR files.
The sample streams contained in a PyChips stream container are processed using numerous sink objects. Currently, implemented examples include virtual oscilloscopes and spectrum analyzers, as well as acquisition engines and signal-tracking modules.
A unique feature of PyChips is that all of the functionalities described above are defined/specified by a draft SDR language called Signal and ARchitecture Description Language (SARDL). SARDL is implemented as a grouping of JavaScript object notation (JSON) files. Current and next-generation advanced satnav signal structures and the receiver architectures used to process them are constructed by assembling pre-built low-level functional blocks. For example, as described by Gunawardena (2021), the user can build receiver tracking modules to process GPS L1C TMBOC(6, 1, 4/33) and Galileo E1OS CBOC(6, 1, 1/11) MBOC signals as simple BOC(1, 1) signals to model a low-cost, low-power mass market receiver or a high-end survey-grade receiver taking full advantage of these “dual-personality” signals.
Indeed, at this stage, the goal of the PyChips project is to hone SARDL with a vast number of diverse signal specifications, use cases, and applications in order to explore the concept of a “satnav signals and systems specification language.” Today, the reference SDR that implements SARDL is written in Python and is therefore called PyChips. However, the ultimate goal of this effort is to contribute toward satnav SDR implementations that have the performance, power efficiency, and scalability of ASICs with the flexibility, reconfigurability, adaptability, and ease of use of software.
3.8 UAB Snapshot GNSS Software Receiver
The UAB snapshot GNSS software receiver (cf. Table 9) was originally developed as part of the research activities on indoor GNSS positioning carried out by the Signal Processing for Communications and Navigation (SPCOMNAV) group at UAB in 2007. At that time, the group was involved in one of two parallel contracts awarded by the ESA to assess the feasibility of indoor GNSS positioning, under the project named DINGPOS. The proposed strategy was to rely on a combination of technologies such as Wi-Fi, ultra wideband, 2G/3G cellular networks, and GNSS, as discussed by López-Salcedo et al. (2008). As far as GNSS was concerned, UAB was in charge of developing the software implementation of a so-called high-sensitivity GNSS (HS-GNSS) receiver, which would be able to operate under the extremely weak signal conditions experienced indoors. This implementation involves working with attenuation losses of 10–40 dB, which drive the effective carrier power to noise power spectral density, i.e., C/N0, down to values for which conventional GNSS receivers cannot operate.
The proposed HS-GNSS receiver implementation was based on a snapshot architecture in which a batch of input samples is processed at one time to provide the user’s position. This approach is often referred to in the literature as “push-to-fix” or “acquisition-only” because no tracking stage is actually implemented at the receiver. Consequently, the receiver operates in open-loop mode by providing at its output the observables obtained directly from the acquisition stage. The implementation of the HS-GNSS software receiver was strongly influenced by the work already initiated by Gonzalo Seco-Granados before joining UAB, during his period from 2002 to 2005 as technical staff at the European Space Research and Technology Center of the ESA in The Netherlands, where he was leading research activities concerning indoor GNSS and snapshot GNSS receivers. The core of the UAB snapshot GNSS receiver was inspired by the concept of double-FFT acquisition introduced by Jiménez-Baños et al. (2006). This algorithm uses two consecutive FFT operations to implement the correlation of the received signal with the local code replica and then the simultaneous estimation of the fine Doppler frequency and bit synchronization. Readers interested in the double-FFT algorithm and a detailed description of the UAB snapshot GNSS receiver implementation are referred to the comprehensive description written by Seco-Granados et al. (2012).
From a general perspective, the UAB snapshot GNSS software receiver implements a set of specific signal-processing techniques that are tailored to indoor working conditions. Nevertheless, the implementation is flexible and does not prevent the receiver from operating efficiently in other scenarios, such as outdoors. For an indoor environment, the most important impairment to be counteracted is the severe attenuation due to propagation through building materials and other obstacles. Attenuation of up to 40 dB can easily be experienced, thus requiring specific action to recover as much of the lost power in order to still be able to detect GNSS satellites. Because the received energy is the most important parameter from a signal detection and estimation viewpoint and because energy is simply the power multiplied by the observation time, the only way to compensate for an extremely weak received power is to increase the observation time. Thus, a longer piece of received signal must be processed, which requires very long correlation integration times at the GNSS receiver, on the order of hundreds of milliseconds or even a few seconds. Unfortunately, increasing the correlation time is hindered by the presence of navigation message data symbols, residual Doppler errors, and clock instabilities. Consequently, the approach adopted in practice by most snapshot GNSS receivers, particularly those intended for high-sensitivity applications, is to split a long correlation into pieces of shorter, but sufficiently long, coherent correlations whose outputs are then noncoherently accumulated. This combination of coherent and noncoherent correlation has proven to be successful in increasing the receiver sensitivity and thus enabling the receiver to detect a few GNSS satellites indoors. An interesting discussion on the importance of sufficiently long coherent integrations has been provided by Pany et al. (2009).
The correlation between the received signal and the local replica is the most important operation of a snapshot GNSS receiver because, with such correlation, the most accurate code delay and Doppler observables must be estimated. Here, no tracking stage is implemented, and thus, there is no opportunity to further refine these observables in subsequent stages of the receiver. For this reason, the correlation must be implemented in the most optimal way, taking into account subtle details that might be ignored in conventional GNSS receiver implementations. Such optimality is achieved by the double-FFT algorithm implemented in the UAB snapshot GNSS receiver, which applies an optimal joint estimation of the code delay and fine Doppler over a long period of time, where potential sign transitions may occur because of the presence of data-modulating symbols. Additional considerations, such as how to handle a non-integer number of samples when performing the FFT, the interpolation between consecutive correlation peaks, the code-Doppler effect over a long correlation period, etc., have been reported by Seco-Granados et al. (2012).
The code delay and Doppler estimates provided by the acquisition stage are directly used by the navigation module to compute the user’s position. Such code-delay estimates are ambiguous for one code period because no absolute time reference is available, and therefore, no other time-delay information can be provided besides that contained with a PRN code period. Here, only one batch of received samples is processed, and thus, no access to the transmission time encoded onto the navigation message is generally available. As a result, the user’s position must be computed without such time reference, which reflects a specific feature of snapshot GNSS receivers. This problem can be solved by coarse-time navigation, where the conventional navigation equations are augmented to include an additional unknown that represents the missing absolute time reference. Interested readers will find an excellent description of this method in the work by (Van Diggelen, 2009, Ch. 4).
Since its development in 2008, the UAB snapshot GNSS receiver has been a key tool for many research activities at the SPCOMNAV group. This software has been used, for instance, to characterize multipath propagation indoors (López-Salcedo et al., 2009), to assess the feasibility of using GNSS receivers in missions to the Moon, where the weak-signal problem is similar to the indoor case (Manzano-Jurado et al., 2014), to test near-far mitigation techniques that may appear in indoor/space applications (Locubiche-Serra et al., 2016), to assess the impact of phase noise (Gómez-Casco et al., 2016), and to provide GNSS positioning to internet of things (IOT) sensors in smart cities (Minetto et al., 2020) by means of a cloud-based implementation of the UAB snapshot GNSS receiver that was developed from 2016 to 2018.
Migration of the UAB snapshot receiver into a cloud-based implementation was a major milestone that attracted the interest of the community and opened the door for new applications and use cases. The interest in cloud GNSS positioning was motivated by the fact that, at that time, GNSS software receivers were running in local computers next to the user, who collected the samples to be processed. However, with the advent and widespread deployment of cloud computing platforms such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud, such local computers could actually be placed anywhere, and remote access could be granted to upload and process GNSS samples in a remote server in a scalable manner. Furthermore, this approach was well suited for a snapshot GNSS receiver implementation, in which a batch of samples could be sent to a remote server where the user’s position would then be computed via the same tools as in any other snapshot GNSS receiver. These computations include using assisted GNSS (A-GNSS) for reducing the acquisition search space, making extensive use of FFT operations, and computing the user’s position by means of coarse-time navigation techniques.
This concept motivated the so-called “cloudGNSSrx,” the cloud-based implementation of the UAB snapshot GNSS receiver, as described by SPCOMNAV (2019). The architecture was based on a dockerized compilation of the MATLAB source code implementing the UAB snapshot GNSS receiver. Then, a system of job queues, schedulers and load balancers was built on AWS to automate and scale the remote execution of the receiver, and an API was developed for machine-to-machine communication, facilitating the provision of GNSS positioning to small IOT sensors (Lucas-Sabola et al., 2016). In this way, IOT sensors requiring GNSS positioning were able to offload most of the computational load to a remote server, thus significantly reducing the power consumption and extending their battery lifetime.
Low-power GNSS positioning is one of the main applications of cloud GNSS software receivers, because, for snapshots shorter than a few tens of milliseconds, the energy spent in sending the GNSS samples to the cloud is balanced by the significant energy saved at the user’s terminal for not processing such samples and for performing such processing at the cloud instead (Lucas-Sabola et al., 2017). This feature was acknowledged by the former European GNSS Agency (GSA), now the EUSPA, who identified the UAB cloud GNSS receiver as promising technology for the future adoption of GNSS in the IOT domain (European Union Agency for the Space Programme, 2018). The cloud GNSS software receiver developed by UAB was then licensed in 2019 to the startup company Loctio, who significantly improved the initial prototype and produced a commercial product.
It is important to remark that apart from the low-power consumption use case, cloud GNSS software receivers can also be used to provide access to sophisticated signal processing techniques that cannot be implemented in conventional receivers, such as advanced signal-monitoring techniques, spoofing detection, or authenticated/certified positioning, the latter being reported by Rügamer et al. (2016). Thus, there is a brilliant future ahead for cloud GNSS software receivers with many exciting new applications to come.
3.9 The NGene Family of Receivers at Politecnico di Torino and LINKS
The development of NGene, a GNSS software receiver, originated at Politecnico di Torino and the LINKS Foundation in the early 2000s. At that time, the Navigation Signal Analysis and Simulation Group was already engaged in software implementation of various sections of GNSS baseband processing. This endeavor capitalized on the group’s extensive expertise in digital signal processing and specifically in simulating complex communication systems.
Efforts initially focused on optimizing the acquisition and tracking stages, both as post-processing tools and as core processing units on programmable hardware. In 2005, under regional funding, the research team, partially affiliated with the Istituto Superiore Mario Boella (now part of the LINKS Foundation), commenced the development of a fully software-based, real-time GNSS receiver for GPS and forthcoming Galileo signals.
The outcome of the work was the software receiver NGene, as documented by Molino et al. (2009). NGene demonstrated real-time processing capabilities for GPS, Galileo, and European Geostationary Navigation Overlay Service signal components transmitted on the L1/E1 band. Prior to processing, the signals were subjected to IF downconversion and digitalization by an external analog front-end device. Communication between the front-end device and the software receiver occurred via a USB connection. The hardware component of the receiving chain consisted solely of the antenna, its low noise amplifier (LNA), and the analog-to-digital converter with front-end filtering, with all other components being software-based. This fundamental architecture laid the groundwork for subsequent enhancements and has been the essential building block of the NGene receiver family.
Thanks to its reconfigurable and modular structure, NGene has long served as the primary tool for in-lab analysis, development, and prototyping of signal-processing algorithms and architectures. Because of its flexible implementation, NGene was adapted to process the Galileo IOV signals (GIOVE-A) and subsequently to process the first Galileo signals immediately upon their availability, as detailed by Margaria et al. (2012). As a result, the research team was among the first worldwide to achieve a position fix using the initial four Galileo satellites. Over time, the software receiver continued to evolve and was tailored to address diverse applications, leveraging the advantages of software radio implementation (see Table 10).
Today, the NGene receiver family offers configurable support for various RF-to-IF front-ends, which connect to the software processor via USB, meeting the requirements of numerous activities and projects. A simplified, low-complexity version was developed to enable GNSS positioning capabilities on ARM-based embedded processors (Gamba, Nicola, et al., 2015). Additional branches of the software were adapted for GNSS reflectometry receiver deployment in reflectometry tests (Gamba, Marucco, et al., 2015), evaluation of anti-jamming algorithms, and detection of non-standard code transmission and its effects on Galileo positioning (Dovis et al., 2017), while also serving as a tool for studying the 2019 Galileo outage event (Dovis et al., 2019). One of the latest branches of the NGene family encompasses algorithms for authenticating Galileo messages using the OSNMA, as described by Nicola et al. (2022); Gamba et al. (2020a). Furthermore, a set of functions is being developed to support future GPS Chimera authentication service processing (Gamba et al., 2020b).
3.10 The MATRIX SDR for Navigation with SOPs
MATRIX (Multichannel Adaptive TRansceiver Information eXtractor) is a state-of-the-art cognitive SDR, developed at Kassas’ Autonomous Systems Perception, Intelligence, and Navigation (ASPIN) Laboratory, for navigation with terrestrial and space-based SOPs (Kassas et al., 2020). MATRIX continuously searches for opportune signals from which it draws navigation and timing information, employing signal characterization on the fly as necessary. MATRIX can produce a navigation solution in a standalone fashion (Shamaei & Kassas, 2021a) or by fusing SOPs with sensors (e.g., IMU (Morales & Kassas, 2021), lidar (Maaref et al., 2019), etc.), digital maps (Maaref & Kassas, 2020), and/or other signals (e.g., GNSS) (Kassas et al., 2017). Figure 1 shows MATRIX’s architecture, and Table 11 lists its main features.
On one hand, MATRIX has achieved the most accurate navigation results to date in the published literature with cellular SOPs (3G code division multiple access (CDMA), 4G LTE, and 5G new radio (NR)), achieving meter-level navigation indoors (Abdallah & Kassas, 2021) and on ground vehicles (Maaref & Kassas, 2022) and sub-meter-level navigation on uncrewed aerial vehicles (Khalife & Kassas, 2022). In addition, MATRIX’s efficacy has been demonstrated in a real-world GPS-denied environment (Kassas, Khalife, Abdallah, & Lee, 2022), achieving a position root mean squared error of 2.6 m with 7 cellular LTE eNodeBs over a trajectory of 5 km (one of which was more than 25 km away), during which GPS was intentionally jammed (Abdallah et al., 2022). MATRIX has also achieved remarkable results on high-altitude aircraft, where it was able to acquire and track cellular 3G CDMA and 4G LTE signals at altitudes as high as 23,000 ft above ground level and from cellular towers more than 100 km away (Kassas, Khalife, Abdallah, Lee, Jurado, et al., 2022). Furthermore, meter-level high-altitude aircraft navigation was demonstrated over aircraft trajectories exceeding 50 km, by fusing MATRIX’s cellular navigation observables with an altimeter (Kassas, Abdallah, et al., 2022).
On the other hand, MATRIX has achieved the first published results in the literature for exploiting unknown SpaceX’s Starlink LEO satellite signals for positioning, obtaining a horizontal positioning error of 10 m with Doppler observables (Neinavaie et al., 2021) and 7.7 m with carrier phase observables (Khalife et al., 2022). In addition, the first ground vehicle navigation results with multi-constellation LEO satellites (Orbcomm, Iridium NEXT, and Starlink) were achieved with MATRIX (Kassas et al., 2021), upon coupling its LEO navigation observables with an INS in a tightly coupled fashion through a simultaneous tracking and navigation framework (Kassas et al., 2019).
3.11 Other Achievements with GNSS SDRs
Apart from the success stories described in the previous subsections, a number of other achievements have been accomplished with GNSS SDRs, as listed in this subsection.
The first real-time GNSS/INS integration with an SDR was achieved by Gunawardena et al. (2004), and one of the first GNSS SDR implementations on a GPU was reported by Hobiger et al. (2010).
GNSS SDRs are known to achieve the highest possible sensitivity, as different integration schemes or data wipe-off procedures can be performed in post-processing. This enables very long coherent integration times, which are beneficial for sensitivity or multipath mitigation, as reported in Section 3.8. Characterization of the GPS transmit antenna pattern with a 30-s-long coherent integration resulting in 0-dBHz sensitivity has been discussed by Donaldson et al. (2020). The same sensitivity was achieved by 300 noncoherent integrations, each 1 s long, by iPosi Inc. (2015) for the purpose of indoor timing.
Graphical programming languages, such as LabVIEW and Simulink, are attractive choices for implementing SDRs because of their flexibility, modularity, and upgradability. Moreover, because SDRs are conceptualized as block diagrams, graphical programming languages enable a one-to-one correspondence between the architectural conceptualization and software implementation (Hamza et al., 2009; Kassas et al., 2013).
The scope of SDRs was first extended to non-GNSS signals by McEllroy et al. (2006). SDRs became the implementation of choice in numerous studies aimed at exploiting SOPs for navigation purposes (Diouf et al., 2021, 2019; Kassas et al., 2017), such as (i) cellular 3G CDMA (Khalife et al., 2018; Pesyna et al., 2011; Yang & Soloviev, 2018), 4G LTE (del Peral-Rosado et al., 2017; Ikhtiari, 2019; Kang et al., 2019; Shamaei & Kassas, 2018; Shamaei et al., 2018; Wang et al., 2022; Yang et al., 2022), and 5G NR (Abdallah & Kassas, 2022; del Peral-Rosado et al., 2022; Fokin & Volgushev, 2022; Lapin et al., 2022; Santana et al., 2021; Shamaei & Kassas, 2021b; Tang & Peng, 2022); (ii) AM/FM radio (Chen et al., 2020; McEllroy, 2006; Psiaki & Slosman, 2022; Souli et al., 2021); (iii) digital television (Souli et al., 2020, 2022; Yang & Soloviev, 2020); and (iv) LEO satellites (Farhangian et al., 2021; Farhangian & Landry, 2020; Nardin et al., 2021; Orabi et al., 2021; Pinell, 2021; Zhao et al., 2022).
Because of their enhanced analysis possibilities, GNSS SDRs proved to be very useful for elucidating ionospheric scintillation. The first dedicated SDRs were described by O’Hanlon et al. (2011); Peng & Morton (2011). The authors used a general-purpose front-end that was reconfigurable for multi-GNSS multi-band signals and a custom dual-frequency front-end. The first system further evolved into an intelligent, scintillation event-driven data collection, as reported by Morton et al. (2015).
Commercialization of academic SDR developments was partly discussed in the previous sections. In addition, a major receiver manufacturer has provided GNSS SDRs, starting with a timing receiver (Trimble Inc., 2005) and then moving to a flexible narrowband receiver (Trimble Inc., 2017). Wideband signals were later added, with some signal processing performed on an FPGA, as reported by PR Newswire (2021). The most recent commercial activity has been reported by LocusLock (2022) and builds upon the software described in Section 3.1.
4 SDR FRONT-ENDS
As outlined above, a front-end is required to obtain digital samples for SDR processing. The front-end tasks are to receive, filter, amplify, downconvert, and further digitize and quantize the analog RF signal entering the GNSS antenna. Many different types of front-ends have been used for GNSS SDRs. Roughly, five different categories can be identified:
Discrete components: Using RF-connectable components such as LNAs, filters, or ADCs, it is comparable easy to realize the function of a front-end and log IF or baseband samples. These setups are easy to realize, but are often bulky and sometimes prone to interference.
Commercial signal recorders: Several companies offer GNSS signal recorders that allow one to record (and often to replay) one or more GNSS frequency bands. These recorders usually do not implement a real-time connection to an SDR.
Generic non-GNSS front-ends: SDR technology is used in many different fields of electrical engineering, and front-ends covering a wide frequency range are available. Their prices range from a few dollars (Fernández–Prades et al., 2013) to highly sophisticated multi-channel front-ends costing several tens of thousands of dollars. The oscillator quality, bit width, and RF-filter characteristics are not always optimal for GNSS signal processing.
Dedicated GNSS real-time front-ends: Built for the purpose of realizing a real-time GNSS SDR, these front-ends are compact and built with discrete components. A good example is described in Section 4.1.
ASICs: Some RF ASICs seem to target GNSS SDR use, and evaluation kits allow streaming of IF samples, e.g., as reported by NTLAB, UAB (2022); RF Micro Devices, Inc., Greensboro (2006).
GNSS signals need a relatively high sampling rate of the front-end, and when connected to a PC via a USB cable, the transfer was not always reliable in early years. Various optimizations and workarounds have been implemented, such as watermarking the IF sample stream and skipping lost sample packets (Foerster & Pany, 2013). With the advent of USB 3.0 and PCIe, these solutions became obsolete.
In the following section, we describe Fraunhofer USB front-ends as an example of user needs as well as the main features and general architectures of GNSS SDR front-ends. For a broader perspective of GNSS-compatible front-ends in the market, the interested reader can refer to the work by (Borre, Fernández-Hernández et al., 2022, Ch. 12).
4.1 Fraunhofer USB Front-Ends
The scientific community, along with some industrial partners, required a multi-band solution for the upcoming civil multi-band signals in GPS and Galileo planning. In 2006, Fraunhofer IIS developed a front-end called the L125 Triband USB (see Figure 2(a)), which allowed recording of fixed frequencies of L1/E1, L2, and L5/E5a. This front-end had one antenna input and, via two USB 2.0 connectors, could record data streams with a sampling rate of up to 40 megasamples per second (MSPS) and a 2- or 4-bit ADC resolution. However, increasing customer demands for portable and flexible solutions led to a complete redesign of the USB front-end concept. One major request was reconfigurability on the SDR front-end side. To meet these different requirements in one SDR front-end hardware component, a new version of the USB front-end was developed that realizes signal conditioning to an onboard FPGA, enabling desired reconfigurability on the fly. This feature was necessary to allow for a single-band receiver with a low sampling rate for specific real-time SDR projects, as well as a wideband and multi-frequency front-end for other projects.
In 2012, Fraunhofer IIS (Rügamer et al., 2012) introduced the Flexiband multi-system, multi-band USB front-end depicted in Figure 2(b). Within the last ten years, this front-end has been used and validated in numerous scientific and industrial projects. Furthermore, it has been commercialized and is distributed as the “MGSE REC” product of TeleOrbit GmbH (2022).
A regular Flexiband unit consists of up to three analog reception boards, a carrier board with ADCs and an FPGA, and a USB 3.0 interface board. A common antenna input port is supported, with separate front-end input signals for up to three antenna inputs. Three dual-channel ADCs sample the incoming signal with 81 MSPS and 8 bits in-phase/quadrature. The raw data stream is received by an FPGA in which different digital operations such as filtering, mixing, data rate reduction, and bit-width reduction as well as digital automatic gain control are applied. Finally, a single multiplexed data stream is formed together with a checksum. This multiplexed stream is sent via a USB 3.0 interface to the PC. Data rates of up to 1296 MBit/s or 162 MByte/s for a raw data stream are supported. The Flexiband GUI software receives the raw multiplexed stream, verifies its integrity, and demultiplexes it. The data streamed can be either written to hard disk or sent to a customer application (e.g., a software receiver). The raw samples can be stored as a multiplexed data stream, in an 8-bit/sample format, or directly as a .mat file for MATLAB. In parallel, the ION Metadata *.sdrx is provided.
Because of its bandwidth, sampling rates, quantization, and multiplexing schema flexibility, the ION SDR Standard is a perfect fit to clearly and unambiguously define the configuration for the user. Therefore, immediately after the first conclusion of the ION SDR Standard, each binary raw data output file of the Flexiband front-end is equipped with an sdrx metadata file specifying the raw data format.
Finally, a replay variant of this Flexiband exists, which reads in the raw IF samples on hard disk using the ION SDR Standard specification and replays the digital data as an analog RF output stream supporting multiple GNSS bands at the same time.
5 ION SDR STANDARD
The previous sections have already clarified that data exchange between the various SDRs requires a certain level of standardization. The events that led up to the suggestion of developing what became the ION SDR Standard (also known as the ION GNSS Metadata Standard, ION SDR Metadata Standard, GNSS SDR Sampled Data Metadata Standard, or GNSS SDR Metadata Standard) can be traced back to circa 1999. Building upon the successful contributions made by Akos, the Ohio University Avionics Engineering Center undertook several research projects leveraging GPS SDRs. One such project was called the GPS anomalous event monitor (GAEM) (Snyder et al., 1999). This project was sponsored by the FAA Technical Center and led by Prof. Frank van Graas. Commercial GPS receivers within prototype local-area augmentation system ground facilities were experiencing brief unexplained outages. GAEM maintained a continuous 10-s history of IF samples in a circular memory buffer. When an outage occurred, GAEM was triggered to dump this buffer to disk and collect for an additional 10 s. These sample files were then post-processed in MATLAB to determine the cause of the anomaly. Early versions of GAEM used commercial data collection cards and had numerous issues related to their proprietary drivers. Around 2001, Gunawardena developed a refined version of GAEM based on one of the earliest commercially available PCI-based dual-ADC-plus-FPGA development cards. This version collected two GPS L1 data streams at 5 MSPS and 2-MHz bandwidth. This version of GAEM was fielded at three airports, operated continuously for over three years, and helped to characterize numerous anomalous events (Gunawardena et al., 2009). This GAEM also supported a continuous collection mode and was used for several research projects, including the characterization of GPS multipath over water (Zhu & Van Graas, 2009) and GPS/IMU deep integration demonstrations in flight (Soloviev et al., 2004). For the latter project, the 2-kHz raw data from a micro-electromechanical system IMU were interleaved with SDR samples thanks to the FPGA-based architecture that allowed for such custom capabilities.
Circa 2002, as these research projects progressed, the 2-MHz bandwidth limitation of GAEM became apparent. There was a pressing need to support emerging research opportunities related to GPS L5, as well as high-fidelity GPS signal quality monitoring. A multi-band and higher-bandwidth (24 MHz) front-end and SDR data collection system was needed. There were only a handful of vendors selling such systems at the time, and it was not clear whether these systems would serve the purpose for satnav SDR applications (sampling coherency concerns, etc.). Moreover, the >$350k price tag of these systems far precluded any hope of their purchase for university research. Thus, researchers decided to develop this capability in-house. In 2003, a 2-channel L1/L5 front-end with 24-MHz bandwidth and 56.32 MSPS was developed (Gunawardena et al., 2007) based on connectorized RF components. The sampling and collection subsystems were carried over from GAEM.
The capabilities of the dual-frequency high-bandwidth system attracted interest from several universities, government research groups, and a defense contractor. To support these opportunities, the development of a new system known as the Wideband TRIGR was completed in 2008 (Gunawardena & Van Graas, 2011). The front-end was miniaturized to a single-frequency custom printed circuit board module. Up to eight such modules (with the required frequency options) were combined with an 8-channel 12-bit ADC to create modular systems for various sponsors. The raw samples from the ADC are transferred to a PCIe FPGA card, where the eight streams are packed in various formats according to the user’s selection in a GUI. Supported formats range from any one stream at 1-bit sample depth, any two streams at 12 bits (sign extended to 16), to all eight streams at 4 bits. The sustained data transfer rate from the PCIe FPGA card to storage via a redundant array of independent disks (RAID) was limited to 240 MB/s. Thus, the appropriate format had to be selected to balance between the required capability and transfer rate. The generated file names embed a coordinated universal time (UTC) timestamp as well as the packed stream order and sample depth.
The event-based data collection feature of GAEM needed to be incorporated into Wideband TRIGR. However, the >10× data rate meant that a 10-s circular buffer could not be easily implemented in random access memory using the 32-bit systems of the day. This issue was addressed by writing data as a sequence of smaller files, where a new file was spawned before the current file was closed, with some sample overlap for data integrity, a technique known as temporal splitting. A separate process was used to delete older files from the RAID array to make room for new files unless an event was received, in which case the files surrounding the event were moved to a folder for post-processing.
With the myriad of sample packing formats available for Wideband TRIGR, along with the temporal splitting-based file generation scheme, it became clear that a machine-readable metadata file needed to be included with every collection. An XML schema was designed for this purpose.
Up until this time, apart from the FPGA-based real-time GPS receiver that was developed and used for certain projects, all SDR files generated by GAEM and Wideband TRIGR were post-processed in MATLAB. As others have mentioned, this step was excruciatingly slow, especially for Wideband TRIGR data. To address this issue and to support the rapid emergence of multi-band and multi-constellation satnav signals, Gunawardena wrote and distributed a MATLAB SDR toolbox in which correlation was performed in optimized C code and multi-threading was leveraged in a parallel data architecture. This toolbox, known as ChameleonChips, also read the XML metadata files produced by Wideband TRIGR to determine the appropriate sample unpacking kernel to use. This work was presented at ION GNSS+ 2013 in Nashville, TN (Gunawardena, 2013). During this presentation, it was suggested that the satnav SDR community adopt a metadata standard—similar to the standard developed for Wideband TRIGR—in order to alleviate the numerous difficulties associated with sharing such files. This suggestion was met with widespread support and enthusiasm. Longstanding ION members Phillip Ward, Jade Morton, and Michael Braasch helped to pitch this idea to the ION Executive Committee.
During the January 2014 Council Meeting in San Diego, ION approved the process for establishing a formal standard (Gunawardena et al., 2021). The ION GNSS SDR Metadata Working Group (WG) was formed in April 2014 with Thomas Pany and Gunawardena as co-chairs (James Curran was later added as a third co-chair). Membership represented academia, industry (including satnav SDR product vendors as well as traditional satnav equipment manufacturers), non-profit research entities, and government agencies spanning countries in Europe, America, Asia, and Australia. The WG developed the standard as well as associated normative software over a course of six years. With regard to the normative software, while many individuals contributed, initial development of the C++ object model was performed by Michael Mathews of Loctronix while James Curran wrote much of the functionality to decode packed samples based on the metadata specification. The draft standard was adopted as the formal ION SDR Standard in January 2020.
5.1 Use of the ION SDR Standard
Today, the ION SDR Standard serves as a reference for describing IF formats and is useful, for example, for public tenders or if an established format is needed. A number of SDRs include the C++ libraries to read metadata and IF samples.
The level of exchange of IF samples between research groups is limited to some extent, and such exchanges occur much less frequently than, e.g., the exchange of RINEX files. This trend is related to the huge size of IF sample files and to the fact that, for the majority of GNSS use cases, RINEX observation data or PVT exchange is sufficient. Furthermore, GNSS SDRs still tend to use primarily the same front-ends, and once the respective data format is known, there is obviously no need to describe it via the XML format. A disadvantage of the C++ routines is their generic design, which renders sample reading quite slow, as each sample is isolated via a number of for-loops from the input files. Clements et al. (2021) proposed an algorithm to automatically generate optimized code for sample reading for a given IF format, but this proposal has not yet been manifest into a usable implementation.
5.2 ION SDR Standard Extension
During the standardization process, a number of features were identified that appeared to be useful for the standard; however, a lack of resources did not allow for the inclusion of all of these features in the formal standardization procedure. These features are described in Appendix II of ION SDR Working Group (2020). At the ION-GNSS+ 2022 meeting in September, the following points were discussed and will be included in Appendix II of the next version (V1.1) of the ION SDR Standard.
5.2.1 Flexible Bit Layout
The ION SDR Standard defines a “lump” as the ordered containment of all samples occurring within an interval. The ordered containment is understood in a regular way, with the samples of individual streams held together. Clements et al. (2021) view this aspect as a limitation, as highly efficient SDRs may use efficient bit-packing schemes to optimize data transfer over communication lines that need buffering. They have identified a need to distribute the samples of different streams in interleaved ways over the lump. This interleaving cannot be described by V1.0 of the ION SDR Standard. To overcome this limitation, the authors propose a new but optional attribute for the lump object, called “layout.” If the layout is present, further information on the bit packing scheme must be provided, explicitly describing the type of each bit of a lump. The authors presented a detailed proposal for this new lump layout following the structure of the existing standard. The proposal even includes more advanced bit use cases, such as puncturing (e.g., explicit omission of bits) and overwriting of bits by time markers.
5.2.2 Refined Sample Rate/Epoch Definitions
Clements et al. (2021) noted that V1.0 of the ION SDR Standard makes implicit assumptions about the timing of the sampling process that are not suitable for staggered sampling. Staggered sampling occurs if the sampling instants of different GNSS signals are delayed with respect to each other, which might be of use for increasing the observability of GNSS interference in a multi-antenna system. To overcome this limitation, the authors propose the addition of two new attributes for “stream” objects to shift the sampling epochs of different GNSS streams with respect to each other.
5.2.3 JSON Format for Metadata Files
Comment ID 22 of the initial request for comments suggested that the WG should consider markup languages other than XML for metadata files, specifically JSON, YAML, and TOML (Anonymous, 2017). In 2017, this comment was addressed by asserting that the XML format would be maintained for the time being, as normative software that parses XML had already been developed. However, the WG responded with the assurance that “other markup languages will be considered in the future based on community need and interest.”
As of the time of this writing and with the experience gained from developing PyChips (a satnav SDR that is completely described using a draft signal/system specification language based on JSON, as described in Section 3.7), it is this author’s opinion that JSON may have some distinct advantages over XML for future applications and use cases. For example, JSON streaming is a methodology for transferring object-oriented data over communications protocols (Wikipedia, 2022) and is widely used in well-known applications such as that described by Plotly (2022). Hence, streaming JSON could be one way to parse SDR sample streams whose formats are changing dynamically.
Figure 3 presents a notional listing for a JSON-formatted metadata description for the Flexiband front-end XML metadata listing reported by Gunawardena et al. (2021).
To maintain compatibility with the existing and formally adopted XML-based metadata specification, it is understood that any adoption of another markup language such as JSON must include open-source normative software and tools to convert between these formats. The adoption of JSON-based metadata is currently being considered for future versions of PyChips. Once a successful implementation has been achieved, consideration for adopting JSON as another valid option for representing ION SDR Standard-compliant metadata in a future version of the standard will be requested.
SUMMARY AND CONCLUSION
Since the beginning of GPS SDR developments in the mid 1990s, together with the operational declaration of GPS, the feasibility of GPS SDR has been widely proven by several platforms and their derivatives. We defined GNSS SDR platforms as those implementing receiver functions in general-purpose software and processors and divided them in real-time receivers, teaching/research tools, and snapshot receivers. We described some of these platforms, with a focus on those related to the authors but also including other developments. In particular, and based on the pioneering work by Akos, we described the bit-wise parallelism platform developed by the Cornell GPS group, which led to GRID by UT Austin; the MuSNAT receiver by UniBwM, which led to IFEN GmbH’s SX3 commercial receiver; the SoftGPS MATLAB receiver and associated book, which are widely used for GNSS teaching and are also influencing other platforms, such as FGI-GSRx; the popular C++ open-source GNSS-SDR by CTTC; AutoNav SDR by Inha University; PyChips by Gunawardena, based on Python; the snapshot GNSS receiver developed by UAB, leading to cloudGNSSrx; the real-time NGene receiver developed by LINKS, used for early testing of the first Galileo signals and OSNMA; and the MATRIX receiver by ASPIN for navigation with terrestrial and space-based SOPs, among others. We provided an overview of the tasks and components of SDR front-ends, and for this purpose, we described Fraunhofer developments from the last few years as a reference. Finally, we discussed the ION SDR Standard, officially approved by ION in 2020, and its current extensions.
In view of the impact in the GNSS community and progress in the last decades, we conclude that GNSS SDR has a promising future and will continue coexisting with FPGA and ASIC receivers in the decades to come.
HOW TO CITE THIS ARTICLE
Pany, T., Akos, D., Arribas, J., Bhuiyan, M. Z. H., Closas, P., Dovis, F., Fernandez-Hernandez, I., Fernández-Prades, C., Gunawardena, S., Humphreys, T., Kassas, Z., López-Salcedo, J. A., Nicola, M., Psiaki, M. L., Rügamer, A., Song, Y-J., & Won, J-H. (2024). GNSS software-defined radio: History, current developments, and standardization efforts. NAVIGATION, 71(1). https://doi.org/10.33012/navi.628
ACKNOWLEDGMENTS AND REMARKS
The authors are mainly listed in alphabetical order to reflect the variety and importance of all contributions. The contributions have been partly edited by Thomas Pany, who also takes responsibility for the structure of the work, the abstract, and the introduction and is thus listed as first author. This article is based on a contribution by the same authors to the ION-GNSS+ conference 2022 in Denver, CO.
The GNSS SDR developments at the University of the Bundeswehr Munich, described in Section 3.2, were supported by numerous research projects administered by the German Aerospace Center and were financed by the German Federal Ministry for Economic Affairs and Climate Action. The authors acknowledge financial support from the University of the Bundeswehr München for this publication.
At Northeastern University, support has been partially provided by the NSF under awards ECCS-1845833 and CCF-2326559.
The UAB snapshot GNSS software receiver was supported in part by numerous ESA-funded research projects and by the Spanish State Research Agency under project PID2020-118984GB-I00.
The MATRIX SDR development at the ASPIN Laboratory was supported by the Office of Naval Research under grants N00014-16-1-2305, N00014-19-1-2613, and N00014-19-1-2511; the Air Force Office of Scientific Research under grant FA9550-22-1-0476; the U.S. Department of Transportation under grant 69A3552047138 for the CARMEN University Transportation Center; and the National Institute of Standards and Technology under grant 70NANB17H192.
The authors would like to acknowledge the work of Prof. Kai Borre, who passed away in 2017, for his influential contributions to the GNSS SDR field over the last decades.
The views expressed in this article are those of the individual authors and do not reflect the official policy or position of any state or government entity.
This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited.