Firmware v0206 offers:

• Stabilized raw data output for output rates up to 10 Hz
• Extended $POUTC NMEA message, including current LEAP SECONDS value, flags for expected UTC correction, and PPS edge shift relative to UTC (sawtooth correction SW).
• Stabilized sleep mode operation ($POPWR,1111*66) for all NV08C series HW versions
• Increased position accuracy and stability in urban canyon conditions with poor SV visibility
• Cold start initialized to LEAP SECOND 16 (LEAP SECOND 16 came into effect July 1, 2012)

Benefits include:

• Obtain initial receiver coordinates more quickly, in cold starts, low satellite signal (foliage/canopy) and loss of satellite signal conditions (indoor, garages, tunnels…).
• Greater satellite tracking reliability in poor visibility conditions (urban canyon/tall buildings, bridges/underpasses…).
• Stable raw data output up to 10Hz rate.
• Full sleep mode support for effective power savings.
• Complies with ERA-GLONASS requirements.

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

John Lavrakas

Economically, the System Differs Significantly from Its GNSS Cousins

John W. Lavrakas

In May 2007, I authored an article in GPS World looking ten years into the future and envisioning how the GNSS field would operate at that then-distant time. Reviewing my assessments, I see that I was both accurate and wide of the mark with my predictions.

The prediction that has proved accurate was that the GNSS world would be hybrid, with no one system as the sole provider of satellite-based positioning and timing services. This was hardly a risky prediction. Most in the GNSS community would have come to the same assessment.

But what I did not see coming were the advances China would take with its BeiDou program. My original assessment was based on three GNSSs only: GPS, GLONASS, and Galileo, and did not include BeiDou.

When I did my analysis in 2006, China was pretty quiet on BeiDou: no technical descriptions, no interface control document (ICD); no presentations at conferences of the Institute of Navigation. What little we knew about BeiDou was that it was a limited system, offering at best a regional solution. The original design was an active system using geosynchronous satellites, requiring each remote unit to request position from the satellite, which was calculated and sent back to the remote station.

How things have changed.

Since 2007, China has reshaped the BeiDou concept into a full-fledged modern GNSS, offering CDMA codes, navigation messages, and data rates comparable to GPS and Galileo — and lots of satellites. The ICD states in section 3.1, “When fully deployed, the space constellation of BDS consists of five geostationary Earth-orbit (GEO) satellites, twenty-seven medium Earth-orbit (MEO) satellites, and three inclined geosynchronous satellite orbit (IGSO) satellites.” No dates are provided, however, regarding attaining these numbers. So the BeiDou system promises to be on par with the other GNSSs.

Why does this matter?

While technically the BeiDou system resembles its cousins, economically it presents quite a different animal. Unlike other nations offering GNSS, China has a huge capacity for manufacturing at low cost. Considering this situation from a business perspective, a possible scenario could be that China offers GNSS chipsets that operate with BeiDou (either solely or as a hybrid with another GNSS)at extremely low prices. In doing so, China could corner the market for general purpose LBS applications (setting aside specialty receivers, such as for surveying and aviation applications). The price point would be so attractive that LBS services would employ Chinese devices in preference to the GPS ones, much like consumers purchase television sets: most come from China, and none are made in the United States any more.

China offers something, then, in this scenario that neither Russia, Europe, nor the United States can currently match. This may not be the scenario that eventually occurs, but it is possible. Other factors such as local terrestrial PNT solutions and dual-frequency improvements will come into play, but what I have described is one possible scenario. While the signal is free, the equipment is not, and when we are talking about a billion or more installations, cost is going to be a big driver.

Am I going out on a limb and saying that BeiDou will be the system of choice in another ten years or so? No, I would not go this far.

But I do say that serious competition for GNSS users (read “market share”) is now in play. Further, it is important for each GNSS operator to recognize this as they consider the services and features they choose to offer, and the impact these have in capturing their share of the market. GNSS providers now must factor the business aspect of their services as much as the technical, scientific, or safety of life. The U.S. government, for one, has gotten a bit complacent in upgrading GPS services to meet user needs, operating from a basis that it is the only GNSS on the block. It could wake up one day and find this no longer to be the case.

John Lavrakas is president of Advanced Research Corporation, where he provides consulting services on satellite navigation and fishery information systems. He has spent 32 years in GPS, supporting development of the GPS Control Segment, GPS user equipment, GPS performance analysis capabilities, and developing and marketing location-based systems. He is past president of the Institute of Navigation and an ION Fellow.

A method of decoding an unknown pseudorandom noise code uses a conventional GNSS antenna and receiver with modified firmware. The method was verified using the signals from the Galileo In-Orbit Validation satellites.

Decoding an unknown GNSS pseudorandom noise (PRN) code can be rather easily done using a high-gain steerable dish antenna as was used, for example, in determine the BeiDou-M1 broadcast codes before they were publicly announced. The signal-to-noise ratio within one chip of the code is sufficient to determine its sign. This article describes a method of getting this information using a conventional GNSS antenna and receiver with modified firmware. The method was verified using the signals from the Galileo In-Orbit Validation (IOV) satellites. In spite of the fact that only pilot signal decoding seems to be possible at first glance, it is shown that in practice data signals can also be decoded.

Concept

The idea is to do coherent accumulation of each chip of an unknown signal during a rather long time interval. The interval may be as long as a full satellite pass; for medium Earth orbits, this could be up to six hours. One of the receiver’s channels is configured in the same way as for signal tracking. The I and Q signal components are accumulated during one chip length in the digital signal processor, and these values are added to an array cell, referenced by chip number, by the processor. Only a limited amount of information need be known about the signal: its RF frequency; the expected chip rate; the expected total code length; and the modulation method.

The decoding of binary-phase-shift-keying (BPSK) signals (as most often used) is the subject of this article. It appears that the decoding of more complicated signals is possible too, but this should be proved. A limitation of this method (in common with that of the dish method) is the maximum total code length that can be handled: for lengths greater than one second and bitrates higher than 10,000 kilobits per second, the receiver’s resources may not be sufficient to deal with the signal.

Reconstructing the Signal’s Phase

This method requires coherency. During the full accumulation period, the phase difference between the real signal phase and the phase of the signal generated by the receiver’s channel should be much less than one cycle of the carrier frequency. Depending on the GNSS’s available signals, different approaches may be used. The simplest case is reconstruction of a third signal while two other signals on different frequencies are of known structure and can be tracked.

The main (and possibly the only significant) disturbing factor is the ionosphere. The ionospheric delay (or, more correctly, the variation of ionospheric delay) is calculated using the two known tracked signals, then the phase of the third signal, as affected by the ionosphere, is predicted.

The final formula (the calculations are trivial and are widely available in the literature) is:

where:
φ1 , f1 are the phase and frequency of the first signal in cycles and Hz, respectively
φ2 , f2   are the phase and frequency of the second signal in cycles and Hz, respectively
φ3 , f3   are the phase and frequency of the third signal in cycles and Hz, respectively.

It was confirmed that for all pass periods (elevation angles less than 10 degrees were not tested), the difference between the calculated phase and real phase was always less than one-tenth of a cycle. GPS Block IIF satellites PRN 1 and PRN 25 were used to prove this: the L1 C/A-code and L5 signals were used as the first and second signals, with the L2C signal as the third unknown.

If two known signals are not available, and the ionospheric delay cannot be precisely calculated, it is theoretically possible to obtain an estimate of the delay from one or more neighboring satellites with two signals available. Calculations and estimations should be carried out to investigate the expected precision.

The Experiment

The Galileo E6-B/C signal as currently transmitted by the IOV satellites was selected for the experiment, as its structure has not been published. The E6 signal has three components: E6-A, E6-B and E6-C. The E6-A component is part of the Galileo Public Regulated Service, while the two other components will serve the Galileo Commercial Service. The E6-B component carries a data signal, while the E6-C component is a pilot signal.

From open sources, it is known that the carrier frequency of the E6 signal is 1278.75 MHz and that the E6-B and E6-C components use BPSK modulation at 5,115 chips per millisecond with a primary code length of one millisecond. E6-B’s data rate is 1,000 bits per second and the total length of the pilot code is 100 milliseconds (a secondary code of 100 bits over 100 milliseconds is also present in the E6-C signal, which aids in signal acquisition).

A slightly modified commercial high-precision multi-GNSS receiver, with the E6 band and without the GLONASS L2 band, was used for this experiment. The receiver was connected to a conventional GNSS antenna, placed on a roof and was configured as described above. The E1 signal was used as the first signal and E5a as the second signal. The E6 code tracking (using 5,115 chip values of zero) was 100 percent guided from the E1 code tracking (the changing of the code delay in the ionosphere was ignored). The E6 phase was guided from E1 and E5a using the above equation. Two arrays for 511,500 I and Q samples were organized in firmware. The integration period was set to one chip (200 nanoseconds).

Galileo IOV satellite PRN 11 (also variously known as E11, ProtoFlight Model and GSAT0101) was used initially, and the experiment started when the satellite’s elevation angle was about 60 degrees and lasted for only about 30 minutes. Then the I and Q vectors were downloaded to a PC and analyzed.

Decoding of Pilot Signal (E6-C)

Decoding of the pilot signal is made under the assumption that any possible influence of the data signal is small because the number of ones and zeros of E6-B in each of 511,500 chips of the 100-millisecond integration interval is about the same. First, the secondary code was obtained. Figure 1 shows the correlation of the first 5,115 chips with 5,115 chips shifted by 0 to 511,500 chips. Because the initial phase of the E6 signal is unknown, two hypotheses for computing the amplitude or signal level were checked: [A] = [I] + [Q] and [A] = [I] – [Q], and the combination with the higher correlation value was selected for all further analysis.

Figure 1. Un-normalized autocorrelation of E6-C signal chips.

In Figure 1, the secondary code is highly visible: we see a sequence of 100 positive and negative correlation peaks (11100000001111 …; interpreting the negative peaks as zeros).This code is the exact complement (all bits reversed) of the published E5a pilot secondary code for this satellite. More will be said about the derived codes and their complements later. It appears that, for all of the IOV satellites, the E6-C secondary codes are the same as the E5a secondary codes.

After obtaining the secondary code, it is possible to coherently add all 100 milliseconds of the integration interval with the secondary code sign to increase the energy in each chip by 100 times. Proceeding, we now have 5,115 chips of the pilot signal ­— the E6-C primary code.

To understand the correctness of the procedure and to check its results, we need to confirm that there is enough signal energy in each chip. To this end, a histogram of the pilot signal chip amplitudes can be plotted (see Figure 2). We see that there is nothing in the middle of the plot. This means that all 5,115 chips are correct, and there is no chance that even one bit is wrong.

Figure 2. Histogram of pilot signal chip amplitude in arbitrary units.

But there is one effect that seems strange at first glance: instead of two peaks we have four (two near each other). We will shortly see that this phenomenon results from the influence of the E6-B data signal and it may be decoded also.

Decoding the Data Signal

The presence of four peaks in the histogram of Figure 2 was not understood initially, so a plot of all 511,500 signal code chips was made (see Figure 3).
Interestingly, each millisecond of the signal has its own distribution, and milliseconds can be found where the distribution is close to that when two signals with the same chip rate are present. In this case, there should be three peaks in the energy (signal strength) spectrum: –2E, 0, and +2E, where E is the energy of one signal (assuming the B and C signals have the same strength).

Figure 3. Plot of 511,500 signal code chip amplitudes in arbitrary units.

One such time interval (starting at millisecond 92 and ending at millisecond 97) is shown in Figure 4. The middle of the plot (milliseconds 93 to 96) shows the described behavior. Figure 5 is a histogram of signal code chip amplitude for the signal from milliseconds 93 to 96.

Figure 4. Plot of signal code chip amplitude in arbitrary units from milliseconds 93 to 96.

Then we collect all such samples (milliseconds) with the same data sign together to increase the signal level. Finally, 5,115 values are obtained. Their distribution is shown in Figure 6.

The central peak is divided into two peaks (because of the presence of the pilot signal), but a gap between the central and side peaks (unlike the case of Figure 5) is achieved. This allows us to get the correct sign of all data signal chips. Subtracting the already known pilot signal chips, we get the 5,115 chips of the data signal — the E6-B primary code. This method works when there are at least some samples (milliseconds) where the number of chips with the same data bit in the data signal is significantly more than half.

Figure 5. Histogram of signal code chip amplitude.

Figure 6. Histogram of the signed sum of milliseconds chip amplitude with a noticeable presence of the data signal.

Proving the Codes

The experimentally determined E6-B and E6-C primary codes and the E6-C secondary codes for all four IOVsatellites (PRNs 11, 12, 19, and 20) were put in the receiver firmware. The receiver was then able to autonomously track the E6-B and E6-C signals of the satellites.

Initial decoding of E6-B navigation data has been performed. It appears that the data has the same preamble (the 16-bit synchronization word) as that given for the E6-B signal in the GIOVE Interface Control Document (ICD). Convolutional encoding for forward error correction is applied as described in the Galileo Open Service ICD, and 24-bit cyclic redundancy check error detection (CRC-24) is used. At the time of the analysis, all four IOV satellites transmitted the same constant navigation data message.

Plots of PRN 11 E6 signal tracking are shown in Figure 7 and in Figure 8. The determined codes may be found at www.gpsworld.com/galileo-E6-codes. Some of these codes may be the exact complement of the official codes since the code-determination technique has a one-half cycle carrier-phase ambiguity resulting in an initial chip value ambiguity. But from the point of view of receiver tracking, this is immaterial.

Figure 7. Signal-to-noise-density ratio of E1 (red), E5a (magenta), E5b (blue), and E6 (green) code tracking of Galileo IOV satellite PRN 11 on December 21–22, 2012.

Figure 8. Pseudorange minus carrier phase (in units of meters) of E1 (red), E5a (magenta), E5b (blue), and E6 (green) code tracking of Galileo IOV satellite PRN 11 on December 21–22, 2012.

Acknowledgments

Special thanks to JAVAD GNSS’s DSP system developers. The system is flexible so it allows us to do tricks like setting the integration period to one chip, and powerful enough to be able to do required jobs within a 200-nanosecond cycle. This article was prepared for publication by Richard Langley.

Manufacturers

A JAVAD GNSS TRE-G3T-E OEM receiver, a modification of the TRE-G3T receiver, was used in the experiment, connected to a conventional JAVAD GNSS antenna. Plots of E6 code tracking of all four IOV satellites may be found on the company’s website.

Sergei Yudanov is a senior firmware developer at JAVAD GNSS, Moscow.

According to the Belgian GNSS receiver manufacturer, its engineers “are currently processing further data sets to finalize the implementation of full BeiDou support. Although the BeiDou constellation is still being deployed, the data analysis already shows promising results.”

Figure 1. Top: Computed height above reference point (m) for GPS-only, GPS+GLONASS and GPS+GLONASS+BeiDou vs. time of day (hour).

The bottom panel of Figure 1 shows that, even with the current BeiDou constellation (15 satellites total, of which five are geostationary over China, five in full mid-Earth orbit similar to GPS and GLONASS, and five in inclined geosynchronous orbit over Asia), the total number of satellites used over the European region reached 26 for a short moment.

Figure 2. L1 pseudorange residuals (m) for GPS (L1 C/A, top) and COMPASS (B1-I, bottom) vs. time of day (hour).

Figure 2 shows the L1 pseudorange residuals for all constellations individually. This comparison highlights the advantage of the GPS constellation, which builds on two decades of real-time orbit prediction. The BeiDou orbits are “quite accurate for a relatively young constellation, but show typical meter-level jumps when ephemerides are updated,” according to Septentrio.

Septentrio says that the new feature will soon become available on selected company platforms. Users of its multi-constellation receivers will then benefit from improvements in urban availability and signal integrity, thanks to the augmented signal coverage.

GPS is routinely used on Low Earth Orbit (LEO) satellites to provide the orbital position and offer a source of time to the satellite. Spacecraft in orbits higher than the 20,000 km of the GPS constellation, however, can only receive a few of the signals that “spill over” from the far side of the Earth, meaning that the signals are much weaker and a position fix cannot always be secured.

With the support of the European Space Agency (ESA) and the ARTES 4 program, SSTL included the SGR-GEO receiver on the GIOVE-A satellite to prove that a receiver could achieve a position fix from a higher orbit. The SGR-GEO is adapted from SSTL’s SGR range of receivers and incorporates a high-gain antenna and a precise oven-controlled clock. It will demonstrate special algorithms to allow reception of weak signals and an orbit estimator intended to allow a near continuous position fix throughout orbit.

“The results from the SGR-GEO receiver are really encouraging,” said Martin Unwin, principal GNSS engineer at SSTL. “We’re getting higher signal strengths than anticipated and also acquiring side lobes from the GPS transmit antennas, which improves the availability of the usable signals for navigation. With the success of the SGR-GEO receiver, GPS, in combination with Galileo and GLONASS, could soon be helping navigate spacecraft much further away from Earth.”

The experimental GPS receiver onboard GIOVE-A has been inactive for six years while the satellite has been used for its primary purpose of transmitting prototype Galileo signals. GIOVE-A’s retirement in June 2012 has allowed the commissioning of the experiment and is now providing valuable data to SSTL and ESA in support of the future use of spaceborne GNSS receivers at GEO altitudes. Engineers at SSTL will continue operations, testing out, tuning and improving the receiver software onboard GIOVE-A to achieve the best possible performance.

Figure 1. Distribution of the GPS+COMPASS tracking network established by the GNSS Research Center at Wuhan University and used as test network in this study.

Data from a tracking network with 12 stations in China, the Pacific region, Europe, and Africa demonstrates the capacity of Compass with a constellation comprising four geostationary Earth-orbit (GEO) satellites and five inclined geosynchronous orbit (IGSO) satellites in operation. The regional system will be completed around the end of 2012 with a constellation of five GEOs, five IGSOs, and four medium-Earth orbit (MEO) satellites. By 2020 it will be extended into a global system.

By Maorong Ge, Hongping Zhang, Xiaolin Jia, Shuli Song, and Jens Wickert

China’s satellite navigation system Compass, also known as BeiDou, has been in deveopment for more than a decade. According to the China National Space Administration, the development is scheduled in three steps: experimental system, regional system, and global system.

The experimental system was established as the BeiDou-1 system, with a constellation comprising three satellites in geostationary orbit (GEO), providing operational positioning and short-message communication. The follow-up BeiDou-2 system is planned to be built first as a regional system with a constellation of five GEO satellites, five in inclined geosynchronous orbit (IGSO), and four in medium-Earth orbit (MEO), and then to be extended to a global system consisting of five GEO, three IGSO, and 27 MEO satellites. The regional system is expected to provide operational service for China and its surroundings by the end of 2012, and the global system to be completed by the end of 2020.

The Compass system will provide two levels of services. The open service is free to civilian users with positioning accuracy of 10 meters, timing accuracy of 20 nanoseconds (ns) and velocity accuracy of 0.2 meters/second (m/s). The authorized service ensures more precise and reliable uses even in complex situations and probably includes short-message communications.

The fulfillment of the regional-system phase is approaching, and the scheduled constellation is nearly completed. Besides the standard services and the precise relative positioning, a detailed investigation on the real-time precise positioning service of the Compass regional system is certainly of great interest.

With data collected in May 2012 at a regional tracking network deployed by Wuhan University, we investigate the performance of precise orbit and clock determination, which is the base of all the precise positioning service, using Compass data only. We furthermore demonstrate the capability of Compass precise positioning service by means of precise point positioning (PPP) in post-processing and simulated real-time mode.

After a short description of the data set, we introduce the EPOS-RT software package, which is used for all the data processing. Then we explain the processing strategies for the various investigations, and finally present the results and discuss them in detail.

Tracking Data

The GNSS research center at Wuhan University is deploying its own global GNSS network for scientific purposes, focusing on the study of Compass, as there are already plenty of data on the GPS and GLONASS systems. At this point there are more than 15 stations in China and its neighboring regions.

Two weeks of tracking data from days 122 to 135 in 2012 is made available for the study by the GNSS Research Center at Wuhan University, with the permission of the Compass authorities. The tracking stations are equipped with UR240 dual-frequency receivers and UA240 antennas, which can receive both GPS and Compass signals, and are developed by the UNICORE company in China. For this study, 12 stations are employed. Among them are seven stations located in China: Chengdu (chdu), Harbin (hrbn), HongKong (hktu), Lhasa (lasa), Shanghai (sha1), Wuhan (cent) and Xi’an (xian); and five more in Singapore (sigp), Australia (peth), the United Arab Emirates (dhab), Europa (leid) and Africa (joha). Figure 1 shows the distribution of the stations, while Table 1 shows the data availability of each station during the selected test period.

Table 1. Data availability of the stations in the test network.

There were 11 satellites in operation: four GEOs (C01, C03, C04, C05), five IGSOs (C06, C07, C08, C09, C10), and two MEOs (C11, C12). During the test time, two maneuvers were detected, on satellite C01 on day 123 and on C06 on day 130. The two MEOs are not included in the processing because they were still in their test phase.

Software Packages

The EPOS-RT software was designed for both post-mission and real-time processing of observations from multi-techniques, such as GNSS and satellite laser ranging (SLR) and possibly very-long-baseline interferometry (VLBI), for various applications in Earth and space sciences. It has been developed at the German Research Centre for Geosciences (GFZ), primarily for real-time applications, and has been running operationally for several years for global PPP service and its augmentation. Recently the post-processing functions have been developed to support precise orbit determinations of GNSS and LEOs for several ongoing projects.

We have adapted the software package for Compass data for this study. As the Compass signal is very similar to those of GPS and Galileo, the adaption is straight-forward thanks to the new structure of the software package. The only difference to GPS and Galileo is that recently there are mainly GEOs and IGSOs in the Compass system, instead of only MEOs. Therefore, most of the satellites can only be tracked by a regional network; thus, the observation geometry for precise orbit determination and for positioning are rather different from current GPS and GLONASS.

Figure 2 shows the structure of the software package. It includes the following basic modules: preprocessing, orbit integration, parameter estimation and data editing, and ambiguity-fixing. We have developed a least-square estimator for post-mission data processing and a square-root information filter estimator for real-time processing.

Figure 2. Structure of the EPOS-RT software.

GPS Data Processing

To assess Compass-derived products, we need their so-called true values. The simplest way is to estimate the values using the GPS data provided by the same receivers.

First of all, PPP is employed to process GPS data using International GNSS Service (IGS) final products. PPP is carried out for the stations over the test period on a daily basis, with receiver clocks, station coordinates, and zenith tropospheric delays (ZTD) as parameters. The repeatability of the daily solutions confirms a position accuracy of better than 1 centimeter (cm), which is good enough for Compass data processing. The station clock corrections and the ZTD are also obtained as by-products.

The daily solutions are combined to get the final station coordinates. These coordinates will be fixed as ground truth in Compass precise orbit and clock determination. Compass and GPS do not usually have the same antenna phase centers, and the antenna is not yet calibrated, thus the corresponding corrections are not yet available. However, this difference could be ignored in this study, as antennas of the same type are used for all the stations.

Orbit and Clock Determination

For Compass, a three-day solution is employed for precise orbit and clock estimation, to improve the solution strength because of the weak geometry of a regional tracking network. The orbits and clocks are estimated fully independent from the GPS observations and their derived results, except the station coordinates, which are used as known values.

The estimated products are validated by checking the orbit differences of the overlapped time span between two adjacent three-day solutions. As shown in Figure 3, orbit of the last day in a three-day solution is compared with that over the middle day of the next three-day solution. The root-mean-square (RMS) deviation of the orbit difference is used as index to qualify the estimated orbit.

Figure 3. Three-day solution and orbit overlap. The last day of a three-day solution is compared with the middle day of the next three-day solution.

In each three-day solution, the observation models and parameters used in the processing are listed in Table 2, which are similar to the operational IGS data processing at GFZ except that the antenna phase center offset (PCO) and phase center variation (PCV) are set to zero for both receivers and satellites because they are not yet available.

Satellite force models are also similar to those we use for GPS and GLONASS in our routine IGS data processing and are listed in Table 2. There is also no information about the attitude control of the Compass satellites. We assume that the nominal attitude is defined the same as GPS satellite of Block IIR.

Satellite Orbits. Figure 4 shows the statistics of the overlapped orbit comparison for each individual satellite. The averaged RMS in along- and cross-track and radial directions and 3D-RMS as well are plotted. GEOs are on the left side, and IGSOs on the right side; the averaged RMS of the two groups are indicated as (GEO) and (IGSO) respectively. The RMS values are also listed in Table 3.

As expected, GEO satellites have much larger RMS than IGSOs. On average, GEOs have an accuracy measured by 3D-RMS of 288 cm, whereas that of IGSOs is about 21 cm.

As usual, the along-track component of the estimated orbit has poorer quality than the others in precise orbit determination; this is evident from Figure 4 and Table 3. However, the large 3D-RMS of GEOs is dominated by the along-track component, which is several tens of times larger than those of the others, whereas IGSO shows only a very slight degradation in along-track against the cross-track and radial. The major reason is that IGSO has much stronger geometry due to its significant movement with respect to the regional ground-tracking network than GEO.

Figure 4. Averaged daily RMS of all 12 three-day solutions. GEOs are on the left side and IGSOs on the right. Their averages are indicated with (GEO) and (IGSO), respectively.

Table 3. RMS of overlapped orbits (unit, centimeters).

If we check the time series of the orbit differences, we notice that the large RMS in along-track direction is actually due to a constant disagreement of the two overlapped orbits. Figure 5 plots the time series of orbit differences for C05 and C06 as examples of GEO and IGSO satellites, respectively. For both satellites, the difference in along-track is almost a constant and it approaches –5 meters for C05.

Note that GEO shows a similar overlapping agreement in cross-track and radial directions as IGSO.

Figure 5. Time series of orbit differences of satellite C05 and C06 on the day 124 2012. A large constant bias is in along-track, especially for GEO C05.

Satellite Clocks. Figure 6 compares the satellite clocks derived from two adjacent three-day solutions, as was done for the satellite orbits. Satellite C10 is selected as reference for eliminating the epoch-wise systematic bias. The averaged RMS is about 0.56 ns (17 cm) and the averaged standard deviation (STD) is 0.23 ns (7 cm). Satellite C01 has a significant larger bias than any of the others, which might be correlated with its orbits.

From the orbit and clock comparison, both orbit and clock can hardly fulfill the requirement of PPP of cm-level accuracy. However, the biases in orbit and clock are usually compensatable to each other in observation modeling. Moreover, the constant along-track biases produce an almost constant bias in observation modeling because of the slightly changed geometry for GEOs. This constant bias will not affect the phase observations due to the estimation of ambiguity parameters. Its effect on ranges can be reduced by down-weighting them properly. Therefore, instead of comparing orbit and clock separately, user range accuracy should be investigated as usual. In this study, the quality of the estimated orbits and clocks is assessed by the repeatability of the station coordinates derived by PPP using those products.

Figure 6. Statistics of the overlap differences of the estimated receiver and satellite clocks. Satellite C10 is selected as the reference clock.

Precise Point Positioning

With these estimates of satellite orbits and clocks, PPP in static and kinematic mode are carried out for a user station that is not involved in the orbit and clock estimation, to demonstrate the accuracy of the Compass PPP service.

In the PPP processing, ionosphere-free phase and range are used with proper weight. Satellite orbits and clocks are fixed to the abovementioned estimates. Receiver clock is estimated epoch-wise, remaining tropospheric delay after an a priori model correction is parameterized with a random-walk process. Carrier-phase ambiguities are estimated but not fixed to integer. Station coordinates are estimated according to the positioning mode: as determined parameters for static mode or as epoch-wise independent parameters for kinematic mode.

Data from days 123 to 135 at station CHDU in Chengdu, which is not involved in the orbit and clock determination, is selected as user station in the PPP processing. The estimated station coordinates and ZTD are compared to those estimated with GPS data, respectively.

Static PPP. In the static test, PPP is performed with session length of 2 hours, 6 hours, 12 hours, and 24 hours. Figure 7 and Table 4 show the statistics of the position differences of the static solutions with various session lengths over days 123 to 125.

The accuracy of the PPP-derived positions with 2 hours data is about 5 cm, 3 cm, and 10 cm in east, north, and vertical, compared to the GPS daily solution. Accuracy improves with session lengths. If data of 6 hours or longer are involved in the processing, position accuracy is about 1 cm in east and north and 4 cm in vertical. From Table 4, the accuracy is improved to a few millimeters in horizontal and 2 cm in vertical with observations of 12 to 24 hours. The larger RMS in vertical might be caused by the different PCO and PCV of the receiver antenna for GPS and Compass, which is not yet available.

Figure 7. Position differences of static PPP solutions with session length of 2 hours, 6 hours, 12 hours, and 24 hours compared to the estimates using daily GPS data for station CHDU.

Table 4. RMS of PPP position with different session length.

Kinematic PPP. Kinematic PPP is applied to the CHDU station using the same orbit and clock products as for the static positioning for days 123 to 125 in 2012.

The result of day 125 is presented here as example. The positions are estimated by means of the sequential least-squares adjustment with a very loose constraint of 1 meter to positions at two adjacent epochs. The result estimated with backward smoothing is shown in Figure 8. The differences are related to the daily Compass static solution. The bias and STD of the differences in east, north, and vertical are listed in Table 5. The bias is about 16 mm, 13 mm, and 1 mm, and the STD is 10 mm, 14 mm and 55 mm, in east, north, and vertical, respectively.

Figure 8. Position differences of the kinematic PPP and the daily static solution, and number of satellites observed.

Table 5. Statistics of the position differences of the kinematic PPP in post-processing mode and the daily solution. (m)

Compass-Derived ZTD. ZTD is a very important product that can be derived from GNSS observations besides the precise orbits and clocks and positions. It plays a crucial role in meteorological study and weather forecasting.

ZTD at the CHDU station is estimated as a stochastic process with a power density of 5 mm √hour by fixing satellite orbits, clocks, and station coordinates to their precisely estimated values, as is usually done for GPS data.

The same processing procedure is also applied to the GPS data collected at the station, but with IGS final orbits and clocks. The ZTD time series derived independently from Compass and GPS observations over days 123 to 125 in 2012 and their differences are shown on Figure 9.

Figure 9. Comparison of ZTD derived independently from GPS and COMPASS observations. The offset of the two time series is about -14 mm (GPS – COMPASS) and the STD is about 5 mm.

Obviously, the disagreement is mainly caused by Compass, because GPS-derived ZTD is confirmed of a much better quality by observations from other techniques. However, this disagreement could be reduced by applying corrected PCO and PCV corrections of the receiver antennas, and of course it will be significantly improved with more satellites in operation.

Simulated Real-Time PPP Service

Global real-time PPP service promises to be a very precise positioning service system. Hence we tried to investigate the capability of a Compass real-time PPP service by implementing a simulated real-time service system and testing with the available data set.

We used estimates of a three-day solution as a basis to predict the orbits of the next 12 hours. The predicted orbits are compared with the estimated ones from the three-day solution. The statistics of the predicted orbit differences for the first 12 hours on day 125 in 2012 are shown on Figure 10.

From Figure 10, GEOs and IGSOs have very similar STDs of about 30 cm on average. Thus, the significantly large RMS, up to 6 meters for C04 and C05, implies large constant difference in this direction. The large constant shift in the along-track direction is a major problem of the current Compass precise orbit determination. Fortunately, this constant bias does not affect the positioning quality very much, because in a regional system the effects of such bias on observations are very similar.

Figure 10. RMS (left) and STD (right) of the differences between predicted and estimated orbits.

With the predicted orbit hold fixed, satellite clocks are estimated epoch-by-epoch with fixed station coordinates. The estimated clocks are compared with the clocks of the three-day solution, and they agree within 0.5 ns in STD. As the separated comparison of orbits and clocks usually does not tell the truth of the accuracy of the real-time positioning service, simulated real-time positioning using the estimated orbits and clocks is performed to reveal the capability of Compass real-time positioning service.

Figure 11 presents the position differences of the simulated real-time PPP service and the ground truth from the static daily solution. Comparing the real-time PPP result in Figure 11 and the post-processing result in Figure 8, a convergence time of about a half-hour is needed for real-time PPP to get positions of 10-cm accuracy. Afterward, the accuracy stays within ±20 cm and gets better with time. The performance is very similar to that of GPS because at least six satellites were observed and on average seven satellites are involved in the positioning. No predicted orbit for C01 is available due to its maneuver on the day before. Comparing the constellation in the study and that planned for the regional system, there are still one GEO and four MEOs to be deployed in the operational regional system. Therefore, with the full constellation, accuracy of 1 decimeter or even of cm-level is achievable for the real-time precise positioning service using Compass only.

Figure 11. Position differences of the simulated real-time PPP and the static daily PPP. The number of observed satellites is also plotted.

Summary

The three-day precise orbit and clock estimation shows an orbit accuracy, measured by overlap 3D-RMS, of better than 288 cm for GEOs and 21 cm for IGSOs, and the accuracy of satellite clocks of 0.23 ns in STD and 0.56 in RMS. The largest orbit difference occurs in along-track direction which is almost a constant shift, while differences in the others are rather small.

The static PPP shows an accuracy of about 5 cm, 3 cm, and 10 cm in east, north, and vertical with two hours observations. With six hours or longer data, accuracy can reach to 1 cm in horizontal and better than 4 cm in vertical. The post-mission kinematic PPP can provide position accuracy of 2 cm, 2 cm, and 5 cm in east, north, and vertical. The high quality of PPP results suggests that the orbit biases, especially the large constant bias in along-track, can be compensated by the estimated satellite clocks and/or absorbed by ambiguity parameters due to the almost unchanged geometry for GEOs.

The simulated real-time PPP service also confirms that real-time positioning services of accuracy at 1 decimeter-level and even cm–level is achievable with the Compass constellation of only nine satellites. The accuracy will improve with completion of the regional system.

This is a preliminary achievement, accomplished in a short time. We look forward to results from other colleagues for comparison. Further studies will be conducted to validate new strategies for improving accuracy, reliability, and availability. We are also working on the integrated processing of data from Compass and other GNSSs. We expect that more Compass data, especially real-time data, can be made available for future investigation.

UA240 OEM card made by Unicore company and used in Compass reference stations.

Acknowledgments

We thank the GNSS research center at Wuhan University and the Compass authorities for making the data available for this study.

The material in this article was first presented at the ION-GNSS 2012 conference.

Maorong Ge received his Ph.D. in geodesy at Wuhan University, China. He is now a senior scientist and head of the GNSS real-time software group at the German Research Centre for Geosciences (GFZ Potsdam).

Hongping Zhang is an associate professor of the State Key Laboratory of Information Engineering in Surveying, Mapping and Remote Sensing at Wuhan University, and holds a Ph.D. in GNSS applications from Shanghai Astronomical Observatory. He designed the processing system of ionospheric modeling and prediction for the Compass system.

Xiaolin Jia is a senior engineer at Xian Research Institute of Surveying and Mapping. He received his Ph.D. from the Surveying and Mapping College of Zhengzhou Information Engineering University.

Shuli Song is an associate research fellow. She obtained her Ph.D. from the Shanghai Astronomical Observatory, Chinese Academy of sciences.

Jens Wickert obtained his doctor’s degree from Karl-Franzens-University Graz in geophysics/meteorology. He is acting head of the GPS/Galileo Earth Observation section at the German Research Center for Geosciences GFZ at Potsdam.

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. SX-NSR plus two NavPort-4 front ends with inter-front-end link.

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

Figure 9. Scalar tracking standard point positioning (SPP) solution (red), vector-tracking SPP solution (yellow), Kalman-filter vector-tracking solution (green).

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