Innovation: Software GNSS Receiver

September 1, 2012 - By GPS World Staff

An Answer for Precise Positioning Research

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.

Table 2. SX-NSR cross-correlation parameter values.

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/N₀ 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/N₀ 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/N₀ 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. TOBIAS HARTMANN works for IFEN GmbH in the receiver technology department. GÜNTER STANGL 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. CARSTEN STÖBER is a research associate at UniBwM.