The civil infrastructures behind safety-critical applications in aviation, maritime and terrestrial navigation rely heavily on global navigation satellite system (GNSS) signals. The civil GNSS signal structures are vulnerable to spoofing attacks, which can endanger public safety.
In this work, the authors introduced an optimal cumulative position-domain innovation (CPI) monitor to detect spoofing by accumulating tracking errors embedded in the spoofer’s signal. The authors also derived relationships between missed detection probability, tracking error magnitude and monitor run time to show that even with decimeter-level tracking error, the monitor can detect spoofing with a low probability of missed detection in less than 1 minute.
The team of researchers evaluated the performance of the CPI monitor for both white and time-correlated (colored) tracking errors. To compute protection levels and detect short-duration spoofing, researchers proposed a complementary solution separation (SS) monitor to implement in sequential, overlapping windows to compare the integrated INS/GNSS position solution against an inertial navigation system (INS) coasting solution. The INS-only coasting element allows the system to maintain positioning continuity after detection, albeit at lower accuracy, as the INS drifts.
The experimental results indicate that implementing a CPI monitor can dismiss the conjecture that INS-based spoofing detection is susceptible to slowly deviating counterfeit signals. It was found that if the duration of the spoofing event exceeds a minimum time defined by the variance and time constant of the tracking error, the spoofer’s target tracking error can be detected.
Birendra Kujur, Samer Khanafseh and Boris Pervan; “Optimal INS Monitor for GNSS Spoofer Tracking Error Detection.”
Space-Time Adaptive Processing
Antenna arrays and spatial processing techniques are among the most effective countermeasures against GNSS signal interference. In this paper, the authors propose a new array concept, space-time adaptive processing (STAP), that consists of spatially distributed subarrays small enough to fit inside the non-metallic parts of an automobile. The device is designed to be installed in bumpers or side mirrors.
During the experimental testing, the authors used beamforming algorithms for the array to perform against jammers in the GPS L5 and Galileo E5a bands. The authors composed a GNSS jamming scenario to compare conventional space adaptive processing (SAP) methods and the new STAP method using real-life measurements in a dynamic scenario. In this simulation, the car was rotated 360° throughout the complete measurement. The comparison between the received signal quality demonstrated an improvement for wideband signals.
The results demonstrate that the performance of the STAP was dependent on the number of taps analyzed in the testing simulation that included different fractional delays. Overall, the research showed STAP could outperform SAP implementation in applications requiring robust tracking, as it was able to process all satellites for an additional 12 seconds.
Marius Brachvogel, Michael Niestroj, Michael Meurer, Syed N. Hasnain, Ralf Stephan and Matthias A. Hein; “Space-Time Adaptive Processing as a Solution for Mitigating Interference Using Spatially-Distributed Antenna Arrays.”
Enabling RTK Positioning Under Jamming
New GNSS applications demand high position accuracy and resilience against radio frequency interference. Separately, these demands can be fulfilled by multi-antenna systems using spatial filtering and carrier-phase positioning algorithms, such as real-time kinematics (RTK), respectively. However, combining these approaches creates a severe issue: the spatial filtering induces a phase offset into the measured carrier phase leading to a loss of position accuracy.
This paper presents a new approach to compensate for the phase offset without knowing the antenna array radiation pattern or the direction of arrival of the signals. The proposed algorithm was tested in two different scenarios using an in-house software receiver in combination with the RTKlib — an open-source program package for GNSS positioning — that was used to estimate an RTK solution. In the first scenario, the signal power of a jammer from a constant direction of arrival (DoA) was raised stepwise. In the second scenario, a jammer with constant signal power was moved around the receiver antenna array. For both scenarios, the proposed algorithm was compared with a multi-antenna system not compensating for the phase bias and with a single antenna processing.
It is most suitable in situations where a medium-to-high precision (dm to cm) solution must be resilient to interference. A very high precision solution (cm to mm), comparable with a geodetic receiver accounting for antenna phase center variations, cannot be achieved with this algorithm.
In this paper, the signal recording and processing time was limited to less than half an hour. The carrier-phase offset produced by the proposed algorithm may become larger over longer observation times. Evaluating this is part of future work.
Tobias Bamberg, Andriy Konovaltsev and Michael Meurer; “Enabling RTK Positioning Under Jamming: Mitigation of Carrier-Phase Distortions Induced by Blind Spatial Filtering.”
Several layers of defense can be implemented in a GNSS receiver to improve its performance in the presence of interference. These layers include the use of pre-correlation mitigation techniques, post-correlation quality indicators to screen measurements and fault detection and exclusion (FDE) at the position solution level.
This paper provides a characterization of the interactions between these layers of interference mitigation and a measurement quality check. Data collected in the presence of increasing levels of jamming were processed using different interference mitigation techniques, including robust interference mitigation (RIM) and the adaptive notch filter (ANF). A software-defined radio (SDR) approach was used, and measurements were generated by considering five interference-mitigation techniques. Position solutions were then computed using a forward-backward approach for receiver autonomous integrity monitoring (RAIM). Signals from GPS, Galileo and BeiDou were processed and both single and dual-constellation solutions were analyzed.
The results demonstrated that interference mitigation allowed the receiver to track a larger number of signals even in the presence of high levels of jamming power. This increased measurement availability was then effectively exploited by RAIM techniques to provide more reliable solutions. Measurements from several constellations further improved the reliable availability of the position solutions.
Ciro Gioia and Daniele Borio; “Multi-layered Multi-Constellation Global Navigation Satellite System Interference Mitigation.”
Artists rendering of the B-21 raider, which is being produced by Northrup Grumman for the U.S. Air Force to operate in tomorrow’s high-end threat environment. (Image: U.S. Air Force)
With assured positioning, navigation and timing (APNT) and low-Earth orbit PNT (LEO PNT) coming on strong, what does the future hold for military and commercial systems dependent on the current configuration of GPS? Should military and commercial platforms be modified to include APNT, for now, with an eye to adding LEO PNT in the future? Should they integrate these two systems, or rely on one or the other as standalone systems?
Government and industry agree that interference with GPS and all GNSS is an increasing threat as jamming and spoofing technologies evolve. This has prompted government support for APNT to bolster GPS. A Feb. 12, 2020, Executive Order required a comprehensive update to national policy on PNT services by the federal government, and by owners and operators of critical infrastructure to strengthen the resilience of critical infrastructure.
Research, development and production have improved the performance — positioning, timing and (desired) accuracy — of GNSS PNT and the ability to operate in RF-challenged environments. APNT gives the U.S. military a reliable way to further enable GPS, or to act as an alternative to it, by utilizing other sensors, such as inertial navigation systems, differential GPS, visual sensors, lidar, radar, radios and star trackers that complement GPS.
The near-term expansion of internet service to include commercial broadband LEO satellites also provides potential for robust PNT, using their waveforms as signals of opportunity (SOOP). GPS and other GNSS have an infrastructure to maintain very precise time throughout their constellations, as well as satellites with specially designed transmitters, clocks, and a waveform dedicated to the PNT function. By contrast, SOOPs are in space for another purpose and not optimized for PNT. Therefore, the challenge is to exploit features of the SOOP waveforms, designing innovative techniques to determine the range to each satellite and to provide users with reliable PNT. The approach for LEO PNT may have applications to ground troops and for aerial, munition, missile and commercial applications requiring higher levels of PNT security and integrity.
GPS receivers for future military platform designs may use a software defined radio (SDR) approach and be capable of incorporating LEO PNT signals. This technology, although designed to work standalone, can be used to complement existing navigation sensors that are typically used in navigation systems, including APNT. Expansion to the usage of multiple constellations will serve to optimize performance and resiliency in an RF-challenged environment. However, LEO satellites’ closer proximity to Earth and their signal structures allow for higher signal powers, thus are more robust against jamming. With all these separate systems or fusion by SDR, how does the receiver ensure the integrity of the signal or its accuracy? An SDR qualification test would involve an unlimited number of scenarios.
One hallmark of the GPS program is that it facilitates a thorough systems engineering effort by managing in a single location interface control documents (ICDs) for alternative systems being developed by different program offices all over the country. This makes both the integration of the systems and the development of the receivers extremely difficult and complex.
“The new SPD-7 [Space Policy Directive 7, the United States Space-based Positioning, Navigation and Timing Policy, dated Jan. 15, 2021] focusing on interoperability and APNT is a seminal document to address a realized threat and a way forward,” said Bernie Gruber, a former head of the GPS Directorate (now the Military Communications and PNT Directorate). “To that end, the combination of SDRs and data fusion potentially offer a clear advantage to utilize signal and sensor diversity, thus improving the robustness of critical PNT information.”
A Step-by-Step Exposition of an Educational Resource
Innovation Insights with Richard Langley
THE RADIO. It’s been around for more than 100 years. Pioneering work by Guglielmo Marconi and others in the1890s and 1900s resulted in practical wireless telegraphy devices that permitted point-to-point communications with ships at sea and between stations on land hundreds and thousands of kilometers apart and even between stations on different continents. The first radio broadcasts (point-to-multipoint) were time signal transmissions and weather broadcasts. Experimental audio transmissions took place in the early 1900s, and by 1920 or so, radio stations were established in many countries for broadcasting speech and music to the general public.
The first radio receivers were simple crystal sets. It wasn’t until the mid-1920s that tube radios became commercially available. Eventually, tubes were replaced by transistors, and transistors by integrated circuits. The introduction of microprocessors resulted in digital receivers, with the conversion of the received analog radio signals into audio being carried out digitally for the most part.
One of the latest advances in radio technology is the software-defined radio or SDR. An SDR typically consists of two components: a piece of hardware, called a radio frequency (RF) front end, and a piece of software run on a general-purpose computer. The job of the front end is to convert a portion of the radio spectrum received by its antenna to a digital data stream processed by the software. The software decodes the data to produce the desired result. Since the software does most of the “heavy lifting” in processing a radio signal, it is often called the SDR itself. And by the way, there are SDR transmitters, too.
It should come as no surprise that SDR technology has come to the GNSS field. In fact, in 2007, the seminal text on GNSS SDRs, A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach, was published along with the sale of an inexpensive RF front-end in a thumb-drive-sized package that allowed graduate students and others to experiment with a GNSS SDR themselves. And we have covered GNSS SDR developments in this column from time to time, most recently in January 2018 (“The Continued Evolution of the GNSS Software-Defined Radio: Getting Better All the Time”).
In this month’s column, researchers from the lab that helped produce the SDRs documented in the 2007 book (which is still in print) discuss their development and testing of additional freely available SDR codebases covering all four GNSS (GPS, Galileo, BeiDou and GLONASS). They provide an excellent resource for learning how GNSS receivers actually work.
By Joan Bernabeu, Nicolas Gault, Yafeng Li and Dennis M. Akos
With the publication of the book A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by Kai Borre, Dennis Akos and their fellow authors, an open-source GNSS software-defined radio (SDR) receiver developed using Mathwork’s Matlab language was made available, together with sample data sets that facilitated the testing process for all interested readers. The first SDR implementation focused on processing the GPS L1 C/A-code legacy signal and served as a starting point for students and researchers in the Radio Frequency (RF) and Satellite Navigation Laboratory at the University of Colorado Boulder, where later activities aimed to improve the software code and add new features as new GNSS signals emerged. As a result, the initial codebase evolved into a complete collection of SDRs capable of processing all GNSS signals from every satellite constellation, with BeiDou’s B1I, B1C, B3I and B2a signals the latest additions. The most recent efforts were dedicated to collecting all SDR codebases, putting them in a common format, and testing them to give an account of their performance. This article describes our efforts, placing special emphasis on explaining the test framework designed to test each SDR, as well as on reporting the adjustments made and the results obtained. GPS test cases have been taken as examples to show how some SDRs were assessed when issues were found in the results they provided.
OPEN-SOURCE GNSS SDR COLLECTION
The whole SDR collection has been developed in Mathwork’s Matlab programming language. To run the code and perform tests, users simply require an active Matlab license and the software available on their computer. Once these requirements are met, the user can choose to download any of the available codebases and the corresponding data set to start experimenting.
We recommend using version control software to keep track of changes made to the original version of the code. Users should consult the Borre et al. text for further details on running the codebases.
A total of 12 SDR codebases are aimed at processing each of the GNSS signals (see TABLE 1). All code files for each SDR are organized in the same subdirectories, and most of them have the same filenames.
Table 1. All GNSS signals that can be processed by the SDR collection, organized by their corresponding satellite systems.
All SDRs are set to work with a default configuration. They are all run using an init.m script, which collects user settings (input data file path, sampling frequency and so on) from the initSettings.m configuration script. Given this, the first file that users may want to modify is initSettings.m, to define the run settings for a given test. Most of the SDRs operate in an identical way, however some include particular features oriented at exploiting certain characteristics of the corresponding GNSS signal. The GPS L2C SDR, for example, gives the user the option of whether to process the pilot component of the signal.
The test samples available in the public directory were obtained in accordance with the characteristics depicted in TABLE 2 for every signal. The first two columns from the left show all the signals the SDR collection can process and the central carrier frequency at which they are transmitted. The third column gives the bandwidth selected in the recording process for every signal. This value must match the sampling frequency defined in the initSettings.m file for each SDR. Only three frequency bandwidths can be used to record GNSS data, so as to make the configuration structure more homogeneous across different SDRs. They were selected to ensure similar characteristics for each signal in terms of performance, encompassing most of the signal power for each modulation, but also keeping the recorded GNSS data files within a reasonable size.
Table 2. Summary of the tested GNSS signals’ center frequencies and the selected bandwidth (BW) for their processing. The common IF for all signals is 20 MHz.
All the signals were mixed to a common intermediate frequency (IF) of 20 MHz in the recording process. Both the frequency bandwidth and the IF are fundamental to obtain the expected results from each SDR codebase. These are set in the settings file. The default configuration was validated in the testing campaign explained in later sections, and should only be modified to meet the user’s specific needs, being aware that some SDR performance characteristics may also be affected.
BASIC GNSS SDR STRUCTURE
While the general SDR receiver structure is similar across all codebases, each comes with adjustments and/or additions to adapt the code to the format of a specific signal. The general codebase structure can be summarized in four major modules:
signal acquisition
tracking stage
navigation data decoding
position, velocity and time (PVT) computation.
An important remark is that the SDR collection developed is designed to process files of limited duration. The code is designed to use enough data to provide a successful initial acquisition, and then use a single set of satellites for the remaining execution. In other words, there is no extra logic oriented at acquiring or reacquiring satellites after the first acquisition is achieved.
Signal Acquisition.The design of the acquisition scheme depends on the characteristics of the signal the SDR is aiming to process. There are numerous GNSS signal configurations for each constellation that follow different strategies concerning spreading codes, navigation data and secondary codes, which must be accounted for in the acquisition codebase.
All codebases follow a fast Fourier transform (FFT) accelerated serial search-acquisition approach to obtain estimates of the signal’s carrier frequency and code delay, where a number of signal replicas are generated iteratively, separated by a defined frequency interval in the frequency domain. All the frequency offsets are arranged in what are known as frequency bins. This frequency separation will be referred to as the frequency step. The latter is inversely proportional to the integration time and tells the maximum error allowed in the carrier frequency estimate, which is half the frequency step. Both the frequency step and the coherent integration time are parameters that have a strong effect in acquisition results, as will be seen below.
Each local replica is correlated with the input signal to obtain a code-phase estimate. The length of this correlation is the so-called coherent integration time. The maximum correlation measurement from all frequency bins is then divided by the second maximum found. This ratio is called the peak metric and is used in all SDRs to give a measure of the magnitude difference between the maximum obtained and the remaining correlation results. If the peak metric is not high enough, this implies that the maximum is close to other cross-correlation products and so could not correspond to the result obtained after correlating both input and local replica signals with the right code-phase alignment. When the peak metric surpasses the threshold defined in initSettings.m, the satellite is considered to be acquired.
It is worth noting that in all SDR implementations the local replica is constructed by concatenating a whole primary code and a block of zeros of the same length. This prevents navigation bit transitions from affecting the correlation results. For example, GPS L2C-CM SDR’s acquisition correlates 40 milliseconds of data with 20 milliseconds of pseudorandom noise (PRN) spreading code followed by 20 milliseconds of zeros (the zero padding technique).
Tracking Stage.The tracking stage is oriented at refining and keeping track of the code and carrier estimates provided by the acquisition stage as well as demodulating the navigation data. This is achieved using feedback loops organized in channels, which are typically referred to as tracking channels. There will be as many tracking channels as the number of satellites acquired. Each tracking channel makes adjustments to the corresponding local signal replica for the given satellite, so that it resembles the real received signal as much as possible. When the replica is sufficiently accurate, the tracking loop locks onto the signal, removes the carrier and spreading code components, and starts registering data bit transitions. The task of every tracking channel is to account for signal variations so that they can keep locked on the signal for as long as the satellite is available for use.
Tracking channels implement two feedback loops, the delay lock loop (DLL) and the Costas phase lock loop (PLL). The former is focused on the signals’ code phase while the latter on the carrier phase. These modules depend on two major parameters that determine the properties of the loop filter: the damping ratio and the noise bandwidth. On the one side, the damping ratio controls how fast the filter reaches the settling stage. On the other side, the noise bandwidth informs the amount of noise allowed in the filter.
While all SDRs follow similar tracking loop schemes, some signals, such as GPS L2C, need some adjustments to the parameters mentioned above so that they provide the expected results, as we point out later. Tracking results are stored in a Matlab .mat file, but also can be assessed in the plot the tracking stage generates after it finishes processing all the channels.
FIGURES 1a and 1b show an example of two different tracking results plots, each of which include seven figures. These show the in-phase/quadrature (I/Q prompts), the navigation data bits decoded, the changes in the raw/filtered Costas loop and DLL discriminators, and the early-prompt-late metrics. Note that the plots in Figure 1a suggest the navigation data bits were demodulated successfully. In contrast, in Figure 1b, data bits cannot be distinguished because the tracking stage failed to demodulate the navigation message.
Figure 1. (a) shows the plot generated for a successful tracking channel. In contrast, (b) illustrates the results obtained when the tracking loop in question did not lock appropriately to the signal and therefore was not able to demodulate navigation data. (Image: Authors)
Navigation Data Decoding.This stage extracts the navigation data required by the SDR codebase to compute PVT estimates from the results delivered by the tracking stage. The latter outputs I/Q prompt samples representing data bits, containing the encoded navigation data. The navigation data format for each signal can be found in the interface control document issued by each satellite constellation operator.
The general process that each SDR implements to demodulate navigation data from I/Q samples is summarized as follows:
detect a preamble within data bits
arrange the bit sequence in the corresponding structures, such as frames
remove secondary code if present
de-interleave and decode
check if the bit stream has errors
extract navigation parameters
Once navigation parameters are extracted, they are stored and later used by the functions involved in the PVT computation stage.
PVT Computation.The PVT stage takes the decoded navigation data, computes satellite positions, and solves the geometry problem, whose solution is the receiver’s location.
As with all the other stages, all SDRs follow the same approach, and use the least-squares method to solve for a position estimate once all the data is available. Position estimates are delivered in both Earth-centered Earth-fixed and east-north-up coordinates.
Similarly to the tracking stage, the PVT computation stage returns a plot showing some PVT statistics to help the user get an idea of the PVT performance of the test conducted. FIGURES 2aand 2b show an example of two positioning plots obtained for two different data files.
Figure 2. (a) shows the plot of a priori, good statistics for the navigation solution; (b) shows a navigation plot for a file that presented a problem affecting the PVT solution. (Image: Authors)
EXPERIMENTAL SET-UP AND TESTING
In this section, we present the equipment we used in our tests (see FIGURE 3) and detail the process we followed to collect GNSS data, as well as the testing framework designed to exercise the SDR collection.
Figure 3: The antenna was connected to the RF port of the USRP. The USRP sampled the analog data delivered by the antenna using the TCXO as the reference oscillator. The resulting sampled data was stored in a Linux-based computer. (Image: Authors)
RF Antenna.The device used to sense the RF GNSS signals was a Trimble Zephyr2 antenna, which has enhanced capabilities for multipath minimization as well as low-elevation-angle satellite tracking properties.
The antenna was installed on the rooftop of the Ann and H.J. Smead Department of Aerospace Engineering Sciences building at the University of Colorado Boulder.
USRP and TCXO Devices.An Ettus Universal Software Radio Peripheral (USRP) B200 hardware SDR connected to an IQD temperature-compensated crystal oscillator (TCXO) was used to collect digital samples from GNSS analogue signals sensed by the antenna.
The B200 device was controlled by means of the USRP hardware driver (UHD) through a computer running a Linux operating system. UHD is a software application programming interface (API) that enables the development of code to manage USRP settings and operation.
PC Setup.The PC setup consisted of a Linux computerwith all the required drivers and program dependencies, as well as with Mathworks’ Matlab software installed. Matlab was used to program and automate the data recording process.
Recording Process.The equipment described in previous subsections was used to record data suitable for each SDR codebase. The process to obtain signal data for all 12 codebases was reduced to eight stages by selecting an adequate frequency bandwidth, as some signals share the same central carrier frequency (see Table 2).
For each stage, a total of 100 files with 61 seconds of I/Q GNSS data were recorded over a 24-hour time period. The I/Q samples recorded by the USRP were formatted as 8 bit sine carriers. All the data sets recorded are available together with a description file based on the Institute of Navigation’s metadata standard for GNSS.
TESTING FRAMEWORK
The workflow we followed to test every codebase from the collection is outlined in the following steps:
Record data samples.A set of one hundred files were recorded with 61 seconds of GNSS data.
Debug the SDR with the selected files. A debugging stage preceded every test case to ensure the codebase performed well enough, or else to make the required adjustments.
Run the SDR for one hundred trials. A total of one hundred tests, one per file, were performed for all SDRs.
Log metrics and present results.The results from all SDR stages (acquisition, tracking and data demodulation) were stored for each file. Also, each iteration returned a message that summarized the execution results.
All of the messages returned for every file corresponded to one of the cases summarized as follows:
Codebase issue. Message type returned when the codebase failed because of a coding issue.
No navigation solution. The codebase was not able to deliver a navigation solution either due to a malfunction of the codebase or due to a lack of satellite availability. Navigation solutions are only available when both the tracking channel and the navigation data demodulation stages are successful for more than three satellites.
Navigation solution with accuracy worse than 30 meters. A position solution fix more than 30 meters (in three dimensions) from the known antenna location was considered a non-accurate estimate.
Navigation solution with accuracy under 30 meters.When the 3D positioning error was < 30 meters, the navigation solution for the position was considered accurate.
All codebases passed a debugging stage before being tried with the whole set of available data. This was done to ensure that they performed as expected, and were able to achieve the required performance in terms of the metrics mentioned above in this section. An example of this debugging stage will be explained in further detail below. We take the GPS L2C codebase as an example of how all implementations were assessed in an attempt to improve their initial performance and make them more robust to code errors. See our proceedings paper for further details of our test cases.
GPS L2C Test Case.The problem observed for GPS L2C was that some satellites acquired with a high acquisition metric were failing the tracking stage. The result was that no navigation data was demodulated from them. An in-depth study was required to find out the adjustments needed in the codebase that would help to solve this issue.
The GPS L2C signal encompasses two signal components called civil moderate (CM) and civil long (CL). The CM component is formed by a spreading code that modulates a navigation message. The CL component is a pilot (data-less) signal modulated with a longer spreading code allowing for longer coherent and non-coherent integration times, yielding better sensitivity.
For CM signal acquisition, the 20 millisecond code length limits the coherent integration time to 20 milliseconds, due to the overlaid navigation message. This integration time defines the minimum frequency resolution required to obtain the expected correlation results. The CL component is used in the SDR to accumulate consecutive correlation results non-coherently, contributing to the receiver’s sensitivity by allowing it to operate with higher acquisition metrics in general.
The initial configuration for this SDR codebase is represented in TABLE 3a.
Table 3. Configurations for GPS L2C test case.
With this configuration, a total of 10 satellites were acquired. However, it was observed that for some satellites acquired with high peak metrics, it was not possible to demodulate their navigation data, and thus they were not considered for the navigation solution in later stages. This situation was abnormal, as typically this behavior is more characteristic of weaker signals whose bit transitions are too noisy to be decoded. This problem suggested that either the code-phase or the carrier frequency estimates (or both) were not accurate enough for each tracking channel to generate a proper replica to lock onto the input signal.
The first step taken to address this matter was to inspect the SDR’s acquisition stage for a file presenting the mentioned problems. For instance, taking a closer look at the carrier and code-phase 3D representation for those satellites acquired with a high acquisition metric that were not successfully tracked afterwards. After doing so, some satellites were identified with the irregular characteristics described above, as for example the PRN 10 satellite. PRN 10 is taken as a reference throughout this subsection.
The metric analyzed for PRN 10 was the matrix built by the acquisition’s serial search process. This matrix contains the correlation results obtained for each frequency bin. The width of each frequency bin is determined by the frequency step size defined in the configuration file. In this way, the smaller the frequency step, the more frequency bins that the corresponding matrix contains. This implies a better frequency resolution.
With this in mind, the frequency resolution was progressively increased by decreasing the frequency step size. Extra logic had to be added to the acquisition algorithm to implement this feature. It was found that when using a step size of 6.5 Hz, the tracking stage was then able to lock and demodulate navigation bits from PRN 10 effectively. This was the most significant determining factor to overcome the issue in question for the majority of the satellites available. However, other smaller adjustments also improved tracking results in general. These are depicted in TABLE 3b.
CODE AVAILABILITY
All the resources concerning the SDR collection are publicly available at the portal hosted by University of Colorado Boulder. Through this portal, all the GNSS codebases along with the data sets for testing can be acquired, as well as access to the discussion forum.
CONCLUSION
The first version of the SDR collection was made available after the seminal text by Borre et al. was published and consisted of a GPS L1C/A SDR and multiple data sets. From then on, this project kept evolving by adding more SDRs as new GNSS signals emerged across different satellite constellations.
Our most recent work was to collect all the SDR codebases, arrange them in a common format, and test each implementation to assert their robustness and extract statistics concerning their performance.
Future work will be dedicated to adding more features aiming at refining the PVT estimates delivered by each SDR.
More progress is expected to be made soon, with additional improvements made in the GNSS laboratory. In addition, there is plenty of room for contributions from other researchers who want to support and collaborate with this open-source initiative. Our portal provides a convenient way to manage these contributions.
ACKNOWLEDGMENTS
We thank the many individuals who collaborated in the development of the open-source GNSS SDR collection.
This article is based on the paper “A Collection of SDRs for Global Navigation Satellite Systems (GNSS)” presented at ION ITM 2022, the 2022 International Technical Meeting of the Institute of Navigation, Jan. 25–27, 2022.
JOAN BERNABEU is a Ph.D. student at the Institut Supérieur de l’Aéronautique et de l’Espace, Toulouse, France. He also works as a satellite navigation engineer for GMV, Spain.
NICOLAS GAULT is a Ph.D student at École Nationale d’Aviation Civile, Toulouse, France. He was a visiting scholar in the Department of Aerospace Engineering Sciences at the University of Colorado (CU) Boulder in 2020-2021.
YAFENG LI is an associate professor in the School of Automation at the Beijing Information Science and Technology University, China. He was a visiting researcher with the Department of Aerospace Engineering Sciences, CU Boulder in 2017–18.
DENNIS M. AKOS is a faculty member in the Department of Aerospace Engineering Sciences at CU Boulder.
iP-Solutions has added a GNSS receiver to its software-defined-receiver (SDR) front-end family. The new Eagle-2 works with software receivers in real time or records GNSS signals for post-processing.
For post-processing, Eagle-2 it supports most third-party receivers, such as MATLAB and C/C++ receivers.
The front end allows a user to work with two perfectly synchronized channels connected to two antennas.
The Eagle-2 supports GPS, Galileo, GLONASS , BeiDou, QZSS and SBAS.
Per Vices Corp. has launched an upgraded version of its high-performance software-defined radio (SDR) platform Cyan EC (extended channel).
Cyan EC enables up to 64 digital signal processing (DSP) channels across 16 physical SMA ports. This extension allows Cyan EC users to break up the one large bandwidth physical chain into multiple digital channels, allowing the radio platform to do the multiplexing.
By providing additional digital chains, which are coherently superimposed into a single physical channel, the computational complexity required to address wide bandwidths is further reduced, and allows for processing over multiple cores on a single host system or across multiple host systems concurrently.
“We are excited that customers have already used and integrated our platform into their products,” said Victor Wollesen, CEO of Per Vices Corp “The additional processing capability provided by this option allows our customers to improve performance and implement more advanced applications using existing computational resources. I believe Cyan EC is the highest channel count software-defined radio commercially available.”
The Cyan EC product option enables engineers and system integrators to realize the benefits of both the high-bandwidth SDR and having more independent channels to ease the complexity associated with processing the high amount of data by breaking it up into separate channels. This further helps to achieve better spurious-free dynamic range (SFDR), sensitivity and signal-to-noise ratio (SNR) while continuing to offer a high throughput SDR solution.
Cyan EC benefits engineers and integrators across different markets including GNSS/GPS, radar systems, magnetic resonance imaging (MRI) receivers and exciters, and spectrum monitoring, as well as test and measurement.
A Top Canadian Defense Company
Image: Canadian Defence Review
Per Vices Corp. has been named one of the Top Defence Companies in Canada for 2021 by Canadian Defence Review, a defense and military magazine. A new inclusion to the list for 2021, Per Vices specializes in software-defined radio (SDR) solutions that are integrated into radar, GNSS/GPS, satellite, aerospace and communications systems.
The company is growing and expanding its operations and product line to satisfy the stringent and advanced requirements of its clients and their applications.
“We are incredibly honoured to be added to this list,” said Brandon Malatest, COO, Per Vices Corp. “This shows recognition and support for high performance manufacturers and companies that are bringing innovative solutions to the table, both within Canada and internationally. We offer the best software defined radio solutions commercially available and work closely with our customers to solve challenges for mission critical applications.”
The 100 companies, which must have manufacturing, R&D or service operations in Canada, are evaluated by Canadian Defence Review editorial staff and independent advisors. They are ranked on factors such as economic impact to the country, research and development initiatives, innovation, contribution to the nation’s security, and contract wins. The list is used to showcase Canadian technological innovation and its defence industry.
As technological advances make GPS/GNSS devices more affordable, our lives are becoming increasingly dependent on precise positioning and timing. Industries such as survey, construction and logistics rely on precise positioning for automation, efficiency and safety.
GNSS time provides the pulsating heartbeat for the backbone of our industry by synchronizing telecom networks, banks and the power grid. A single day of GNSS outage is estimated to cost $1 billion U.S. dollars alone.
GNSS is a reliable system, and to keep it as such, professional GNSS receivers need to be wary of all possible vulnerabilities which could be exploited. Using GNSS receivers that are robust against jamming and spoofing is key for secure PNT (positioning, navigation and timing).
What is GPS/GNSS spoofing?
Radio interference can overpower weak GNSS signals, causing satellite signal loss and potentially loss of positioning. Spoofing, is an intelligent form of interference which makes the receiver believe it is at a false location. During a spoofing attack a radio transmitter located nearby sends fake GPS signals into the target receiver. For example, a cheap software-defined radio (SDR) can make a smartphone believe it’s on Mount Everest!
Figure 1. A cheap SDR can overpower GNSS signals and spoofs a single-frequency smartphone GPS into believing it is on Mount Everest. (Image: Septentrio)
Why GPS spoofing?
Imagine a combat situation. Clearly, the side which uses GPS/GNSS technology would have an advantage over the side which does not. But what if one side could manipulate GPS receivers of their adversary? This could mean taking over control of autonomous vehicles and robotic devices which rely on GPS positioning.
For example, in October 2018, Russia accused the U.S. of spoofing a drone and redirecting it to attack a Russian air base in Syria.
Figure 2. GNSS spoofing could be used to manipulate movement of aerial drones. (Image: Septentrio)
In the last three years, more than 600 incidents of spoofing have been recorded in the seas near the Russian border. These ships appeared to be “transported” to nearby airports.
This type of spoofing might have been introduced as a defense mechanism to ground spy drones. Most semi-professional drones on the market have a built-in geo-fencing mechanism that lands them automatically if they come close to airports or other restricted areas.
Some of the most enthusiastic spoofers are Pokémon GO fans who use cheap SDRs to spoof their GPS position and catch elusive Pokémon without having to leave their room.
Types of spoofing
Spoofers overpower relatively weak GNSS signals with radio signals carrying false positioning information. There are two ways of spoofing:
Rebroadcasting GNSS signals recorded at another place or time (so-called meaconing)
Generating and transmitting modified satellite signals
Spoof-proof: How can you protect your receiver against spoofing?
To combat spoofing, GNSS receivers need to detect spoofed signals out of a mix of authentic and spoofed signals. Once a satellite signal is flagged as spoofed, it can be excluded from positioning calculation.
GNSS receivers can offer various levels of spoofing protection. Let’s compare it to a house intrusion-detection system. You can have a simple entry alarm system or a more complex movement detection system. For added security you might install video image recognition, breaking-glass sound detection or a combination of the above.
Like a house with an open door, an unprotected GNSS receiver is vulnerable to even the simplest forms of spoofing. Secured receivers, on the other hand, can detect spoofing by looking for signal anomalies, or by using signals designed to prevent spoofing such as Galileo OS-NMA and E6 or the GPS military code.
Advanced interference mitigation technologies, such as the Septentrio AIM+, use signal-processing algorithms to flag spoofing by detecting various anomalies in the signal. For example, a spoofed signal is usually more powerful than an authentic GNSS signal.
AIM+ won’t even be fooled by an advanced GNSS signal generator: Spirent GSS9000. With realistic power levels and with actual navigation data within the signal, AIM+ can identify it as a “non-authentic” signal.
Other advanced anti-spoofing techniques such as using a dual-polarized antenna are being researched.
Satellite navigation data authentication
Various countries invest in spoofing resilience by building security directly into their GNSS satellites. With OS-NMA (Open Service Navigation Message Authentication), Galileo is the first satellite system to introduce an anti-spoofing service directly on a civil GNSS signal.
OS-NMA is a free service on the Galileo E1 frequency. It enables authentication of the navigation data on Galileo and even GPS satellites. Such navigation data carries information about satellite location and if altered will result in wrong receiver positioning computation. While currently in development, OS-NMA is planned to become publicly available in the near future. Also GPS is experimenting with satellite based anti-spoofing for civil users with their recent Chimera authentication system.
Figure 3. European Galileo satellites provide an open authentication service on the E1 signal and a commercial authentication service on the E6 signal. (Image: European Space Agency)
Recently, within the scope of the FANTASTIC project led by GSA, OS-NMA anti-spoofing protection was implemented on a Septentrio receiver.
The strongest shield: signal-level GNSS authentication
The Galileo system will be offering Commercial Authentication Service (CAS) on the E6 signal with the highest level of security for safety-critical applications such as autonomous vehicles. The signal level encryption will be based on similar techniques as the military GPS signals. Only the receivers who have the secret key are able to track such encrypted signals. The secret key is also needed to generate the signal making it impossible to fake. CAS authentication techniques are currently being prototyped at Septentrio in collaboration with the European Space Agency.
Spoof-resilient GNSS means reliable precise positioning and timing, and a peace of mind for everyone touched by this indispensable technology.
In this month’s column, we review the history and future of software-defined radios (SDRs), looking in particular at GNSS SDRs.
This online version of the print article includes two bonus sections for which there wasn’t room in the magazine: New Frontiers: GNSS SDRs in Space and The Economics of SDRs.
By James T. Curran, Carles Fernández-Prades, Aiden Morrison and Michele Bavaro
Innovation Insights with Richard Langley
I had a fairly normal childhood—as a nerd. I was interested in radio and so was my sister. For her, it was the local AM radio stations where she could hear the latest Beatles’ hits on her six-transistor handheld portable. But for me, it was shortwave radio. I received a Knight-Kit two-tube regenerative shortwave receiver for Christmas 1963 when I was 14. It used one tube for the RF section and one tube for the audio amplifier. Using a random-length antenna above my mother’s clothesline, I was able to log radio stations from more than 100 countries during my high-school days.
With the pressures of university studies and starting to work for a living, I put my radio hobby on hold. But on an Air Canada flight to a conference early in 1985, I spotted an advertisement in the inflight magazine for the diminutive Sony ICF-7600D portable shortwave receiver — the height of miniaturization of microprocessor-controlled receivers at the time — and I acquired one in Hong Kong in May of that year before starting a lecture tour in the People’s Republic of China. I used the Sony receiver extensively at home and on trips overseas and heard many interesting broadcasts over the years including President Gorbachev’s resignation speech live from Radio Moscow.
Fast forward to 2013, when I purchased my first software-defined radio (SDR) receiver, a FUNcube Dongle Pro+, with frequency coverage from longwave up to the L-band. Interfaced via USB to a computer and bespoke software, an SDR receiver allows one to monitor a wide swath of the radio spectrum or record it for future analysis as in-phase and quadrature components. I have since acquired several other SDR receivers, and the capability of these units keeps getting better and better, delighting me and my fellow radio hobbyists. But these improvements in SDR technology extend to other uses of the radio spectrum including GNSS. In this month’s column, we review the history and future of SDRs looking in particular at GNSS SDRs. And what the Beatles said about improving one’s nature as a human being also aptly describes the performance of SDRs: it’s getting better all the time.
The software-defined radio (SDR) has an infinite number of interpretations depending on the context for which it is designed and used. By way of a starting definition, we choose to use that of a reconfigurable radio system whose characteristics are partially or fully defined via software or firmware. In various forms, the SDR has permeated a wide range of user groups, from military and business to academia and the hobby radio community.
SDR technology has evolved steadily over the decades following its birth in the mid-1980s, with various surges of activity being generally aligned with new developments in related technologies (processor power, serial busses, signal processing techniques and SDR chipsets). At present, it appears that we are experiencing one such surge, and the GNSS SDR is expanding in many directions. The proliferation of collaboration and code-sharing sites such as GitHub has enabled communities to share and co-develop receiver technology; the rise in the maker-culture and crowdsourcing has led to the availability of high-performance radio-frequency (RF) front ends; and the adoption of SDRs by some major telecommunications companies has led to the availability of suitable integrated circuits.
These contributing factors have played a part in an increased uptake of GNSS SDRs in military, scientific and commercial applications. In this article, we explore the recent trends and the technology behind them.
SDR TOPOLOGIES
The software-defined radio for GNSS has evolved over the past decade, both in terms of the adoption of new frequencies, new signals and new systems, as they have become available; as well as the adoption of new processing platforms and their associated processing techniques. Shown in FIGURE 1 is a (simplified) depiction of how the topology of the software-defined GNSS receiver has evolved over the years (a–d) with a hint at where it might go next (e, f).
FIGURE 1. A simplified depiction of different SDR topologies (GPP = general-purpose processor, GPU = graphics processing unit, FPGA = field-programmable gate array, SoC = system on chip, RFSoM = radio-frequency system on module, RFSoC = radio-frequency system on chip).
In a traditional GNSS SDR, as depicted in Figure 1 (a), the RF front end typically interfaces with the general-purpose processor (GPP) through a standard bus, and intermediate-frequency (IF) samples are streamed to a buffer. Once on the GPP, basic operations such as correlation, acquisition/tracking, measurement generation and positioning were performed.
Of all of the operations performed by a GNSS receiver, correlation is (by some orders of magnitude) the most computationally intensive. However, the correlation operations are relatively simple, often requiring only integer arithmetic, and can be easily parallelized. When running on modern processors, optimized software receivers can avail themselves of multi-threading (task parallelism) or the operations can be vectorized to exploit data parallelism (single-instruction, multiple data).
Beyond a certain number of GNSS signals and a certain bandwidth, a GPP simply cannot cope, and many SDR receivers looked to hardware acceleration for the correlation process. This either took the form of a graphics processing unit (GPU), or a field-programmable gate array (FPGA), as depicted in Figure 1(b), both of which are well suited to highly parallel tasks. These processing platforms can be powerful and efficient, and so can almost alleviate all challenges associated with correlation. This is not the only way to alleviate the processing burden, as it is also possible to delegate the correlation task to a network of computers. This “cloud” receiver architecture, depicted in Figure 1(e), has received particular attention of late, showing promise for certain niche applications. This computation-in-the-cloud trend has partially reverted with the proliferation of many-core desktop and mobile processors, but at a certain level of signal or processing complexity, the extensions remain applicable.
Nowadays, data throughput becomes an important consideration. When considering multi-constellation, multi-frequency receivers, the objective is often to preserve signal quality, which implies high bandwidth and high digitizer resolution. A triple-frequency front end might easily produce in excess of 100 or even 500 megabytes per second. When this data is delivered to the GPP or somewhere in the host computer, and then offloaded to the GPU (or any other hardware accelerator), it might be handled twice, exacerbating the bottleneck. To overcome this problem (and for other practical architectural reasons) it can be preferable to interface the front end directly with the accelerator, where correlation was performed, and leave the brains of the receiver (including loop closure; data processing; and position, velocity and time computation) on the GPP. This is a particularly convenient approach when using an FPGA accelerator, as shown in Figure 1(d).
A similar architecture can be achieved using modern system-on-chip (SoC) integrated circuits (ICs), which can offer a large FPGA and a powerful GPP on the same piece of silicon, as depicted in Figure 1 (d). Indeed, a number of receivers using this architecture have seen commercial and scientific success, having many of the benefits of dedicated silicon while retaining the benefits of the software-defined radio (for example, the Swift Navigation Piksi Multi GNSS Module). Recent developments in the field have seen the world’s first RF system-on-module (RFSoM) or system-on-chip (RFSoC) devices, targeting 5G mobile communications applications. With an architecture similar to that of Figure 1(f), the IC touts up to eight inputs and eight outputs (8×8) multiple input, multiple output (MIMO) with 12-bit analog-to-digital converters (ADCs) and digital-to-analog converters (DACs) running at rates of 2/4 gigasamples per second. Depending on how this trend evolves (assuming lighter versions become available), this might offer an exciting new platform for GNSS SDRs, simultaneously capable of multi-frequency and multi-antenna operation.
RF HARDWARE: THE ENABLER
GNSS SDRs see the world through a hardware peripheral, and the capability of this hardware defines the perimeter between what the receiver can and cannot do. In essence, the front-end peripheral converts one or more analog RF signals at the antenna to a stream or sequence of packets of digital-baseband/IF data to the GPP.
A software-defined radio for GNSS benefits greatly from being flanked in the RF spectrum on both sides by signals that are of interest to the civilian population. Applications such as Digital Video Broadcasting — Terrestrial (DVB-T) and Digital Video Broadcasting — Satellite Second Generation (DVB-S2) receivers have resulted in the availability of a wide range of low-cost RF ICs that are tunable to GNSS frequencies (typically spanning from 900 MHz to 2.1 GHz), which, along with dedicated GPS ICs, were at the heart of early GNSS SDR front ends. Later developments in ICs designed around the 2/3/4G mobile communications standards brought another generation of ICs, bringing higher instantaneous bandwidth, higher ADC resolution and MIMO, and re-transmit capability. With the increase in popularity of the software-defined radio for cognitive radio, Wi-Fi, 3G and Long-Term Evolution or LTE, and enjoying the benefits of a crowdfunding movement, a wide range of front-end peripherals quickly appeared. Many of these front ends are compatible with GNSS, offering significantly increased performance relative to their predecessors. A selection of some GNSS-compatible SDR peripherals (both new and old) is shown in TABLE 1.
TABLE 1. A selection of GNSS-compatible SDR front ends (Half duplex = transmit and receive but not simultaneously; Full duplex = transmit and receive simultaneously).
Reference Oscillators. Although many of the requirements of modern telecommunications ICs are beyond what is needed for GNSS (such as ADC resolution, frequency range, bandwidth and linearity), clock stability is often inadequate. Communications signals are generally received at high signal-to-noise ratio so the carrier can be easily recovered, even given very poor clock stability.
In contrast, clock stability can be critical for GNSS applications, due to the required comparatively long coherent integration period (greater than 1 millisecond) for a couple of reasons. Firstly, because the search-space granularity is related to the integration period and the size of the search space to the frequency uncertainty, clock accuracy is important, as an uncertainty of some tens of kHz might increase acquisition time. Secondly, the short-term stability is important as a large degree of phase wander can be challenging when attempting to track the carrier phase with a loop-update rate below 1 kHz. In fact, this issue was so pronounced on early RTL-SDR DVB-T front ends, that later revisions upgraded the quartz reference oscillator to a more respectable 0.5 parts per million temperature-compensated crystal oscillator (TCXO). Typically, a TCXO with an accuracy of better than 1 part per million is preferable, but this metric alone is far from sufficient.
Depending on the class of signals for which the SDR front end will be used, the characteristics of the oscillator, the configuration of its support electronics, and even whether the mixers and analog-to-digital conversion process use the same reference can vary. For example, not all TCXOs are suitable for GNSS applications due to the way in which they internally apply their temperature compensations. If a given TCXO uses a stepwise compensation configuration based on any form of digital feedback, the size of the resulting steps can severely impact the GNSS tracking loops. Even if a given TCXO has a suitable compensation curve and implementation, as well as low and acceptable intrinsic phase noise, every other link in the clock chain must preserve this performance. In some front-end implementations, swapping out a low-quality clock for a higher quality one is sufficient, but in others there can be design limitations in the oscillator power supply, the oscillator signal conditioning, subsequent clock generation steps, or distribution routing that can prevent the design from ever being suitable for GNSS use. This can be critical in cases where the carrier phase is of interest, for example, where phase coherence between channels is important for multi-frequency linear combinations, or for multi-antenna systems.
Fortunately, many modern SDR front ends support the use of an external clock. This feature can also be important when attempting to combine two front-end peripherals to effect a dual-frequency or dual-antenna software receiver.
The Bus. An intrinsic bottleneck for any SDR system is the fact that some form of connection or bus is needed to carry data from the collection point to the processing element. In a fully integrated system, this connection still exists, but it is typically a trace on a circuit board or even a pathway within an integrated device. In contrast, in an SDR this often takes the form of a cable or connector between the physically discrete system modules. In cases where the devices are discrete, it is often necessary to implement some data buffering on both ends of the bus.
The suitability of a particular bus is often determined by the sustained data throughput rate required by the application and, in some cases, the latency of the bus. An example of a number of interfaces popular in modern SDR front ends is shown in FIGURE 2, illustrating the nominal throughput and the minimum latency of each. In the case of a GNSS SDR, the minimum conceivable throughput required would be hundreds of megabytes per second, but a system could easily use in excess of 200 megabytes per second for multi-frequency, high-bit-depth data.
Of course, in post-processing applications, bus latency is not a factor. However, certain applications may require that this latency is small, or bounded, or somehow deterministic. Applications such as closed-loop vehicle control or certain safety systems might impose tight requirements on latency. High or unpredictable latency in GNSS measurements might lead to loop instability, in the case of a control system, or might erode safety margins. Although the trend in modern interfaces is for higher throughput, only certain interfaces offer low latency.
FIGURE 2. Bandwidth vs. latency scatter plot for popular buses.
The Silicon. In comparison with less-flexible fixed-function GNSS receiver chips, GNSS SDR hardware platforms provide the opportunity to exchange one to three orders of magnitude of power consumption and system size to gain substantial control over the characteristics of the design. Moreover, one of the other main differences between GNSS front ends and general purpose SDR front ends is the number of bits of ADC resolution and the conversion linearity. Both contribute to power consumption. However, it may be worth considering that GNSS-specific front ends have not received as much attention as telecommunications front ends and, consequently, there is at least a generational gap in silicon mask technology (most GNSS products are at the 350-nanometer level).
In terms of GNSS-specific devices, products such as the SiGe SE4110L, the Maxim MAX2769 and Saphyrion’s SM1027U provide a solution for slightly flexible L1 GPS, Galileo or, in some chip revisions, GLONASS operation. These kinds of chips support a few sampling rates and filtering configurations.
In the middle ground are the much more flexible chips from Maxim including the MAX2120 and MAX2112, which provide total L-band coverage, a myriad of filtering options, and adjustable gain control, all within a 0.3-watt power budget per channel (RF portion only). These chips allow for single-band coverage of adjacent GNSS signals such as GPS and GLONASS L1 or L2 in a single non-aliased RF band.
In terms of multi-channel options, devices such as the Maxim MAX19994A or the NTLab NT1065 offer dual- or quad-channel functionality, respectively. Similar functionality can be achieved by pairing downconversion and IF receiver ICs such as, for example, the Linear Technologies LTC5569 dual-active downconverting mixer and the Analog Devices AD6655 IF receiver, which might offer sufficient performance for high-accuracy dual-frequency positioning.
Higher up the cost, power and complexity structure are radios designed explicitly to support SDR applications that happen to cover GNSS bands such as the Lime LMS6002d/LMS7002M and the Analog Devices AD9364. Notably, these provide receive and transmit channels and frequency coverage up to 6 GHz.
Another interesting and relevant trend is in the use of direct RF sampling ICs, which offer the possibility of full L-band coverage and multi-antenna support. Examples include the Texas Instruments ADS54J40, which offers a dual-channel, 14-bit, 1.0-gigasamples-per-second ADC, or the LM97600 offering a 7.6 bit, quad-channel, 1.25-gigasamples-per-second ADC.
Future Trends, Limitations and Opportunities. Most of the innovation in SDR peripherals has taken place in the telecommunications domain. The GNSS SDR community, being comparatively small, has benefited from these innovations, insofar as they were applicable, but has had little influence over their design.
Looking at the bigger picture, it is clear that GNSS SDRs will simply have to follow the road paved by telecommunications SDRs. We will have to use what is made available, and so future trends in GNSS SDRs will likely be driven by the needs of the telecommunications SDR community.
So what are these trends and will they be aligned with GNSS trends? The answer seems to be yes and no. One of the bigger trends in modern GNSS receivers is the move to dual- or multi-frequency and a second trend is towards multi-antenna receivers for attitude determination or multi-element antennas for interference management. Meanwhile, telecommunications applications are almost universally using MIMO transceivers; however, they don’t seem to be using multiple (simultaneous) carriers.
What is particularly interesting is that the requirements for a MIMO transceiver are well aligned with that of a null-steering GNSS antenna: namely high linearity and high ADC resolution, and phase-coherence between channels (provided by, for example, the Lime Microsystems LMS7002M or the Analog Devices AD9361). As a result, it is possible (or even likely) that in the near future we will see more innovation in GNSS SDRs in the area of multi-antenna processing than in multi-frequency processing.
Signal Processing Techniques for SDRs. As mentioned above, signal correlation for acquisition and tracking is the most computationally intensive operation conducted by a GNSS receiver. In software receivers, many signal acquisition strategies are built around the fast Fourier transform (FFT) algorithm with a signal tracking rake of three or more correlators per signal. When targeting real-time processing, these operations need to be applied to a stream of signal samples arriving at a rate of many megasamples per second. This is a challenge for GPPs when implementing a multi-constellation, multi-frequency GNSS receiver.
The processing task can either be alleviated or accelerated. Assistance data can allow the receiver to reduce the size of the search acquisition space, thereby dramatically reducing the overall computational load. In many cases, the software receiver is running on a host computer with many connectivity options. Alternatively, a variety of options are available for accelerating the tasks.
Parallelization. The main approach for accelerating GNSS signal processing is parallelization. Shared-memory parallel computers can execute different instruction streams (or threads) on different processors, or by interleaving multiple instruction streams on a single processor (simultaneous multithreading or SMT), or both. This approach is referred to as task parallelism, and it is well supported by the main programming languages, compilers and operating systems. This approach fits naturally with the architecture of a GNSS receiver, which has many channels (one per satellite and frequency band) operating in parallel over the same input data. When programmed with the appropriate design, execution can be accelerated almost linearly with the number of processing cores. However, the spreading of processing tasks along different threads must be carefully designed in order to avoid bottlenecks (either in the processing or in memory access).
In combination with task parallelization, software-defined receivers can still resort to another form of parallelization: instructions that can be applied to multiple data elements at the same time, thus exploiting data parallelism. This computer architecture is known as Single Instruction Multiple Data (SIMD), where a single operation is executed in one step on a vector of data, as illustrated in FIGURE 3.
FIGURE 3. Illustration of the operation of single-instruction multiple-data (SIMD) processors, which take a multiple-data input (arguments) and produce multiple results, given a single instruction operated in parallel in a set of processing units (PUs).
In GNSS receivers, this type of instruction can implement operations like multiply-and-accumulate across multiple (16, 32, 64 and so on) samples in a single clock cycle. Intel introduced the first instance of 64-bit SIMD extensions, called MMX, in 1997. Later SIMD extensions, SSE 1 to 4, added multiple 128-bit registers. AMD quickly followed and SIMD is now present in almost all modern processors.
Later, Intel introduced more new instruction sets called Advanced Vector Extensions (AVX) featuring 256-bit registers, new instructions and a new coding scheme. In 2013, AVX-2 expanded most integer commands to 256 bits and by 2016, the introduction of AVX-512 provided 512-bit extensions. SIMD technology is also present in embedded systems: NEON technology is a 128-bit SIMD architecture extension for the ARMv7 Cortex-A series processors, providing 32 registers, 64-bits wide (dual view as 16 registers, 128-bits wide), and AArch64 NEON for ARMv8 processors, which provides 32 128-bit registers. In many cases, well written code will be automatically implemented as some combination of these SIMD intrinsics. In other cases, they can be coded explicitly.
Hardware Acceleration. Another possibility for accelerating signal processing is to offload computation-intensive portions of the workload to a device external to the main GPP executing the software. This is the case of graphics processing units (GPUs). Such processor architecture follows another parallel programming model called Single Instruction, Multiple Threads (SIMT). While in SIMD elements of short vectors are processed in parallel, and in SMT instructions of several threads are run in parallel, SIMT is a hybrid between vector processing and hardware threading. Currently, Open Computing Language or OpenCL is the most popular open GPU computing language that supports devices from several manufacturers, while CUDA (originally, Compute Unified Device Architecture) is the dominant proprietary framework specific for Nvidia GPUs. The key idea is to exploit the computation power of both GPP cores and GPU execution units in tandem for better utilization of available computing power. The main constraint in using GPUs is memory bandwidth. If not programmed carefully, most of the time will be spent on transferring data back and forth between the GPP and the GPU, instead of in the actual processing. A possible solution to this is an approach known as zero-copy operations, which consists of a unified address space for the GPP and the GPU that facilitates the passing of pointers between them, thus reducing the memory bandwidth requirements.
Similar benefits can be had by offloading correlation to reconfigurable hardware such as FPGAs. The correlation duties can be offloaded to an FPGA and the loop-closure and navigation engine can remain in the GPP. The FPGA is particularly well suited to the GNSS correlation tasks and can implement dedicated low-resolution (such as 1-4 bit) multiply-and-accumulate blocks, where the equivalent 8-, 16- or 32-bit operations on a GPP would be excessive or inefficient. Early approaches involved an FPGA connected as a peripheral device via Ethernet, Peripheral Component Interconnect Express (PCIe) or a similar bus. However, similar to the GPU, the data transfer quickly becomes a bottleneck. This challenge is addressed by integrating the GPP-FPGA packages. An early example of this approach was the Intel Atom E6x5C package hosting an Altera FPGA. More recent examples are Xilinx’s Zynq 7000 family integrating ARM and FPGA processors in a single encapsulation. These SoCs allow the direct injection of signal samples from the RF front end into the FPGA, greatly reducing the amount of information to be interchanged with the GPP. This approach provides flexibility with regard to how tracking and correlation resources are allocated, allowing configurable architectures according to the targeted signals of interest and application at hand, and enabling the execution of full-featured software-defined receivers in small form factor devices.
THE CLOUD
The ability to manage resources as logical entities instead of as physical, hardwired units dedicated to a given application has materialized in business models such as Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructures as a Service (IaaS). A network of software-defined GNSS receivers executed in the cloud, appears to be the next natural step in this technology trend, in which the GNSS receiver is no longer a physical device but a virtualized function provided as a service (see FIGURE 4).
FIGURE 4. Illustration of the cloud-based GNSS signal-processing paradigm. (Courtesy of SPCOMNAV, Universitat Autònoma de Barcelona)
A virtualized software application is a program that can be executed regardless of the underlying computer platform. This can be achieved by packaging the application and all its software requirements (the operating system, supporting libraries and programs) in a single, self-contained software entity, which can be then run on any platform. An instance of a software-defined GNSS receiver executed in a virtual environment can then be called a virtualized GNSS receiver.
Early virtualization was in the form of full or machine virtualization (virtual machine or VM), which is a software application that emulates the hardware environment and functionality of a physical computer. With VMs, a software component called a hypervisor interfaces between the VM environment and the underlying hardware (CPU), providing the necessary layer of abstraction. A VM can run a full operating system, so conventional software applications (such as a software-defined GNSS receiver) can run within a VM without any required change.
Recently, the use of operating system virtualization or software containers has become more popular as they are often faster and more lightweight than VMs. Instead of a hypervisor, software containers use a daemon that supplements the host kernel, and can therefore be more efficient in making use of the underlying hardware. Examples of these software containers are Docker and Ubuntu Snaps. An example of an open-source software-defined GNSS receiver packaged as a Docker container is available.
Virtualized GNSS receivers bring important benefits in two fields: business-wise, as a technology enabler for new GNSS-based services; and also the use of GNSS SDRs as scientific tools, to ensure reproducibility.
As a service enabler, virtualized GNSS receivers allow for automatic and elastic creation, execution and destruction of application instances as required, and intelligent spread of the running instances across computing resources, regardless of processor architecture, host operating system or physical location. Several solutions are reported in the technical literature, many based on the GNSS snapshot-receiver, in which a short batch of data is sent to the software for position, velocity and time computation. Notable examples of such an approach are Microsoft’s energy-efficient GPS sensing with cloud offloading and the system running on Amazon Web Services. These approaches allow extremely low power consumption to the user equipment, at the expense of limited accuracy (ranging from 10 to 100 meters of error) and high latency. Commercially, Trimble offers Catalyst, a subscription-based GNSS receiver cloud-based service for which the user is charged according to the provided accuracy level, although the exact details are not yet public.
Virtualization technologies also offer a convenient solution for security-related applications (such as GPS M-code and Galileo PRS), since the encryption module remains on the service provider’s premises, and there is no need for a security module in the receiver equipment. This approach may enable the widespread use of restricted/authorized signals by the civilian population.
Finally, virtualization also offers important benefits for science. The flexibility of SDR receivers makes them an ideal tool for scientific experiments, since an implementation released under an open source license would allow a scientist to share a complete description of the processing from raw signal samples to the final research results.
STANDARDIZATION EFFORTS
GNSS signals are generally introduced to the front end through a standard interface, perhaps an SMA, MCX, or U.FL RF connector, and the digitized signals depart through another standard interface, perhaps USB, PCIe, or RJ45. However for a GNSS SDR, this is where the standardization ends. As discussed above, it is clear that there is a wide range of possibilities when capturing and digitizing a GNSS spectrum. Before processing this stream of digitized samples, details such as sample rate, center frequency, sample resolution and format/packing, and a variety of other parameters must be established. This is particularly important in a variety of scenarios such as when sharing/post-processing archived datasets in scientific applications, when offloading computational burden to a cloud-computer, or when interfacing different data-capture devices with different receivers. Ad-hoc methods of digitized data formats do not encourage interoperability and instead cultivate the potential for technology segmentation.
To address this challenge, The Institute of Navigation has lead an effort to develop a specification for standardized metadata, which would accurately and unambiguously describe the digitized data. Adoption of this metadata standard both by the data collection hardware and the software-defined radio receiver can promote interoperability, and can reduce the potential for error. Similarly, an SDR processor’s utility is extended when it is capable of supporting many file formats from multiple sources seamlessly. For more detail on the initiative, readers are encouraged to visit sdr.ion.org.
NEW FRONTIERS: GNSS SDRS IN SPACE
In space, GNSS receivers need to operate in scenarios that are quite different from those of ground-based receivers: higher (albeit predictable) dynamics conditions, low signal-to-noise-density ratios and poor positioning geometry. It is then an excellent scenario for SDRs, since it requires non-standard features from the receiver.
However, space is a harsh environment for semiconductor devices. Charged particles and gamma rays create ionization, which can alter device parameters. In addition to permanently damaging complementary metal-oxide semiconductor (CMOS) ICs, radiation may cause single-event effects, which are caused by ionizing radiation strikes that discharge the charge in storage elements, such as configuration memory cells, user memory and registers. When those effects happen, the system is usually recoverable with a power reset or a memory rewrite, but they also may destroy the device.
Until recently, radiation-hardened solutions were limited to application-specific integrated circuits or ASICs and one-time-programmable solutions. However, recently there has been an increase in the availability of space-grade FPGAs and memory devices. As examples, we can mention Xilinx’s Virtex-5QV, Microsemi’s RTG4 and Atmel’s ATF80 FPGA processors, and commercial SDR platforms such as GOMspace’s GOMX-3. Those devices allow the implementation of space-qualified GNSS receivers fully defined by software.
SDR receivers offer both reprogrammability (or upgradeability) and self-healing (or auto-remediation) capabilities. Examples could be the possibility to upload algorithms yet-to-be-invented at the receiver’s launch time, or the ability to recover from a single-event effect by remotely rewriting damaged functionalities, reducing the need of onboard redundancy.
THE ECONOMICS OF SDRS
Flexibility has a cost—and more flexibility costs more. This is why an FPGA implementation of a complex system can never compete with the unit cost of a fixed function ASIC. An example of a virtuous overlap might be seen in the Maxim 2120 and 2112 line of DVB-S2 TV receiver ICs, which have been successfully co-opted for GNSS SDR front ends due to their features (configurable mixers, gains, filters, operating power range and so on), which happen to be a good-enough match for the GNSS domain. On initial inspection, this allows for flexibility between the two application spaces and provides an ideal platform for SDRs supporting both TV decoding or GNSS on the same hardware radio module, but soon problems appear. The MAX21xx series are designed for TV applications, and TV applications tend to use 75-ohm input impedances while GNSS has standardized on 50 ohms. Certainly, one could add a software-defined impedance-selector block to the design, but we are now spending real hardware resources to accommodate SDR options. Adding an application that requires reception and transmission such as Wi-Fi, adds an entire signal chain to the design, as well as a large increase in the required dynamic range of the system. Adding an application that exploits MIMO, multiplies the hardware resources needed.
The flexibility of SDR makes it an indispensable research, development, validation and hobbyist tool, but system design is about target selection and trade-offs. To quote one of the most successful engineers of the current era and Eckert-Mauchly Award winner Dr. Robert P. Colwell: “Pick your [technical] targets judiciously. … Pick your vision and then chase it. You can’t pick everything as your vision, that’s a recipe for mediocrity. If you can’t pick your target you’re not going to hit any of them.” For SDR-based systems, this would seem to mean that we should focus on applications where the flexibility afforded offsets the inevitable platform cost push, or where it allows targets of opportunity that require a subset of the capabilities of the platform already being used.
At the same time, our earlier definition of an SDR as “a reconfigurable radio system whose characteristics are partially or fully defined via software or firmware” means that SDRs are already everywhere around us on some level. Cellular phones provide an example of devices that connect a large number of hardware radios to a dizzying array of applications that process, consume, modify and sometimes retransmit the received data, while consumer devices such as wireless routers can often add support for protocol changes or tweaks via firmware. While the economics might prevent radio systems from being universal on all dimensions, there are very few radio devices now sold that don’t expose at least a few parameters via software.
CONCLUSION
It seems that we are at an interesting epoch in the evolution of the software-defined GNSS receiver. The GNSS community has begun to springboard off developments and advances in RF equipment and is enjoying both an increase in functionality and a reduction in cost.
Simultaneously, the software-defined GNSS receiver architecture has morphed in multiple directions, enjoying virtually unlimited processing power of cloud computing, or availing itself of fully integrated RF and host-processor modules. As the use cases and host environments for GNSS receivers continue to diversify and the need for flexibility in the receiver continues to increase, it may be that the software-defined GNSS receiver emerges as a contender for the ASIC receiver for certain specialized use cases. Furthermore, as navigation is increasingly provided by an internet-connected device, the software-defined radio may even carve out its own niche, to become the go-to solution.
ACKNOWLEDGMENTS
The authors thank Sanjeev Gunawardena at the Air Force Institute of Technology and José López-Salcedo of Universitat Autònoma de Barcelona for their discussions and correspondence and for providing valuable insight and suggestions.
JAMES T. CURRAN received a Ph.D. in electrical engineering in 2010 from the Department of Electrical Engineering, University College Cork, Ireland. He is a radio-navigation engineer at the European Space Agency in the Netherlands.
CARLES FERNÁNDEZ-PRADES received an M.Sc. and a Ph.D. in electrical engineering from the Universitat Politecnica de Catalunya, Barcelona, Spain, in 2001 and 2006, respectively. In 2006, he joined Centre Tecnològic Telecomunicacions Catalunya, Barcelona, where he holds a position as senior researcher and serves as head of the Communications Systems Division.
AIDEN MORRISON received his Ph.D. in 2010 from the University of Calgary, where he worked on ionospheric phase scintillation characterization using multi-frequency civil GNSS signals. He works as a research scientist at SINTEF Digital in Trondheim, Norway.
MICHELE BAVARO received his master’s degree in computer science from the University of Pisa, Italy, in 2003. After working for several organizations including his own consulting firm, he was appointed as a technical officer at the Joint Research Centre of the European Commission in Brussels. He now works at Swift Navigation in San Francisco, California.
Digital Satellite Navigation and Geophysics: A Practical Guide with GNSS Signal Simulator and Receiver Laboratory by I.G. Petrovski and T. Tsujii with foreword by R.B. Langley, published by Cambridge University Press, Cambridge, U.K., 2012.
A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, and S.H. Jensen, published by Birkhäuser Engineering, Springer-Verlag GmbH, Heidelberg, 2007.
“Snapshot Positioning for Unaided GPS Software Receivers” by Y. Qian, X. Cui, M. Lu and Z. Feng in Proceedings of ION GNSS 2008, the 21st International Technical Meeting of the Satellite Division of The Institute of Navigation, Savannah, Georgia, September 16–19, 2008, pp. 2343-2350.
• Cloud GNSS Signal Processing
“A Cloud Optical Access Network for Virtualized GNSS Receivers” by C. Fernández-Prades, C. Pomar, J. Arribas, J.M. Fàbrega, J. Vilà-Valls, M. Svaluto Moreolo, R. Casellas, R. Martínez, M. Navarro, F.J. Vílchez, R. Muñoz, R. Vilalta, L. Nadal and A. Mayoral in Proceedings of ION GNSS+ 2017, the 30th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, Sept. 25–29, 2017, pp. 3796–3815.
“Computational Performance of a Cloud GNSS Receiver Using Multi-thread Parallelization” by V. Lucas-Sabola, G. Seco-Granados, J.A. López-Salcedo, J.A. García-Molina, and M. Crisci in Proceedings of Navitec 2016, the 8th Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing, Noordwijk, The Netherlands, Dec. 14–16, 2016, doi: 10.1109/NAVITEC.2016.7849357.
“CO-GPS: Energy Efficient GPS Sensing with Cloud Offloading” by J. Liu, B. Priyantha, T. Hart, Y. Jin, W. Lee, V. Raghunathan, H.S. Ramos and Q. Wang in IEEE Transactions on Mobile Computing, Vol. 15, No. 6, June 2016, pp. 1348–1361, doi: 10.1109/TMC.2015.2446461.
• High-Performance RF Sampling
“A 13b 4GS/s Digitally Assisted Dynamic 3-stage Asynchronous Pipelined-SAR ADC” by B. Vaz, A. Lynam and B. Verbruggen in Proceedings of 2017 ISSCC, the IEEE International Solid-State Circuits Conference, San Francisco, California, Feb. 5–9, 2017, pp. 276-277, doi: 10.1109/ISSCC.2017.7870368.
In recent years there has been a proliferation of software-defined radio (SDR) data-collection systems and processing platforms designed for GNSS receiver applications or those that support GNSS bands. For post-processing, correctly interpreting the GNSS SDR sampled datasets produced or consumed by these systems has historically been a cumbersome and error-prone process.
This is because these systems necessarily produce datasets of various formats, the subtleties of which are often lost in translation when communicating between the producer and consumer of these datasets.
This specification standardizes the metadata associated with GNSS SDR sampled data files and the layout of the binary sample files.
The GNSS SDR Metadata Standard defines parameters and schema to express the contents of SDR sample data files. The standard is designed to promote the interoperability of GNSS SDR data collection systems and processors.
The metadata files are human readable and in XML format. A compliant open source C++ API for reading metadata and binary samples is also officially supported to promote ease of integration into existing SDR systems.
Review the formal standards document and click on Submit a Comment to provide feedback. Comments will be accepted through December 31, 2017.
Stéphan Hamel, CEO and co-founder of Skydel, describes Skydel’s GNSS simulator, which runs on an SDR, at ION GNSS+ 2015. Hamel also touches on the company’s partnership with Averna, a test engineering software, solutions and services company.
By Thomas Pany, Nico Falk, Bernhard Riedl, Tobias Hartmann, Günter Stangl, and Carsten Stöber
Innovation Insights with Richard Langley
WHAT IS THE IDEAL GNSS RECEIVER? Well, that depends on what you mean by “ideal.” If we take it to mean the simplest, conceptually, yet the most capable and adaptable receiver, then we would just connect an analog-to-digital converter (ADC) to an antenna and pass the converter’s output to a digital signal processor whose software would transform the received signal into the desired result with the utmost speed and precision. There are certain technological limitations that currently preclude fully developing such a device but we are getting very close to the ideal and practical implementations already exist.
Such a GNSS receiver is an example of a software-defined radio — a radio-communications architecture in which as much of the operation of a receiver (or a transmitter) as feasible is performed by software in an embedded system or on a personal computer (PC).
Now, we can’t simply connect an ADC to an antenna since the strength of GNSS signals falls well below the sensitivity threshold of real ADCs and those that can directly digitize microwave radio frequencies are rather power hungry. Therefore, the front end of a real software GNSS receiver includes a low-noise preamplifier, filters, and one or more downconverters to produce an analog intermediate-frequency signal that passes to a high-speed ADC. The digitized signal is provided at the output of the front end in a convenient format, which, for processing signals on a PC, is typically USB 2.0 with its maximum signaling rate of 480 megabits per second. All baseband signal processing is then carried out in the programmable microprocessor.
Software GNSS receivers offer a number of advantages over their hardware cousins. Foremost is their flexibility, which permits easy and rapid changes to accommodate new radio frequency bands, signal modulation types and bandwidths, and baseband algorithms. This flexibility is beneficial not only for multi-GNSS operation but also for prototyping algorithms for conventional hardware designs. Another advantage is their use in embedded systems such as smartphones and wireless personal digital assistants. Software GNSS receivers are also a boon for teaching, where a student can tweak a particular operating parameter and immediately see the effect. And given their remarkable flexibility, software GNSS receivers can be adapted to a variety of special scientific and engineering research applications such as reflectometry and signal analysis.
In this month’s “Innovation,” we look into the development and capabilities of one modern software GNSS receiver in an effort to answer the question “What is the ideal GNSS receiver for precise positioning research?”
“Innovation” is a regular feature that discusses advances in GPS technology andits applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick.
Personal-computer-based software receivers have found broad use as R&D tools for testing new signal processing algorithms, for analyzing received GNSS signals, and for integrating various sensors with GNSS. Software receivers also provide a consistent framework for GNSS signal samples, correlator values, pseudoranges, positions, assistance data, and sensor (inertial) data, and often act as integration platforms for prototype navigation systems. The distinctive feature of PC-based software receivers is their ability to work in post-processing mode in addition to real-time operation and the support of high-performance central processing units (CPUs).
So far, software receivers are typically not used as operational receivers — neither in the mass market, nor in the professional sector, nor as a reference station where a PC would already be available. The last point can be explained by the fact that most software receivers can only process a limited number of frequency bands (sometimes just L1) and are often limited to small bandwidth signals (such as that of the L1 C/A-code signal or the L2 civil signal (L2C)). Improvements of the PC-based software receiver SX-NSR achieved at the end of 2010 and in early 2011 try to overcome these limitations. They include the first real-time implementation of P-code processing on L2, a unique method for processing the ultra-wide Galileo AltBOC signals on E5, and a method to synchronize two NavPort-4 frontends (each supporting four frequency bands of 15 MHz bandwidth) via a hardware link.
The SX-NSR, which has been developed in cooperation with the Universität der Bundeswehr München in Munich, Germany, runs under the Windows operating system (XP or 7) and supports processing of GNSS signals plus sensor data (such as that from an inertial measurement unit, or IMU) in real time and in post-processing mode. It supports all the civil GPS, GLONASS, Galileo, and Compass signals. User-defined signals can be included by providing the pseudorandom noise (PRN) codes and the associated tracking parameters.
The computational real-time performance can be characterized by two rules-of-thumb for acquisition and tracking. Acquisition is based on a flexible coherent and noncoherent integration and may be accelerated by a graphics card based on the Compute Unified Device Architecture (CUDA) — a parallel-computing architecture developed by Nvidia for graphics processing but also useful for accelerating non-graphics applications. Depending on the graphics card type, a few million or many millions of equivalent correlators are available to detect even the weakest signals quickly. Stable tracking is done with multiple correlators. An x86 CPU core supports around 20 channels (for a laptop) to 30 channels (for a PC) at an average CPU load below 50–60 percent. With that CPU load, the software has enough reserve (in terms of the size of the sample buffer) to cope with latencies introduced by the non-real-time Windows operating system. In post-processing, a virtually unlimited number of channels or correlators is available.
The SX-NSR software typically connects to the NavPort-4 front end via a single USB 2.0 connector. One front end supports four RF paths with 15-MHz bandwidth in the L-band. One band is sampled at 40.96 MHz with 12-bit precision. Small batches of samples are transferred with 12 bits at regular intervals to the PC for increased spectral analysis possibilities but the continuous transfer is usually done with just 2 bits. Decimation by a factor of two (yielding a sample rate of 20.48 MHz) and/or bit reduction are options to limit the data transfer bandwidth on the USB bus. The NavPort also includes configurable notch and finite-impulse-response (FIR) filters working with 12-bit precision and 40.96-MHz data rate. The SX-NSR further supports standard output formats (such as Receiver Independent Exchange (RINEX) format or that of the Radio Technical Commission for Maritime Services (RTCM)), has a graphical user interface, and a freely user-accessible application programming interface (API) in the C programming language.
A reference station was established with the SX-NSR for the International GNSS Service (IGS) Multi-GNSS Experiment (M-GEX) starting on February 1, 2012, at the Observatory Graz in Austria (marker name GRAB). The data is routinely processed by the European Reference Frame analysis center at Observatory Lustbuehel, Graz, Austria, with Bernese Software 5.0, and shows results with a quality that is virtually no different than that of commercial hardware receivers.
All-in-view tracking of the four GNSS constellations on all frequencies (see TABLE 1) has been achieved with an off-the-shelf $1,000 PC, two synchronized NavPorts, and the SX-NSR software. In particular, the front end receives Compass B1, B2, and B3 signals and currently the software is tracking two of the geostationary Earth orbit (GEO) satellites, a few of the inclined geosynchronous orbit (IGSO) satellites, and the medium Earth orbit (MEO) satellites at Graz on B1 and B2. There are plans to implement tracking of the B3 signal for the M1 satellite and that of satellite-based augmentation system (SBAS) satellites on L5.
Table 1. Frequency bands supported by the dual NavPort-4 receiver.
Typical received carrier-to-noise-density-ratio (C/N0) values recorded at station GRAB are shown in FIGURE 1. Freely accessible GRAB data in RINEX format can be downloaded from several data archive sites (see Further Reading online).
The SX-NSR software receiver provides a GNSS development and research framework with the API opening it up for user-implemented algorithms. The user may implement only small portions of new code (such as a special acquisition technique) and for the rest of the receiver rely on the well-known behavior of the SX-NSR’s framework. A number of applications are possible using the flexibility of a software receiver; some of them are described in this article.
Figure 1. C/N0 values for five typical satellites, one each for GPS, GLONASS, Galileo, Compass, and the European Geostationary Navigation Overlay Service (EGNOS) SBAS as recorded at Observatory Graz.
The Front End
The front-end frequency plan was adjusted to have a clean spectrum free of internal interference. This is of utmost importance as software receivers are often used to detect and mitigate interference especially for the Galileo E5 and E6 frequency bands due to overlapping radio navigation services.
An inter-front-end link enables synchronization of two NavPort-4 devices. It generates a synchronous reference clock for a proper phase relationship. Moreover, a trigger is used to adjust the digital data stream of both devices. One possible application of the inter-front-end link technology is to easily double the number of available GNSS frequencies. Another possible application is the building of a dual-antenna solution. For this purpose, each NavPort-4 device handles the same GNSS frequencies, but from different antennas. Whereas within each NavPort, a quad analog-to-digital converter (ADC) synchronously samples the four received GNSS signals, the synchronicity between two NavPorts is more complex.
For the inter-front-end link, both devices have to use the same 10-MHz clock reference for a synchronous setup. This is reached by using the reference clock output of the master device as reference clock input of the slave device as depicted in FIGURE 2. It is also possible to connect both NavPort-4 devices to a single external clock reference.
Figure 2.
Each device generates its own 40.96-MHz sample rate from this reference. The phase difference of the 40.96-MHz sample rate is measured in the master and slave with a phase detector. The first input of the detector is the local 40.96-MHz clock. The second input is the 40.96-MHz clock from the other NavPort-4 with a different phase alignment due to ambiguities in its generation and cable delay. The phase detector measures the phase difference between both clocks. The low-pass-filtered output of this measurement is digitized with an ADC. If this measurement is within a phase range of ±7 degrees at 40.96 MHz, which corresponds to ±14 centimeters, the coarse synchronization is finished. If the value is not within this range, the synchronization algorithm repeats.
After starting the data processing for both devices simultaneously with an implemented digital trigger, the phase difference between master and slave clock could be measured continuously for later fine-tuning in the SX-NSR to achieve an accuracy of much below 1 degree at 40.96 MHz, which corresponds to ±2 centimeters.
The synchronization algorithm is verified by connecting two L1-capable NavPorts to the same antenna. The phase and code delay can then be determined from receiver single-differences of GPS L1 C/A-code-derived phase and code measurements. Actually, this delay estimation is part of an attitude solution (see below) and an example is shown in FIGURE 3. The code delay here is around 50 centimeters and includes the RF filter delay difference of around 40 centimeters (which can be calibrated and is stable over power cycles) in addition to the synchronization delay (here around 10 centimeters). The phase delay is naturally determined modulo one cycle and shows warm-up effects of 1.4 centimeters during the first few minutes of operation.
Figure 3. Inter-front-end hardware delay variation on a GPS L1 signal.
GNSS Reference Station
Although the GPS modernization process is ongoing and more and more L2C-capable satellites are in orbit, tracking of the encrypted P-code signal on L2 is still a key element for any receiver to be considered as a reference station or geodetic receiver. Dual-frequency observations need to be available for the full GPS constellation. A possible option to retrieve full wavelength carrier-phase observations and code ranges on L2 is cross-correlation tracking of the encrypted P-code signal. The receiver computes the cross-correlation function between the raw L1 and L2 samples over a long coherent interval as shown in FIGURE 4. The encrypted P-code stream, identical on L1 and L2, is represented by c(tµ).
Figure 4. Cross-correlation block diagram.
A receiver internal complex carrier is generated (see frequency compensation in Figure 4), whose frequency equals the Doppler shift frequency plus the intermediate-frequency difference between L1 and L2. This frequency is generally different for each satellite. The L1 signal is delayed to compute the cross-correlation function for several code-phase taps.
The cross-correlation function is computed using the predicted Doppler difference based on the Doppler frequency estimated from L1 with complex-valued baseband samples. A number of batches are collected and a post-correlation fast Fourier transform is applied. The parameter values shown in TABLE 2 result in a total coherent integration time of 6.4 seconds.
The result is the cross-correlation function as a function of code phase and Doppler. Using interpolation techniques, the position of the peak is determined, which then gives the delay and Doppler shift of the L2 signal with respect to the L1 signal. The complex argument of the peak value gives the L2-L1 carrier-phase differences. Those differences are filtered and are then added to the L1 parameters to give the L2P code estimates.
We use two first-order Kalman filters (one for the code, one for the phase) to smooth the cross-correlation estimates. The code filter is updated with the estimated delay and the Doppler; the phase filter is updated with the estimated Doppler and phase. Cycle slips are detected if the L1-L2 phase changes are too high. Loss-of-lock is detected by comparing the estimated L2 C/N0 value against a threshold. After several Kalman filter tuning steps, the L2P signal is tracked down to low elevation angles. For example, the GPS Block IIF satellite PRN1 was tracked over a whole pass without cycle slips as shown in the code-minus-carrier plot in FIGURE 5.
Figure 5. Code minus carrier-phase measurements for GPS PRN1 at site GRAB on day of year 106, 2012.
One of the key applications of a professional GNSS receiver is its use as a GNSS reference station. Using a software receiver for this purpose would also provide increased monitoring capabilities to detect (un)intentional inference via RF spectral analysis or to detect signal anomalies due to satellite failures or multipath. Furthermore, it is useful for a number of scientific experiments and research topics such as scintillation monitoring or atmospheric occultation studies.
Other GNSS Signals
The inclusion of new GNSS signals in a software receiver is typically straightforward. The PRN codes need to be loaded and the tracking parameters (such as carrier frequency, integration time, error correction scheme, phase relation of signal components data/pilot, correlator positions, and discriminator type) can be selected without source code modification. If a hand-over from a different signal is performed (such as from GPS L1 to GPS L5) and if the first signal has already been synchronized to the transmit time by decoding the time-of-week, then it is possible to directly resolve the code ambiguity of the new signal. If this is not possible, a navigation message decoder has to be implemented to retrieve the time-of-week, which mostly has to be in the source code.
Galileo AltBOC. An important exception to this rule is the Galileo AltBOC signal due to its high bandwidth. A conventional view on the AltBOC signal processing would require a sample rate of at least two times the total signal bandwidth. Depending on how many outer AltBOC side lobes are considered, this results in a sampling rate of 102 megasamples per second or more. This is undesirable for a cost-efficient software receiver solution, regarding the data transfer and the CPU load. The AltBOC processing inside the SX-NSR relies on the fact that both frequency bands E5a and E5b are sampled coherently and this coherency can be exploited to reconstruct the full AltBOC signal. The accuracy of the AltBOC navigation signal is concentrated in the main BOC sidelobes itself. More specifically, the thermal noise and multipath performance are dependent on the Gabor bandwidth, which represents the curvature of the correlation function at the tracking point. Thus a similar Gabor bandwidth can be obtained by sampling the E5a and the E5b band separately. This is the key idea of the resulting AltBOC processing scheme.
The E5a and E5b signal samples are generated synchronously inside the same ADC chip and are transferred via the USB bus to the PC running the SX-NSR. The SX-NSR first acquires and tracks the signal separately on E5a and E5b. As it is quite efficient to run the E5a and E5b tracking on separate threads (and on separate CPU cores), the combination of E5a and E5b correlation values to E5 correlation values is done at the post-correlation level.
There is no feedback from the E5 channel to the E5a/b channels. The channel maintains its own numerically controlled oscillator (NCO). A dedicated transformation is used to account for NCO differences between the E5a/b NCO values and the E5 NCO values. It is basically a sinc-interpolation in the code-phase direction and accounts for Doppler and carrier-phase differences. The transformed correlation values are added and yield an approximation to the AltBOC correlation function.
The E5 correlation values are used to compute the discriminator values to update the E5 tracking loops. The E5 NCO values are used to compute the code pseudoranges and carrier-phase measurements, the Doppler frequency, and the C/N0 values, which are the primary outputs of the E5 receiver. Although the E5 receiver is a somehow a virtual receiver (that is, without correlators), it has the same user interface including most of the configuration parameters, output (for example, multi-correlator), and API.
With AltBOC tracking, the Galileo satellites deliver code and phase measurements on five different carrier frequencies. A code-minus-carrier plot is shown in FIGURE 6. The code accuracy of the AltBOC signal is striking. The E6 signal is severely impacted by the present interference, and phase tracking is only possible for higher elevation angles.
Figure 6. Code minus carrier-phase measurements for Galileo PRN12 at site GRAB on day of year 104, 2012.
Polyfit and Vector Tracking
A software receiver should provide a transparent way to retrieve pseudorange measurements that is well understood and can be well modeled. It should also provide a flexible input to control tracking NCO values. Both points are important if the receiver is part of larger navigation system (such as an integrated GNSS/INS system). Conventional delay-lock loop (DLL) / frequency-lock loop (FLL) / phase-lock loop (PLL) configuration is one option and is well understood by all GNSS researchers and engineers. It has, however, two major drawbacks. The loops introduce time correlations that cannot be easily modeled in a positioning Kalman filter, especially if low bandwidths (carrier aiding) are used. Second, the internal parameters of a DLL are difficult to match to a deeply coupled GPS/INS system.
One way to overcome this is a method called polyfit tracking based on a rather old Jet Propulsion Laboratory patent (U.S. Patent No. 4821294). The idea behind this is to decouple pseudorange determination from the NCO counters. This is accomplished by forming the pseudoranges at the integrate-and-dump rate (such as 50 Hz) and to add the discriminator values to them. The resulting pseudorange is then obtained via a polyfit over the measurement interval.
The time correlation of the measurements is solely determined by the discriminator values, and they compensate for the NCO correlations. A nice example is the application of this method to vector tracking. In vector tracking the NCO values are determined via a line-of-sight projection of the last position, velocity, and time (PVT) estimate and this estimate is usually slightly delayed. Furthermore, the line-of-sight projection is not perfect due to inevitable modeling errors (such as atmospheric delay errors). Thus the NCO does not follow the received signal as well as for DLL/FLL/PLL tracking. This is not a problem as the difference is captured in the discriminator values. FIGURE 7 shows the output of the method for a measurement interval of 0.5 second, one GPS C/A-code signal and for a dynamic user. The PVT update happens with a delay of about 100 milliseconds, changing the Doppler frequency. This resulting phase slope discontinuity is nicely compensated by the phase discriminator. The actual measurements are marked as brown stars in Figure 7. The method can also be applied to slave a channel to a master channel. This is useful for reflectometry, for example, where the master channel locks onto a line-of-sight signal and the slave channel tracks the reflected signal from sea surface.
Figure 7. NCO-based phases (green) plus discriminator values (yellow) and polyfit for carrier-phase, code, and Doppler tracking (dynamic user, GPS C/A-code tracking).
With multiple correlators (for example, nine correlators equally spaced from -0.5 to 0.3 chip for GPS C/A-code tracking), the polyfit method can be extended in a natural way to estimate and mitigate multipath. Using the polyfit carrier estimate, the multi-correlator values are coherently combined over the measurement interval and then a correlation function model is fitted to it. An eventually presented data bit is estimated and wiped off. The correlator fit starts with the assumption that only the line-of-sight signal is present. If the chi-squared value is above a certain threshold, the correlator fit is repeated assuming additionally one multipath signal. Up to two multipath signals can be estimated.
The performance of this method can be tested with an RF signal generator. The scenario includes the line-of-sight signal (GPS C/A-code) and one multipath signal. The initial multipath delay is 0 meters and increases slowly (5.7 millimeters per second). The standard tracking method uses a multipath-mitigating double-delta code discriminator formed from four correlators (-0.2, -0.1, 0.1, 0.2) and an arctan carrier discriminator. Standard tracking is used to control the NCO values. FIGURE 8 shows that multipath is detected for delays larger than 15 meters. The detection performance depends on the carrier-phase difference of the line-of-sight and multipath signal, but for delays larger than 32 meters, multipath is always detected. If multipath is detected, the corrected ranges and C/N0 values are significantly improved.
Figure 8. SX-NSR real-time carrier-phase multipath detection and mitigation performance for a GPS C/A-code signal with a -10 dB multipath signal (standard tracking shown in black, multipath-estimating discriminator output shown in red).
The polyfit method is used routinely in the reference station and has also been tested in a dynamic scenario. A bus drive near the IFEN office in Poing, Germany, with the antenna mounted on the roof has been carried out. Even in this rural area, short-term shading and multipath severely distort single channel (DLL/PLL) tracking causing rather large position errors (red dots in FIGURE 9).
Source: Thomas Pany, Nico Falk, Bernhard Riedl, Tobias Hartmann, Günter Stangl, and Carsten Stöber
With a simple switch in the software, the NCO control can be switched from DLL/PLL to vector tracking (polyfit tracking is always on with the same fit parameters). If the standard point positioning (SPP) solution is used to control the NCO values (yellow dots), the errors are already drastically reduced because the NCOs follow the position and not the reflected signals. Also, erratic NCO jitter preceding loss-of-lock events is now eliminated. A further improvement is achieved if the PVT solution is computed by a Kalman filter (green dots), giving finally the typical high-navigation accuracy of modern GNSS receivers even with partial signal blocking.
Dual-Antenna Heading Determination
The bus drive mentioned above has actually been carried out with two antennas on the roof top with the aim of demonstrating the dual-antenna performance of the software receiver to determine heading. Two synchronized NavPorts have been used, both receiving GPS C/A-code signals (more frequencies would even be more beneficial and possible, but such a test has not yet been carried out). The software is fully prepared to handle data streams from two antennas and one option is to use the same NCO for both antennas. That is, the master antenna data is used to realize vector tracking and the discriminators of the slave channels capture the relative movement of the slave antenna to the master antenna. Again, polyfit tracking provides a natural framework to cope with this data.
Attitude is determined with receiver single-difference observations. It is beneficial to form this difference as early as possible in the receiver processing, that is, immediately after correlation. Thus carrier-phase tracking is based on receiver single-difference correlators, being the product of the complex-conjugate master prompt correlator and the slave prompt correlator (both obviously for the same GNSS signal). The heading is shown in FIGURE 10. As reference, a GPS/INS system was used that calibrated the IMU during the first 300 seconds. One sees that the polyfit plus difference correlator is able to track the carrier phase continuously over 400 seconds in the rural test drive, although there is high multipath and some shading even for the high-elevation-angle satellites. Switching off only one option (vector tracking or the difference correlator) introduces cycle slips and corrupts the heading solution.
Figure 10. Heading and heading error for the dual-antenna test.
Conclusions
Currently, we see two main applications for software receivers. First, they may replace hardware receivers if the increased software receiver performance/flexibility justifies the increased power consumption and size. Several features have been shown in this article, and the possibility to do post-processing and the high-power CPU for customized algorithms are striking arguments for software receivers. On the other hand, software receivers may be customized by inserting user-specific code via the API offering enormous possibilities.
Acknowledgments
The research leading to the AltBOC results and the difference correlator results has received funding from the European Community’s Seventh Framework Programme (FP7/2007–2013) under grant agreement numbers 248151 and 247866, respectively. This article is based, in part, on the award-winning paper “Wide-band Signal Processing Features for Reference Station use of a PC-based Software Receiver: Cross-correlation Tracking on GPS L2P, AltBOC and the Inter-frontend Link for up to Eight Frequency Bands” presented at ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, held in Portland, Oregon, September 19–23, 2011.
Manufacturers
The IFEN GmbH NavPort/SX-NSR receiver at station GRAB is fed by a Leica Geosystems AG LEIAR25.R4 antenna with a LEIT radome. The kinematic test used a NovAtel Inc. SPAN GNSS/inertial system.
THOMAS PANY works for IFEN GmbH in Poing, Germany, as a senior research engineer in the GNSS receiver department. He also works as a lecturer (Priv.-Doz.) at the Universität der Bundeswehr München (UniBwM) in Munich, Germany. NICO FALK works for IFEN GmbH in the receiver technology department. BERNHARD RIEDL works for IFEN GmbH as product manager for SX-NSR. TOBIASHARTMANN works for IFEN GmbH in the receiver technology department. GÜNTERSTANGL is an officer of the Austrian Federal Office for Metrology and Surveying and works half time at the Space Research Institute of the Austrian Academy of Sciences. CARSTENSTÖBER is a research associate at UniBwM.
FURTHER READING
• Authors’ Proceedings Paper
“Wide-band Signal Processing Features for Reference Station Use of a PC-based Software Receiver: Cross-correlation Tracking on GPS L2P, AltBOC and the Inter-frontend Link for up to Eight Frequency Bands” by T. Pany, N. Falk, B. Riedl, T. Hartmann, J. Winkel, and G. Stangl in Proceedings of ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 19–23, 2011, pp. 753–766.
• Software GNSS Receiver Algorithms and Implementations
Digital Satellite Navigation and Geophysics: A Practical Guide with GNSS Signal Simulator and Receiver Laboratory by I.G. Petrovski and T. Tsujii with foreword by R.B. Langley, published by Cambridge University Press, Cambridge, U.K., 2012.
Navigation Signal Processing for GNSS Software Receivers by T. Pany, published by Artech House, Norwood, Massachusetts, 2010.
A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach by K. Borre, D.M. Akos, N. Bertelsen, P. Rinder, and S.H. Jensen, published by Birkhäuser, Boston, 2007.
Fundamentals of Global Positioning System Receivers: A Software Approach, 2nd Edition, by J. B.-Y. Tsui, published by John Wiley & Sons, Inc., Hoboken, New Jersey, 2005.
• Galileo Signal Tracking
“Performance Evaluation of Single Antenna Interference Suppression Techniques on Galileo Signals using Real-time GNSS Software Receiver” by A.S. Ayaz, R. Bauernfeind, J. Jang, I. Kraemer, D. Dötterbock, B. Ott, T. Pany, and B. Eissfeller in Proceedings of ION GNSS 2010, the 23rd International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 21–24, 2010, pp. 3330–3338.
“The International GNSS Service in a Changing Landscape of Global Navigation Satellite Systems” by J.M. Dow, R.E. Neilan, and C. Rizos in Journal of Geodesy special issue, “The International GNSS Service (IGS) in a Changing Landscape of Global Navigation Satellite Systems,” Vol. 83, Nos. 3-4, 2009, pp. 191–198, doi: 10.1007/s00190-008-0300-3.
The Institute of Navigation’s 
