Tag: software receiver

Building a Wide-Band Multi-Constellation Receiver
The Universal Software Radio Peripheral as RF Front-End

By Ningyan Guo, Staffan Backén, and Dennis Akos

The authors designed a full-constellation GNSS receiver, using a cost-effective, readily available, flexible front-end, wide enough to capture the frequency from 1555 MHz to 1607 MHz, more than 50MHz. This spectrum width takes into account BeiDou E2, Galileo E1, GPS L1, and GLONASS G1. In the course of their development, the authors used an external OCXO oscillator as the reference clock and reconfigured the platform, developing their own custom wide-band firmware.

The development of the Galileo and BeiDou constellations will make many more GNSS satellite measurements be available in the near future. Multiple constellations offer wide-area signal coverage and enhanced signal redundancy. Therefore, a wide-band multi-constellation receiver can typically improve GNSS navigation performance in terms of accuracy, continuity, availability, and reliability. Establishing such a wide-band multi-constellation receiver was the motivation for this research.

A typical GNSS receiver consists of three parts: RF front-end, signal demodulation, and generation of navigation information. The RF front-end mainly focuses on amplifying the input RF signals, down-converting them to an intermediate frequency (IF), and filtering out-of-band signals. Traditional hardware-based receivers commonly use application-specific integrated circuit (ASIC) units to fulfill signal demodulation and transfer the range and carrier phase measurements to the navigation generating part, which is generally implemented in software. Conversely, software-based receivers typically implement these two functions through software. In comparison to a hardware-based receiver, a software receiver provides more flexibility and supplies more complex signal processing algorithms. Therefore, software receivers are increasingly popular for research and development.

The frequency coverage range, amplifier performance, filters, and mixer properties of the RF front-end will determine the whole realization of the GNSS receiver. A variety of RF front-end implementations have emerged during the past decade. Real down-conversion multi-stage IF front-end architecture typically amplifies filters and mixes RF signals through several stages in order to get the baseband signals. However, real down-conversion can bring image-folding and rejection. To avoid these drawbacks, complex down-conversion appears to resolve much of these problems. Therefore, a complex down-conversion multi-stage IF front-end has been developed. But it requires a high-cost, high-power supply, and is larger for a multi-stage IF front-end. This shortcoming is overcome by a direct down-conversion architecture. This front-end has lower cost; but there are several disadvantages with direct down-conversion, such as DC offset and I/Q mismatch. DC offset is caused by local oscillation (LO) leakage reflected from the front-end circuit, the antenna, and the receiver external environment.

A comparison of current traditional RF front-ends and different RF front-end implementation types led us to the conclusion that one model of a universal software radio peripheral, the USRP N210, would make an appropriate RF front end option. USRP N210 utilizes a low-IF complex direct down-conversion architecture that has several favorable properties, enabling developers to build a wide range of RF reception systems with relatively low cost and effort. It also offers high-speed signal processing. Most importantly, the source code of USRP firmware is open to all users, enabling researchers to rapidly design and implement powerful, flexible, reconfigurable software radio systems. Therefore, we chose the USRP N210 as our reception device to develop our wide-band multi-constellation GNSS receiver, shown in Figure 1.

Figure 1. Custom wide-band multi-constellation software receiver architecture based on universal software radio peripheral (USRP).

USRP Front-End Architecture

The USRP N210 front-end has wider band-width and radio frequency coverage in contrast with other traditional front-ends as shown by the comparison in Table 1. It has the potential to implement multiple frequencies and multiple-constellation GNSS signal reception. Moreover, it performs higher quantization, and the onboard Ethernet interface offers high-speed data transfer.

Table 1. GNSS front-ends comparison.

USRP N210 is based on the direct low-IF complex down-conversion receiver architecture that is a combination of the traditional analog complex down-conversion implemented on daughter boards and the digital signal conditioning conducted in the motherboard. Some studies have shown that the low-IF complex down-conversion receiver architecture overcomes some of the well-known issues associated with real down-conversion super heterodyne receiver architecture and direct IF down-conversion receiver architecture, such as high cost, image-folding, DC offset, and I/Q mismatch.

The low-IF receiver architecture effectively lessens the DC offset by having an LO frequency after analog complex down-conversion. The first step uses a direct complex down-conversion scheme to transform the input RF signal into a low-IF signal. The filters located after the mixer are centered at the low-IF to filter out the unwanted signals. The second step is to further down-covert the low-IF signal to baseband, or digital complex down-conversion.

Similar to the first stage, a digital half band filter has been developed to filter out-of-band interference. Therefore, direct down-conversion instead of multi-stage IF down-conversion overcomes the cost problem; in the meantime, the signal is down-converted to low-IF instead of base-band frequency as in the direct down-conversion receiver, so the problem of the DC offset is also avoided in the low-IF receiver. These advantages make the USRP N210 platform an attractive option as GNSS receiver front-end.

Figure 2 shows an example GNSS signal-streaming path schematic on a USRP N210 platform with a DBSRX2 daughter board. Figure 3 shows a photograph of internal structure of a USRP N210 platform.

Figure 2 GNSS signal streaming on USRP N210 + DBSRX2 circuit.

Figure 3. USRP N210 internal structure.

The USRP N210 platform includes a main board and a daughterboard. In the main board, 14-bit high precision analog-digital converters (ADCs) and digital-analog converters (DACs) permit wide-band signals covering a high dynamic range. The core of the main board is a high-speed field-programmable gate array (FPGA) that allows high-speed signal processing. The FPGA configuration implements down-conversion of the baseband signals to a zero center frequency, decimates the sampled signals, filtering out-of-band components, and finally transmits them through a packet router to the Ethernet port. The onboard numerically controlled oscillator generates the digital sinusoid used by the digital down-conversion process. A cascaded integrator-comb (CIC) filter serves as decimator to down-sample the signal.

The signals are filtered by a half pass filter for rejecting the out-of-band signals. A Gigabit Ethernet interface effectively enables the delivery of signals out of the USRP N210, up to 25MHz of RF bandwidth. In the daughterboard, first the RF signals are amplified, then the signals are mixed by a local onboard oscillator according to a complex down-conversion scheme. Finally, a band-pass filter is used remove the out-of-band signals.

Several available daughter boards can perform signal conditioning and tuning implementation. It is important to choose an appropriate daughter board, given the requirements for the data collection.

A support driver called Universal Hardware Driver (UHD) for the USRP hardware, under Linux, Windows and Mac OS X, is an open-source driver that contains many convenient assembly tools. To boot and configure the whole system, the on-board microprocessor digital signal processor (DSP) needs firmware, and the FPGA requires images. Firmware and FPGA images are downloaded into the USRP platform based on utilizations provided by the UHD. Regarding the source of firmware and FPGA images, there are two methods to obtain them:
- directly use the binary release firmware and images posted on the web site of the company;
- build (and potentially modify) the provided source code.
USRP Testing and Implementation

Some essential testing based on the original configuration of the USRP N210 platform provided an understanding of its architecture, which was necessary to reconfigure its firmware and to set up the wide-band, multi-constellation GNSS receiver. We collected some real GPS L1 data with the USRP N210 as RF front-end. When we processed these GPS L1 data using a software-defined radio (SDR), we encountered a major issue related to tracking, described in the following section.

Onboard Oscillator Testing. A major problem with the USRP N210 is that its internal temperature-controlled crystal oscillator (TCXO) is not stable in terms of frequency. To evaluate this issue, we recorded some real GPS L1 data and processed the data with our software receiver. As shown in Figure 4, this issue results in the loss of GPS carrier tracking loop at 3.18 seconds, when the carrier loop bandwidth is 25Hz.

Figure 4. GPS carrier loop loss of lock.

Consequently, we adjusted the carrier loop bandwidth up to 100Hz; then GPS carrier tracking is locked at the same timing (3.18s), shown in Figure 5, but there is an almost 200 Hz jump in less than 5 milliseconds.

Figure 5. GPS carrier loop lock tracking.

As noted earlier, the daughter card of the USRP N210 platform utilizes direct IF complex down-conversion to tune GNSS RF signals. The oscillator of the daughter board generates a sinusoid signal that serves as mixer to down-convert input GNSS RF signals to a low IF signal. Figure 6 illustrates the daughter card implementation. The drawback of this architecture is that it may bring in an extra frequency shift by the unstable oscillator. The configuration of the daughter-card oscillator is implemented by an internal TCXO clock, which is on the motherboard. Unfortunately, the internal TCXO clock has coarse resolution in terms of frequency adjustments. This extra frequency offset multiplies the corresponding factor that eventually provides mixer functionality to the daughter card. This approach can directly lead to a large frequency offset to the mixer, which is brought into the IF signals.

Figure 6. Daughter-card tuning implementation.

Finally, when we conduct the tracking operation through the software receiver, this large frequency offset is beyond the lock range of a narrow, typically desirable, GNSS carrier tracking loop, as shown in Figure 4.

In general, a TCXO is preferred when size and power are critical to the application. An oven-controlled crystal oscillator (OCXO) is a more robust product in terms of frequency stability with varying temperature. Therefore, for the USRP N210 onboard oscillator issue, it is favorable to use a high-quality external OCXO as the basic reference clock when using USRP N210 for GNSS applications.

Front-End Daughter-Card Options. A variety of daughter-card options exist to amplify, mix, and filter RF signals. Table 2 lists comparison results of three daughter cards (BURX, DBSRX and DBSRX2) to supply some guidance to researchers when they are faced with choosing the correct daughter-board.

Table 2. Front-end daughter-card options.

The three daughter cards have diverse properties, such as the primary ASIC, frequency coverage range, filter bandwidth and adjustable gain. BURX gives wider radio frequency coverage than DBSRX and DBSRX2. DBSRX2 offers the widest filter bandwidth among the three options.

To better compare the performance of the three daughter cards, we conducted another three experiments. In the first, we directly connected the RF port with a terminator on the USRP N210 platform to evaluate the noise figure on the three daughter cards. From Figure 7, we can draw some conclusions:
- BURX has a better sensitivity than DBSRX and DBSRX2 when the gain is set below 30dB.
- DBSRX2 observes feedback oscillation when the gain set is higher than 70dB.
Figure 7. Noise performance comparisons of three daughter cards.

The second experimental setup configuration used a USRP N210 platform, an external OCXO oscillator to provide stable reference clock, and a GPS simulator to evaluate the C/N₀ performance of the three daughter boards. The input RF signals are identical, as they come from the same configuration of the GPS simulator. Figure 8 illustrates the C/N₀ performance comparison based on this experimental configuration. The figure shows that BURX performs best, with DBSRX2 just slightly behind, while DBSRX has a noise figure penalty of 4dB.

Figure 8. C/N₀ performance comparisons of three daughter cards.

In the third experiment, we added an external amplifier to increase the signal-to-noise ratio (SNR). From Figure 9, we see that the BURX, DBSRX and DBSRX2 have the same C/N₀ performance, effectively validating the above conclusion. Thus, an external amplifier is recommended when using the DBSRX or DBSRX2 daughter boards.

Figure 9. C/N₀ performance comparisons of three daughter cards with an external amplifier.

The purpose of these experiments was to find a suitable daughter board for collecting wide-band multi-constellation GNSS RF signals. The important qualities of an appropriate wide-band multi-constellation GNSS receiver are:
- high sensitivity;
- wide filter bandwidth; and
- wide frequency range.
After a comparison of the three daughter boards, we found that the BURX has a better noise figure than the DBSRX or DBSRX2. The overall performance of the BURX and DBSRX2 are similar however. Using an external amplifier effectively decreases the required gain on all three daughter cards, which correspondingly reduces the effect of the internal thermal noise and enhances the signal noise ratio. As a result, when collecting real wide-band multi-constellation GNSS RF signals, it is preferable to use an external amplifier.

To consider recording GNSS signals across a 50MHz band, DBSRX2 provides the wider filter bandwidth among the three daughter-card options, and thus we selected it as a suitable daughter card.

Custom Wide-band Firmware Development. When initially implementing the wideband multi-constellation GNSS reception devices based on the USRP N210 platform, we found a shortcoming in the default configuration of this architecture, whose maximum bandwidth is 25MHz. It is not wide enough to record 50MHz multi-constellation GNSS signals (BeiDou E2, GPS L1, Galileo E1, and GlonassG1). A 50MHz sampling rate (in some cases as much as 80 MHz) is needed to demodulate the GNSS satellites’ signals.

Meanwhile since the initiation of the research, the USRP manufacturer developed and released a 50MHz firmware. To highlight our efforts, we further modified the USRP N210 default configuration to increase the bandwidth up to 100MHz, which has the potential to synchronously record multi-constellation multi-frequency GNSS signals (Galileo E5a and E5b, GPS L5 and L2) for further investigation of other multi-constellation applications, such as ionospheric dispersion within wideband GNSS signals, or multi-constellation GNSS radio frequency compatibility and interoperability.

Apart from reprogramming the host driver, we focused on reconfiguring the FPGA firmware. With the aid of anatomizing signal flow in the FPGA, we obtained a particular realization method of augmenting its bandwidth. Figure 10 shows the signal flow in the FPGA of the USRP N210 architecture.

Figure 10. Signal flow in the FPGA of the USRP N210 platform.

The ADC produces 14-bit sampled data. After the digital down-conversion implementation in the FPGA, 16-bit complex I/Q sample data are available for the packet transmitting step. According to the induction document of the USRP N210 platform, VITA Radio Transport Protocol functions as an overall framework in the FPGA to provide data transmission and to implement an infrastructure that maintains sample-accurate alignment of signal data. After significant processing in the VITA chain, 36-bit data is finally given to the packet router. The main function of the packet router is to transfer sample data without any data transformation. Finally, through the Gigabit Ethernet port, the host PC receives the complex sample data.

In an effort to widen the bandwidth of the USRP N210 platform, the bit depth needs to be reduced, which cuts 16-bit complex I/Q sample data to a smaller length, such as 8-bit, 4-bit, or even 2-bit, to solve the problem. By analyzing Figure 10, to fulfill the project’s demanding requirements, modification to the data should be performed after ADC sampling, but before the digital down-conversion. We directly extract the 4-bit most significant bits (MSBs) from the ADC sampling data and combined eight 4-bit MSB into a new 16-bit complex I/Q sample, and gave this custom sample data to the packet router, increasing the bandwidth to 100 MHz.

Wide-Band Receiver Performance Analysis. The custom USRP N210-based wide-band multi-constellation GNSS data reception experiment is set up as shown in Figure 11.

Figure 11. Wide-band multi-constellation GNSS data recording system.

A wide-band antenna collected the raw GNSS data, including GPS, GLONASS, Galileo, and BeiDou. An external amplifier was included to decrease the overall noise figure. An OCXO clock was used as the reference clock of the USRP N210 system. After we found the times when Galileo and BeiDou satellites were visible from our location, we first tested the antenna and external amplifier using a commercial receiver, which provided a reference position. Then we used 1582MHz as the reception center frequency and issued the corresponding command on the host computer to start collecting the raw wide-band GNSS signals. By processing the raw wide-band GNSS data through our software receiver, we obtained the acquisition results from all constellations shown in Figure 12; and tracking results displayed in Figure 13.

Figure 12. Acquisition results for all constellations.

Figure 13. Tracking results for all constellations.

We could not do the full-constellation position solution because Galileo was not broadcasting navigation data at the time of the collection and the ICD for BeiDou had not yet been released. Therefore, respectively using GPS and GLONASS tracking results, we provided the position solution and timing information that are illustrated in Figure 14 and in Figure 15.

Figure 14. GPS position solution and timing information.

Figure 15. GLONASS position solution.

Conclusions

By processing raw wide-band multi-constellation GNSS signals through our software receiver, we successfully acquired and tracked satellites from the four constellations. In addition, since we achieved 100MHz bandwidth, we can also simultaneously capture modernized GPS and Galileo signals (L5 and L2; E5a and E5b, 1105–1205 MHz).

In future work, a longer raw wide-band GNSS data set will be recorded and used to determine the user position leveraging all constellations. Also an urban collection test will be done to assess/demonstrate that multiple constellations can effectively improve the reliability and continuity of GNSS navigation.

Acknowledgment

The first author’s visiting stay to conduct her research at University of Colorado is funded by China Scholarship Council, File No. 2010602084.

This article is based on a paper presented at the Institute of Navigation International Technical Conference 2013 in San Diego, California.

Manufacturers

The USRP N210 is manufactured by Ettus Research. The core of the main board is a high-speed Xilinx Spartan 3A DSP FPGA. Ettus Research provides a support driver called Universal Hardware Driver (UHD) for the USRP hardware. A wide-band Trimble antenna was used in the final experiment.

Ningyan Guo is a Ph.D. candidate at Beihang University, China. She is currently a visiting scholar at the University of Colorado at Boulder.

Staffan Backén is a postdoctoral researcher at University of Colorado at Boulder. He received a Ph.D. in in electrical engineering from Luleå University of Technology, Sweden.

Dennis Akos completed a Ph.D. in electrical engineering at Ohio University. He is an associate professor in the Aerospace Engineering Sciences Department at the University of Colorado at Boulder with visiting appointments at Luleå University of Technology and Stanford University
March 1, 2013
Innovation: Software GNSS Receiver

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.

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.

• IFEN Software Receiver Website

• Overviews of Software GNSS Receivers

“Real-Time Software Receivers: Challenges, Status, Perspectives” by M. Baracchi-Frei, G. Waelchli, C. Botteron, and P.-A. Farine in GPS World, Vol. 20, No. 9, September 2009, pp. 40–47.

“GNSS Software Defined Radio: Real Receiver or Just a Tool for Experts?” by J.-H. Won, T. Pany, and G. Hein in Inside GNSS, Vol. 1, No. 5, July–August 2006, pp. 48–56

“Satellite Navigation Evolution: The Software GNSS Receiver” by G. MacCougan, P.L. Normark, and C. Ståhlberg in GPS World, Vol. 16, No. 1, January 2005, pp. 48–55.

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

“Simulating GPS Signals: It Doesn’t Have to Be Expensive” by A. Brown, J. Redd, and M.-A. Hutton in GPS World, Vol. 23, No. 5, May 2012, pp. 44–50.

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.

“GNSS Radio: A System Analysis and Algorithm Development Research Tool for PCs” by J.K. Ray, S.M. Deshpande, R.A. Nayak, and M.E. Cannon in GPS World, Vol. 17, No. 5, May 2006, pp. 51–56.

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.

• Detecting Multipath and Signal Anomalies

“Implementing Real-time Signal Monitoring within a GNSS Software Receiver” by C. Stöber, F. Kneißl, I. Krämer, T. Pany, and G. Hein in Proceedings of ENC-GNSS 2008, Toulouse, April 23–25, 2008.

• International GNSS Service

“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 International GNSS Service: Any Questions?” by A.W. Moore in GPS World, Vol. 18, No. 1, January 2007, pp. 58–64.

IGS Multi-GNSS Experiment (M-GEX) website: http://www.igs.org/mgex.

Software receiver data archive for site GRAB: ftp://olggps.oeaw.ac.at/pub/igsmgex/.

September 1, 2012
Sensing Location: Software Receiver Estimates Signal States During Outages

By Hans-Georg Büsing, Ulrich Haak, and Peter Hecker

Future safety-relevant driver assistant systems demand vehicle state estimations accurate enough to match the position within a road lane, which cannot be provided by standalone GPS. A promising approach to meet the requirements is the fusion of standalone or differential GNSS measurements with vehicle sensor data like odometers or accelerometers. To achieve deeper sensor integration, a software GNSS receiver was developed at the Institute of Flight Guidance (IFF) that is able to use dead reckoning sensors to support its signal acquisition. This article presents an approach to estimate the signal states during outages based on the tightly coupled vehicle state, which reduces the reacquisition time and significantly increases the signal availability.

GNSS-based navigation is a key enabler for future advanced driver assistance systems (ADAS). Car manufacturers have identified automotive assistance systems as core devices to propose their uniqueness mainly in the luxury and upper-class market segments. While the precision and availability of loosely coupled single-frequency GPS navigation satisfies the requirements of typical route guidance systems, future automotive systems — especially those that enhance driving safety — are more demanding on positioning system performance.

The Institute of Flight Guidance (IFF) of the Technische Universität, Braunschweig, Germany, is involved in two research projects evaluating the performance of unaided traditional GNSS receivers coupled with vehicle sensor measurements such as odometers in a tightly coupled architecture. Besides these involvements, the IFF has developed a general-purpose software-based GNSS receiver allowing full access to signal processing routines.

The benefits of the tight sensor fusion are reliable state estimations even during total signal outages that are common in the automotive sector due to tunnels, parking decks, or urban canyons. In this architecture, the GNSS receiver works autonomously to deliver raw GNSS-measurements only. Additional knowledge provided by the vehicle sensors cannot be used to support the receiver in any way. Besides other beneficial aspects in the tracking channels, additional external knowledge about the vehicle state has the potential to reduce acquisition times and improve the measurement availability significantly.

The Institute of Flight Guidance uses a software environment called “Automotive Data and Time-Triggered Framework” (ADTF) for research in the field of ADAS and automotive navigation. In this software framework, the overall system architecture is assembled with independent modules. These modules are implemented as libraries and loaded into ADTF. Data is exchanged via pins that are defined as public variables. The framework also attaches timestamps to the individual measurements and adds a data recording and playback functionality.

From a general-purpose software GNSS receiver, presented at the ION GNSS 2010, we have derived an automotive-specific ADTF software receiver module. The software framework adds the flexibility to synchronously process measurements from vehicle sensors additionally to the IF data from the front end. This gives us the opportunity to aid signal processing in the software GNSS receiver with additional external sensors.

For positioning, a tightly coupled positioning filter based on GPS raw data measurements and the rear-wheel odometers is implemented. The vehicle’s motion is modeled using a kinematic relationship between the vehicle sensors and the GNSS measurements.

Based on the tightly coupled vehicle state estimation, an acquisition state is processed during signal outages that enables the software GNSS receiver to reacquire the satellite signal instantaneously with high precision.

In this article, the constituent parts of the system are presented and the estimation of the acquisition state derived. The system was tested in an urban scenario, and the state estimations validated with the recorded measurements.

System Architecture

The software-defined GNSS receiver developed by the IFF was designed to process the computationally expensive signal correlation on an Nvidia graphics board using the vast parallel processing capability of graphics processing units (GPUs). With the use of common graphics boards, an entire receiver can be implemented on an ordinary PC, needing only a front-end to receive digital GNSS signals in an intermediate frequency (IF) band.

For research in the field of vehicle state estimation, a derivate of the software receiver of the Institute of Flight Guidance has been implemented in the “Automotive Data and Time-Triggered Framework” (ADTF). The software is commonly used in the automotive industry for the development of ADAS. Figure 1 shows a typical system layout in ADTF. A central component of the framework is the ability to record and play back measurement data, which is indicated by the buttons on the left of the screenshot.

Figure 1. System Architecture in ADTF. (Click to enlarge.)

Within ADTF, the systems are assembled from modules that are shown as blocks within the graphical configuration editor. Standard modules such as the connection of common hardware are provided with the framework. Custom modules can be implemented in C++ by the user. Every module is implemented as a dynamic library (DLL) and interpreted by the framework. Modules can be featured with input and output pins.

These pins are implemented by using specific data types from the framework. The communication and data exchange between the modules is handled via these pins. They can be connected by graphically drawing connector lines in the configuration editor.

ADTF provides the user with classes for timing and threading. Processes can thereby be linked to the ADTF system time, which is especially important as the data replay can be slowed down or sped up for debugging.

The instantaneous reacquisition algorithm is based on a traditional approach of tightly coupling GNSS raw data with vehicle sensor measurements. The fusion is based on a kinematic model following the Ackermann geometry establishing the relationship between the vehicle’s motion and the respective measurements.

At each time step of an arriving measurement, the vehicle’s motion is predicted based on the last estimated state with an extended Kalman filter. The prediction is then corrected using either measurements from the vehicle sensors or GNSS raw measurements. The range and Doppler measurements are calculated in the tracking channels of the ADTF software GNSS receiver. The corrected vehicle state is then fed back into the kinematic model for the next update cycle.

In case the GNSS signal is lost in a tracking channel, a virtual tracking channel is initialized with the last calculated channel states. The change in the channel output is then predicted utilizing the change in the vehicle state and the current evaluation of the ephemeris. The schematic implementation of the channel state prediction is shown in Figure 2.

Figure 2. Schematic of Channel State Prediction. (Click to enlarge.)

Signal State Estimation

Using the tightly coupled architecture presented above, an estimated position and velocity can even be provided during total signal outages. Assuming that the last valid observation of a satellite signal is stored together with its respective time t_o and position, an estimation of the signal state (that is, Doppler frequency, code- and carrier-phase) based on the estimation of the vehicle state during the signal outage at time t₁ can be used for an instantaneous signal reacquisition. Using the ephemeris data provided by the respective GPS satellite the range between a user position x_u and the satellite x_sv can be calculated using the following terms
    (1)
and
(2)
with |…| indicating the Euclidian distance.

Therefore the change of the range can be obtained with equations (1) and (2):
(3)
Assuming an unbiased Gaussian error distribution of the measurements, the tightly coupled system provides an estimation of the covariance matrix of the vehicle state. Using only the submatrix
(4)
related to the vehicle position, the covariance of the user position along the line-of-sight to the satellite can be obtained with the Euclidean norm of the line-of-sight vector
(5)
and the law of error propagation:
(6)

Furthermore, using the law of error propagation, it can be shown that the variance of the change of range estimation in equation (3) is obtained by:
   (7)

With the last valid range measurement related to time t_o, the signal state at time t₁ can be obtained for the pseudo-range PSR
   (8)
and the carrier phase Φ:
    (9)

The resulting variance of these estimations can by expressed by
   (10)
and
   (11)
respectively. The estimate of the Doppler and the related variance can be obtained analogous.
Considering the variances of the estimation, it can be decided if the signal can be reacquired instantaneously or if the receiver has to find the signal using standard acquisition routines in a limited search space.

Experimental Validation

The Volkswagen Passat station wagon operated by the Institute of Flight Guidance was used to evaluate the performance of the proposed algorithm (see PHOTO.) The test vehicle is customized from the standard by adding an additional generator to meet the power requirements of the measurement and processing hardware. In addition, the Controller Area Network (CAN) is mirrored and open to access the data collected by the sensors of the vehicle. The relevant sensors include a longitudinal accelerometer, a gyro for measuring the yaw rate as well as the odometers of all four wheels. The test vehicle is equipped with a GNSS front-end developed by the Fraunhofer Institute for Integrated Circuits. It is capable of streaming L1, L2, and L5 RF samples via two USB ports. The sampling rate of L1 is 40.96 MHz at an intermediate frequency of 12.82 MHz.

Test Vehicle. A customized Volkswagen Passat was used to evaluate performance of the algorithm.

The vehicle sensor data is streamed via CAN to an automotive PC from Spectra. It is equipped with an Intel quadcore CPU, 8 GB RAM, a Vector PCI CAN device and 256 GB SATA solid state disk allowing up to 195 MB/s writing speed. Additionally, it has been equipped with an Nvidia GeForce GT 440 graphics board that is used for processing the GNSS RF data. This specific graphics board was chosen because it offers a comparably high performance of the GPU at relatively low power consumption.

Both GNSS RF data and data from the vehicle sensor network are streamed to an ADTF hard disk recorder. Due to the setup of the data acquisition, several challenges have to be solved. The first challenge is that the front-end needs to be used as hardware-in-the-loop. It is by itself not equipped with an automated gain control. Therefore, it is not possible to just stream the RF data but it has to be decoded, processed for adjusting the gain, and then stored to the hard drive.

Secondly, the recording setup needs to cover high data rates. The GNSS front-end streams approximately 20 MB/s. As the data needs to be decoded and processed for gain control, the expanded data rate for recording is ~40 MB/s. In total including vehicle sensor measurements, >2000 data packets per second are streamed to the recorder. Because this could not be done using mechanical hard drives, we used solid state disks that also allow data storage during times of high vibration.

Related to the before-mentioned challenges, an efficient thread management needed to be implemented. The software framework’s threading classes are utilized to parallelize the receiver processes. Additionally, it has arisen that a significant part of the processing time is taken by the data transfer to the memory of the GPU.

In order to prove the advantages of an odometer-aided reacquisition, an applicable testing scenario was chosen. To distinguish an odometer-based aquisition approach from a model-based approach, a trajectory was chosen that features a right turn of 90 degrees immediately after cutting off the GNSS signal. A model-based kinematic prediction would project the trajectory in the direction of the latest known heading derived by the GNSS solution. Only a sensor-based state estimation is able to resolve the right turn. The driven trajectory is shown in Figure 3.

The GNSS signal has been cut off for approximately 10 seconds, which is equivalent of a 75-meter drive on dead reckoning sensors only after the right turn.

Figure 3. Trajectory of test drive includes a 90-degree turn. (Click to enlarge.)

Results

The following plots in Figure 4 show the performance of the virtual tracking channels. The plots in the upper row show the pseudorange output over time. For vividness they have been corrected for the motion of the respective satellite that is dominant due to their high speeds. Over a short period of time the satellites’ motion relative to the receiver can be linearly approximated. The pseudorange measurements over time were fit using a linear regression. The respective value of the linear regression was then subtracted from the pseudorange and plot over time as shown in the figures in the second row, leaving only the approximated influence of the vehicle’s motion.

Figure 4. Modified pseudorange and Doppler results of the virtual tracking channels. (Click to enlarge.)

The Doppler measurements have been similarly compensated by just subtracting the minimum measurement. These modifications of the pseudorange and Doppler measurements allow a direct comparison of each other as the Doppler can be understood as the first derivate of the pseudorange over time.

The results of PRN 6 show that the Doppler estimate during the GPS outage smoothly fits into the surrounding measurements without any major outliers. The plot of the pseudorange shows a similar behavior. The pseudorange could have potentially been modeled using a dynamic prediction that is not based on vehicle sensors due to the limited dynamics on the pseudorange measurements.

The Doppler plot of PRN 16 shows a strong change in the relative velocity between satellite and receiver. If a further projection of the Doppler using a linear dynamic model would have been used instead of predicting with vehicle sensors, it would likely have misled the reacquisition by ~ 50 Hz. The trend in the pseudorange measurements is comparable to PRN 6 at a higher rate of change.

The plots of PRN 21 probably show the advantages of using vehicle sensors for reacquisition best as the dynamics on pseudorange and Doppler are the most significant in the group. Both pseudorange and Doppler show a turning point during the GNSS outage. Especially, the pseudorange would have been mismodeled using a kinematic predicion that is not relying on additional sensors.

Conclusion

In this article, a tightly coupled positioning system implemented in the automotive-specific framework ADTF was presented that is based on the fusion of standard automotive sensor data and software receiver measurements. We showed that, using the tightly coupled solution, an acquisition state during signal outages can be estimated that allows the tracking channels to reacquire the signal instantaneously without the need of computationally expensive acquisition routines.

Under the assumption of a tightly coupled RTK position and small outage times, a reacquisition of the carrier phase without loosing the information about the phase ambiguity seems possible.

In the next version of the automotive GNSS receiver, the authors are planning to integrate the vehicle sensors to aid the tracking loops, which is likely to further improve tracking continuity especially in scenarios with high vegetation. Additionally, we plan to show that the implementation is capable of working in real time. Improvements of the initialization of the virtual tracking loops are also intended.

Acknowledgments

This article is based on a paper presented at ION-GNSS 2011, held September 19–23 in Portland, Oregon.

This work was funded by the Federal State of Lower Saxony, Germany. Project: Galileo – Laboratory for the research airport Braunschweig.
The authors would like to thank their colleagues working in the automotive navigation group for continuous support with the ADTF framework.

Hans-Georg Büsing holds a Dipl.-Ing. in aerospace engineering from the Technische Universität Braunschweig and has been a research engineer at IFF since 2008. He works in the area of applied satellite navigation, especially in the field of vehicle positioning.

Ulrich Haak holds a Dipl.-Ing. in mechanical engineering from the Technische Universität Braunschweig and joined IFF in 2008 as a research engineer. He works in the areas of receiver design and positioning algorithms.

Peter Hecker joined IFF in 1989 as research scientist. Initial focus of his scientific work was in the field of automated situation assessment for flight guidance. From 2000 until 2005, he was head of the DLR Pilot Assistance department. Since April 2005, he has been director of IFF. He is managing research activities in the areas of air/ground cooperative air traffic management, airborne measurement technologies and services, satellite navigation, human factors in aviation, and safety in air transport systems.

March 1, 2012
Testing Software Receivers
To meet the challenges inherent in producing a low-cost, highly CPU-efficient software receiver, the multiple offset post-processing method leverages the unique features of software GNSS to greatly improve the coverage and statistical validity of receiver testing compared to traditional, hardware-based testing setups, in some cases by an order of magnitude or more.

By Alexander Mitelman, Jakob Almqvist, Robin Håkanson, David Karlsson, Fredrik Lindström, Thomas Renström, Christian Ståhlberg, and James Tidd, Cambridge Silicon Radio

Real-world GNSS receiver testing forms a crucial step in the product development cycle. Unfortunately, traditional testing methods are time-consuming and labor-intensive, particularly when it is necessary to evaluate both nominal performance and the likelihood of unexpected deviations with a high level of confidence. This article describes a simple, efficient method that exploits the unique features of software GNSS receivers to achieve both goals. The approach improves the scope and statistical validity of test coverage by an order of magnitude or more compared with conventional methods.

While approaches vary, one common aspect of all discussions of GNSS receiver testing is that any proposed testing methodology should be statistically significant. Whether in the laboratory or the real world, meeting this goal requires a large number of independent test results. For traditional hardware GNSS receivers, this implies either a long series of sequential trials, or the testing of a large number of nominally identical devices in parallel. Unfortunately, both options present significant drawbacks.

Owing to their architecture, software GNSS receivers offer a unique solution to this problem. In contrast with a typical hardware receiver application-specific integrated circuit (ASIC), a modern software receiver typically performs most or all baseband signal processing and navigation calculations on a general-purpose processor. As a result, the digitization step typically occurs quite early in the RF chain, generally as close as possible to the signal input and first-stage gain element. The received signal at that point in the chain consists of raw intermediate frequency (IF) samples, which typically encapsulate the characteristics of the signal environment (multipath, fading, and so on), receiving antenna, analog RF stage (downconversion, filtering, and so on), and sampling, but are otherwise unprocessed. In addition to ordinary real-time operation, many software receivers are also capable of saving the digital data stream to disk for subsequent post-processing. Here we consider the potential applications of that post-processing to receiver testing.

FIGURE1. Conventional test drive (two receivers)

Conventional Testing Methods

Traditionally, the simplest way to test the real-world performance of a GNSS receiver is to put it in a vehicle or a portable pack; drive or walk around an area of interest (typically a challenging environment such as an “urban canyon”); record position data; plot the trajectory on a map; and evaluate it visually. An example of this is shown in Figure 1 for two receivers, in this case driven through the difficult radio environment of downtown San Francisco.

While appealing in its simplicity and direct visual representation of the test drive, this approach does not allow for any quantitative assessment of receiver performance; judging which receiver is “better” is inherently subjective here. Different receivers often have different strong and weak points in their tracking and navigation algorithms, so it can be difficult to assess overall performance, especially over the course of a long trial. Also, an accurate evaluation of a trial generally requires some first-hand knowledge of the test area; unless local maps are available in sufficiently high resolution, it may be difficult to tell, for example, how accurate a trajectory along a wooded area might be.

In Figure 2, it appears clear enough that the test vehicle passed down a narrow lane between two sets of buildings during this trial, but it can be difficult to tell how accurate this result actually is. As will be demonstrated below, making sense of a situation like this is essentially beyond the scope of the simple “visual plotting” test method.

FIGURE 2. Test result requiring local knowledge to interpret
correctly.

To address these shortcomings, the simple test method can be refined through the introduction of a GNSS/INS truth reference system. This instrument combines the absolute position obtainable from GNSS with accurate relative measurements from a suite of inertial sensors (accelerometers, gyroscopes, and occasionally magnetometers) when GNSS signals are degraded or unavailable. The reference system is carried or driven along with the devices under test (DUTs), and produces a truth trajectory against which the performance of the DUTs is compared.

This refined approach is a significant improvement over the first method in two ways: it provides a set of absolute reference positions against which the output of the DUTs can be compared, and it enables a quantitative measurement of position accuracy. Examples of these two improvements are shown in Figure 3 and Figure 4.

FIGURE 3. Improved test with GPS/INS truth reference: yellow
dots denote receiver under test; green dots show the reference
trajectory of GPS/INS.

FIGURE 4. Time-aligned 2D error.

As shown in Figure 4, interpolating the truth trajectory and using the resulting time-aligned points to calculate instantaneous position errors yields a collection of scalar measurements en. From these values, it is straightforward to compute basic statistics like mean, 95th percentile, and maximum errors over the course of the trial. An example of this is shown in Figure 5, with the data (horizontal 2D error in this case) presented in several different ways. Note that the time interpolation step is not necessarily negligible: not all devices align their outputs to whole second boundaries of GPS time, so assuming a typical 1 Hz update rate, the timing skew between a DUT and the truth reference can be as large as 0.5 seconds. At typical motorway speeds, say 100 km/hr, this results in a 13.9 meter error between two points that ostensibly represent the same position. On the other hand, high-end GPS/INS systems can produce outputs at 100 Hz or higher, in which case this effect may be safely neglected.

FIGURE 5. Quantifying error using a truth reference

Despite their utility, both methods described above suffer from two fundamental limitations: results are inherently obtainable only in real time, and the scope of test coverage is limited to the number of receivers that can be fixed on the test rig simultaneously. Thus a test car outfitted with five receivers (a reasonable number, practically speaking) would be able to generate at most five quasi-independent results per outing.

Software Approach

The architecture of a software GNSS receiver is ideally suited to overcoming the limitations described above, as follows.

The raw IF data stream from the analog-to-digital converter is recorded to a file during the initial data collection. This file captures the essential characteristics of the RF chain (antenna pattern, downconverter, filters, and so on), as well as the signal environment in which the recording was made (fading, multipath, and so on). The IF file is then reprocessed offline multiple times in the lab, applying the results of careful profiling of various hardware platforms (for example, Pentium-class PC, ARM9-based embedded device, and so on) to properly model the constraints of the desired target platform. Each processing pass produces a position trajectory nominally identical to what the DUT would have gathered when running live. The complete multiple offset post-processi
ng (MOPP) setup is illustrated in Figure 6.

FIGURE 6. Multiple Offset Post-Processing (MOPP).

The fundamental improvement relative to a conventional testing approach lies in the multiple reprocessing runs. For each one, the raw data is processed starting from a small, progressively increasing time offset relative to the start of the IF file. A typical case would be 256 runs, with the offsets uniformly distributed between 0 and 100 milliseconds — but the number of runs is limited only by the available computing resources, and the granularity of the offsets is limited only by the sampling rate used for the original recording. The resulting set of trajectories is essentially the physical equivalent of having taken a large number of identical receivers (256 in this example), connecting them via a large signal splitter to a single common antenna, starting them all at approximately the same time (but not with perfect synchronization), and traversing the test route.

This approach produces several tangible benefits.
- The large number of runs dramatically increases the statistical significance of the quantitative results (mean accuracy, 95th percentile error, worst-case error, and so on) produced by the test.
- The process significantly increases the likelihood of identifying uncommon (but non-negligible) corner cases that could only be reliably found by far more testing using ordinary methods.
- The approach is deterministic and completely repeatable, which is simply a consequence of the nature of software post-processing. Thus if a tuning improvement is made to the navigation filter in response to a particular observed artifact, for example, the effects of that change can be verified directly.
- The proposed approach allows the evaluation of error models (for example, process noise parameters in a Kalman filter), so estimated measurement error can be compared against actual error when an accurate truth reference trajectory (such as that produced by the aforementioned GPS/INS) is available. Of course, this could be done with conventional testing as well, but the replay allows the same environment to be evaluated multiple times, so filter tuning is based on a large population of data rather than a single-shot test drive.
- Start modes and assistance information may be controlled independently from the raw recorded data. So, for example, push-to-fix or A-GNSS performance can be tested with the same granularity as continuous navigation performance.
From an implementation standpoint, the proposed approach is attractive because it requires limited infrastructure and lends itself naturally to automated implementation. Setting up handful of generic PCs is far simpler and less expensive than configuring several hundred identical receivers (indeed, space requirements and RF signal splitting considerations alone make it impractical to set up a test rig with anywhere near the number of receivers mentioned above). As a result, the software replay setup effectively increases the testing coverage by several orders of magnitude in practice. Also, since post-processing can be done significantly faster than real time on modern hardware, these benefits can be obtained in a very time-efficient manner.

As with any testing method, the software approach has a few drawbacks in addition to the benefits described above. These issues must be addressed to ensure that results based on post-processing are valid and meaningful.

Error and Independence

The MOPP approach raises at least two obvious questions that merit further discussion.
- How accurately does file replay match live operation?
- Are runs from successive offsets truly independent?
The first question is answered quantitatively, as follows. A general-purpose software receiver (running on an x86-class netbook computer) was driven around a moderately challenging urban environment and used to gather live position data (NMEA) and raw digital data (IF samples) simultaneously. The IF file was post-processed with zero offset using the same receiver executable, incorporating the appropriate system profiling to accurately model the constraints of real-time processing as described above, to yield a second NMEA trajectory. Finally, the two NMEA files were compared using the methods shown in Figure 4 and Figure 5, this time substituting the post-processed trajectory for the GPS/INS reference data. A plot of the resulting horizontal error is shown in Figure 7.

FIGURE 7. Quantifying error introduced by post-processing.

The mean horizontal error introduced by the post-processing approach relative to the live trajectory is on the order of 2.5 meters. This value represents the best accuracy achievable by file replay process for this environment.

More challenging environments will likely have larger minimum error bounds, but that aspect has not yet been investigated fully; it will be considered in future work. Also, a single favorable comparison of live recording against a single replay, as shown above, does not prove that the replay procedure will always recreate a live test drive with complete accuracy. Nevertheless, this result increases the confidence that a replayed trajectory is a reasonable representation of a test drive, and that the errors in the procedure are in line with the differences that can be expected between two identical receivers being tested at the same time.

To address the question of run-to-run independence, consider two trajectories generated by post-processing a single IF file with offsets jB and kB, where B is some minimum increment size (one sample, one buffer, and so on), and define F_JK to be some quantitative measurement of interest, for example mean or 95th percentile horizontal error. The deterministic nature of the file replay process guarantees F_JK = 0 for j = k. Where j and k differ by a sufficient amount to generate independent trajectories, F_JK will not be constant, but should be centered about some non-negative underlying value that represents the typical level of error (disagreement) between nominally identical receivers. As mentioned earlier, this is the approximate equivalent of connecting two matched receivers to a common antenna, starting them at approximately the same time, and driving them along the test trajectory.

Given these definitions, independence is indicated by an abrupt transition in F_JK between identical runs ( j = k) and immediately adjacent runs (|j – k| = 1) for a given offset spacing B. Conversely, a gradual transition indicates temporal correlation, and could be used to determine the minimum offset size required to ensure run-to-run independence if necessary. As shown in Figure 8, the MOPP parameters used in this study (256 offsets, uniformly spaced on [0, 100 msec] for each IF file) result in independent outputs, as desired.

FIGURE 8. Verifying independence of adjacent offsets (upper: full view; lower: zoomed top view)

One subtlety pertaining to the independence analysis deserves mention here in the context of the MOPP method. Intuitively, it might appear that the offset size B should have a lower usable bound, below which temporal correlation begins to appear between adjacent post-processing runs. Although a detailed explanation is outside the scope of this paper, it can be shown that certain architectural choices in the design of a receiver’s baseband can lead to somewhat counterintuitive results in this regard.

As a simple example, consider a receiver that does not forcibly align its channel measurements to whole-second boundaries of system time. Such a device will produce its measurements at slightly different times with respect to the various timing markers in the incoming signal (epoch, subframe, and frame boundaries) for each different post-processing offset. As a result, the position solution at a given time point will differ slightly between adjacent post-processing runs until the offset size becomes smaller than the receiver’s granularity limit (one packet, one sample, and so on), at which point the outputs from successive offsets will become identical. Conversely, altering the starting point by even a single offset will result in a run sufficiently different from its predecessor to warrant its inclusion in a statistical population.

Application-to-Receiver Optimization

Once the independence and lower bound on observable error have been established for a particular set of post-processing parameters, the MOPP method becomes a powerful tool for finding unexpected corner cases in the receiver implementation under test. An example of this is shown in Figure 9, using the 95th percentile horizontal error as the statistical quantity of interest.

FIGURE 9. Identifying a rare corner case (upper: full view; lower: top view)

For this IF file, the “baseline” level for the 95th percentile horizontal error is approximately 6.7 meters. The trajectory generated by offset 192, however, exhibits a 95th percentile horizontal error with respect to all other trajectories of approximately 12.9 meters, or nearly twice as large as the rest of the data set. Clearly, this is a significant, but evidently rare, corner case — one that would have required a substantial amount of drive testing (and a bit of luck) to discover by conventional methods.

When an artifact of the type shown above is identified, the deterministic nature of software post-processing makes it straightforward to identify the particular conditions in the input signal that trigger the anomalous behavior. The receiver’s diagnostic outputs can be observed at the exact instant when the navigation solution begins to diverge from the truth trajectory, and any affected algorithms can be tuned or corrected as appropriate. The potential benefits of this process are demonstrated in Figure 10.

FIGURE 10. Before (top) and after (bottom) MOPP-guided tuning (blue = 256 trajectories; green = truth)

Limitations

While the foregoing results demonstrate the utility of the MOPP approach, this method naturally has several limitations as well. First, the IF replay process is not perfect, so a small amount of error is introduced with respect to the true underlying trajectory as a result of the post-processing itself. Provided this error is small compared to those caused by any corner cases of interest, it does not significantly affect the usefulness of the analysis — but it must be kept in mind.

Second, the accuracy of the replay (and therefore the detection threshold for anomalous artifacts) may depend on the RF environment and on the hardware profiling used during post-processing; ideally, this threshold would be constant regardless of the environment and post-processing settings.

Third, the replay process operates on a single IF file, so it effectively presents the same clock and front-end noise profile to all replay trajectories. In a real-world test including a large number of nominally identical receivers, these two noise sources would be independent, though with similar statistical characteristics. As with the imperfections in the replay process, this limitation should be negligible provided the errors due to any corner cases of interest are relatively large.

Conclusions and Future Work

The multiple offset post-processing method leverages the unique features of software GNSS receivers to greatly improve the coverage and statistical validity of receiver testing compared to traditional, hardware-based testing setups, in some cases by an order of magnitude or more. The MOPP approach introduces minimal additional error into the testing process and produces results whose statistical independence is easily verifiable. When corner cases are found, the results can be used as a targeted tuning and debugging guide, making it possible to optimize receiver performance quickly and efficiently.

Although these results primarily concern continuous navigation, the MOPP method is equally well-suited to tuning and testing a receiver’s baseband, as well its tracking and acquisition performance. In particular, reliably short time-to-first-fix is often a key figure of merit in receiver designs, and several specifications require acquisition performance to be demonstrated within a prescribed confidence bound. Achieving the desired confidence level in difficult environments may require a very large number of starts — the statistical method described in the 3GPP 34.171 specification, for example, can require as many as 2765 start attempts before a pass or fail can be issued — so being able to evaluate a receiver’s acquisition performance quickly during development and testing, while still maintaining sufficient confidence in the results, is extremely valuable.

Future improvements to the MOPP method may include a careful study of the baseline detection threshold as a function of the testing environment (open sky, deep urban canyon, and so on). Another potentially fruitful line of investigation may be to simulate the effects of physically distinct front ends by adding independent, identically distributed swaths of noise to copies of the raw IF file prior to executing the multiple offset runs.

Alexander Mitelman is GNSS research manager at Cambridge Silicon Radio. He earned his M.S. and Ph.D. degrees in electrical engineering from Stanford University. His research interests include signal quality monitoring and the development of algorithms and testing methodologies for GNSS.

Jakob Almqvist is an M.Sc. student at Luleå University of Technology in Sweden, majoring in space engineering, and currently working as a software engineer at Cambridge Silicon Radio.

Robin Håkanson is a software engineer at Cambridge Silicon Radio. His interests include the design of optimized GNSS software algorithms, particularly targeting low-end systems.

David Karlsson leads GNSS test activities for Cambridge Silicon Radio. He earned his M.S. in computer science and engineering from Linköping University, Sweden. His current focus is on test automation development for embedded software and hardware GNSS receivers.

Fredrik Lindström is a software engineer at Cambridge Silicon Radio. His primary interest is general GNSS software development.

Thomas Renström is a software engineer at Cambridge Silicon Radio. His primary interests include developing acquisition and tracking algorithms for GNSS software receivers.

Christian Ståhlberg is a senior software engineer at Cambridge Silicon Radio. He holds an M.Sc. in computer science from Luleå University of Technology. His research interests include the development of advanced algorithms for GNSS signal processing and their mapping to computer architecture.

James Tidd is a senior navigation engineer at Cambridge Silicon Radio. He earned his M.Eng. from Loughborough University in systems engineering. His research interests
include integrated navigation, encompassing GNSS, low-cost sensors, and signals of opportunity.
December 1, 2009
Real-Time Software Receivers: Challenges, Status, Perspectives
By Marcel Baracchi-Frei,
Grégoire Waelchli, Cyril Botteron,
and Pierre-André Farine

The idea of a software receiver is to replace the data processing implemented in hardware with software and to sample the analog input signal as close as possible to the antenna. Thus, the hardware is reduced to the minimum — antenna and analog-to-digital converters (ADCs) — while all the signal processing is done in software. As current mobile devices (such as personal digital assistants and smartphones) include more and more computing power and system features, it becomes possible to integrate a complete GNSS receiver with very few external components.

One advantage of a software receiver clearly lies in the low-cost opportunity, as the system resources such as the calculation power and system memory can be shared. Another advantage resides in the flexibility for adapting to new signals and frequencies. Indeed, an update can easily be performed by changing some parameters and algorithms in software, while it would require a new redevelopment for a standard hardware receiver.

Updating capabilities may become even more important in the future, as the world of satellite navigation is in complete effervescence: Europe is developing its own solution, Galileo, foreseen to be operational in 2013; China has undertaken a fundamental redevelopment of its current Compass navigation system; Russia is investing huge sums of money in GLONASS to bring it back to full operation; and the U.S. GPS system will see some fundamental improvements during the next few years, with new frequencies and new modulation techniques. At the same time, augmentation systems (either space-based or land-based) will develop all over the world.

These future developments will increase the number of accessible satellites available to every user — with the advantage of better coverage and higher accuracy. However, to take full advantage of the new satellite constellations and signals, new GNSS receivers and algorithms must be developed.

Definition and Types

The definition of a software receiver (SR) always brings some confusion among researchers and engineers in the field of communications and GNSS. For example, a receiver containing multiple hardware parts which can be reconfigured by setting a software flag or hardware pins of a chipset are regarded by some communication engineers to be a SR. In this article, however, we will consider the widely accepted SR definition in the field of GNSS; that is, a receiver in which all the baseband signal processing is performed in software by a programmable microprocessor.

Nowadays, software receivers can be grouped in three main categories:
- field programmable gate arrays (FPGAs), which are sometimes also referred to the domain of SR. These receivers can be reconfigured in the field by software.
- post-processing receivers include, among others, countless software tools or lines of code for testing new algorithms and for analyzing the GNSS signal, for example, to investigate GPS satellite failure or to decrypt unpublished codes.
- real-time-capable software receivers group that will be further considered here.
A modern GNSS receiver normally contains a RF front-end, a signal acquisition, a tracking, and a navigation block. A hardware-based receiver accomplishes the residual carrier removal, PRN code-despreading, and integration at the system sampling rate. Until the late 1990s, due to the limited processing power of microprocessors, these signal functions could only be practically implemented in hardware.

The GNSS SR boom really started with the development of real-time processing capability. This was first accomplished on a digital signal processor (DSP) and later on a commercial conventional personal computer (PC). Today, DSPs are increasingly replaced by specialized processors for embedded applications.

Challenges

Data rate. The ideal software receiver would place the ADC as close as possible to the antenna to reduce hardware parts to a minimum. In that sense, the most straightforward approach consists of digitizing the data directly at the antenna, without pre-filtering or pre-processing. But as the Nyquist theorem must be fulfilled (that is, sampling with at least twice the highest signal frequency), this translates into a data rate that is, for the time being, too high to be processed by a microcontroller.

Considering the GPS L1 signal and assuming 1 quantization bit per sample, this leads to the following values:

FGPSL1 5 1.57542 GHz
FSampling > 2 3 FGPSL1 5 3.15 GHz
Data rate > 3.15 GBit/s 5 393 MB/s

In order to reduce the data throughput, a solution such as a low intermediate frequency (IF) or a sub-sampling analog front-end must be chosen. In a low IF front-end, the incoming signal is down-converted to a lower intermediate frequency of several megahertz. This allows working with a sampling (and data) rate that can be more easily handled by a microcontroller. With the new BOC signal modulations (used for the Galileo E1 and the modernized GPS L1 signals) that have no energy at and near DC, a zero-IF or homodyne architecture is also possible without SNR degredation due to DC offset, flicker noise, or even-order distortions.

The sub-sampling technique exploits the fact that the effective signal bandwidth in a GNSS signal is much lower than the carrier frequency. Therefore, not the carrier frequency but the signal bandwidth must be respected by the Nyquist theorem (assuming appropriate band-pass filtering). In this case, the modulated signal is under-sampled to achieve frequency translation via intentional aliasing. Again, if the GPS L1 signal is taken as an example with assuming 1 quantization bit per sample, this leads to the following values:

Bandwidth GPS L1 5 2 MHz
FSampling > 2 3 Bandwidth 5 4 MHz
Data rate > 4 MBit/s 5 500 kB/s

However, as the sub-sampling approach is still difficult to implement due to current hardware and resources limitations, a more classical solution based on an analog IF down-conversion is often chosen. That means that the signal is first down-converted to an intermediate frequency and afterwards digitized.
Baseband Processing. Considering an IF-based architecture, the ADC provides a data stream (real or complex), which is first shifted into baseband by at least one complex mixer. The signal is then multiplied with several code replicas (generally early, prompt, and late) and finally accumulated. Figure 1 shows an example of a real data IF architecture.

FIGURE 1. Real IF architecture

In hardware receivers, the local code and carrier are generally generated in real-time by means of a numerically controlled oscillator (NCO) that performs the role of a digital waveform generator by incrementing an accumulator by a per-sample phase increment. The resulting value is then converted to the corresponding amplitude value to recreate the waveform at any desired phase offset. The frequency resolution is typically in the range of a few millihertz with a 32-bit accumulator, and a sampling frequency in the range of a few megahertz.

Assuming that a look-up table (LUT) address can be obtained with two logical operations (one shift and one mask), and the corresponding LUT value reads with 1 memory access — which is quite optimistic — the amount of operations needed to generate the complex waveforms per channel is given in Table 1.

Source: Marcel Baracchi-Frei, Grégoire Waelchli, Cyril Botteron, and Pierre-André Farine

The real-time carrier generation is computationally expensive and is consequently not suitable for a one-to-one software implementation. Earlier studies [Heckler, 2004] demonstrated that, assuming that an integer operation and a multiplication take one and 14 CPU cycles, respectively (for an Intel Pentium 4 processor), the baseband operations (without carrier and code generation or navigation solution) would require at least a 3 GHz Intel Pentium 4 processor with 100 percent CPU load. Therefore, under these conditions, real-time operations are not suitable for embedded processors. Therefore standard hardware receiver architectures cannot be translated directly into software, and consequently new strategies must be developed to lower the processing load.

Status

A major problem with the software architecture is the important computing resources required for baseband processing, especially for the accumulation process. As a straightforward transposition of traditional hardware-based architectures into software would lead to an amount of operations which is not suitable for today’s fastest computers, two main alternate strategies have been proposed in the literature: the first relies on single-instruction multiple-data (SIMD) operations, which provide the capability of processing vectors of data. Since they operate on multiple integer values at the same time, SIMD can produce significant gains in execution speed for repetitive tasks such as baseband processing. However, SIMD operations are tied to specific processors and therefore severely limit the portability of the code.

The second alternative consists in the bitwise parallel operations (sometimes also referred to as vector processing in the literature), which exploit the native bitwise representation of the signal. The data bits are stored in separate vectors, one sign and one or several magnitude vectors, on which bitwise parallel operations can be performed. The objective is to take advantage of the universality, high parallelism, and speed of the bitwise operations for which a single integer operation is translated into a few simple parallel logical relations. While SIMD operations use advanced and specific optimization schemes, the latter methodology exploits universal CPU instructions set. The drawback of the bitwise operations is the different representation of the values. To be able to perform integer operations, a time consuming conversion is needed.

Single-Instruction Multiple-Data

In 1995, Intel introduced the first instance of SIMD under the name of Multi Media Extension (MMX). The SIMD are mathematical instructions that operate on vectors of data and perform integer arithmetic on eight 8-bit, four 16-bit, or two 32-bit integers packed into a MMX register (see Figure 2).

FIGURE 2. Single-instruction single-data versus single-instruction multiple-data.

On average, the SIMD operations take more clock cycles to execute than a traditional x86 operation. Anyhow, since they operate on multiple integers at the same time, MMX code can produce significant gains in execution speed for appropriately structured algorithms. Later SIMD extensions (SSE, SSE2, and SSE3) added eight 128-bit registers to the x86 instruction set. Additionally, SSE operations include SIMD floating point operations, and expand the type of integer operations available to the programmer.

SIMD operations are well suited to parallelize the operations of the baseband processing (BBP) stage. In particular, they can be used to allow the PRN code mixing and the accumulation to be performed concurrently for all the code replicas. With the help of further optimizations such as instruction pipelining, more than 600 percent performance improvement with the SIMD operations compared to the standard integer operations can be observed [Heckler, 2006].For this reason, most of the software receivers with real-time processing capabilities use SIMD operations [Heckler; Pany 2003; Charkhandeh, 2006 ].

Bitwise Operations. Bitwise operation (or vector processing) was first introduced into the SR domain in 2002 [Ledvina]. The method exploits the bit representation of the incoming signal, where the data bits are stored in separate vectors on which bitwise parallel operations can be performed. Figure 3 shows a typical data storage scheme for vector processing.

Source: Marcel Baracchi-Frei, Grégoire Waelchli, Cyril Botteron, and Pierre-André Farine

The sign information is stored in the sign word while the remaining bit(s) representing the magnitude is (are) stored in the magn word(s). The objective is to take advantage of the high parallelism and speed of the bitwise operations for which a single integer addition or multiplication is translated into simple parallel logical operations. The carrier mixing stage is reduced to one or a few simple logical operations which can be performed concurrently on several bits. In the same way, the PRN code removal only affects the sign word.

In a U.S. patent by Ledvina and colleagues, the complete code and carrier removal process requires two operations for each code replica (early, prompt, and late). The complexity can be even further reduced by more than 30 percent by considering one single combination of early and late code replicas (typically early-minus-late). This way, the authors claim an improvement of a factor of 2 for the bitwise method compared to the standard integer operations.

The inherent drawback of this approach is the lack of flexibility: the complexity of the process becomes bit-depth dependent and the signal quantification cannot be easily changed (while performing BBP with integers allows the signal structure to change significantly without code modification).

To overcome this limitation, a combination of bitwise processing and distributed arithmetic can be used [described in Waelchli, 2009]. The power-consuming operations are performed with bitwise operations, and to be able to keep the flexibility of the calculations, standard integer operations are used after the code and carrier removal. The conversion between the two methods is performed with distributed arithmetic that offers an extremely efficient way to switch between the two representations.

Another important aspect in a software receiver is the code and carrier generation. As these tasks represent a huge processing load, new solutions must be developed in this domain.

Code Generation

The pseudorandom noise (PRN) codes transmitted by the satellites are deterministic sequences with noise-like properties that are typically generated with tapped linear feedback shift registers (for GPS L1 C/A) or saved in memory (for Galileo E1). But in order to save processing power, it is preferable for software applications to compute off-line the 32 codes and store them in memory.

One method stores the different PRN codes in their oversampled representation (the code are pre-generated) [Ledvina, 2002]. As the incoming signal code phase is random, the beginning of the first code chip is in general not aligned with the beginning of a word and may occur anywhere within it. To overcome this issue, either all the possible phases can be stored in memory, or the code can be shifted appropriately during the tracking. While the first approach increases the memory requirements, the second requires further data processing in function of the phase mismatch. Regarding the Doppler compensation, all the PRN codes in the table are assumed to have a zero Doppler shift. The code phase errors due to this hypothesis are eliminated by choosing a replica code from the table whose midpoint occurs at the desired midpoint time. The only other effect of the zero Doppler shift assumption is a small correlation power loss which is not more than 0.014 dB if the magnitude of the true Doppler shift is less than 10 kHz [Ledvina patent]. This approach is very popular in the SR domain and can be found in several solutions.

Carrier Generation

The generation of a local carrier frequency is necessary to perform the Doppler removal. The standard trigonometric functions or the Taylor decompositions for the sines and cosines computation are too heavy for a software implementation and are seldom considered.

However, several other techniques exist to reduce the computational load for the carrier generation: the values for the carrier can be pre-generated and then stored in lookup tables. As this would require several gigabytes of memory to store all the possible frequencies, the values are recorded on a coarse frequency grid with zero phases and at the RF front-end sampling frequency. The carrier will thus be available in a sampled version. The limited number of available carrier frequencies introduces a supplementary mismatch in the Doppler removal process. This error can be compensated with a simple phase rotation of the accumulation results. This method is very popular in the SR domain, and many solutions take advantage of it to avoid the power-hungry real-time carrier generation.

Based on the same principle as above, Normark (2004) proposed a method that pre-computes a set of carrier frequency candidates to be stored in memory. The grid spacing is selected so as to minimize the loss due to Doppler frequency offset. Furthermore, to provide phase alignement capabilities of the carriers, a set of initial phases is also provided for each possible Doppler frequency, as illustrated in Figure 4.

FIGURE 4. Set of carrier frequency candidates.

Contrarily to the Ledvina approach and thanks to the phase alignement capabilities, the number of sampling points must not obligatorily correspond to an entire acquisition period. Therefore, the length of the frequency candidate vectors can be chosen with respect to the available memory space and becomes quasi independent of the sampling frequency.

Another approach consists in removing concurrently the Doppler from all received satellite signals [Petovello, 2006]. The algorithm is implemented as a look-up table containing one single frequency, and the carrier removal is performed for all channels with the same frequency, but the frequency error results normally in an unacceptable loss. To overcome this problem, the integration interval is split into sub-intervals for which a partial accumulation is computed.

The result is rotated proportionally to the frequency mismatch in the same way as in the method described above. The algorithm can be applied recursively and with an appropriate selection of the sub-intervals, and the total attenuation factor can be limited to a reasonable value. The author claims an improvement of up to 30 percent compared to the standard look-up table method with respect to the total complexity for both Doppler removal and correlation stages. Regarding the computational complexity, the Doppler removal stage remains unchanged, with the difference that it is only performed once for all satellites. But the rotation needs to be done for each of the sub-intervals. However, this algorithm remains difficult to implement (number of samples varies in one or more full C/A code chip, and the data alignment is different than the sub-interval boundaries).

Available Receivers

Today, software receivers can be found at university and commercial levels. The development not only includes programming solution but also the realization of dedicated RF front-ends. As these RF front-ends are able to capture more and more frequencies with increasing bit-rates and band-widths, the PC-based software receivers require a comparably complex interface to transfer the digitized IF samples into the computer’s memory.

Two classes of PC-based GNSS SR front-end solutions can be found. The first one uses commercially available ADCs that are either connected directly to the PC (for example, via the PCI bus) or that are working as stand-alone devices. The ADC directly digitizes the received IF signal, which is taken from a pure analog front-end. This solution is often found at the university and research institute level, where a high amount of flexibility is required; for example, at the Department of Geomatics Engineering of the University of Calgary, Cornell University, and the University FAF Munich’s Institute of Geodesy and Navigation.

The second solution is based on front-ends that integrate an ADC plus a USB 2.0 interface. Currently, an impressive number of commercial and R&D front-ends are available for the GNSS market. NordNav (acquired by CSR) and Accord were among the first to provide USB-based solutions. Another interesting development comes from the University of Colorado, which in an OpenGPS forum published all details on the RF and USB sections. More companies announced and continue to announce front-ends that are not only capable of capturing a single frequency, but several different bands. To be able to deal with this increasing bandwidth, the USB port is very well suited for SR development, and its maximum theoretical transfer rate of 480 MBit/s allows realizing GPS/Galileo multi-frequency high bandwidth front-ends.

Embedded Market. As mentioned in the introduction, the embedded market will gain increasing importance during the next few years. A growing number of receivers are developed for this market, supporting different embedded platforms (for example, Intel XScale, ARM-based, and DSP-based). Several companies offer commercial software receivers for the embedded market, among others NordNav and SiRF (acquired by CSR), ALK Technologies Inc., and CellGuide.

Commercial PC-Based Receivers. The first commercial GPS/Galileo receiver for a PC platform was presented in 2001 by NordNav. This SR can be compared to a normal GPS receiver, although the CPU load of this solution is still quite impressive. Several other solutions have been presented more recently. One of the first (car) navigation solutions was presented by ALK Technologies under the name CoPilot. The CPU load was drastically reduced, and this solution works on a standard commercial personal computer. The client does not really see a difference compared to a solution that is based on a hardware receiver.

Research Activities. Use in teaching and training is one of the most valuable and obvious application for software GNSS receivers. Receivers, for which the source code is available, allow the observation and inspection of almost every signal data by the researcher.

Several textbooks have been published related to software GNSS receivers. The pioneer in this area is James Bao-yen Tsui, who in 2000 wrote the first book on software receivers, Fundamentals of Global Positioning System Receivers: A Software Approach (Wiley-Interscience, updated in 2004). Kai Borre and co-authors published in 2006 a book that comes with a complete (post-processing) software receiver written in Matlab: A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach (Birkhäuser Boston, 1st edition).

The European Union is financing development of receivers for Galileo. One project was the Galileo Receiver Analysis and Design Application (GRANADA) simulation tool. Running under Matlab, GRANADA is realized as a modular and configurable tool with a dual role: test-bench for integration and evaluation of receiver technologies, and SR as asset for GNSS application developers.

Other companies provide toolboxes (in Matlab or C) that allow testing of new algorithms in a working environment and inspecting almost all data signals; for example, Data Fusion Corporation and NavSys.

Outlook

Software receivers have found their place in the field of algorithm prototyping and testing. They also play a key role for certain special applications. What remains unclear today is if they will enter and drastically change the embedded market, or succeed as generic high-end receivers.

A software GNSS receiver offers advantages including design flexibility, faster adaptability, faster time-to-market, higher portability, and easy optimization at any algorithm stage. However, a major drawback persists in the slow throughput and the high CPU load.

Many different companies and universities have projects running that seek to optimize and develop new algorithms and methods for a software implementation. The developments not only consider the software levels, but also extend in the direction of using additional hardware that is already available on a standard PC; for example, using the high performance graphic processing unit (GPU) for calculating the local carrier [Petovello, 2008].

On the opposite end of the spectrum from the mass market, the following factors seem to ensure that, sooner or later, high-end software receivers will be available:
- High bandwidth signals (GPS and Galileo) can already be transferred into the PC in real time and processed.
- The processing power is increasing, allowing real-time processing with a limited amount of multi-correlators. The introduction of new multi-core processors will be advantageous for software receivers.
- Post-processing is one of the most important benefits of a software receiver, as it enables a re-analysis of the signal several times with all possible processing options. Increasing hard disk capacity facilitates storage of several long data sequences.
- Some signal-processing algorithms such as frequency-domain tracking or maximum-likelihood tracking are much easier to implement in software than in hardware, as they require complex operations at the signal level.
History

During the 1990s, a U.S. Department of Defense (DoD) project named Speakeasy was undertaken with the objective of showing and proving the concept of a programmable waveform, multiband, multimode radio [Lackey, 1995]. The Speakeasy project demonstrated the approach that underlies most software receivers: the analog to digital converter (ADC) is placed as near as possible to the antenna front-end, and all baseband functions that receive digitized intermediate frequency (IF) data input are processed in a programmable microprocessor using software techniques rather than hardware elements, such as correlators. The programmable implementation of all baseband functions offers a great flexibility that allows rapid changes and modifications. This property is an advantage in the fast-changing environment of GNSS receivers as new radio frequency (RF) bands, modulation types, bandwidths, and spreading/dispreading and baseband algorithms are regularly introduced.

In 1990, researchers at the NASA/Caltech Jet Propulsion Laboratory introduced a signal acquisition technique for code division multiple access (CDMA) systems that was based on the Fast Fourier Transform (FFT) [van Nee, 1991]. Since then, this method has been widely adopted in GNSS SR because of its simplicity and efficiency of processing load.

In 1996, researchers at Ohio University provided a direct digitization technique — called the bandpass sampling technique — that allowed the placing of ADCs closer to the RF portions of GNSS SRs. Until this time, the implemented SRs in university laboratories post-processed the data due to the lack of processing power mentioned earlier.

Finally, in 2001, researchers at Stanford University implemented a real-time processing-capable SR for the GPS L1 C/A signal [Akos, 2001].

However, the GNSS SR boom really started with the development of real-time processing capability. This was first accomplished on a digital signal processor (DSP) and later on a commercial conventional personal computer (PC). Today, the DSPs are increasingly replaced by specialized processors for embedded applications.

Marcel Baracchi-Frei received a physics-electronics degree from the University of Neuchâtel, Switzerland, and is working as a project leader and Ph.D. candidate in the Electronics and Signal Processing Laboratory at the Swiss Federal Institute of Technology (EPFL).

GRÉGOIRE WAELCHLI received his degree of physics-electronics from the University of Neuchâtel and is now at EPFL for a Ph.D.
thesis in the field of GNSS software receivers.

CYRIL BOTTERON received a Ph.D. with specialization in wireless communications from the University of Calgary, Canada, and now leads the EPFL GNSS and UWB research subgroups.

PIERRE-ANDRÉ FARINE is professor and head of the Electronics and Signal Processing Laboratory at EPFL, and associate professor at the University of Neuchâtel.
September 1, 2009
Innovation: Satellite Navigation Evolution: The Software GNSS Receiver (PDF)

Innovation: Satellite Navigation Evolution: The Software GNSS Receiver (PDF)

By Glenn MacGougan, Peter Ludvig Normark, and Christian Stahlberg

Published: January 2005 GPS World

In this month’s Innovation, we look at a further evolution of the GNSS receiver which offers the promise of flexibility, adaptability, and cost-effectiveness.—Richard Langley

January 1, 2005