GNSS Software-Defined Radio: History, Current Developments, and Standardization Efforts

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/N₀, 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.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 1

MATRIX cognitive SDR architecture

The SDR consists of (i) USRPs to collect different radio signals, (ii) various modules to produce navigation observables from different types of signals (e.g., cellular, LEO satellites, etc.), (iii) external sensors (e.g., IMU, lidar, GNSS receivers, etc.), whose measurements can be fused with the navigation observables produced by the signal modules, and (iv) a navigation filter that fuses all measurements to produce a navigation solution.

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.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).

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 2

Two exemplary USB front-ends from Fraunhofer IIS (a) TriBand USB2.0 front-end from 2006 (b) Flexiband USB3.0 front-end from 2012 onwards

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.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.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).

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 3

Notional JSON representation of Flexiband front-end metadata from 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.