GPS World » Innovation

Innovation: Evil Waveforms: Generating Distorted GNSS Signals Using a Signal Simulator

Richard Langley — Wed, 01 May 2013 23:28:50 +0000

Editor’s Note:Further Reading for this article will appear soon.

By Mathieu Raimondi, Eric Sénant, Charles Fernet, Raphaël Pons, Hanaa Al Bitar, Francisco Amarillo Fernández, and Marc Weyer

INNOVATION INSIGHTS with Richard Langley

INTEGRITY. It is one of the most desirable personality traits. It is the characteristic of truth and fair dealing, of honesty and sincerity. The word also can be applied to systems and actions with a meaning of soundness or being whole or undivided. This latter definition is clear when we consider that the word integrity comes from the Latin word integer, meaning untouched, intact, entire — the same origin as that for the integers in mathematics: whole numbers without a fractional or decimal component.

Integrity is perhaps the most important requirement of any navigation system (along with accuracy, availability, and continuity). It characterizes a system’s ability to provide a timely warning when it fails to meet its stated accuracy. If it does not, we have an integrity failure and the possibility of conveying hazardously misleading information. GPS has built into it various checks and balances to ensure a fairly high level of integrity. However, GPS integrity failures have occasionally occurred.

One of these was in 1990 when SVN19, a GPS Block II satellite operating as PRN19, suffered a hardware chain failure, which caused it to transmit an anomalous waveform. There was carrier leakage on the L1 signal spectrum. Receivers continued to acquire and process the SVN19 signals, oblivious to the fact that the signal distortion resulted in position errors of three to eight meters. Errors of this magnitude would normally go unnoticed by most users, and the significance of the failure wasn’t clear until March 1993 during some field tests of differential navigation for aided landings being conducted by the Federal Aviation Administration. The anomaly became known as the “evil waveform.”

(I’m not sure who first came up with this moniker for the anomaly. Perhaps it was the folks at Stanford University who have worked closely with the FAA in its aircraft navigation research. The term has even made it into popular culture. The Japanese drone-metal rock band, Boris, released an album in 2005 titled Dronevil. One of the cuts on the album is “Evil Wave Form.” And if drone metal is not your cup of tea, you will find the title quite appropriate.) Other types of GPS evil waveforms are possible, and there is the potential for such waveforms to also occur in the signals of other global navigation satellite systems. It is important to fully understand the implications of these potential signal anomalies. In this month’s column, our authors discuss a set of GPS and Galileo evil-waveform experiments they have carried out with an advanced GNSS RF signal simulator. Their results will help to benchmark the effects of distorted signals and perhaps lead to improvements in GNSS signal integrity.

“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. He welcomes comments and topic ideas.

GNSS signal integrity is a high priority for safety applications. Being able to position oneself is useful only if this position is delivered with a maximum level of confidence. In 1993, a distortion on the signals of GPS satellite SVN19/PRN19, referred to as an “evil waveform,” was observed. This signal distortion induced positioning errors of several meters, hence questioning GPS signal integrity. Such events, when they occur, should be accounted for or, at least, detected.

Since then, the observed distortions have been modeled for GPS signals, and their theoretical effects on positioning performance have been studied through simulations. More recently, the models have been extended to modernized GNSS signals, and their impact on the correlation functions and the range measurements have been studied using numerical simulations. This article shows, for the first time, the impact of such distortions on modernized GNSS signals, and more particularly on those of Galileo, through the use of RF simulations. Our multi-constellation simulator, Navys, was used for all of the simulations.

These simulations are mainly based on two types of scenarios: a first scenario, referred to as a static scenario, where Navys is configured to generate two signals (GPS L1C/A or Galileo E1) using two separate RF channels. One of these signals is fault free and used as the reference signal, and the other is affected by either an A- or B-type evil waveform (EW) distortion (these two types are described in a latter section).

The second type of scenario, referred to as a dynamic scenario, uses only one RF channel. The generated signal is fault free in the first part of the simulation, and affected by either an A- or B-type EW distortion in the second part of the scenario. Each part of the scenario lasts approximately one minute.

All of the studied scenarios consider a stationary satellite position over time, hence a constant signal amplitude and propagation delay for the duration of the complete scenario.

Navys Simulator

The first versions of Navys were specified and funded by Centre National d’Etudes Spatiales or CNES, the French space agency. The latest evolutions were funded by the European Space Agency and Thales Alenia Space France (TAS-F). Today, Navys is a product whose specifications and ownership are controled by TAS-F. It is made up of two components: the hardware part, developed by ELTA, Toulouse, driven by a software part, developed by TAS-F.

The Navys simulator can be configured to simulate GNSS constellations, but also propagation channel effects. The latter include relative emitter-receiver dynamics, the Sagnac effect, multipath, and troposphere and ionosphere effects. Both ground- and space-based receivers may be considered.

GNSS Signal Generation Capabilities. Navys is a multi-constellation simulator capable of generating all existing and upcoming GNSS signals. Up to now, its GPS and Galileo signal-generation capabilities and performances have been experienced and demonstrated. The simulator, which has a generation capacity of 16 different signals at the same time over the entire L band, has already been successfully tested with GPS L1 C/A, L1C, L5, and Galileo E1 and E5 receivers.

Evil Waveform Emulation Capabilities. In the frame of the ESA Integrity Determination Unit project, Navys has been upgraded to be capable of generating the signal distortions that were observed in 1993 on the signals from GPS satellite SVN19/PRN19. Two models have been developed from the observations of the distorted signals.

The first one, referred to as Evil Waveform type A (EWFA), is associated with a digital distortion, which modifies the duration of the GPS C/A code chips, as shown in FIGURE 1. A lead/lag of the pseudorandom noise code chips is introduced. The +1 and –1 state durations are no longer equal, and the result is a distortion of the correlation function, inducing a bias in the pseudorange measurement equal to half the difference in the durations. This model, based on GPS L1 C/A-code observations, has been extended to modernized GNSS signals, such as those of Galileo (see Further Reading). In Navys, type A EWF generation is applied by introducing an asymmetry in the code chip durations, whether the signal is modulated by binary phase shift keying (BPSK), binary offset carrier (BOC), or composite BOC (CBOC).

FIGURE 1. Theoretical L1 C/A code-chip waveforms in the presence of an EWFA (top) and EWFB (bottom).

The second model, referred to as Evil Waveform type B (EWFB) is associated with an analog distortion equivalent to a second-order filter, described by a resonance frequency (fd) and a damping factor (σ), as depicted in Figure 1. This failure results in correlation function distortions different from those induced by EWFA, but which also induces a bias in the pseudorange measurement. This bias depends upon the characteristics (resonance frequency, damping factor) of the filter. In Navys, an infinite impulse response (IIR) filter is implemented to simulate the EWFB threat. The filter has six coefficients (three in the numerator and three in the denominator of its transfer function). Hence, it appears that Navys can generate third order EWF type B threats, which is one order higher that the second order threats considered by the civil aviation community. Navys is specified to generate type B EWF with less than 5 percent root-mean-square (RMS) error between the EWF module output and the theoretical model. During validation activities, a typical value of 2 percent RMS error was measured. This EWF simulation function is totally independent of the generated GNSS signals, and can be applied to any of them, whatever its carrier frequency or modulation.

It is important to note that such signal distortions may be generated on the fly — that is, while a scenario is running. FIGURE 2 gives an example of the application of such threat models on the Galileo E1 BOC signal using a Matlab theoretical model.

FIGURE 2. Theoretical E1 C code-chip waveforms in the presence of an EWFA (top) and EWFB (bottom).

GEMS Description

GEMS stands for GNSS Environment Monitoring Station. It is a software-based solution developed by Thales Alenia Space aiming at assessing the quality of GNSS measurements. GEMS is composed of a signal processing module featuring error identification and characterization functions, called GEA, as well as a complete graphical user interface (see online version of this article for an example screenshot) and database management.

The GEA module embeds the entire signal processing function suite required to build all the GNSS observables often used for signal quality monitoring (SQM). The GEA module is a set of C/C++ software routines based on innovative-graphics-processing-unit (GPU) parallel computing, allowing the processing of a large quantity of data very quickly. It can operate seamlessly on a desktop or a laptop computer while adjusting its processing capabilities to the processing power made available by the platform on which it is installed. The GEA signal-processing module is multi-channel, multi-constellation, and supports both real-time- and post-processing of GNSS samples produced by an RF front end.

GEMS, which is compatible with many RF front ends, was used with a commercial GNSS data-acquisition system. The equipment was configured to acquire GNSS signals at the L1 frequency, with a sampling rate of 25 MHz. The digitized signals were provided in real time to GEMS using a USB link.

From the acquired samples, GEMS performed signal acquisition and tracking, autocorrelation function (ACF) calculation and display, and C/N₀ measurements. All these figures of merit were then logged in text files.

EWF Observation

Several experiments were carried out using both static and kinematic scenarios with GPS and Galileo signals.

GPS L1 C/A. The first experiment was intended to validate Navys’ capability of generating state-of-the-art EWFs on GPS L1 C/A signals. It aimed at verifying that the distortion models largely characterized in the literature for the GPS L1 C/A are correctly emulated by Navys.

EWFA, static scenario. In this scenario, Navys is configured to generate two GPS L1 C/A signals using two separate RF channels. The same PRN code was used on both channels, and a numerical frequency transposition was carried out to translate the signals to baseband. One signal was affected by a type A EWF, with a lag of 171 nanoseconds, and the other one was EWF free. Next, its amplified output was plugged into an oscilloscope. The EWFA effect is easily seen as the faulty signal falling edge occurs later than the EWF-free signal, while their rising edges are still synchronous. However, the PRN code chips are distorted from their theoretical versions as the Navys integrates a second-order high pass filter at its output, meant to avoid unwanted DC emissions. The faulty signal falling edge should occur approximately 0.17 microseconds later than the EWF-free signal falling edge.

A spectrum analyzer was used to verify, from a spectral point of view, that the EWFA generation feature of Navys was correct. For this experiment, Navys was configured to generate a GPS L1 C/A signal at the L1 frequency, and Navys output was plugged into the spectrum analyzer input. Three different GPS L1 C/A signals are included: the spectrum of an EWF-free signal, the spectrum of a signal affected by an EWF type A, where the lag is set to 41.1 nanoseconds, and the spectrum of a signal affected by an EWF type A, where the lag is set to 171 nanoseconds. As expected, the initial BPSK(1) signal is distorted and spikes appear every 1 MHz. The spike amplitude increases with the lag.

EWFA, dynamic scenario. In a second experiment, Navys was configured to generate only one fault-free GPS L1 C/A signal at RF. The RF output was plugged into the GEMS RF front end, and acquisition was launched. One minute later, an EWFA distortion, with a lag of 21 samples (about 171 nanoseconds at 120 times f₀, where f₀ equals 1.023 MHz), was activated from the Navys interface.

FIGURE 3 shows the code-phase measurement made by GEMS. Although the scenario was static in terms of propagation delay, the code-phase measurement linearly decreases over time. This is because the Navys and GEMS clocks are independent and are drifting with respect to each other.

FIGURE 3. GEMS code-phase measurements on GPS L1 C/A signal, EWFA dynamic scenario.

The second observation is that the introduction of the EWFA induced, as expected, a bias in the measurement. If one removes the clock drifts, the bias is estimated to be 0.085 chips (approximately 25 meters). According to theory, an EWFA induces a bias equal to half the lead or lag value. A value of 171 nanoseconds is equivalent to about 50 meters.

FIGURE 4 represents the ACFs computed by GEMS during the scenario. It appears that when the EWFA is enabled, the autocorrelation function is flattened at its top, which is typical of EWFA distortions. Eventually, FIGURE 5 showed that the EWFA also results in a decrease of the measured C/N₀, which is completely coherent with the flattened correlation function obtained when EWFA is on.

FIGURE 4. GEMS ACF computation on GPS L1 C/A signal, EWFA dynamic scenario.

FIGURE 5. GEMS C/N0 measurement on GPS L1 C/A signal, EWFA dynamic scenario.

Additional analysis has been conducted with Matlab to confirm Navys’ capacity. A GPS signal acquisition and tracking routine was modified to perform coherent accumulation of GPS signals. This operation is meant to extract the signal out of the noise, and to enable observation of the code chips. After Doppler and code-phase estimation, the signal is post-processed and 1,000 signal periods are accumulated. The result, shown in FIGURE 6, confronts fault-free (blue) and EWFA-affected (red) code chips. Again, the lag of 171 nanoseconds is clearly observed. The analysis concludes with FIGURE 7, which shows the fault-free (blue) and the faulty (red) signal spectra. Again, the presence of spikes in the faulty spectrum is characteristic of EWFA.

FIGURE 6. Fault-free vs. EWFA GPS L1 C/A signal.

FIGURE 7. Fault-free vs. EWFA GPS L1 C/A signal power spectrum density.

EWFB, static scenario. The same experiments as for EWFA were conducted for EWFB. Fault-free and faulty (EWFB with a resonance frequency of 8 MHz and a damping factor of 7 MHz) signals were simultaneously generated and observed using an oscilloscope and a spectrum analyzer. The baseband temporal signal undergoes the same default as that of the EWFA because of the Navys high-pass filter. However, the oscillations induced by the EWFB are clearly observed.

The spectrum distortion induced by the EWFB at the L1 frequency is amplified around 8 MHz, which is consistent with the applied failure.

EWFB, dynamic scenario. Navys was then configured to generate one fault-free GPS L1 C/A signal at RF. The RF output was plugged into the GEMS RF front end, and acquisition was launched. One minute later, an EWFB distortion with a resonance frequency of 4 MHz and a damping factor of 2 MHz was applied. As for the EWFA experiments, the GEMS measurements were analyzed to verify the correct application of the failure. The code-phase measurements, illustrated in FIGURE 8, show again that the Navys and GEMS clocks are drifting with respect to each other. Moreover, it is clear that the application of the EWFB induced a bias of about 5.2 meters on the code-phase measurement. One should notice that this bias depends upon the chip spacing used for tracking. Matlab simulations were run considering the same chip spacing as for GEMS, and similar tracking biases were observed.

FIGURE 8. GEMS code-phase measurements on GPS L1 C/A signal, EWFB dynamic scenario.

FIGURE 9 shows the ACF produced by GEMS. During the first minute, the ACF looks like a filtered L1 C/A correlation function. Afterward, undulations distort the correlation peak.

FIGURE 9. GEMS ACF computation on GPS L1 C/A signal, EWFB dynamic scenario.

Again, additional analysis has been conducted with Matlab, using a GPS signal acquisition and tracking routine. A 40-second accumulation enabled comparison of the faulty and fault-free code chips. FIGURE 10 shows that the faulty code chips are affected by undulations with a period of 244 nanoseconds, which is consistent with the 4 MHz resonance frequency. This temporal signal was then used to compute the spectrum, as shown in FIGURE 11. The figure shows well that the faulty L1 C/A spectrum (red) secondary lobes are raised up around the EWFB resonance frequency, compared to the fault-free L1 C/A spectrum (blue).

FIGURE 10. Fault-free vs EWFB GPS L1 C/A signal.

FIGURE 11. Fault-free vs EWFB GPS L1 C/A signal power spectrum density.

Galileo E1 CBOC(6, 1, 1/11). In the second part of the experiments, Navys was configured to generate the Galileo E1 Open Service (OS) signal instead of the GPS L1 C/A signal. The goal was to assess the impact of EWs on such a modernized signal.

EWFA, static scenario. First, the same Galileo E1 BC signal was generated using two different Navys channels. One was affected by EWFA, and the other was not. The spectra of the obtained signals were observed using a spectrum analyzer. The spectrum of the signal produced by the fault-free channel shows the BOC(1,1) main lobes, around 1 MHz, and the weaker BOC(6,1) main lobes, around 6 MHz. The power spectrum of the signal produced by the EWFA channel has a lag of 5 samples at 120 times f₀ (40 nanoseconds). Again, spikes appear at intervals of f₀, which is consistent with theory. The signal produced by the same channel, but with a lag set to 21 samples (171.07 nanoseconds) was also seen. Such a lag should not be experienced on CBOC(6,1,1/11) signals as this lag is longer than the BOC(6,1) subcarrier half period (81 nanoseconds). This explains the fact that the BOC(6,1) lobes do not appear anymore in the spectrum.

EWFB, static scenario. The same experiments as for EWFA were conducted for EWFB. Fault-free and faulty (EWFB with a resonance frequency of 8 MHz and a damping factor of 7 MHz) signals were simultaneously generated and observed using the spectrum analyzer. The spectrum distortion induced by the EWFB at the E1 frequency was evident. The spectrum is amplified around 8 MHz, which is consistent with the applied failure.

EWFA, dynamic scenario. The same scenario as for the GPS L1 C/A signal was run with the Galileo E1 signal: first, for a period of one minute, a fault-free signal was generated, followed by a period of one minute with the faulty signal. GEMS was switched on and acquired and tracked the two-minute-long signal. Its code-phase measurements, shown in FIGURE 12, reveal a tracking bias of 6.2 meters. This is consistent with theory, where the set lag is equal to 40 nanoseconds (12.0 meters). GEMS-produced ACFs show the distortion of the correlation function in FIGURE 13. The distortion is hard to observe because the applied lag is small.

FIGURE 12. GEMS code-phase measurements on Galileo E1 pilot signal, EWFA dynamic scenario.

FIGURE 13. GEMS ACF computation on Galileo E1 pilot signal, EWFA dynamic scenario.

A modified version of the GPS signal acquisition and tracking Matlab routine was used to acquire and track the Galileo signal. It was configured to accumulate 50 seconds of fault-free signal and 50 seconds of a faulty signal. This operation enables seeing the signal in the time domain, as in FIGURE 14. Accordingly, the following observations can be made:

The E1 BC CBOC(6,1,1/11) signal is easily recognized from the blue curve (fault-free signal).
The EWFA effect is also seen on the BOC(1,1) and BOC(6,1) parts. The observed lag is consistent with the scenario (five samples at 120 times f₀ ≈ 0.04 chips).
The lower part of the BOC(6,1) seems absent from the red signal. Indeed, the application of the distortion divided the duration of these lower parts by a factor of two, and so multiplied their Fourier representation by two. Therefore, the corresponding main lobes should be located around 12 MHz. At the receiver level, the digitization is being performed at 25 MHz; this signal is close to the Shannon frequency and is therefore filtered by the anti-aliasing filter.

FIGURE 14. Fault-free vs EWFA Galileo E1 signal.

The power spectrum densities of the obtained signals were then computed. FIGURE 15 shows the CBOC(6,1,1/11) fault-free signal in blue and the faulty CBOC(6,1,1/11) signal, with the expected spikes separated by 1.023 MHz.

FIGURE 15. Fault-free vs. EWFA Galileo E1 signal power spectrum density.

It is noteworthy that the EWFA has been applied to the entire E1 OS signal, which is B (data component) minus C (pilot component). EWFA could also affect exclusively the data or the pilot channel. Although such an experiment was not conducted during our research, Navys is capable of generating EWFA on the data component, the pilot component, or both.

EWFB, dynamic scenario. In this scenario, after one minute of a fault-free signal, an EWFB, with a resonance frequency of 4 MHz and a damping factor of 2 MHz, was activated. The GEMS code-phase measurements presented in FIGURE 16 show that the EWFB induces a tracking bias of 2.8 meters. As for GPS L1 C/A signals, it is to be noticed that the bias induced by EWFB depends upon the receiver characteristics and more particularly the chip spacing used for tracking.

FIGURE 16. GEMS code-phase measurements on Galileo E1 pilot signal, EWFB dynamic scenario.

The GEMS produced ACFs are represented in FIGURE 17. After one minute, the characteristic EWFB undulations appear on the ACF.

FIGURE 17. GEMS ACF computation on Galileo E1 pilot signal, EWFB dynamic scenario.

In this case, signal accumulation was also performed to observe the impact of EWFB on Galileo E1 BC signals. The corresponding representation in the time domain is provided in FIGURE 18, while the Fourier domain representation is provided in FIGURE 19. From both points of view, the application of EWFB is compliant with theoretical models. The undulations observed on the signal are coherent with the resonance frequency (0.25 MHz ≈ 0.25 chips), and the spectrum also shows the undulations (the red spectrum is raised up around 4 MHz).

FIGURE 18. Fault-free vs EWFB Galileo E1 signal.

FIGURE 19. Fault-free vs. EWFB Galileo E1 signal power spectrum density.

Conclusion

Navys is a multi-constellation GNSS simulator, which allows the generation of all modeled EWF (types A and B) on both GPS and Galileo signals. Indeed, the Navys design makes the EWF application independent of the signal modulation and carrier frequency.

The International Civil Aviation Organization model has been adapted to Galileo signals, and the correct application of the failure modes has been verified through RF simulations. The theoretical effects of EWF types A and B on waveforms, spectra, autocorrelation functions and code-phase measurements have been confirmed through these simulations.

For a given lag value, the tracking biases induced by type A EWF distortions are equal on GPS and Galileo signals, which is consistent with theory.

Eventually, for a given resonance frequency-damping factor combination, the type B EWF distortions induce a tracking bias of about 5.2 meters on GPS L1 C/A measurements and only 2.8 meters on Galileo E1 C measurements. This is mainly due to the fact that the correlator tracking spacing was reduced for Galileo signal tracking (± 0.15 chips instead of ± 0.5 chips). (Additional figures showing oscilloscope and spectrum analyzer screenshots of experimental results are available in the online version of this article.)

Acknowledgments

This article is based on the paper “Generating Evil WaveForms on Galileo Signals using NAVYS” presented at the 6th ESA Workshop on Satellite Navigation Technologies and the European Workshop on GNSS Signals and Signal Processing, Navitec 2012, held in Noordwijk, The Netherlands, December 5–7, 2012.

Manufacturers

In addition to the Navys simulator, the experiments used a Saphyrion sagl GDAS-1 GNSS data acquisition system, a Rohde & Schwarz GmbH & Co. KG RTO1004 digital oscilloscope, and a Rohde & Schwarz FSW26 signal and spectrum analyzer.

MATHIEU RAIMONDI is currently a GNSS systems engineer at Thales Alenia Space France (TAS-F). He received a Ph.D. in signal processing from the University of Toulouse (France) in 2008.

ERIC SENANT is a senior navigation engineer at TAS-F. He graduated from the Ecole Nationale d’Aviation Civile (ENAC), Toulouse, in 1997.

CHARLES FERNET is the technical manager of GNSS system studies in the transmission, payload and receiver group of the navigation engineering department of the TAS-F navigation business unit. He graduated from ENAC in 2000.

RAPHAEL PONS is currently a GNSS systems engineering consultant at Thales Services in France. He graduated as an electronics engineer in 2012 from ENAC.

HANAA AL BITAR is currently a GNSS systems engineer at TAS-F. She graduated as a telecommunications and networks engineer from the Lebanese Engineering School of Beirut in 2002 and received her Ph.D. in radionavigation in 2007 from ENAC, in the field of GNSS receivers.

FRANCISCO AMARILLO FERNANDEZ received his Master’s degree in telecommunication engineering from the Polytechnic University of Madrid. In 2001, he joined the European Space Agency’s technical directorate, and since then he has worked for the Galileo program and leads numerous research activities in the field of GNSS evolution.

MARC WEYER is currently working as the product manager in ELTA, Toulouse, for the GNSS simulator and recorder.

Additional Images

GEMS graphical interface.

Observation of EWF type A on GPS L1 C/A signal with an oscilloscope.

Impact of EWF A on GPS L1 C/A signal spectrum for 0 (green), 41 (black), and 171 (blue) nanosecond lag.

Observation of EWF type A on GPS L1 C/A signal with an oscilloscope.

Impact of EWF B on GPS L1 C/A signal spectrum for fd = 8 MHz and σ = 7 MHz.

Impact of EWF A on Galileo E1 BC signal spectrum for 0 (green), 40 (black), and 171 (blue) nanosecond lag.

Navys hardware equipment – Blackline edition.

Innovation: Interfacing Clearly: A New Approach to the Design and Development of Global Navigation Satellite Systems

GPS World staff — Mon, 01 Apr 2013 09:38:20 +0000

By Daniele Gianni, Marco Lisi, Pierluigi De Simone, Andrea D’Ambrogio, and Michele Luglio

INNOVATION INSIGHTS with Richard Langley

MY FIRST DEGREE is in applied physics from the University of Waterloo. Founded in 1957, Waterloo was one of the first universities to introduce co-operative education. Co-operative education (or “co-op” as it is commonly known) is a program that uses both classroom study and temporary jobs to provide students with practical experience. Applied Physics was a co-op program and I worked in both industry and research environments including stints at Philips Electronics and the Atomic Energy of Canada Limited’s Chalk River Laboratories.

Both on campus and on the job, I met fellow co-op students from a variety of disciplines including mathematics (computer science) and various branches of engineering. One of those was systems design engineering or systems engineering for short. At that time, I really didn’t know much about systems engineering except that it was an all-encompassing branch of engineering and the most challenging of all of the engineering programs at Waterloo — at least according to the students in the program.

Systems engineering is an interdisciplinary field of engineering focusing on the design and management of complex engineering projects. According to the International Council on Systems Engineering, systems engineers establish processes “to ensure that the customer and stakeholder’s needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system’s entire life cycle. This process is usually comprised of the following seven tasks: State the problem, Investigate alternatives, Model the system, Integrate, Launch the system, Assess performance, and Re-evaluate [or, SIMILAR, for short].”

Central to the systems engineering process and the end-product design is the generation of models. Many types of system models are used, including physical analogs, analytical equations, state machines, block diagrams, functional flow diagrams, object-oriented models, computer simulations, and even mental models. (If you want to learn a bit about mental and other kinds of models, including how to fix radios by thinking, you could do no better than to look at some of Richard Feynman’s writings including the eminently readable “Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character.)

As aids to the modeling process, systems engineers have developed specialized modeling languages including the Unified Modeling Language (UML) and the Systems Modeling Language (SysML). These are graphical-based languages that can be used to express information or knowledge about systems in a structure that is defined by a consistent set of rules. Both UML and SysML are widely used in systems engineering. However, both are limited when it comes to representing the signal-in-space (SIS) interfaces for global navigation satellite systems.

In this month’s column, a team of authors affiliated with the Galileo project discusses the Interface Communication Modeling Language, an extension of UML that allows engineers to clearly represent SIS interfaces, critical for the design of GNSS receivers.

“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. He welcomes comments and topic ideas. To contact him, see the “Contributing Editors” section on page 4.

In this article, we present the results of ongoing research on the use of a modeling language, namely Interface Communication Modeling Language (ICML), for signal-in-space (SIS) interface specification of global navigation satellite systems (GNSS). Specifications based on modeling languages (also known as model-based specifications) have proven to offer a wide range of benefits to systems engineering activities, for supporting system interoperability, reducing design risk, automating software development, and so on. We argue that similar benefits can be obtained for satellite navigation systems and receivers, if a model-based approach is used for defining and expressing the SIS interface specification. In particular, we outline how a model-based SIS interface specification can support the identification of solutions to two key issues: GNSS interoperability and the design of GNSS receivers, particularly Galileo receivers. Both issues are becoming increasingly central to the Galileo program since it entered the In-Orbit-Validation (IOV) phase and is steadily approaching the 2014 milestone, when the first early services — the Open Service (OS) and the Search and Rescue Service — will be provided to users.

GNSS interoperability concerns the integration of different GNSS with the purpose of being used together, along with regional positioning systems, to provide a seamless navigation capability and improved services in terms of availability, continuity, accuracy, and integrity, for example. GNSS interoperability should be addressed in terms of intra-GNSS interoperability and GNSS-receiver interoperability. The intra-GNSS interoperability concerns the data exchanged among the GNSS, including coordination to guarantee data coherence and consistency over time. For example, GNSS may need to share terrestrial reference frames and constantly synchronize their global time references. On the other hand, GNSS-receiver interoperability concerns the capability of the receiver to use independent GNSS signals for the computation of positions globally. This capability implicitly requires that the receiver computations are decoupled from the SIS interface of any particular GNSS. A key condition to achieve this decoupling is that the SIS interface specification is available in a consistent, unambiguous, and possibly standard format, which can support engineers to more effectively design interoperable receivers. A model-based SIS interface specification would considerably facilitate this as it enables designers to use the processing capabilities of a computer system for the verification of the specification consistency and completeness, for example. Moreover, a model-based SIS interface specification would ease the visual and electronic inspection of the data messages, therefore facilitating the automatic identification of different data representations for the same orbital and temporal parameters.

The design of GNSS receivers, and particularly those for Galileo, is increasingly of interest, and a model-based SIS interface specification can similarly support the definition of future solutions. For Galileo, specifically, the receiver design is critical to support the marketing strategies that are promoting the use of Galileo services. Key issues underlying any marketing strategy concern the Galileo receiver market appealing from a cost-to-performance ratio point of view. As Galileo receivers may require new design and adaptation of existing software (SW) or hardware (HW), as well as new production chains, higher costs — in particular non-recurring ones — are likely to occur for the production of the Galileo receivers with respect to the well-established GPS receivers. As a consequence, limitations may be experienced in market penetration and in the growth velocity of Galileo receivers’ share of the receiver market. In turn, this may hinder the estimated economic return for the Galileo project.

Preventing and counteracting this possibility is therefore a critical issue if we aim to achieve the widest possible success of the Galileo project. Market barriers inherently originate from the following needs:

Designing new SW and HW solutions for Galileo receivers;
Reusing existing SW and HW for GPS receivers;
Converting existing production chains to the new Galileo-specific SW and HW solutions.

GNSS receivers often use established mathematical models that can determine the receiver position from a fundamental set of parameters, such as satellite orbit and system time. As a consequence, the intrinsic representation of the parameter set is a major factor in the adaptation of the existing design and implementation of SW and HW solutions.

To reduce the impact of the above needs, a model-based SIS interface specification may play a pivotal role in several ways, such as:

reducing ambiguities in the Galileo SIS interface specification;
enhancing the communication with the involved stakeholders;
linking the SIS interface specification to the design schemas of GNSS receivers — particularly Galileo ones — for tracing the interface elements onto the receiver functional and physical schema, thereby supporting the reuse and adaptation of existing HW and SW solutions;
supporting the model-based design of security solutions for blocking, jamming, and spoofing.

Galileo Project

In October 2012, the final two IOV satellites were launched into orbit, completing the designed configuration for the Galileo IOV phase — the initial stage of the Galileo constellation development. In this phase, preliminary validation tests will be performed and the initial navigation message will be broadcast to the Galileo ground segment for further validation. Shortly after the conclusion of this phase, a series of launches will take place to gradually deploy the remaining 26 satellites that will form the Galileo Full Operational Capability (FOC) configuration. Currently, the Galileo Early Open Service (EOS) is expected to be available by the end of 2014. The EOS will provide ranging capabilities and will enable receiver manufacturers to begin to design and test their technological solutions for Galileo receivers and Galileo overlay services, such as search and rescue.

In the meantime, the European GNSS Agency has been established and assigned the governance of the Galileo sub-systems, including activities such as:

initiating and monitoring the implementation of security procedures and performing system security audits;
system infrastructure management, maintenance, improvement, certification, and standardization, and service provision;
development and deployment of activities for the evolution and future generations of the systems, including procurement activities;
contributing to the exploitation of the systems, including the marketing and promotion of applications and services, including market analysis.

With the now-rapid development of the Galileo project, it becomes increasingly important to support the receiver manufacturers in the design and implementation of global navigation solutions based on the Galileo services. This is necessary to guarantee the widespread use of the Galileo services, particularly in an increasingly crowded GNSS panorama.

Model-Based Systems Engineering

Model-based systems engineering (MBSE) is predicated on the notion that a system is developed by use of a set of system models that evolve throughout the development lifecycle, from abstract models at the early stages down to the operational system. A visual presentation is provided by FIGURE 1, which shows the roles of MBSE approaches within the systems engineering V-shaped process. Specifically, the MBSE approaches enable the designer to effectively trace the requirements and design alternatives on the descending branch of the “V.” For the same characteristics, MBSE facilitates the verification through a model repository that interconnects not only the design products, but also the stakeholders involved in the entire process. In addition, MBSE approaches support the automatic generation of the documentation and of other artifacts, particularly software. All of these capabilities eventually enable the validation of the implementation activities on the ascending branch of the V-process. Also, in this case, MBSE and the model repository play a major role in connecting design to implementation, and users and designers to developers.

FIGURE 1. Systems engineering V-process supported by an model-based systems engineering with model repository (courtesy of the INCOSE Survey).

Main Concepts. MBSE approaches are gaining increasing popularity with the widespread adoption of standard modeling languages, such as Unified Modeling Language (UML) and Systems Modeling Language (SysML).

UML is a formally defined general-purpose graphical language and is mainly used in the context of software systems development. It has been developed and is being managed by the Object Management Group and is the core standard of the Model Driven Architecture (MDA) effort, which provides a set of standards to shift from code-centric to model-driven software development. By use of an MDA-based approach, a software system is built by specifying and executing a set of automated model transformations.

SysML is defined as an extension of UML and provides a general-purpose modeling language for systems engineering applications (See FIGURE 2). SysML supports MBSE approaches in the development of complex systems that include hardware, software, information, processes, personnel, and facilities.

FIGURE 2. UML-SysML relationships. (UML 2 is the second generation version of UML introduced in 2005.)

Advantages. With respect to the conventional document-based approaches, MBSE approaches present the following advantages:

Conformance to standard specifications and availability of development tools;
Increased level of automation due to the formal specification and execution of model transformations that take as input a model at a given level of abstraction and yield as output a refined model at a lower level of abstraction;
Better understanding of the system in its operational context;
Support for simulation activities at different levels of detail and at different development stages, from concept exploration to dynamic system optimization;
Support for the coherent extension of standard modeling languages to adapt them to a specific target or domain.

These capabilities have motivated and have been sustaining an increasing trend of moving from document-centric to model-centric systems engineering.

ICML Language

UML and SysML are widely used languages for MBSE. A plethora of tools and technologies are available to compose models, transform models into documents, derive software products from models, and share and reuse models by means of repositories. However, neither of these languages offers capabilities for the representation of SIS interfaces, which are the critical interfaces for the design of Galileo receivers. For this reason, we have introduced ICML: a modeling language that can enable a full MBSE approach for the design of Galileo receivers. Moreover, ICML extends UML, and therefore it can integrate with system specifications based on compliant technologies as well as be used within standard tools.

Layout of Interface Specification. The typical layout of ICML-based interface specification is shown in FIGURE 3. The specification covers the definition of both the message structure and conversion processes. The message structure consists of five abstraction levels, and describes how the data is structured within the message. The conversion processes describe how the data values are transformed between adjacent levels of the message specification.

FIGURE 3. Layout of ICML-based interface specifications.

The message structure is defined at five levels: Data Definition, (Logical) Binary Coding, Logical Binary Structure, Physical Binary Coding, and Physical Signal, each covering specific aspects of the SIS interface specification.

For example, the Data Definition level covers the specification of the logical data structure, which includes the data items composing the message information. A data item is either of application or control type. An application data item represents a domain-specific concept that conveys the information expected by the message recipient. On the other hand, a control data item represents a domain-independent concept that can support the correctness and integrity verification of the associated application data items. A data item can also be associated with semantic and pragmatic definitions. The former specifies the meaning of the data item and the latter specifies the contextual interpretation for the semantic definition.

Analogously, the Binary Coding level covers the specification of the binary coding for each of the data items defined at the above level. For a data item, the binary coding is represented as a binary sequence and it includes at least a sequence identifier, the semantic definition, and the pragmatic definitions. Similarly to the above level, the semantic and pragmatic definitions enrich the interface specification, conveying an accurate representation of the binary coding.

The conversion processes describe the activities to be performed for deriving message values between adjacent levels of the above structural specification. As shown in Figure 3, eight processes should be defined to specify all the conversions between adjacent levels. For example, the DataDefinition2BinaryCoding process defines the activities to be performed for the derivation of the logical binary sequences representing data values. Similarly, the LogicalBinary2PhysicalBinary process defines the activities for the implementation of convolution or encryption algorithms on the logical binary sequence. However, these processes do not always need to be explicitly defined. In particular, if the implementation of a process is trivial or standard, a textual note referring to an external document may suffice for the specification purposes.

The first prototypal version of ICML has been implemented and can be used within the open source TopCased tool. The prototypal version is available under the GNU General Public License (GPL) v3.0 from the ICML project website. We applied the profile and developed the example ICML-based specification given below.

Galileo-Like Specification. An ICML-based specification of a Galileo-like OS interface, concerning only the above-defined level 3, would display as shown in FIGURE 4. This figure specifically details a part of a reduced F/NAV (the freely accessible navigation message provided by the E5a signal for the Galileo OS) structure consisting of one data frame made up of two F/NAV subframes.

FIGURE 4. Example of ICML-based specification of an F/NAV-like message structure at the Logical Binary Coding level.

Benefits. ICML can bring the above-mentioned MBSE benefits to support GNSS interoperability and to GNSS and Galileo receiver design. For example, ICML can:

provide a reference guideline for structuring the specification data and thus facilitating the communication between the Galileo SIS designers and the receiver producers;
ease visual inspection of the specification for verification purposes and for the identification of data incompatibilities of two GNSS systems;
convey the data semantics as well as the measurement units, to guarantee that the binary data from different GNSS are correctly decoded and interpreted;
support syntactical model validation using existing tools;
provide support for future advance exploitation by means of a machine-readable data format.

In particular, the availability of a machine-readable format is also the basis for advanced use cases that can exploit the capabilities of modern computer technologies.

Advanced Future Use Cases. In line with the above-mentioned MBSE model exploitations, we foresee a number of possible exploitation cases:

Automatic generation of the interface specification documents;
Collaborative development of the interface specification;
Automatic completeness and consistency checking of the interface specification;
Integration of SIS specifications with model-driven simulation engineering approaches for the simulation of single- and multi-GNSS receivers;
Integration of SIS specifications with receiver design models in SysML, for requirements traceability and reuse of existing GNSS solutions.

The automatic generation of interface specification documents can be an important capability during the lifecycle of a specification. For example, the specification may be updated several times during the interface design, and the textual documentation may need to be produced several times. Using a model-based approach, it is possible to automate the error-prone activities related to the document writing as well as other important functions such as specification versioning.

Complex system specifications are often the product of collaborating teams, which may occasionally be geographically dispersed. Using a model-based approach, the interface specification can be stored within a version control system that can be concurrently accessed by team members.

Completeness and consistency checking is also a manual activity, which demands a high degree of mental attention, and it is consequently highly error prone. Once the specification is available in a machine-readable format, the checking can be easily automated by specifying the verification rules that the interface model must satisfy.

Existing technologies support the simulation of single- and multi-GNSS receivers. As the SIS specification has a major impact on the internal structure of the receiver, the interface specification is a key input for developing GNSS simulators as well as for determining the boundary properties of the input signal into the receiver, including the admitted analog signal and the format of the digital data.

Moreover, the model-based interface specification can be integrated with a receiver design schema in SysML. This would be important to provide traceability between the interface requirements and the receiver’s functional and physical components. In the following section, we provide an outline for a preliminary integration between the interface specification and the receiver design.

Designing Galileo Receivers

Model-based interface specifications can support the design of Galileo receivers in several ways. For example, a specification can provide a link between Galileo requirements down to the Galileo receiver specifications, as shown in FIGURE 5.

FIGURE 5. Links between ICML and SysML specifications.

This capability may be useful in several scenarios. In particular, we have identified three scenarios. Scenario 1 consists of the identification of the receiver requirements that are introduced or modified by the Galileo OS SIS, with respect to existing GPS receivers. Scenario 2 concerns the linking between the ICML specification and the receiver functional schema to identify how a Galileo receiver will differ from existing GPS solutions. Scenario 3 is a development of Scenario 1 and Scenario 2, in which the physical schema definition and the physical components identification (HW and SW) may further exploit the ICML-based approach for supporting the reuse of existing GPS components.

Below, we detail Scenario 2, introducing a simplified receiver functional schema in SysML and linking the above ICML example to the schema.

Example Functional Schema. In this section, we illustrate a preliminary SysML representation for a simplified GNSS receiver. However, the figures are meant for exemplification purposes only and are not to be considered fully realistic and detailed for real GNSS receivers. Nevertheless, the SysML hierarchical modeling capabilities can be used to further refine the model, up to a potentially infinitesimal level of detail.

A GNSS receiver functional schema has been derived from A Software-Defined GPS and Galileo Receiver: A Single-Frequency Approach (see Further Reading) and its equivalent SysML internal block diagram (IBD) is shown in FIGURE 6.

FIGURE 6. High-level receiver internal block diagram (functional schema).

In particular, the IBD illustrates the functional blocks (instances and types) and connections among these blocks that define the GNSS receiver. In particular, each of these block types is also described in other diagrams, in which the designers can specify the operations performed by the block, the attributes of the block, the referred properties, and the defined values, for example.

In this short article, we have particularly focused on the navigation data decoder. The data decoder is defined by a Block Definition Diagram (BDD) and an IBD, which are shown in FIGURES 7 and 8, respectively.

FIGURE 7. Navigation data decoder block definition diagram.

FIGURE 8. Navigation data decoder internal block diagram.

In particular, the BDD indicates that the navigation data decoder is composed of four types of blocks: shift buffer, parity checker, binary adder, and data item retriever. The shift buffer receives the incoming physical sequence of bits, which is subsequently verified by the parity checker. The verified sequence is then processed to retrieve the standard binary format from the SIS-specific logical coding for the data item. This function is guided by the data item retriever, which stores the defined properties of each incoming data item, in the form of a physical sequence of bits (level 1). As a consequence, the navigation data decoder is involved with data defined at several of the above-defined ICML levels. From this description, it is also possible to sketch the preliminary IBD diagram of Figure 8.

Using a model-based approach, it becomes easier to establish links between interface elements and the functional blocks in the receiver schema.

Moreover, these links can also be decorated with a number of properties that can be used to further describe the type of the relationship between the interface element and the functional block. The link identification is important to the receiver design in several ways. For example, linking the interface elements to the receiver functional blocks, it becomes easier to identify which functional blocks are affected by each element of the SIS interface. Moreover, the tracing can be transitively extended to the physical schema, enabling the receiver designers to more immediately identify which physical components can be reused and which ones must be replaced in existing GNSS solutions.

We exemplify the tracing of interface elements on the above data decoding functional schema in FIGURE 9. This figure shows the navigation data decoder’s BDD in conjunction with ICML level 3 elements (with a white background). As in Figure 7, the relationships are drawn in red, including a richer set of relationship qualifiers. For example, the <> qualifier indicates that the originating block uses the data specified in the connected ICML element. Similarly, the <> qualifier indicates that the originating block takes in input instances of the ICML element. ICML level 4 elements are also relevant to this BDD; however, they are not shown for the sake of conciseness.

FIGURE 9. Linking level 3 elements to the navigation data decoder block definition.

Conclusions

Galileo receivers may face market barriers that are inherently raised by the costs linked with the introduction of new technologies with respect to the existing GPS ones. In this article, we have advocated that a model-based SIS interface specification can help mitigate possible extra costs in several ways. For example, the model-based interface specification can ease the communication among stakeholders, promote the reuse and adaptation of existing GPS software and chipsets, and support the implementation of receiver-side multi-GNSS interoperability. With the objective of supporting model-based interface specifications, we have designed ICML, which has been provided with a UML profile implementation in an open-source modeling tool. We have also shown an excerpt of a possible model-based specification for a simplified Galileo OS interface. Moreover, we have outlined how the model-based specification can integrate with SysML models of GNSS receivers and support the reuse and adaptation of existing solutions. A preliminary identification of potential exploitations and further benefits is also included. Further research is ongoing to generalize the existing ICML language to more complex types of SIS interfaces.

Acknowledgments

The authors would like to thank the students Serena Annarilli and Carlo Di Bartolomei (University of Rome Tor Vergata) for implementing the first prototype version of the ICML profile. The authors would also like to thank Marco Porretta, European Space Agency (ESA) / European Space Research and Technology Centre (ESTEC), for the suggestions of the GNSS example. The ICML project has been partially sponsored by the ESA Summer of Code in Space Initiative, edition 2012. No endorsement is made for the use of ICML for the official Galileo SIS interface specification.

DANIELE GIANNI is currently a requirement engineering consultant at EUMETSAT in Germany. EUMETSAT is the European operational satellite agency for monitoring weather, climate and the environment. Gianni received a Ph.D. in computer and control engineering from University of Rome Tor Vergata (Italy), in the field of modeling and simulation, in 2007. He has previously held research appointments at ESA, Imperial College, and Oxford University.

MARCO LISI is currently GNSS services engineering manager at ESA’s Directorate of Galileo Programme and Navigation- Related Activities at ESTEC in Noordwijk, The Netherlands. He was previously responsible for system engineering, operations, and security activities in the Galileo project. He is also a special advisor to the European Commission on European space policies. Lisi has over thirty years of working experience in the aerospace and telecommunication sectors, holding management positions in R&D, and being directly involved in a number of major satellite programs, including Artemis, Meteosat Operational, Meteosat Second Generation, Globalstar, Cosmo-Skymed, and more recently Galileo.

PIERLUIGI DE SIMONE is currently working on system assembly, integration, and verification for the Galileo mission in ESA. He has worked on many software developments in the fields of graphics, safe mode software, and visual programming. He has worked on many space missions including Helios, Meteosat, Metop, Cosmo-Skymed, and Galileo. His main interests are in modeling paradigms and cryptography and he holds a master’s degree in physics from University of Rome Tor Vergata.

ANDREA D’AMBROGIO is associate professor of computer science at the University of Rome Tor Vergata. He has formerly been a research associate at the Concurrent Engineering Research Center of West Virginia University in Morgantown, West Virginia. His research interests are in the areas of engineering and validation of system performance and dependability, model-driven systems and software engineering, and distributed simulation.

MICHELE LUGLIO is associate professor of telecommunication at University of Rome Tor Vergata. He works on designing satellite systems for multimedia services both mobile and fixed. He received the Ph.D. degree in telecommunications in 1994.

Innovation: A Better Way: Monitoring the Ionosphere with Integer-Leveled GPS Measurements

Richard Langley — Fri, 01 Mar 2013 00:43:51 +0000

By Simon Banville, Wei Zhang, and Richard B. Langley

INNOVATION INSIGHTS with Richard Langley

IT’S NOT JUST FOR POSITIONING, NAVIGATION, AND TIMING. Many people do not realize that GPS is being used in a variety of ways in addition to those of its primary mandate, which is to provide accurate position, velocity, and time information.

The radio signals from the GPS satellites must traverse the Earth’s atmosphere on their way to receivers on or near the Earth’s surface. The signals interact with the atoms, molecules, and charged particles that make up the atmosphere, and the process slightly modifies the signals. It is these modified or perturbed signals that a receiver actually processes. And should a signal be reflected or diffracted by some object in the vicinity of the receiver’s antenna, the signal is further perturbed — a phenomenon we call multipath.

Now, these perturbations are a bit of a nuisance for conventional users of GPS. The atmospheric effects, if uncorrected, reduce the accuracy of the positions, velocities, and time information derived from the signals. However, GPS receivers have correction algorithms in their microprocessor firmware that attempt to correct for the effects. Multipath, on the other hand, is difficult to model although the use of sophisticated antennas and advanced receiver technologies can minimize its effect.

But there are some GPS users who welcome the multipath or atmospheric effects in the signals. By analyzing the fluctuations in signal-to-noise-ratio due to multipath, the characteristics of the reflector can be deduced. If the reflector is the ground, then the amount of moisture in the soil can be measured. And, in wintery climes, changes in snow depth can be tracked from the multipath in GPS signals.

The atmospheric effects perturbing GPS signals can be separated into those that are generated in the lower part of the atmosphere, mostly in the troposphere, and those generated in the upper, ionized part of the atmosphere — the ionosphere. Meteorologists are able to extract information on water vapor content in the troposphere and stratosphere from the measurements made by GPS receivers and regularly use the data from networks of ground-based continuously operating receivers and those operating on some Earth-orbiting satellites to improve weather forecasts.

And, thanks to its dispersive nature, the ionosphere can be studied by suitably combining the measurements made on the two legacy frequencies transmitted by all GPS satellites. Ground-based receiver networks can be used to map the electron content of the ionosphere, while Earth-orbiting receivers can profile electron density. Even small variations in the distribution of ionospheric electrons caused by earthquakes; tsunamis; and volcanic, meteorite, and nuclear explosions can be detected using GPS.

In this month’s column, I am joined by two of my graduate students, who report on an advance in the signal processing procedure for better monitoring of the ionosphere, potentially allowing scientists to get an even better handle on what’s going on above our heads.

Representation and forecast of the electron content within the ionosphere is now routinely accomplished using GPS measurements. The global distribution of permanent ground-based GPS tracking stations can effectively monitor the evolution of electron structures within the ionosphere, serving a multitude of purposes including satellite-based communication and navigation.

It has been recognized early on that GPS measurements could provide an accurate estimate of the total electron content (TEC) along a satellite-receiver path. However, because of their inherent nature, phase observations are biased by an unknown integer number of cycles and do not provide an absolute value of TEC. Code measurements (pseudoranges), although they are not ambiguous, also contain frequency-dependent biases, which again prevent a direct determination of TEC. The main advantage of code over phase is that the biases are satellite- and receiver-dependent, rather than arc-dependent. For this reason, the GPS community initially adopted, as a common practice, fitting the accurate TEC variation provided by phase measurements to the noisy code measurements, therefore removing the arc-dependent biases. Several variations of this process were developed over the years, such as phase leveling, code smoothing, and weighted carrier-phase leveling (see Further Reading for background literature).

The main challenge at this point is to separate the code inter-frequency biases (IFBs) from the line-of-sight TEC. Since both terms are linearly dependent, a mathematical representation of the TEC is usually required to obtain an estimate of each quantity. Misspecifications in the model and mapping functions were found to contribute significantly to errors in the IFB estimation, suggesting that this process would be better performed during nighttime when few ionospheric gradients are present. IFB estimation has been an ongoing research topic for the past two decades are still remains an issue for accurate TEC determination.

A particular concern with IFBs is the common assumption regarding their stability. It is often assumed that receiver IFBs are constant during the course of a day and that satellite IFBs are constant for a duration of a month or more. Studies have clearly demonstrated that intra-day variations of receiver instrumental biases exist, which could possibly be related to temperature effects. This assumption was shown to possibly introduce errors exceeding 5 TEC units (TECU) in the leveling process, where 1 TECU corresponds to 0.162 meters of code delay or carrier advance at the GPS L1 frequency (1575.42 MHz).

To overcome this limitation, one could look into using solely phase measurements in the TEC estimation process, and explicitly deal with the arc-dependent ambiguities. The main advantage of such a strategy is to avoid code-induced errors, but a larger number of parameters needs to be estimated, thereby weakening the strength of the adjustment. A comparison of the phase-only (arc-dependent) and phase-leveled (satellite-dependent) models showed that no model performs consistently better. It was found that the satellite-dependent model performs better at low-latitudes since the additional ambiguity parameters in the arc-dependent model can absorb some ionospheric features (such as gradients). On the other hand, when the mathematical representation of the ionosphere is realistic, the leveling errors may more significantly impact the accuracy of the approach.

The advent of precise point positioning (PPP) opened the door to new possibilities for slant TEC (STEC) determination. Indeed, PPP can be used to estimate undifferenced carrier-phase ambiguity parameters on L1 and L2, which can then be used to remove the ambiguous characteristics of the carrier-phase observations. To obtain undifferenced ambiguities free from ionospheric effects, researchers have either used the widelane/ionosphere-free (IF) combinations, or the Group and Phase Ionospheric Calibration (GRAPHIC) combinations. One critical problem with such approaches is that code biases propagate into the estimated ambiguity parameters. Therefore, the resulting TEC estimates are still biased by unknown quantities, and might suffer from the unstable datum provided by the IFBs.

The recent emergence of ambiguity resolution in PPP presented sophisticated means of handling instrumental biases to estimate integer ambiguity parameters. One such technique is the decoupled-clock method, which considers different clock parameters for the carrier-phase and code measurements. In this article, we present an “integer-leveling” method, based on the decoupled-clock model, which uses integer carrier-phase ambiguities obtained through PPP to level the carrier-phase observations.

Standard Leveling Procedure

This section briefly reviews the basic GPS functional model, as well as the observables usually used in ionospheric studies. A common leveling procedure is also presented, since it will serve as a basis for assessing the performance of our new method.

Ionospheric Observables. The standard GPS functional model of dual-frequency carrier-phase and code observations can be expressed as:

(1)

(2)

(3)

(4)

where Φ_i ^j is the carrier-phase measurement to satellite j on the L_i link and, similarly, P_i ^j is the code measurement on L_i. The term is the biased ionosphere-free range between the satellite and receiver, which can be decomposed as:

(5)

The instantaneous geometric range between the satellite and receiver antenna phase centers is ρ ^j. The receiver and satellite clock errors, respectively expressed as dT and dt^j, are expressed here in units of meters. The term T^j stands for the tropospheric delay, while the ionospheric delay on L1 is represented by I ^j and is scaled by the frequency-dependent constant μ for L2, where . The biased carrier-phase ambiguities are symbolized by and are scaled by their respective wavelengths (λⁱ). The ambiguities can be explicitly written as:

(6)

where N_i^j is the integer ambiguity, b_i is a receiver-dependent bias, and b_i^j is a satellite-dependent bias. Similarly, B_i and B_i^j are instrumental biases associated with code measurements. Finally, ε contains unmodeled quantities such as noise and multipath, specific to the observable. The overbar symbol indicates biased quantities.

In ionospheric studies, the geometry-free (GF) signal combinations are formed to virtually eliminate non-dispersive terms and thus provide a better handle on the quantity of interest:

(7)

(8)

where IFB_r and IFB ^j represent the code inter-frequency biases for the receiver and satellite, respectively. They are also commonly referred to as differential code biases (DCBs). Note that the noise terms (ε) are neglected in these equations for the sake of simplicity.

Weighted-Leveling Procedure. As pointed out in the introduction, the ionospheric observables of Equations (7) and (8) do not provide an absolute level of ionospheric delay due to instrumental biases contained in the measurements. Assuming that these biases do not vary significantly in time, the difference between the phase and code observations for a particular satellite pass should be a constant value (provided that no cycle slip occurred in the phase measurements). The leveling process consists of removing this constant from each geometry-free phase observation in a satellite-receiver arc:

(9)

where the summation is performed for all observations forming the arc. An elevation-angle-dependent weight (w) can also be applied to minimize the noise and multipath contribution for measurements made at low elevation angles. The double-bar symbol indicates leveled observations.

Integer-Leveling Procedure

The procedure of fitting a carrier-phase arc to code observations might introduce errors caused by code noise, multipath, or intra-day code-bias variations. Hence, developing a leveling approach that relies solely on carrier-phase observations is highly desirable. Such an approach is now possible with the recent developments in PPP, allowing for ambiguity resolution on undifferenced observations. This procedure has gained significant momentum in the past few years, with several organizations generating “integer clocks” or fractional offset corrections for recovering the integer nature of the undifferenced ambiguities. Among those organizations are, in alphabetical order, the Centre National d’Études Spatiale; GeoForschungsZentrum; GPS Solutions, Inc.; Jet Propulsion Laboratory; Natural Resources Canada (NRCan); and Trimble Navigation. With ongoing research to improve convergence time, it would be no surprise if PPP with ambiguity resolution would become the de facto methodology for processing data on a station-by-station basis. The results presented in this article are based on the products generated at NRCan, referred to as “decoupled clocks.”

The idea behind integer leveling is to introduce integer ambiguity parameters on L1 and L2, obtained through PPP processing, into the geometry-free linear combination of Equation (7). The resulting integer-leveled observations, in units of meters, can then be expressed as:
(10)
where and are the ambiguities obtained from the PPP solution, which should be, preferably, integer values. Since those ambiguities are obtained with respect to a somewhat arbitrary ambiguity datum, they do not allow instant recovery of an unbiased slant ionospheric delay. This fact was highlighted in Equation (10), which indicates that, even though the arc-dependency was removed from the geometry-free combination, there are still receiver- and satellite-dependent biases (b_r and b ^j, respectively) remaining in the integer-leveled observations. The latter are thus very similar in nature to the standard-leveled observations, in the sense that the biases b_r and b ^j replace the well-known IFBs. As a consequence, integer-leveled observations can be used with any existing software used for the generation of TEC maps. The motivation behind using integer-leveled observations is the mitigation of leveling errors, as explained in the next sections.

Slant TEC Evaluation

As a first step towards assessing the performance of integer-leveled observations, STEC values are derived on a station-by-station basis. The slant ionospheric delays are then compared for a pair of co-located receivers, as well as with global ionospheric maps (GIMs) produced by the International GNSS Service (IGS).

Leveling Error Analysis. Relative leveling errors between two co-located stations can be obtained by computing between-station differences of leveled observations:

(11)

where subscripts A and B identify the stations involved, and ε_l is the leveling error. Since the distance between stations is short (within 100 meters, say), the ionospheric delays will cancel, and so will the satellite biases (b ^j) which are observed at both stations. The remaining quantities will be the (presumably constant) receiver biases and any leveling errors. Since there are no satellite-dependent quantities in Equation (11), the differenced observations obtained should be identical for all satellites observed, provided that there are no leveling errors. The same principles apply to observations leveled using other techniques discussed in the introduction. Hence, Equation (11) allows comparison of the performance of various leveling approaches.

This methodology has been applied to a baseline of approximately a couple of meters in length between stations WTZJ and WTZZ, in Wettzell, Germany. The observations of both stations from March 2, 2008, were leveled using a standard leveling approach, as well as the method described in this article. Relative leveling errors computed using Equation (11) are displayed in Figure 1, where each color represents a different satellite. It is clear that code noise and multipath do not necessarily average out over the course of an arc, leading to leveling errors sometimes exceeding a couple of TECU for the standard leveling approach (see panel (a)). On the other hand, integer-leveled observations agree fairly well between stations, where leveling errors were mostly eliminated. In one instance, at the beginning of the session, ambiguity resolution failed at both stations for satellite PRN 18, leading to a relative error of 1.5 TECU, more or less. Still, the advantages associated with integer leveling should be obvious since the relative error of the standard approach is in the vicinity of -6 TECU for this satellite.

FIGURE 1. Relative leveling errors between stations WTZJ and WTZZ on March 2, 2008: (a) standard-leveled observations and (b) integer-leveled observations.

The magnitude of the leveling errors obtained for the standard approach agrees fairly well with previous studies (see Further Reading). In the event that intra-day variations of the receiver IFBs are observed, even more significant biases were found to contaminate standard-leveled observations. Since the decoupled-clock model used for ambiguity resolution explicitly accounts for possible variations of any equipment delays, the estimated ambiguities are not affected by such effects, leading to improved leveled observations.

STEC Comparisons. Once leveled observations are available, the next step consists of separating STEC from instrumental delays. This task can be accomplished on a station-by-station basis using, for example, the single-layer ionospheric model. Replacing the slant ionospheric delays (I ^j) in Equation (10) by a bilinear polynomial expansion of VTEC leads to:

(12)

where M(e) is the single-layer mapping function (or obliquity factor) depending on the elevation angle (e) of the satellite. The time-dependent coefficients a₀, a₁, and a₂ determine the mathematical representation of the VTEC above the station. Gradients are modeled using Δλ, the difference between the longitude of the ionospheric pierce point and the longitude of the mean sun, and Δϕ, the difference between the geomagnetic latitude of the ionospheric pierce point and the geomagnetic latitude of the station. The estimation procedure described by Attila Komjathy (see Further Reading) is followed in all subsequent tests. An elevation angle cutoff of 10 degrees was applied and the shell height used was 450 kilometers. Since it is not possible to obtain absolute values for the satellite and receiver biases, the sum of all satellite biases was constrained to a value of zero. As a consequence, all estimated biases will contain a common (unknown) offset. STEC values, in TECU, can then be computed as:

(13)

where the hat symbol denotes estimated quantities, and is equal to zero (that is, it is not estimated) when biases are obtained on a station-by-station basis. The frequency, f₁, is expressed in Hz. The numerical constant 40.3, determined from values of fundamental physical constants, is sufficiently precise for our purposes, but is a rounding of the more precise value of 40.308.

While integer-leveled observations from co-located stations show good agreement, an external TEC source is required to make sure that both stations are not affected by common errors. For this purpose, Figure 2 compares STEC values computed from GIMs produced by the IGS and STEC values derived from station WTZJ using both standard- and integer-leveled observations. The IGS claims root-mean-square errors on the order of 2-8 TECU for vertical TEC, although the ionosphere was quiet on the day selected, meaning that errors at the low-end of that range are expected. Errors associated with the mapping function will further contribute to differences in STEC values. As apparent from Figure 2, no significant bias can be identified in integer-leveled observations. On the other hand, negative STEC values (not displayed in Figure 2) were obtained during nighttimes when using standard-leveled observations, a clear indication that leveling errors contaminated the observations.

FIGURE 2. Comparison between STEC values obtained from a global ionospheric map and those from station WTZJ using standard- and integer-leveled observations.

STEC Evaluation in the Positioning Domain. Validation of slant ionospheric delays can also be performed in the positioning domain. For this purpose, a station’s coordinates from processing the observations in static mode (that is, one set of coordinates estimated per session) are estimated using (unsmoothed) single-frequency code observations with precise orbit and clock corrections from the IGS and various ionosphere-correction sources. Figure 3 illustrates the convergence of the 3D position error for station WTZZ, using STEC corrections from the three sources introduced previously, namely: 1) GIMs from the IGS, 2) STEC values from station WTZJ derived from standard leveling, and 3) STEC values from station WTZJ derived from integer leveling. The reference coordinates were obtained from static processing based on dual-frequency carrier-phase and code observations. The benefits of the integer-leveled corrections are obvious, with the solution converging to better than 10 centimeters. Even though the distance between the stations is short, using standard-leveled observations from WTZJ leads to a biased solution as a result of arc-dependent leveling errors. Using a TEC map from the IGS provides a decent solution considering that it is a global model, although the solution is again biased.

FIGURE 3. Single-frequency code-based positioning results for station WTZZ (in static mode) using different ionosphere-correction sources: GIM and STEC values from station WTZJ using standard- and integer-leveled observations.

This station-level analysis allowed us to confirm that integer-leveled observations can seemingly eliminate leveling errors, provided that carrier-phase ambiguities are fixed to proper integer values. Furthermore, it is possible to retrieve unbiased STEC values from those observations by using common techniques for isolating instrumental delays. The next step consisted of examining the impacts of reducing leveling errors on VTEC.

VTEC Evaluation

When using the single-layer ionospheric model, vertical TEC values can be derived from the STEC values of Equation (13) using:

(14)

Dividing STEC by the mapping function will also reduce any bias caused by the leveling procedure. Hence, measures of VTEC made from a satellite at a low elevation angle will be less impacted by leveling errors. When the satellite reaches the zenith, then any bias in the observation will fully propagate into the computed VTEC values. On the other hand, the uncertainty of the mapping function is larger at low-elevation angles, which should be kept in mind when analyzing the results.

Using data from a small regional network allows us to assess the compatibility of the VTEC quantities between stations. For this purpose, GPS data collected as a part of the Western Canada Deformation Array (WCDA) network, still from March 2, 2008, was used. The stations of this network, located on and near Vancouver Island in Canada, are indicated in Figure 4. Following the model of Equation (12), all stations were integrated into a single adjustment to estimate receiver and satellite biases as well as a triplet of time-varying coefficients for each station. STEC values were then computed using Equation (13), and VTEC values were finally derived from Equation (14). This procedure was again implemented for both standard- and integer-leveled observations.

FIGURE 4. Network of stations used in the VTEC evaluation procedures.

To facilitate the comparison of VTEC values spanning a whole day and to account for ionospheric gradients, differences with respect to the IGS GIM were computed. The results, plotted by elevation angle, are displayed in Figure 5 for all seven stations processed (all satellite arcs from the same station are plotted using the same color). The overall agreement between the global model and the station-derived VTECs is fairly good, with a bias of about 1 TECU. Still, the top panel demonstrates that, at high elevation angles, discrepancies between VTEC values derived from standard-leveled observations and the ones obtained from the model have a spread of nearly 6 TECU. With integer-leveled observations (see bottom panel), this spread is reduced to approximately 2 TECU. It is important to realize that the dispersion can be explained by several factors, such as remaining leveling errors, the inexact receiver and satellite bias estimates, and inaccuracies of the global model. It is nonetheless expected that leveling errors account for the most significant part of this error for standard-leveled observations.

For satellites observed at a lower elevation angle, the spread between arcs is similar for both methods (except for station UCLU in panel (a) for which the estimated station IFB parameter looks significantly biased). As stated previously, the reason is that leveling errors are reduced when divided by the mapping function. The latter also introduces further errors in the comparisons, which explains why a wider spread should typically be associated with low-elevation-angle satellites. Nevertheless, it should be clear from Figure 5 that integer-leveled observations offer a better consistency than standard-leveled observations.

FIGURE 5. VTEC differences, with respect to the IGS GIM, for all satellite arcs as a function of the elevation angle of the satellite, using (a) standard-leveled observations and (b) integer-leveled observations.

Conclusion

The technique of integer leveling consists of introducing (preferably) integer ambiguity parameters obtained from PPP into the geometry-free combination of observations. This process removes the arc dependency of the signals, and allows integer-leveled observations to be used with any existing TEC estimation software. While leveling errors of a few TECU exist with current procedures, this type of error can be eliminated through use of our procedure, provided that carrier-phase ambiguities are fixed to the proper integer values. As a consequence, STEC values derived from nearby stations are typically more consistent with each other. Unfortunately, subsequent steps involved in generating VTEC maps, such as transforming STEC to VTEC and interpolating VTEC values between stations, attenuate the benefits of using integer-leveled observations.

There are still ongoing challenges associated with the GIM-generation process, particularly in terms of latency and three-dimensional modeling. Since ambiguity resolution in PPP can be achieved in real time, we believe that integer-leveled observations could benefit near-real-time ionosphere monitoring. Since ambiguity parameters are constant for a satellite pass (provided that there are no cycle slips), integer ambiguity values (that is, the leveling information) can be carried over from one map generation process to the next. Therefore, this methodology could reduce leveling errors associated with short arcs, for instance.

Another prospective benefit of integer-leveled observations is the reduction of leveling errors contaminating data from low-Earth-orbit (LEO) satellites, which is of particular importance for three-dimensional TEC modeling. Due to their low orbits, LEO satellites typically track a GPS satellite for a short period of time. As a consequence, those short arcs do not allow code noise and multipath to average out, potentially leading to important leveling errors. On the other hand, undifferenced ambiguity fixing for LEO satellites already has been demonstrated, and could be a viable solution to this problem.

Evidently, more research needs to be conducted to fully assess the benefits of integer-leveled observations. Still, we think that the results shown herein are encouraging and offer potential solutions to current challenges associated with ionosphere monitoring.

Acknowledgments

We would like to acknowledge the help of Paul Collins from NRCan in producing Figure 4 and the financial contribution of the Natural Sciences and Engineering Research Council of Canada in supporting the second and third authors. This article is based on two conference papers: “Defining the Basis of an ‘Integer-Levelling’ Procedure for Estimating Slant Total Electron Content” presented at ION GNSS 2011 and “Ionospheric Monitoring Using ‘Integer-Levelled’ Observations” presented at ION GNSS 2012. ION GNSS 2011 and 2012 were the 24th and 25th International Technical Meetings of the Satellite Division of The Institute of Navigation, respectively. ION GNSS 2011 was held in Portland, Oregon, September 19–23, 2011, while ION GNSS 2012 was held in Nashville, Tennessee, September 17–21, 2012.

SIMON BANVILLE is a Ph.D. candidate in the Department of Geodesy and Geomatics Engineering at the University of New Brunswick (UNB) under the supervision of Dr. Richard B. Langley. His research topic is the detection and correction of cycle slips in GNSS observations. He also works for Natural Resources Canada on real-time precise point positioning and ambiguity resolution.

WEI ZHANG received his M.Sc. degree (2009) in space science from the School of Earth and Space Science of Peking University, China. He is currently an M.Sc.E. student in the Department of Geodesy and Geomatics Engineering at UNB under the supervision of Dr. Langley. His research topic is the assessment of three-dimensional regional ionosphere tomographic models using GNSS measurements.

Innovation: Getting Control: Off-the-Shelf Antennas for Controlled-Reception-Pattern Antenna Arrays

Richard Langley — Fri, 01 Feb 2013 18:23:11 +0000

By Yu-Hsuan Chen, Sherman Lo, Dennis M. Akos, David S. De Lorenzo, and Per Enge

INNOVATION INSIGHTS with Richard Langley

THE ANTENNA IS A CRITICAL COMPONENT OF ANY GNSS RECEIVING EQUIPMENT. It must be carefully designed for the frequencies and structures of the signals to be acquired and tracked. Important antenna properties include polarization, frequency coverage, phase-center stability, multipath suppression, the antenna’s impact on receiver sensitivity, reception or gain pattern, and interference handling. While all of these affect an antenna’s performance, let’s just look at the last two here.

The gain pattern of an antenna is the spatial variation of the gain, or ratio of the power delivered by the antenna for a signal arriving from a particular direction compared to that delivered by a hypothetical isotropic reference antenna. Typically, for GNSS antennas, the reference antenna is also circularly polarized and the gain is then expressed in dBic units.

An antenna may have a gain pattern with a narrow central lobe or beam if it is used for communications between two fixed locations or if the antenna can be physically steered to point in the direction of a particular transmitter. GNSS signals, however, arrive from many directions simultaneously, and so most GNSS receiving antennas tend to be omni-directional in azimuth with a gain roll-off from the antenna boresight to the horizon.

While such an antenna is satisfactory for many applications, it is susceptible to accidental or deliberate interference from signals arriving from directions other than those of GNSS signals. Interference effects could be minimized if the gain pattern could be adjusted to null-out the interfering signals or to peak the gain in the directions of all legitimate signals. Such a controlled-reception-pattern antenna (CRPA) can be constructed using an array of antenna elements, each one being a patch antenna, say, with the signals from the elements combined before feeding them to the receiver. The gain pattern of the array can then be manipulated by electronically adjusting the phase relationship between the elements before the signals are combined. However, an alternative approach is to feed the signals from each element to separate banks of tracking channels in the receiver and form a beam-steering vector based on the double-difference carrier-phase measurements from pairs of elements that is subsequently used to weight the signals from the elements before they are processed to obtain a position solution. In this month’s column, we learn how commercial off-the-shelf antennas and a software-defined receiver can be used to design and test such CRPA arrays.

“Innovation” features discussions about advances in GPS technology, its applications, and the fundamentals of GPS positioning. The column is coordinated by Richard Langley, Department of Geodesy and Geomatics Engineering, University of New Brunswick. To contact him with topic ideas, email him at lang @ unb.ca.

Signals from global navigation satellite systems are relatively weak and thus vulnerable to deliberate or unintentional interference. An electronically steered antenna array system provides an effective approach to mitigate interference by controlling the reception pattern and steering the system’s beams or nulls. As a result, so-called controlled-reception-pattern-antenna (CRPA) arrays have been deployed by organizations such as the U.S. Department of Defense, which seeks high levels of interference rejection.

Our efforts have focused on developing a commercially viable CRPA system using commercial off-the-shelf (COTS) components to support the needs of Federal Aviation Administration (FAA) alternative position navigation and timing (APNT) efforts. In 2010, we implemented a seven-element, two-bit-resolution, single-beam and real-time CRPA software receiver. In 2011, the receiver was upgraded to support all-in-view, 16-bit-resolution with four elements.

Even though we can implement these CRPA software receivers in real time, the performance of anti-interference is highly dependent on the antenna array layout and characteristics of the antenna elements. Our beamforming approach allows us to use several COTS antennas as an array rather than a custom-designed and fully calibrated antenna. The use of COTS antennas is important, as the goal of our effort is to develop a CRPA for commercial endeavors — specifically for robust timing for the national airspace. Hence, it is important to study the geometry layout of the individual antennas of the array to assess the layouts and to determine how antenna performance affects the array’s use.

In our work, we have developed a procedure for calculating the electrical layouts of an antenna array by differential carrier-phase positioning. When compared to the physical layout, the results of electrical layouts can be used to determine the mutual coupling effect of each combination. Using the electrical layout, the resultant gain patterns can be calculated and used to see the beamwidth and the side-lobe issue. This is important as these factors have significant effects on anti-interference performance. This study focuses on understanding the performance effects of geometry and developing a method for describing the best geometry.

We adopted three models of COTS antenna and two possible layouts for a four-element array. Then, signal collection hardware consisting of four Universal Software Radio Peripheral (USRP) software-defined radios and one host personal computer was assembled to collect array data sets for each layout/antenna combination. Our developed CRPA software receiver was used to process all data sets and output carrier-phase measurements.

In this article, we will present the pattern analysis for the two selected layouts and describe how we collected the experimental data. We’ll then show the results of calculating the electrical spacing for the layouts are compare them to the physical layouts. Lastly, we’ll show the resulting patterns, discuss the antenna mutual coupling effects, and give our conclusions.

Antenna Array Pattern Analysis

Pattern is defined as the directional strength of a radio-frequency signal viewed from the antenna. The pattern of an antenna array is the product of the isotropic array factor and the isolated element pattern. We assume that the pattern of each element is identical and only consider the isotropic array factor. FIGURE 1 shows the coordination of an antenna array. The first element is set as a reference position. The x-axis is the east direction, the y-axis is the north direction, and the z-axis is the up direction. The baseline vector of the ith antenna is given by and is the unit vector to the satellite.

Figure 1. Antenna array geometry and direction of satellite. Array elements are identified as E#1, E#2, E#3, and E#4.

The isotropic array factor is given by

(1)

where λ is wavelength, and A_i is a complex constant. Currently, we only implement a four-element-array CRPA software receiver in real time. Hence, we analyze two kinds of layout of half-wavelength four-element arrays: a symmetrical Y array and a square array. Each antenna is separated from its nearest neighbor by a half wavelength. FIGURE 2 shows photos of the two layouts. FIGURE 3 shows the physical layouts.

Figure 2. Photos of antenna arrays (left: Y array; right: square array).

Figure 3A. Physical layout of antenna arrays (Y array).

Figure 3B. Physical layout of antenna arrays (square array).

The antenna patterns towards an elevation angle of 90 degrees, computed using equation 1 and the design layouts, are shown in FIGURE 4. One of the key characteristics of a pattern is the beamwidth, which is defined as the angle with 3-dB loss. FIGURE 5 shows the patterns in elevation angle where the beamwidth of the Y layout is 74 degrees and 86 degrees for the square layout. A narrow beamwidth will benefit anti-interference performance particularly if the interference is close to the direction of a target satellite.

Figure 4. Patterns of antenna arrays (left: Y array; right: square array).

Figure 5. Pattern beamwidths of Y and square arrays (3 dB beamwidth shown).

Specifications of COTS Antennas

Typically, the COTS antenna selection is determined by high gain and great out-of-band rejection. TABLE 1 shows the specifications of the three antenna models used in this article. These antennas are all patch antennas. The antennas are equipped with surface-acoustic-wave filters for rejecting out-of-band signals. A three-stage low noise amplifier with over 30 dB gain is also embedded in each antenna.

Table 1. Specifications of COTS antennas used.

Signal Collection Hardware and Experimental Setup

The hardware used to collect the antenna array datasets is shown in FIGURE 6 with block-diagram representation in FIGURE 7. The hardware includes a four-element antenna array, four USRP2 software radio systems and one host computer. The signal received from the COTS antenna passes to a USRP2 board equipped with a 800–2300 MHz DBSRX2 programmable mixing and down-conversion daughterboard. The individual USRP2 boards are synchronized by a 10-MHz external common clock generator and a pulse-per-second (PPS) signal. The USRP2s are controlled by the host computer running the Ubuntu distribution of Linux. The open-source GNU Radio software-defined radio block is used to configure USRP2s and collect datasets. All USRP2s are configured to collect the L1 (1575.42 MHz) signal. The signals are converted to near zero intermediate frequency (IF) and digitized to 14-bit complex outputs (I and Q).

Figure 6. Photo of the signal collection hardware.

Figure 7. Block diagram of the signal collection hardware.

The sampling rate is set as 4 MHz. The host computer uses two solid state drives for storing data sets. For our study, a 64-megabytes per second data transfer rate is needed. The fast solid state drives are especially useful when using high bandwidth signals such as L5, which will require an even higher data streaming rate (80 megabytes per second per channel).

To compare the physical and electrical layouts of the antenna arrays, we set up the signal collection hardware to record six data sets for the two layouts and the three antenna models as shown in TABLE 2. All of the data sets were five minutes long to obtain enough carrier-phase measurements for positioning.

Table 2. Experimental setups.

Logging Carrier-Phase Measurements

To calculate the precise spacing between the antenna elements, hundreds of seconds of carrier-phase measurements from each element are needed. The collected data sets were provided by our in-house-developed CRPA software receiver. The receiver was developed using Visual Studio under Windows. Most of source code is programmed using C++. Assembly language is used to program the functions with high computational complexity such as correlation operations. The software architecture of the receiver is depicted in FIGURE 8. This architecture exploits four sets of 12 tracking channels in parallel to process each IF signal from an antenna element. Each channel is dedicated to tracking the signal of a single satellite. The tracking channels output carrier-phase measurements to build the steering vectors for each satellite. The Minimum Variance Distortionless Response (MVDR) algorithm was adopted for adaptively calculating the weights for beamforming. Here, there are 12 weight sets, one for each satellite in a tracking channel, for the desired directions of satellites.

Figure 8. Block diagram of the software architecture.

Using the pre-correlation beamforming approach, the weights are multiplied with IF data and summed over all elements to form 12 composite signals. These signals are then processed by composite tracking channels. Finally, positioning is performed if pseudoranges and navigation messages are obtained from these channels. FIGURE 9 is the graphical user interface (GUI) of the CRPA software receiver. It consists of the channel status of all channels, carrier-phase differences, positioning results, an east-north (EN) plot, a sky plot, a carrier-to-noise-density (C/N₀) plot and the gain patterns of the array for each tracked satellite. In the figure, the CRPA software receiver is tracking 10 satellites and its positioning history is shown in the EN plot. The beamforming channels have about 6 dB more gain in C/N₀ than the channels of a single element. In each pattern, the direction with highest gain corresponds to the direction of the satellite. While the CRPA software receiver is running, the carrier-phase measurements of all elements and the azimuth and elevation angle of the satellites are logged every 100 milliseconds. Each data set in Table 2 was processed by the software receiver to log the data.

Figure 9. Screenshot of the controlled-reception-pattern-antenna software-receiver graphical user interface.

Electrical Layout of Antenna Array – Procedure

The procedure of calculating the electrical layout of an antenna array is depicted in FIGURE 10. The single-difference integrated carrier phase (ICP) between the signals of an element, i, and a reference element, j, is represented as:

(2)

where r^k_ij is differential range toward the kth satellite between the ith and jth antenna elements (a function of the baseline vector between the ith and jth elements), δL_ij is the cable-length difference between the ith and jth antenna elements, N^k_ij is the integer associated with Φ^k_ij , ε^k_ij and is the phase error. The double-difference ICP between the kth satellite and reference satellite l is represented as:
(3)

The cable-length difference term is subtracted in the double difference. Since the distances between the antenna elements are close to one wavelength, equation (3) can be written as:
(4)

where is the unit vector to satellite k, p_ij is the baseline vector between the ith and jth elements. By combining all the double-difference measurements of the ijth pair of elements, the observations equation can be represented as:
(5)

From the positioning results of composite channels, the azimuth and elevation angle of satellites are used to manipulate matrix G. To solve equation (5), the LAMBDA method was adopted to give the integer vector N. Then, p_ij is solved by substituting N into equation (5). Finally, the cable-length differences are obtained by substituting the solutions of N and p_ij into equation (2).

This approach averages the array pattern across all satellite measurements observed during the calibration period.

Figure 10. Procedure for calculating antenna-array electrical spacing.

Electrical Layout of Antenna Array – Results

Using the procedure in the previous section, all electrical layouts of the antenna array were calculated and are shown in FIGURES 11 and 12. We aligned the vectors from element #1 to element #2 for all layouts. TABLE 3 lists the total differences between the physical and electrical layouts. For the same model of antenna, the Y layout has less difference than the square layout. And, in terms of antenna model, antenna #1 has the least difference for both Y and square layouts. We could conclude that the mutual coupling effect of the Y layout is less than that of the square layout, and that antenna #1 has the smallest mutual coupling effect among all three models of antenna for these particular elements and observations utilized.

Figure 11. Results of electrical layout using three models of antenna compared to the physical layout for the Y array.

Figure 12. Results of electrical layout using three models of antenna compared to physical layout for the square array.

Table 3. Total differences between physical and electrical layouts.

To compare the patterns of all calculated electrical layouts, we selected two specific directions: an elevation angle of 90 degrees and a target satellite, WAAS GEO PRN138, which was available for all data sets. The results are shown in FIGURES 13 and 14, respectively. From Figure 13, the beamwidth of the Y layout is narrower than that of the square layout for all antenna models. When compared to Figure 5, this result confirms the validity of our analysis approach. But, in Figure 14, a strong sidelobe appears at azimuth -60º in the pattern of Y layout for antenna #2. If there is some interference located in this direction, the anti-interference performance of the array will be limited. This is due to a high mutual coupling effect of antenna #2 and only can be seen after calculating the electrical layout.

Figure 13. Patterns of three models of antenna and two layouts toward an elevation angle of 90 degrees.

Figure 14. Patterns of three models of antenna and two layouts toward the WAAS GEO satellite PRN138.

Conclusions

The results of our electrical layout experiment show that the Y layout has a smaller difference with respect to the physical layout than the square layout. That implies that the elements of the Y layout have less mutual coupling. For the antenna selection, arrays based on antenna model #1 showed the least difference between electrical and physical layout. And its pattern does not have a high grating lobe in a direction other than to the target satellite.

The hardware and methods used in this article can serve as a testing tool for any antenna array. Specifically, our methodology, which can be used to collect data, compare physical and electrical layouts, and assess resultant antenna gain patterns, allows us to compare the performances of different options and select the best antenna and layout combination. Results can be used to model mutual coupling and the overall effect of layout and antenna type on array gain pattern and overall CRPA capabilities. This procedure is especially important when using COTS antennas to assemble an antenna array and as we increase the number of antenna elements and the geometry possibilities of the array.

Acknowledgments

The authors gratefully acknowledge the work of Dr. Jiwon Seo in building the signal collection hardware. The authors also gratefully acknowledge the Federal Aviation Administration Cooperative Research and Development Agreement 08-G-007 for supporting this research. This article is based on the paper “A Study of Geometry and Commercial Off-The-Shelf (COTS) Antennas for Controlled Reception Pattern Antenna (CRPA) Arrays” presented at ION GNSS 2012, the 25th International Technical Meeting of the Satellite Division of The Institute of Navigation, held in Nashville, Tennessee, September 17–21, 2012.

Manufacturers

The antennas used to construct the arrays are Wi-Sys Communications Inc., now PCTEL, Inc. models WS3978 and WS3997 and PCTEL, Inc. model 3978D-HR. The equipment used to collect data sets includes Ettus Research LLC model USRP2 software-defined radios and associated DBSRX2 daughterboards.

Yu-Hsuan Chen is a postdoctoral scholar in the GNSS Research Laboratory at Stanford University, Stanford, California.

Sherman Lo is a senior research engineer at the Stanford GNSS Research Laboratory.

Dennis M. Akos is an associate professor with the Aerospace Engineering Science Department in the University of Colorado at Boulder with visiting appointments at Luleå Technical University, Sweden, and Stanford University.

David S. De Lorenzo is a principal research engineer at Polaris Wireless, Mountain View, California, and a consulting research associate to the Stanford GNSS Research Laboratory.

Per Enge is a professor of aeronautics and astronautics at Stanford University, where he is the Kleiner-Perkins Professor in the School of Engineering. He directs the GNSS Research Laboratory.

Innovation: Getting at the Truth: A Civilian GPS Position Authentication System

Richard Langley — Tue, 01 Jan 2013 20:32:51 +0000

By Zhefeng Li and Demoz Gebre-Egziabher

INNOVATION INSIGHTS with Richard Langley

My University, the University of New Brunswick, is one of the few institutes of higher learning still using Latin at its graduation exercises. The president and vice-chancellor of the university asks the members of the senate and board of governors present “Placetne vobis Senatores, placetne, Gubernatores, ut hi supplicatores admittantur?” (Is it your pleasure, Senators, is it your pleasure, Governors, that these supplicants be admitted?). In the Oxford tradition, a supplicant is a student who has qualified for their degree but who has not yet been admitted to it. Being a UNB senator, I was familiar with this usage of the word supplicant. But I was a little surprised when I first read a draft of the article in this month’s Innovation column with its use of the word supplicant to describe the status of a GPS receiver.

If we look up the definition of supplicant in a dictionary, we find that it is “a person who makes a humble or earnest plea to another, especially to a person in power or authority.” Clearly, that describes our graduating students. But what has it got to do with a GPS receiver? Well, it seems that the word supplicant has been taken up by engineers developing protocols for computer communication networks and with a similar meaning. In this case, a supplicant (a computer or rather some part of its operating system) at one end of a secure local area network seeks authentication to join the network by submitting credentials to the authenticator on the other end. If authentication is successful, the computer is allowed to join the network. The concept of supplicant and authenticator is used, for example, in the IEEE 802.1X standard for port-based network access control.

Which brings us to GPS. When a GPS receiver reports its position to a monitoring center using a radio signal of some kind, how do we know that the receiver or its associated communications unit is telling the truth? It’s not that difficult to generate false position reports and mislead the monitoring center into believing the receiver is located elsewhere — unless an authentication procedure is used. In this month’s column, we look at the development of a clever system that uses the concept of supplicant and authenticator to assess the truthfulness of position reports.

“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. He welcomes comments and topic ideas. Contact him at lang @ unb.ca.

This article deals with the problem of position authentication. The term “position authentication” as discussed in this article is taken to mean the process of checking whether position reports made by a remote user are truthful (Is the user where they say they are?) and accurate (In reality, how close is a remote user to the position they are reporting?). Position authentication will be indispensable to many envisioned civilian applications. For example, in the national airspace of the future, some traffic control services will be based on self-reported positions broadcast via ADS-B by each aircraft. Non-aviation applications where authentication will be required include tamper-free shipment tracking and smart-border systems to enhance cargo inspection procedures at commercial ports of entry. The discussions that follow are the outgrowth of an idea first presented by Sherman Lo and colleagues at Stanford University (see Further Reading).

For illustrative purposes, we will focus on the terrestrial application of cargo tracking. Most of the commercial fleet and asset tracking systems available in the market today depend on a GPS receiver installed on the cargo or asset. The GPS receiver provides real-time location (and, optionally, velocity) information. The location and the time when the asset was at a particular location form the tracking message, which is sent back to a monitoring center to verify if the asset is traveling in an expected manner. This method of tracking is depicted graphically in FIGURE 1.

FIGURE 1. A typical asset tracking system.

The approach shown in Figure 1 has at least two potential scenarios or fault modes, which can lead to erroneous tracking of the asset. The first scenario occurs when an incorrect position solution is calculated as a result of GPS RF signal abnormalities (such as GPS signal spoofing). The second scenario occurs when the correct position solution is calculated but the tracking message is tampered with during the transmission from the asset being tracked to the monitoring center. The first scenario is a falsification of the sensor and the second scenario is a falsification of the transmitted position report.

The purpose of this article is to examine the problem of detecting sensor or report falsification at the monitoring center. We discuss an authentication system utilizing the white-noise-like spreading codes of GPS to calculate an authentic position based on a snapshot of raw IF signal from the receiver.

Using White Noise as a Watermark

The features for GPS position authentication should be very hard to reproduce and unique to different locations and time. In this case, the authentication process is reduced to detecting these features and checking if these features satisfy some time and space constraints. The features are similar to the well-designed watermarks used to detect counterfeit currency.

A white-noise process that is superimposed on the GPS signal would be a perfect watermark signal in the sense that it is impossible reproduce and predict. FIGURE 2 is an abstraction that shows how the above idea of a superimposed white-noise process would work in the signal authentication problem. The system has one transmitter, T_x , and two receivers, R_s and R_a. R_s is the supplicant and R_a is the authenticator. The task of the authenticator is to determine whether the supplicant is using a signal from T_x or is being spoofed by a malicious transmitter, T_m. R_a is the trusted source, which gets a copy of the authentic signal, V_x(t) (that is, the signal transmitted by T_x). The snapshot signal, V_s(t), received at R_s is sent to the trusted agent to compare with the signal, V_a(t), received at R_a. Every time a verification is performed, the snapshot signal from R_s is compared with a piece of the signal from R_a. If these two pieces of signal match, we can say the snapshot signal from R_s was truly transmitted from T_x. For the white-noise signal, match detection is accomplished via a cross-correlation operation (see Further Reading). The cross-correlation between one white-noise signal and any other signal is always zero. Only when the correlation is between the signal and its copy will the correlation have a non-zero value. So a non-zero correlation means a match. The time when the correlation peak occurs provides additional information about the distance between R_a and R_s.

Unfortunately, generation of a white-noise watermark template based on a mathematical model is impossible. But, as we will see, there is an easy-to-use alternative.

FIGURE 2. Architecture to detect a snapshot of a white-noise signal.

An Intrinsic GPS Watermark

The RF carrier broadcast by each GPS satellite is modulated by the coarse/acquisition (C/A) code, which is known and which can be processed by all users, and the encrypted P(Y) code, which can be decoded and used by Department of Defense (DoD) authorized users only. Both civilians and DoD-authorized users see the same signal. To commercial GPS receivers, the P(Y) code appears as uncorrelated noise. Thus, as discussed above, this noise can be used as a watermark, which uniquely encodes locations and times. In a typical civilian GPS receiver’s tracking loop, this watermark signal can be found inside the tracking loop quadrature signal.

The position authentication approach discussed here is based on using the P(Y) signal to determine whether a user is utilizing an authentic GPS signal. This method uses a segment of noisy P(Y) signal collected by a trusted user (the authenticator) as a watermark template. Another user’s (the supplicant’s) GPS signal can be compared with the template signal to judge if the user’s position and time reports are authentic. Correlating the supplicant’s signal with the authenticator’s copy of the signal recorded yields a correlation peak, which serves as a watermark. An absent correlation peak means the GPS signal provided by the supplicant is not genuine. A correlation peak that occurs earlier or later than predicted (based on the supplicant’s reported position) indicates a false position report.

System Architecture

FIGURE 3 is a high-level architecture of our proposed position authentication system. In practice, we need a short snapshot of the raw GPS IF signal from the supplicant. This piece of the signal is the digitalized, down-converted, IF signal before the tracking loops of a generic GPS receiver. Another piece of information needed from the supplicant is the position solution and GPS Time calculated using only the C/A signal. The raw IF signal and the position message are transmitted to the authentication center by any data link (using a cell-phone data network, Wi-Fi, or other means).

FIGURE 3. Architecture of position authentication system.

The authentication station keeps track of all the common satellites seen by both the authenticator and the supplicant. Every common satellite’s watermark signal is then obtained from the authenticator’s tracking loop. These watermark signals are stored in a signal database. Meanwhile, the pseudorange between the authenticator and every satellite is also calculated and is stored in the same database.

When the authentication station receives the data from the supplicant, it converts the raw IF signal into the quadrature (Q) channel signals. Then the supplicant’s Q channel signal is used to perform the cross-correlation with the watermark signal in the database. If the correlation peak is found at the expected time, the supplicant’s signal passes the signal-authentication test. By measuring the relative peak time of every common satellite, a position can be computed. The position authentication involves comparing the reported position of the supplicant to this calculated position. If the difference between two positions is within a pre-determined range, the reported position passes the position authentication.

While in principle it is straightforward to do authentication as described above, in practice there are some challenges that need to be addressed. For example, when there is only one common satellite, the only common signal in the Q channel signals is this common satellite’s P(Y) signal. So the cross-correlation only has one peak. If there are two or more common satellites, the common signals in the Q channel signals include not only the P(Y) signals but also C/A signals. Then the cross-correlation result will have multiple peaks. We call this problem the C/A leakage problem, which will be addressed below.

C/A Residual Filter

The C/A signal energy in the GPS signal is about double the P(Y) signal energy. So the C/A false peaks are higher than the true peak. The C/A false peaks repeat every 1 millisecond. If the C/A false peaks occur, they are greater than the true peak in both number and strength. Because of background noise, it is hard to identify the true peak from the correlation result corrupted by the C/A residuals.

To deal with this problem, a high-pass filter can be used. Alternatively, because the C/A code is known, a match filter can be designed to filter out any given GPS satellite’s C/A signal from the Q channel signal used for detection. However, this implies that one match filter is needed for every common satellite simultaneously in view of the authenticator and supplicant. This can be cumbersome and, thus, the filtering approach is pursued here.

In the frequency domain, the energy of the base-band C/A signal is mainly (56 percent) within a ±1.023 MHz band, while the energy of the base-band P(Y) signal is spread over a wider band of ±10.23 MHz. A high-pass filter can be applied to Q channel signals to filter out the signal energy in the ±1.023 MHz band. In this way, all satellites’ C/A signal energy can be attenuated by one filter rather than using separate match filters for different satellites.

FIGURE 4 is the frequency response of a high-pass filter designed to filter out the C/A signal energy. The spectrum of the C/A signal is also plotted in the figure. The high-pass filter only removes the main lobe of the C/A signals. Unfortunately, the high-pass filter also attenuates part of the P(Y) signal energy. This degrades the auto-correlation peak of the P(Y) signal. Even though the gain of the high-pass filter is the same for both the C/A and the P(Y) signals, this effect on their auto-correlation is different. That is because the percentage of the low-frequency energy of the C/A signal is much higher than that of the P(Y) signal. This, however, is not a significant drawback as it may appear initially. To see why this is so, note that the objective of the high-pass filter is to obtain the greatest false-peak rejection ratio defined to be the ratio between the peak value of P(Y) auto-correlation and that of the C/A auto-correlation. The false-peak rejection ratio of the non-filtered signals is 0.5. Therefore, all one has to do is adjust the cut-off frequency of the high-pass filter to achieve a desired false-peak rejection ratio.

FIGURE 4. Frequency response of the notch filter.

The simulation results in FIGURE 5 show that one simple high-pass filter rather than multiple match filters can be designed to achieve an acceptable false-peak rejection ratio. The auto-correlation peak value of the filtered C/A signal and that of the filtered P(Y) signal is plotted in the figure. While the P(Y) signal is attenuated by about 25 percent, the C/A code signal is attenuated by 91.5 percent (the non-filtered C/A auto-correlation peak is 2). The false-peak rejection ratio is boosted from 0.5 to 4.36 by using the appropriate high-pass filter.

FIGURE 5. Auto-correlation of the filtered C/A and P(Y) signals.

Position Calculation

Consider the situation depicted in FIGURE 6 where the authenticator and the supplicant have multiple common satellites in view. In this case, not only can we perform the signal authentication but also obtain an estimate of the pseudorange information from the authentication. Thus, the authenticated pseudorange information can be further used to calculate the supplicant’s position if we have at least three estimates of pseudoranges between the supplicant and GPS satellites. Since this position solution of the supplicant is based on the P(Y) watermark signal rather than the supplicant’s C/A signal, it is an independent and authentic solution of the supplicant’s position. By comparing this authentic position with the reported position of the supplicant, we can authenticate the veracity of the supplicant’s reported GPS position.

FIGURE 6. Positioning using a watermark signal.

The situation shown in Figure 6 is very similar to double-difference differential GPS. The major difference between what is shown in the figure and the traditional double difference is how the differential ranges are calculated. Figure 6 shows how the range information can be obtained during the signal authentication process. Let us assume that the authenticator and the supplicant have four common GPS satellites in view: SAT1, SAT2, SAT3, and SAT4. The signals transmitted from the satellites at time t are S₁(t), S₂(t), S₃(t), and S₄(t), respectively. Suppose a signal broadcast by SAT1 at time t₀ arrives at the supplicant at t₀ + ν₁^s where ν₁^s is the travel time of the signal. At the same time, signals from SAT2, SAT3, and SAT4 are received by the supplicant. Let us denote the travel time of these signals as ν₂^s, ν₃^s, and ν₄^s, respectively. These same signals will be also received at the authenticator. We will denote the travel times for the signals from satellite to authenticator as ν₁^a, ν₂^a, ν₃^a, and ν₄^a. The signal at a receiver’s antenna is the superposition of the signals from all the satellites. This is shown in FIGURE 7 where a snapshot of the signal received at the supplicant’s antenna at time t₀ + ν₁^s includes GPS signals from SAT1, SAT2, SAT3, and SAT4. Note that even though the arrival times of these signals are the same, their transmit times (that is, the times they were broadcast from the satellites) are different because the ranges are different. The signals received at the supplicant will be S₁(t₀), S₂(t₀ + ν₁^s – ν₂^s), S₃(t₀ + ν₁^s – ν₃^s), and S₄(t₀ + ν₁^s – ν₄^s). This same snapshot of the signals at the supplicant is used to detect the matched watermark signals from SAT1, SAT2, SAT3, and SAT4 at the authenticator. Thus the correlation peaks between the supplicant’s and the authenticator’s signal should occur at t₀ + ν₁^a, t₀ + ν₁^s – ν₂^s + ν₂^a, t₀ + ν₁^s – ν₃^s + ν₃^a, and t₀ + ν₁^s – ν₄^s + ν₄^a.

Referring to Figure 6 again, suppose the authenticator’s position (x_a, y_a, z_a) is known but the supplicant’s position (x_s, y_s, z_s) is unknown and needs to be determined. Because the actual ith common satellite (x_i , y_i , z_i ) is also known to the authenticator, each of the ρ_i^a, the pseudorange between the ith satellite and the authenticator, is known. If ρ_i^s is the pseudorange to the ith satellite measured at the supplicant, the pseudoranges and the time difference satisfies equation (1):

ρ₂^s – ρ₁^s= ρ₂^a – ρ₁^a – ct₂₁ + cχ₂₁(1)

where χ₂₁ is the differential range error primarily due to tropospheric and ionospheric delays. In addition, c is the speed of light, and t₂₁ is the measured time difference as shown in Figure 7. Finally, ρ_i^s for i = 1, 2, 3, 4 is given by:

(2)

FIGURE 7. Relative time delays constrained by positions.

If more than four common satellites are in view between the supplicant and authenticator, equation (1) can be used to form a system of equations in three unknowns. The unknowns are the components of the supplicant’s position vector r_s = [x_s, y_s, z_s]^T. This equation can be linearized and then solved using least-squares techniques. When linearized, the equations have the following form:

Aδr_s= δm (3)

where δr_s = [δx_s,δy_s,δz_s]^T, which is the estimation error of the supplicant’s position. The matrix A is given by

where is the line of sight vector from the supplicant to the ith satellite. Finally, the vector δm is given by:

(4)

where δr_iis the ith satellite’s position error, δρ_i^a is the measurement error of pseudorange ρ_i^a or pseudorange noise. In addition, δt_ij is the time difference error. Finally, δχ_ij is the error of χ_ij defined earlier.

Equation (3) is in a standard form that can be solved by a weighted least-squares method. The solution is

δr_s= ( A^T R^-1 A)^-1 A^T R^-1δm (5)

where R is the covariance matrix of the measurement error vector δm. From equations (3) and (5), we can see that the supplicant’s position accuracy depends on both the geometry and the measurement errors.

Hardware and Software

In what follows, we describe an authenticator which is designed to capture the GPS raw signals and to test the performance of the authentication method described above. Since we are relying on the P(Y) signal for authentication, the GPS receivers used must have an RF front end with at least a 20-MHz bandwidth. Furthermore, they must be coupled with a GPS antenna with a similar bandwidth. The RF front end must also have low noise. This is because the authentication method uses a noisy piece of the P(Y) signal at the authenticator as a template to detect if that P(Y) piece exists in the supplicant’s raw IF signal. Thus, the detection is very sensitive to the noise in both the authenticator and the supplicant signals. Finally, the sampling of the down-converted and digitized RF signal must be done at a high rate because the positioning accuracy depends on the accuracy of the pseudorange reconstructed by the authenticator. The pseudorange is calculated from the time-difference measurement. The accuracy of this time difference depends on the sampling frequency to digitize the IF signal. The high sampling frequency means high data bandwidth after the sampling.

The authenticator designed for this work and shown in FIGURE 8 satisfies the above requirements. A block diagram of the authenticator is shown in Figure 8a and the constructed unit in Figure 8b. The IF signal processing unit in the authenticator is based on the USRP N210 software-defined radio. It offers the function of down converting, digitalization, and data transmission. The firmware and field-programmable-gate-array configuration in the USRP N210 are modified to integrate a software automatic gain control and to increase the data transmission efficiency. The sampling frequency is 100 MHz and the effective resolution of the analog-to-digital conversion is 6 bits. The authenticator is battery powered and can operate for up to four hours at full load.

FIGURE 8a. Block diagram of GPS position authenticator.

FIGURE 8b. Photo of constructed unit.

Performance Validation

Next, we present results demonstrating the performance of the authenticator described above. First, we present results that show we can successfully deal with the C/A leakage problem using the simple high-pass filter. We do this by performing a correlation between snapshots of signal collected from the authenticator and a second USRP N210 software-defined radio. FIGURE 9a is the correlation result without the high-pass filter. The periodic peaks in the result have a period of 1 millisecond and are a graphic representation of the C/A leakage problem. Because of noise, these peaks do not have the same amplitude. FIGURE 9b shows the correlation result using the same data snapshot as in Figure 9a. The difference is that Figure 9b uses the high-pass filter to attenuate the false peaks caused by the C/A signal residual. Only one peak appears in this result as expected and, thus, confirms the analysis given earlier.

FIGURE 9a. Example of cross-correlation detection results without high-pass filter.

FIGURE 9b. Example of cross-correlation with high-pass filter.

We performed an experiment to validate the authentication performance. In this experiment, the authenticator and the supplicant were separated by about 1 mile (about 1.6 kilometers). The location of the authenticator was fixed. The supplicant was then sequentially placed at five points along a straight line. The distance between two adjacent points is about 15 meters. The supplicant was in an open area with no tall buildings or structures. Therefore, a sufficient number of satellites were in view and multipath, if any, was minimal. The locations of the five test points are shown in FIGURE 10.

FIGURE 10. Five-point field test. Image courtesy of Google.

The first step of this test was to place the supplicant at point A and collect a 40-millisecond snippet of data. This data was then processed by the authenticator to determine if:

The signal contained the watermark. We call this the “signal authentication test.” It determines whether a genuine GPS signal is being used to form the supplicant’s position report.
The supplicant is actually at the position coordinates that they say they are. We call this the “position authentication test.” It determines whether or not falsification of the position report is being attempted.

Next, the supplicant was moved to point B. However, in this instance, the supplicant reports that it is still located at point A. That is, it makes a false position report. This is repeated for the remaining positions (C through E) where at each point the supplicant reports that it is located at point A. That is, the supplicant continues to make false position reports.

In this experiment, we have five common satellites between the supplicant (at all of the test points A to E) and the authenticator. The results of the experiment are summarized in TABLE 1. If we can detect a strong peak for every common satellite, we say this point passes the signal authentication test (and note “Yes” in second column of Table 1). That means the supplicant’s raw IF signal has the watermark signal from every common satellite. Next, we perform the position authentication test. This test tries to determine whether the supplicant is at the position it claims to be. If we determine that the position of the supplicant is inconsistent with its reported position, we say that the supplicant has failed the position authentication test. In this case we put a “No” in the third column of Table 1. As we can see from Table 1, the performance of the authenticator is consistent with the test setup. That is, even though the wrong positions of points (B, C, D, E) are reported, the authenticator can detect the inconsistency between the reported position and the raw IF data. Furthermore, since the distance between two adjacent points is 15 meters, this implies that resolution of the position authentication is at or better than 15 meters. While we have not tested it, based on the timing resolution used in the system, we believe resolutions better than 12 meters are achievable.

Table 1. Five-point position authentication results.

Conclusion

In this article, we have described a GPS position authentication system. The authentication system has many potential applications where high credibility of a position report is required, such as cargo and asset tracking. The system detects a specific watermark signal in the broadcast GPS signal to judge if a receiver is using the authentic GPS signal. The differences between the watermark signal travel times are constrained by the positions of the GPS satellites and the receiver. A method to calculate an authentic position using this constraint is discussed and is the basis for the position authentication function of the system. A hardware platform that accomplishes this was developed using a software-defined radio. Experimental results demonstrate that this authentication methodology is sound and has a resolution of better than 15 meters. This method can also be used with other GNSS systems provided that watermark signals can be found. For example, in the Galileo system, the encrypted Public Regulated Service signal is a candidate for a watermark signal.

In closing, we note that before any system such as ours is fielded, its performance with respect to metrics such as false alarm rates (How often do we flag an authentic position report as false?) and missed detection probabilities (How often do we fail to detect false position reports?) must be quantified. Thus, more analysis and experimental validation is required.

Acknowledgments

The authors acknowledge the United States Department of Homeland Security (DHS) for supporting the work reported in this article through the National Center for Border Security and Immigration under grant number 2008-ST-061-BS0002. However, any opinions, findings, conclusions or recommendations in this article are those of the authors and do not necessarily reflect views of the DHS. This article is based on the paper “Performance Analysis of a Civilian GPS Position Authentication System” presented at PLANS 2012, the Institute of Electrical and Electronics Engineers / Institute of Navigation Position, Location and Navigation Symposium held in Myrtle Beach, South Carolina, April 23–26, 2012.

Manufacturers

The GPS position authenticator uses an Ettus Research LLC model USRP N210 software-defined radio with a DBSRX2 RF daughterboard.

Zhefeng Li is a Ph.D. candidate in the Department of Aerospace Engineering and Mechanics at the University of Minnesota, Twin Cities. His research interests include GPS signal processing, real-time implementation of signal processing algorithms, and the authentication methods for civilian GNSS systems.

Demoz Gebre-Egziabher is an associate professor in the Department of Aerospace Engineering and Mechanics at the University of Minnesota, Twin Cities. His research deals with the design of multi-sensor navigation and attitude determination systems for aerospace vehicles ranging from small unmanned aerial vehicles to Earth-orbiting satellites.

Innovation: Getting Along: Collaborative Navigation in Transitional Environments

GPS World staff — Thu, 01 Nov 2012 22:02:08 +0000

By Dorota A. Grejner-Brzezinska, J.N. (Nikki) Markiel, Charles K. Toth and Andrew Zaydak

INNOVATION INSIGHTS with Richard Langley

COLLABORATION, n. /kəˌlæbəˈreɪʃən/, n. of action. United labour, co-operation; esp. in literary, artistic, or scientific work — according to the Oxford English Dictionary. Collaboration is something we all practice, knowingly or unknowingly, even in our everyday lives. It generally results in a more productive outcome than acting individually. In scientific and engineering circles, collaboration in research is extremely common with most published papers having multiple authors, for example.

The term collaboration can be applied not only to the endeavors of human beings or other living creatures but also to inanimate objects, too. Researchers have developed systems of miniaturized robots and unmanned vehicles that operate collaboratively to complete a task. These platforms must navigate as part of their functions and this navigation can often be made more continuous and accurate if each individual platform navigates collaboratively in the group rather than autonomously. This is typically achieved by exchanging sensor measurements by some kind of short-range wireless technology such as Wi-Fi, ultra-wide band, or ZigBee, a suite of communication protocols for small, low-power digital radios based on an Institute of Electrical and Electronics Engineers’ standard for personal area networks.

A wide variety of navigation sensors can be implemented for collaborative navigation depending on whether the system is designed by outdoor use, for use inside buildings, or for operations in a wide variety of environments. In addition to GPS and other global navigation satellite systems, inertial measurement units, terrestrial radio-based navigation systems, laser and acoustic ranging, and image-based systems can be used.

In this month’s article, a team of researchers at The Ohio State University discusses a system under development for collaborative navigation in transitional environments — environments in which GPS alone is insufficient for continuous and accurate navigation. Their prototype system involves a land-based deployment vehicle and a human operator carrying a personal navigator sensor assembly, which initially navigate together before the personal navigator transitions to an indoor environment. This system will have multiple applications including helping first responders to emergencies. Read on.

Collaborative navigation is an emerging field where a group of users navigates together by exchanging navigation and inter-user ranging information. This concept has been considered a viable alternative for GPS-challenged environments. However, most of the developed systems and approaches are based on fixed types and numbers of sensors per user or platform (restricted in sensor configuration) that eventually leads to a limitation in navigation capability, particularly in mixed or transition environments.

As an example of an applicable scenario, consider an emergency crew navigating initially in a deployment vehicle, and, when subsequently dispatched, continuing in collaborative mode, referring to the navigation solution of the other users and vehicles. This approach is designed to assure continuous navigation solution of distributed agents in transition environments, such as moving between open areas, partially obstructed areas, and indoors when different types of users need to maintain high-accuracy navigation capability in relative and absolute terms.

At The Ohio State University (OSU), we have developed systems that use multiple sensors and communications technologies to investigate, experimentally, the viability and performance attributes of such collaborative navigation. For our experiments, two platforms, a land-based deployment vehicle and a human operator carrying a personal navigator (PN) sensor assembly, initially navigate together before the PN transitions to the indoor environment.

In the article, we describe the concept of collaborative navigation, briefly describe the systems we have developed and the algorithms used, and report on the results of some of our tests. The focus of the study being reported here is on the environment-to-environment transition and indoor navigation based on 3D sensor imagery, initially in post-processing mode with a plan to transition to real time.

The Concept

Collaborative navigation, also referred to as cooperative navigation or positioning, is a localization technique emerging from the field of wireless sensor networks (WSNs). Typically, the nodes in a WSN can communicate with each other using wireless communications technology based on standards, such as Zigbee/IEEE 802.15.4. The communication signals in a WSN are used to derive the inter-nodal distances across the network. Then, the collaborative navigation solution is formed by integrating the inter-nodal range measurements among nodes (users) in the network using a centralized or decentralized Kalman filter, or a least-squares-based approach.

A paradigm shift from single to multi-sensor to multi-platform navigation is illustrated conceptually in Figure 1. While conventional sensor integration and integrated sensor systems are commonplace in navigation, sensor networks of integrated sensor systems are a relatively new development in navigation. Figure 2 illustrates the concept of collaborative navigation with emphasis on transitions between varying environments. In actual applications, example networks include those formed by soldiers, emergency crews, and formations of robots or unmanned vehicles, with the primary objective of achieving a sustained level of sufficient navigation accuracy in GPS-denied environments and assuring seamless transition among sensors, platforms, and environments.

Figure 1. Paradigm shift in sensor integration concept for navigation.

Figure 2. Collaborative navigation and transition between varying environments.

Field Experiments and Methodology

A series of field experiments were carried out in the fall of 2011 at The Ohio State University (OSU), and in the spring of 2012 at the Nottingham Geospatial Institute of the University of Nottingham, using the updated prototype of the personal navigator developed earlier at the OSU Satellite Positioning and Inertial Navigation Laboratory, and land-based multisensory vehicles. Note that the PN prototype is not a miniaturized system, but rather a sensor assembly put together using commercial off-the-shelf components for demonstration purposes only.

The GPSVan (see Figure 3), the OSU mobile research navigation and mapping platform, and the recently upgraded OSU PN prototype (see Figure 4) jointly performed a variety of maneuvers, collecting data from multiple GPS receivers, inertial measurement units (IMUs), imaging sensors, and other devices. Parts of the collected data sets have been used for demonstrating the performance of navigation indoors and in the transition between environments, and it is this aspect of our experiments that will be discussed in the present article.

Figure 3. Land vehicle, OSU GPSVan.

Figure 4. Personal navigator sensor assembly.

The GPSVan was equipped with navigation, tactical, and microelectromechanical systems (MEMS)-grade IMUs, installed in a two-level rigid metal cage, and the signals from two GPS antennas, mounted on the roof, were shared among multiple geodetic-grade dual-frequency GPS receivers. In addition, odometer data were logged, and optical imagery was acquired in some of the tests.

The first PN prototype system, developed in 2006–2007, used GPS, IMU, a digital barometer, a magnetometer compass, a human locomotion model, and 3D active imaging sensor, Flash LIDAR (an imaging light detection and ranging system using rapid laser pulses for subject illumination). Recently, the design was upgraded to include 2D/3D imaging sensors to provide better position and attitude estimates indoors, and to facilitate transition between outdoor and indoor environments. Consequently, the current configuration allows for better distance estimation among platforms, both indoors and outdoors, as well as improving the navigation and tracking performance in general.

The test area where data were acquired to support this study, shown in Figure 5, includes an open parking lot, moderately vegetated passages, a narrow alley between buildings, and a one-storey building for indoor navigation testing. The three typical scenarios used were:
1)   Sensor/platform calibration: GPSVan and PN are connected and navigate together.
2)   Both platforms moved closely together, that is, the GPSVan followed the PN’s trajectory.
3)   Both platforms moved independently.

Image-Based Navigation

The sensor of interest for the study reported here is an image sensor that actually includes two distinct data streams: a standard intensity image and a 3D ranging image, see Figure 6. The unit consists primarily of a 640 × 480 pixel array of infrared detectors. The operational range of the sensor is 0.8–10 meters, with a range resolution of 1 centimeter at a 2-meter distance.

Figure 6. PN captured 3D image sequence from inside the building.

In this study, the image-based navigation (no IMU) was considered. To overcome this limitation, the intensity images acquired simultaneously with the range data by the unit were leveraged to provide crucial information. The two intensity images were processed utilizing the Scale Invariant Feature Transform (SIFT) algorithm to identify matching features between the pair of 2D intensity images.

The SIFT algorithm has been primarily applied to 1D and 2D imagery to date; the authors are not aware of any research efforts to apply SIFT to 3D datasets for the expressed purpose of positioning. Analysis at our laboratory supported well-published results regarding the exceptional performance of SIFT with respect to both repeatability and extraction of the feature content. The algorithm is remarkably robust to most image corruption schema, although white noise above 5 percent does appear to be the primary weakness of the algorithm. The algorithm suffers in three critical areas with respect to providing a 3D positioning solution. First, the algorithm is difficult to scale in terms of the number of descriptive points; that is, the algorithm quickly becomes computationally intractable for a large number (>5,000) of pixels. Secondly, the matching process is not unique; it is exceptionally feasible for the algorithm to match a single point in one image to multiple points in another image. Finally, since the algorithm loses spatial positioning capabilities to achieve the repeatability, the ability to utilize matching features for triangulation or trilateration becomes impaired. Owing to the noted issues, SIFT was not found to be a suitable methodology for real-time positioning based on 3D Flash LIDAR datasets.

Despite these drawbacks, the intensity images offer the only available sensor input beyond the 3D ranging image. As such, the SIFT methodology provides what we believe to be a “best in class” algorithmic approach for matching 2D intensity images. The necessity of leveraging the intensity images will be apparent shortly, as the schema for deriving platform position is explained.

The algorithm has been developed and implemented by the second author (see Further Reading for details). The algorithm utilizes eigenvector “signatures” for point features as a means to facilitate matching. The algorithm is comprised of four steps:
1)   Segmentation
2)   Coordinate frame transformation
3)   Feature matching
4)   Position and orientation determination.

The algorithm utilizes the eigenvector descriptors to merge points likely to belong to a surface and identify the pixels corresponding to transitions between surfaces. Utilizing an initial coarse estimate from the IMU system, the results from the previous frame are transformed into the current coordinate reference frame by means of a Random Sampling Consensus or RANSAC methodology. Matching of static transitional pixels is accomplished by comparing eigenvector “signatures” within a constrained search window. Once matching features are identified and determined to be static, the closed form quaternion solution is utilized to derive the position and orientation of the acquisition device, and the result updates the inertial system in the same manner as a GPS receiver within the common GPS/IMU integration. The algorithm is unique in that the threshold mechanisms at each step are derived from the data itself, rather than relying upon a-priori limits. Since the algorithm only utilizes transitional pixels for matching, a significant reduction in dimensionality is generally accomplished and facilitates implementation on larger data frames.

The key point in this overview is the need to provide coarse positioning information to the 3D matching algorithm to constrain the search space for matching eigenvector signatures. Since the IMU data were not available, the matching SIFT features from the intensity images were correlated with the associated range pixel measurements, and these range measurements were utilized in Horn’s Method (see Further Reading) to provide the coarse adjustment between consecutive range image frames. The 3D-range-matching algorithm described above then proceeds normally.

The use of SIFT to provide the initial matching between the images entails the acceptance of several critical issues, beyond the limitations previously discussed. First, since the SIFT algorithm is matching 2D features on the intensity image; there is no guarantee that the matched features represent static elements in the field of view. As an example, SIFT can easily “match” the logo on a shirt worn by a moving person; since the input data will include the position of non-static elements, the resulting coarse adjustment may possess very large biases (in position). If these biases are significant, constraining the search space may be infeasible, resulting in either the inability to generate eigenvector matches (worst case) or a longer search time (best case). Since the 3D-range-matching algorithm checks the two range images for consistency before the matching process begins, this can be largely mitigated in implementation. Secondly, the SIFT features are located with sub-pixel location, thus the correlation to the range pixel image will inherently possess an error of ± 1 pixel (row and column). The impact of this error is that range pixels utilized to facilitate the coarse adjustment may in fact not be correct; the correct range pixel to be matched may not be the one selected. This will result in larger errors during the initial (coarse) adjustment process. Third, the uncertainty of the coarse adjustment is not known, so a-priori estimates of the error ellipse must be made to establish the eigenvector search space. The size and extent of these error ellipses is not defined on-the-fly by the data, which reduces one of the key elements of the 3D matching algorithm. Fourth, the limited range of the image sensor results in a condition where intensity features have no associated range measurement (the feature is out of range for the range device). This reduces the effective use of SIFT features for coarse alignment. However, using the intensity images does demonstrate the ability of the 3D-range-matching algorithm to generically utilize coarse adjustment information and refine the result to provide a navigation solution.

Data Analysis

In the experiment selected for discussion in this article, initially, the PN was initially riding in the GPSVan. After completing several loops in the parking lot (the upper portion of Figure 5), the PN then departed the vehicle and entered the building (see Figure 7), exited the facility, completed a trajectory around the second building (denoted as “mixed area” in Figure 5), and then returned to the parking lot.

Figure 7. Building used as part of the test trajectory for indoor and transition environment testing; yellow line: nominal personal navigator indoor trajectories; arrows: direction of personal navigator motion inside the building; insert: reconstructed trajectory section, based on 3D image-based navigation.

While minor GPS outages can occur under the canopy of trees, the critical portion of the trajectory is the portion occurring inside the building since the PN platform will be unable to access the GPS signal during this portion of the trajectory. Our efforts are therefore focused on providing alternative methods for positioning to bridge this critical gap.

Utilizing the combined intensity images (for coarse adjustment via SIFT) and the 3D ranging data, a trajectory was derived for travel inside the building at the OSU Supercomputing Facility. There is a finite interval between exiting the building and recovery of GPS signal lock during which the range acquisition was not available; thus the total extent of travel distance during GPS signal outage is not precisely identical to the travel distance where 3D range solutions were utilized for positioning. We estimate the distance from recovery of GPS signals to the last known 3D ranging-derived position to be approximately 3 meters. Based upon this estimate, the travel distance inside the building should be approximately 53.5 meters (forward), 9.5 meters (right), and 0.75 meters (vertical). Based upon these estimates, the total misclosure based upon 3D range-derived positions is provided in Table 1. The asterisk in the third row indicates the estimated nature of these values.

Table 1. Approximate positional results for the OSU Supercomputing Facility trajectory.

The average positional uncertainty reflects the relative, frame-to-frame error reported by the algorithm during the indoor trajectory. This includes both IMU and 3D ranging solutions. The primary reason for the rather large misclosure in the forward and vertical directions is the result of three distinct issues. First, the image ranging sensor has a limited range; during certain portions of the trajectory the sensor is nearly “blind” due to lack of measurable features within the range. During this period, the algorithm must default to the IMU data, which is known to be suspect, as previously discussed. Secondly, the correlation between SIFT features and range measurement pixels can induce errors, as discussed above. Third, the 3D range positions and the IMU data were not integrated in this demonstration; the range positions were used to substitute for the lost GPS signals and the IMU was drifting. Resolving this final issue would, at a minimum, reduce the IMU drift error and improve the overall solution.

A follow-up study conducted at a different facility was completed using the same platform and methodology. In this study, a complete traverse was completed indoors forming a “box” or square trajectory, which returned to the original entrance point. A plot of the trajectory results is provided in Figure 8. The misclosure is less than four meters with respect to both the forward (z) and right (x) directions. While similar issues exist with IMU drift (owing to lack of tight integration with the ranging data), a number of problems between the SIFT feature/range pixel correlation portion of the algorithm are evident; note the large “clumps’ of data points, where the algorithm struggles to reconcile the motions reported by the coarse (SIFT-derived) position and the range-derived position.

Figure 8. Indoor scenario: square (box) trajectory.

Conclusions

As demonstrated in this paper, the determination of position based upon 3D range measurements can be seen to have particular potential benefit for the problem of navigation during periods of operation in GPS-denied environments. The experiment demonstrates several salient points of use in our ongoing research activities. First, the effective measurement range of the sensor is paramount; the trivial (but essential) need to acquire data is critical to success. A major problem was the presence of matching SIFT features but no corresponding range measurement. Second, orientation information is just as critical as position; the lack of this information significantly extended the time required to match features (via eigenvector signatures). Third, there is a critical need for the sensor to scan not only forward (along the trajectory) but also right/left and up/down. Obtaining features in all axes would support efforts to minimize IMU drift, particularly in the vertical. Alternatively, a wider field of view could conceivably accomplish the same objective. Finally, the algorithm was not fully integrated as a substitute for GPS positioning and the IMU was free to drift. Since the 3D ranging algorithm cannot guarantee a solution for all epochs, accurate IMU positioning is critical to bridge these outages. Fully integrating the 3D ranging solution with a GPS/IMU/3D schema would significantly reduce positional errors and misclosure.

Our study indicates that leveraging 3D ranging images to achieve indoor relative (frame-to-frame) positioning shows great promise. The utilization of SIFT to match intensity images was an unfortunate necessity dictated by data availability; the method is technically feasible but our efforts would suggest there are significant drawbacks to this application, both in terms of efficiency and positional accuracy. It would be better to use IMU data with orientation solutions to derive the best possible solution. Our next step is the full integration within the IMU to enable 3D ranging solutions to update the ongoing trajectory, which we believe will reduce the misclosure and provide enhanced solutions supporting autonomous (or semi-autonomous) navigation.

Acknowledgments

This article is based on the paper “Cooperative Navigation in Transitional Environments,” presented at presented at PLANS 2012, the Institute of Electrical and Electronics Engineers / Institute of Navigation Position, Location and Navigation Symposium held in Myrtle Beach, South Carolina, April 23–26, 2012.

Manufacturers

The equipment used for the experiments discussed in this article included a NovAtel Inc. SPAN system consisting of a NovAtel OEMV GPScard, a Honeywell International Inc. HG1700 Ring Laser Gyro IMU, a Microsoft Xbox Kinect 3D imaging sensor, and a Casio Computer Co., Ltd. Exilim EX-H20G Hybrid-GPS digital camera.

DOROTA GREJNER-BRZEZINSKA is a professor and leads the Satellite Positioning and Inertial Navigation (SPIN) Laboratory at OSU, where she received her M.S. and Ph.D. degrees in geodetic science.

J.N. (NIKKI) MARKIEL is a lead geophysical scientist at the National Geospatial-Intelligence Agency. She obtained her Ph.D. in geodetic engineering at OSU.

CHARLES TOTH is a senior research scientist at OSU’s Center for Mapping. He received a Ph.D. in electrical engineering and geoinformation sciences from the Technical University of Budapest, Hungary.

ANDREW ZAYDAK is a Ph.D. candidate in geodetic engineering at OSU.

Innovation: Easy Peasy, Lemon Squeezy: Satellite Navigation Using Doppler and Partial Pseudorange Measurements

Richard Langley — Mon, 01 Oct 2012 02:30:01 +0000

By Nicholas Othieno and Scott Gleason

INNOVATION INSIGHTS with Richard Langley

BEFORE GPS, THERE WAS TRANSIT. Also known as the U.S. Navy Navigation Satellite System, Transit was the world’s first satellite-based positioning system. It was declared operational in 1968 although it had been in continuous use for the previous five years. The system evolved from the efforts to track the Soviet Union’s Sputnik I, the first artificial Earth-orbiting satellite. By measuring the Doppler frequency shift of the 20-MHz radio signals received from the satellite at a known location, the orbit of the satellite could be worked out. It was then quickly realized that if the orbit of the satellite were known instead, received Doppler data could be used to determine the position of the receiver. Plans for a dedicated satellite navigation system were subsequently drawn up and the first successful test satellite launch occurred in 1960.

Transit navigation required the measurements of the satellite signal’s Doppler shift for a complete pass that could take up to about 18 minutes from horizon to horizon. At the conclusion of the pass, the latitude and longitude of the receiver, the position fix, could be determined. With five operational satellites, the mean time between fixes at a mid-latitude site was around one hour. Eventually, as the orbits of the satellites became better determined, two-dimensional position fix accuracies of several tens of meters were possible from a single satellite pass. By recording data from a number of passes over a few days from a fixed site on land, three-dimensional accuracies better than one meter were possible and Doppler-based control points for mapping were established in many countries and the Canadian north, in particular, saw significant use of Transit for geodetic purposes.

With the advent of GPS and its superior performance, Transit was decommissioned at the end of 1996. And the equivalent Russian satellite Doppler systems have essentially been replaced by GLONASS. However, this hasn’t meant the end of Doppler measurements in satellite navigation. When GPS was being developed, it was determined that Doppler measurements could provide much more accurate receiver velocities than those obtained by simply differencing pseudorange-based position fixes. But what about using Doppler measurements for the position fixes themselves? While they might be good for velocity determination, research in the early 1980s showed that the geometric weakness of GPS Doppler measurement would result in position accuracies at least a couple of orders of magnitude worse than those provided by pseudorange measurements.

So, have we outgrown the use of Doppler measurements for position fixing? Well, it seems not. In this month’s column, we’ll take a look at a GNSS positioning technique that uses admittedly inaccurate Doppler-based position fixes as a first step in producing an accurate fix using just a snapshot of recorded Doppler frequency and code-phase data with no need to decode the navigation message. Old dog, new tricks.

Satellite navigation techniques are evolving to the point where smaller and smaller amounts of data are sufficient to estimate the time and position of the receiver. However, these new processing algorithms require innovative methods to overcome the information that is lost due to a limited duration data set. The field of assisted GNSS (A-GNSS) has boomed in recent years, proposing ways to provide navigation receivers with additional aiding information without the receiver itself having to extract it from the data contained in the off-air signals. These techniques have been wildly successful in advancing the state of the art in satellite navigation. By using nearly omnipresent, real-time Internet connections and propagating on-board ephemeris and clock models, it is possible for many navigation applications to bypass the decoding of the almanac and ephemeris data in the signals themselves. See Further Reading for more information on assisted GNSS.

However, even when using assistance, there are still obstacles that need to be overcome. For example, the shorter the off-air data set that the receiver has to work with, the greater the amount of information normally obtained from the signal that has to be obtained using a different route. In many assisted-GNSS techniques, the satellite ephemeris and clock information is obtained over an external interface. In this case, the receiver needs only to obtain the signal time of transmission from the GNSS signals, which could take between 6 and 12 seconds. For most assisted-GNSS applications, this is not a problem. However, to reduce further the data required, we will need to find an alternative method, which eliminates the need for the signal time of transmission. The first reason for wanting to do this is to reduce to a bare minimum the amount of data the receiver is required to process. The second is to allow the receiver to process limited amounts of data in stand-alone chunks, without decoding the in-signal navigation data in any way. This in turn will allow the receiver to intermittently sample the incoming data stream and process the data and estimate its time and position off-line using a self-contained short-duration snapshot of data.

It has been demonstrated that a receiver position can be estimated using only sub-millisecond code-phase (for the case of GPS L1 C/A-code) measurements and satellite ephemeris and clock data for at least five satellites. This technique is known as time-free or snapshot positioning and reduces the data needed by the receiver to the amount required for the acquisition and tracking loops to converge to a usable code-phase estimate. In this article, we propose a technique whereby the receiver initially estimates its position using Doppler frequency measurements alone and uses this coarse position estimate to satisfy the a priori position requirement needed to perform a time-free estimate. Additionally, as Doppler measurements are influenced by the receiver dynamics, a thorough examination of the errors in Doppler estimation as a function of the receiver velocity is explored.

Technique Overview

The basic processing blocks of a GNSS receiver are well known. In our research, a couple of assumptions are made regarding the overall configuration and availability of assistance data. In our operational configuration, we assume that

An external interface is used to import satellite ephemeris and clock information for the entire GNSS constellation.
The receiver acquisition and tracking algorithms are able to acquire the required number of satellites for this technique to work, thus providing the raw code-phase and Doppler measurements.
The receiver clock is initialized to an accuracy of approximately 20 seconds with respect to GPS System Time.

Notably, the method proposed here does not require the receiver to synchronize and decode the navigation message data in any way, and specifically, it does not need to recover the signal transmission time. In the proposed method, the receiver can start estimating its position as soon as the signal tracking loops have settled to an acceptable accuracy. Importantly, this technique does not require any a priori knowledge of the receiver position.

The combined Doppler/time-free navigation receiver performs the processing steps indicated in Figure 1. Several important differences with regard to traditional GNSS signal processing are important. First, the processing does not assume a continuous data stream as a standard receiver would, but requires only Doppler and code-phase measurements from the tracking loops at a single epoch. Second, the time-free algorithm, like the conventional pseudorange least-squares algorithm, is performed iteratively but with an additional variable of time which causes the estimates of the GNSS satellite positions to change as the time estimate converges.

FIGURE 1. A Doppler/time-free GNSS receiver block diagram.

Doppler Positioning

The method for estimating a GNSS receiver position using Doppler measurements is well known and was first proposed decades ago. This technique never gained much traction in the research and user communities because it was apparent that the accuracy obtained using Doppler measurements was not sufficient for nearly all existing applications. As will be shown below, under good conditions, this technique is capable of estimating the receiver position to within approximately one kilometer. Although estimating a position without range measurements is of interest to some theoretically, practically this level of accuracy was deemed not useful. However, it was observed that this level of accuracy was within the initialization requirements of the time-free position algorithm, thus renewing interest in the technique, not as a useful product itself, but as initialization assistance to the time-free navigation technique discussed below.

The concept of overlapping iso-Doppler lines for the case of two different satellite measurements is shown in Figure 2. The frequency value around the lines of constant Doppler are the frequencies the receiver tracking loops have converged to for each satellite. With at least four satellites (an extra one is needed to solve for the receiver clock drift error), the position of the receiver can be coarsely estimated.

FIGURE 2. Illustration of the isolines of constant Doppler for one and two GNSS satellites. Sv and Uv are the satellite and receiver velocity vectors, respectively. ϴ is the angle between the velocity difference vector and the vector pointing from the satellite to the receiver. The figure on the right shows the intersection of Doppler ellipses for the two satellites.

Briefly, the algorithm for determining the receiver position from the Doppler measurements starts by projecting the difference between the satellite and receiver velocity vectors along the normalized view vector, which is in fact the range rate. The range rate is then linked to the tracked Doppler frequencies for each satellite. However, GNSS measurements are notoriously corrupted by the imperfect receiver clocks, which in this case will introduce a bias into the measured range rate. In other words, the range rate is actually the pseudorange rate. We can now form a measurement equation for an individual satellite that includes the pseudorange-rate measurement, the receiver position estimate, the satellite position, the receiver and satellite velocities, and the receiver clock rate error.

As in the case of the traditional pseudorange least-squares position estimation, this equation can be linearized around an initial guess and a series of corrections to that initial guess solved for iteratively. Importantly, the requirements for the initial guess in Doppler positioning (as in the case of pseudorange positioning) are very generous. For receivers below the GNSS constellation, the initial guess for the receiver position can be the center of the Earth. In practice, this effectively eliminates any burden on the receiver to have any a priori knowledge as to its position.

A minimal system of four equations, one for each observed satellite, can be formed and solved recursively to provide estimates of the three position coordinates plus the receiver clock frequency or rate error. As in the case of pseudorange-based position estimation, the overdetermined case of more than four measurements can be readily solved. Note that the solution only contains a receiver clock frequency error, and not a time bias as in the traditional pseudorange solution. The next section demonstrates this technique and assesses the achievable accuracy under different receiver dynamics.

Off-Air Signal Demonstration. The Doppler positioning algorithm was first tested using live off-air signals. These signals were captured using a USB front-end sampler for about 1 minute. This raw sampled data was logged to a file and subsequently processed by our fastGPS software receiver. To act as a truth reference, the sampled data is first processed using the traditional pseudorange least-squares position-estimation technique. This position is then chosen as the true position and the file is once again processed in fastGPS but using the Doppler positioning algorithm described above. Note that the C/A-code pseudorange positioning technique is known to be accurate to the order of several meters. However, achieving high accuracy using the Doppler method is not of large concern as the goal of this initial estimation is to initialize the time-free algorithm and not act as a result in itself. So for the case of this demonstration, it is not useful to compare the Doppler positioning results to those of a pseudorange position estimation. We are principally interested in demonstrating that the errors in Doppler position estimation are within acceptable limits for initializing time-free positioning.

The off-air data was captured in Parc Mont Royal in Montreal, Canada. This data was processed normally and the pseudorange position obtained was used as the reference position for the Doppler positioning results shown in Figure 3. This position was also coarsely verified using a handheld GPS unit.

FIGURE 3. Doppler position estimation with off-air signals. East-north position for a stationary receiver at 18:04 UTC, October 28, 2010.

From Figure 3, it can be seen that the errors are consistently less that 1 kilometer over the duration of the data set. A total of 173 Doppler solutions were performed by the fastGPS receiver as it processed the entire sampled data file. As will be shown later, this error magnitude is well within the limits needed to initialize the time-free algorithm. The errors tend to be largest when the number of tracked satellites is low and the geometric dilution of precision is unfavorable as would be expected. The position error under normal geometries is generally on the order of a kilometer. In this scenario, GPS Time was initialized to within 20 seconds of the true time for each Doppler positioning attempt.

Dynamic Receiver Performance Evaluation. This algorithm was also tested using simulated data to assess its sensitivity to receiver dynamics. The velocity of the receiver directly influences the Doppler positioning solution estimation. This Doppler contribution will directly contribute to the estimation error and needs to be properly assessed. The impact of the receiver velocity on the accuracy of the solution was investigated using a simulated receiver under a range of dynamics conditions. As will be shown below, the accuracy of the Doppler position estimate will limit when it can be used to initialize the time-free position estimate. This is demonstrated by simulating the Doppler position estimation accuracy for a receiver gradually increasing in velocity.

The simulation was performed using our GNSS measurement simulator. This simulator was configured to generate measurements as would be received from a dynamic receiver over several hours. The simulator is initialized using two-line satellite orbital elements provided by the North American Aerospace Defense Command (NORAD) / Joint Space Operations Center and collected on four separate days.

The simulation duration was chosen to provide realistic viewing geometries at an arbitrary receiver location. The simulations were repeated at different times over a period of four days. This insures that the simulated receiver experiences a good representation of measurements under both good and bad satellite geometries. This allows for the best case, worst case, and average performance of the algorithm to be evaluated.

To simulate a receiver with increasing velocity, the receiver was set to move in one specific compass point direction (north, south, east, and west) over the duration of the simulation. The velocity of the receiver was then increased from 5 meters per second up to 40 meters per second in steps of 5 meters per second. Each velocity is maintained for 20 minutes. The receiver simulations ran for 2 hours and 40 minutes. This is sufficient to investigate the effect of velocity on the algorithm, in that four different test cases with different GPS constellation configurations provided sufficient randomness in satellite geometry.

From Figure 4, it can be seen that the error magnitude increases with the increasing velocity of the receiver. This is because the algorithm used for position determination is dependent on the tracked Doppler frequency of the received satellite signals, which are directly influenced by the receiver velocity. From the data generated for all four test cases, it can be shown that the errors in the Doppler position estimation start to exceed the initialization requirements of the time-free position technique at approximately 80 to 100 kilometers per hour. This limitation and how to mitigate it is discussed in more detail later in the article.

FIGURE 4. Doppler positioning solution error for a receiver with increasing velocity moving southwards at 09:16 UTC, April 19, 2011.

Time-Free Position Estimation

As discussed earlier, one of the main goals of this work is to reduce the amount of data that needs to be processed to obtain a position solution. Normally, even in the case of assisted GNSS, the receiver must decode navigation data provided by the transmitted satellite signal. This processing is needed to estimate the GPS Time and signal time of transmission and is critical to the standard pseudorange position-estimation algorithm. The Doppler positioning algorithm does not require the signal transmission time to be decoded from the signal, but it also does not produce results accurate enough to be useful in themselves. However, we use a method that produces a usable estimation accuracy and yet does not need to retrieve the GPS Time from the transmitted signal. This positioning technique is often called time-free or snapshot positioning. The technique is described in the references provided in Further Reading.

In time-free positioning, the position of a receiver is estimated without having to know the precise time of transmission of a GPS signal. This automatically removes the need to extract the time of week (TOW) from the navigation message. This is done by providing an initial guess of position to within a relatively demanding requirement, a fraction of the pseudorandom-noise-ranging-code repeat period. Also affecting the algorithm is the a priori knowledge of time at the receiver. The required accuracy of both of these quantities together is evaluated below. The a priori knowledge of the receiver position presents the more difficult limitation in an assisted-GNSS configuration. For modern receivers with access to the Internet, the time at the receiver can normally be determined to an accuracy of at least tens of seconds.

Assessment of Time-Free a Priori Requirements. Monte-Carlo simulations were run to investigate the behavior of the algorithm with varied a priori receiver position and time errors. These initialization error limits will determine under which conditions the Doppler algorithm position estimation will be suitable.

When the algorithm converges, the position estimates are on the order of what could be expected for a traditional pseudorange solution.

However, the conditions under which the time-free algorithm does not converge need to be properly understood. To accomplish this, a series of Monte-Carlo simulations were run over a wide range of a priori time and position errors. At the start of each time-free positioning attempt, the initial knowledge of the receiver position and time was corrupted by a random amount. After a reasonable number of iterations, the algorithm either converged to a reasonable solution or diverged wildly. The results indicating under what conditions the algorithm converged are plotted to illustrate the convergence region for the time-free algorithm for GPS C/A-code signals. Figure 5 shows that, as expected, the algorithm performs well when the a priori position and time knowledge are good. As these initial errors increase, the solution is more prone to diverge. The area of interest is the robust convergence zone making up a triangle towards the lower left. The Doppler position estimation must provide a solution within this range for the combined technique to work robustly.

In Figure 5, it can be noted that the solution often converges with larger than expected initialization errors (this is being investigated in more detail). However, the region of most interest is that in which the algorithm always converges. The results show that the time-free positioning algorithm will converge reliably with an a priori receiver position that is in error within the neighborhood of 100 kilometers, as long as the receiver time is kept accurate to within a few seconds. Alternatively, the algorithm will converge with a time error of over one minute, with a lessening of the position initialization tolerance down to about 50 kilometers.

FIGURE 5. Monte-Carlo simulation results for time-free failure cases over a range of a priori position and time errors.

Depending on the application and receiver capabilities, a compromise must be chosen to achieve the a priori initialization limits. From the results in Figure 5, it can be seen that for many applications, a Doppler position estimate will be more than sufficient for the a priori position initialization, thus eliminating the need for any a priori position knowledge for many applications with moderate receiver dynamics.

Combined Doppler and Time-Free Positioning

We have shown that Doppler positioning can estimate a receiver position to within about 100 kilometers for receivers in low and medium dynamics environments (at and below approximately 100 kilometers per hour). Importantly, the Doppler positioning algorithm can be performed using an initial estimate of the receiver position at the center of the Earth.

Subsequently, it was shown that time-free positioning requires an a priori position estimate that is accurate to within about 100 kilometers of the true position and a receiver time that is accurate to within a few seconds to assure algorithm convergence. If the a priori position estimate goes beyond 100 kilometers, there is a probability of divergence of the algorithm even with accurate receiver time. A coarse time accuracy threshold of 10 seconds is selected in this case as it is believed that GNSS receivers with assisted-GNSS capability will not have a lot of difficulty syncing their clocks to this accuracy.

The next step is to update the receiver processing steps to allow for the Doppler and time-free algorithms to be integrated together. In the combination algorithm, the Doppler estimation is performed first and then simply fed into the time-free algorithm as shown in Figure 1 and in more detail in Figure 6.

FIGURE 6. Processing stages in time-free positioning initialized by Doppler positioning.

From Figure 6, it can be seen that three inputs are required for the Doppler positioning algorithm: the initialization time estimate, satellite Doppler measurements, and satellite ephemeris and clock information. The time estimate is obtained from the receiver’s clock whose accuracy should be within 10 seconds of the true GPS Time. The satellite Doppler measurements (a minimum of four) are provided by the tracking functions of the receiver. The ephemeris is assumed to be locally stored at the receiver using an assisted-GNSS external data link.

Subsequently, the time-free positioning algorithm then inputs the Doppler estimate as its initial a priori estimate of the receiver position. The existing assisted-GNSS satellite ephemeris and clock information as well as the coarse estimate of the GPS Time kept by the receiver are also available for the time-free estimation.

The code-phase measurements from at least five GNSS satellites form the last piece of the puzzle. They are obtained as a direct output of the receiver delay lock loop. In the case of GPS C/A-code signals, these will be up to 1 millisecond in length, with longer durations possible with other GNSS signals as discussed below.

Operationally, the Doppler positioning module can be run once, tested for convergence, and then the resulting position estimate fed back into the time-free position estimation. However, for our test cases, the Doppler algorithm was used repeatedly to initialize the time-free algorithm to more thoroughly exercise the process.

What proved to be a robust test on the convergence of the time-free algorithm was a simple comparison of the final output to the initial Doppler-determined input. When this difference was below a single code-sequence repeat period, the algorithm had in all cases converged.

The divergent cases regularly produced differences of significantly larger magnitudes.

Comparison to Traditional Estimation. The combined algorithm was tested on multiple sets of off-air data from the U.S., Canada, and the U.K. The root-mean-square error of the horizontal position estimates and the mean geometric dilution of precision during the observations for each of the tested off-air data sets are shown in Table 1. The error magnitudes of the resulting position solutions are on the same order for both the standard pseudorange least-squares and time-free position estimates. This is to be expected, for if the time-free algorithm computes the correct integer milliseconds, the algorithm will converge to nearly the same solution as the traditionally determined pseudoranges since the code-phase measurements are identical. In this comparison, both the pseudorange and combined Doppler/time-free algorithms were started assuming an initial receiver position at the center of the Earth. As a final check that this method provides comparable results to those from the traditional pseudorange case, we directly compared the error magnitudes of the two methods over a stretch of the same data. This will also prove to illustrate how time-free positioning is capable of more quickly estimating the position than other methods since it does not need to decode the satellite signal’s navigation message.

TABLE 1. Root-mean-square (R.M.S.) error and geometrical dilution of precision (GDOP) for off-air GPS data sets used with the fastGPS software receiver.

Table 1. Root-mean-square (R.M.S.) error and geometrical dilution of precision (GDOP) for off-air GPS data sets used with the fastGPS software receiver.

Figure 7 shows the performance for the combined Doppler/time-free and traditional pseudorange methods together for a period of 34 seconds. As shown, the combined Doppler/time-free positioning algorithm provides receiver position estimates that are comparable in error magnitude to the traditional method. Similar results were obtained for all of the other off-air data sets at our disposal.

FIGURE 7 Comparison of position estimation error magnitudes for time-free and traditional pseudorange-based position estimations. Error magnitudes for both methods tested on the Montreal off-air data set.

Concluding Remarks

In this article, we have demonstrated that that a GNSS receiver can estimate its position using a snapshot of sampled data and no knowledge of the position of the receiver in low and medium dynamics environments. This addresses an existing limitation of the time-free GNSS navigation technique and facilitates new receiver designs based on limited sampled data sets, notably those using software-based processing techniques. It has been shown that by roughly estimating the receiver position using Doppler measurements with no knowledge of the receiver position, a time-free position estimation can be robustly performed. The limitations on this combined method are due mainly to the dynamic environment of the receiver, which will degrade the rough Doppler position estimate. Nevertheless, this technique will work for a wide range of GNSS applications. Additionally, Monte-Carlo simulations have been performed that show that this combined technique is robust within the stated dynamics limitations and initialization requirements of the time-free method for GPS C/A-code signals.

Overcoming the Velocity Limitation. The degradation of the Doppler estimation for receivers at higher velocity can be addressed in a number of ways. The most direct correction to this problem is the inclusion of a simple inertial device on the receiver. This will provide a coarse estimate of the receiver velocity that then can be included in the Doppler estimation and would result in position accuracies using Doppler on the order of 1 kilometer in nearly all dynamic receiver cases (limited only by the capability of the inertial sensor).

The second possibility is to wait for the next generation of GNSS signals to solve the problem for us. Several new GNSS signals (some of which are already being transmitted by active satellites) have been designed with code repeat periods of significantly longer than 1 millisecond (see FIGURE 8). The 1-millisecond code repeat period effectively limits the Doppler estimation error to what was shown above.

FIGURE 8. Comparison of code-phase repeat period ambiguities for various GNSS signals.

Longer repeat periods will correspondingly increase the tolerance of the time-free a priori initialization. Some of the next generation GNSS signals and their respective code repeat periods will be significantly longer than GPS L1 C/A-code. For example, the 20-millisecond code repeat period of the new GPS L2 civil signal corresponds to approximately a 6,000-kilometer repeat length, and an integer 20-millisecond ambiguity of normally only three or four. This will make the construction of the full pseudorange from a 20-millisecond tracking-loop measurement much easier in the presence of larger errors in the a priori position knowledge.

Discussion. Our work provides a useful method to greatly reduce the processing load in a GNSS receiver, and eliminates the task of decoding GNSS navigation data and the need to have coarse position information. These two advantages together provide a useful step in the development of a dramatically different approach in GNSS signal processing and position estimation. As opposed to existing GNSS receivers, which continually process the incoming signals, this technique allows for strict management of the incoming data and position estimation outputs. This management is well suited for applications that are required to remain off or in a low-power state for long and intermittent periods. Using this technique, any platform can estimate its position by operating the GNSS receiver for a short (snapshot) period of time. The logged data captured during this brief time can then be processed in real time or archived and processed later as the application demands. Applications such as animal tracking or long-duration vehicle tracking, where a position needs to be tracked over a long period using extremely challenging power resources, will benefit notable from this new technique.

Software demonstrating the algorithms discussed above can be downloaded free of charge from http://gnssapplications.org/, including Chapter 3 (on the GNSS simulator) and Chapter 5 (on the fastGPS receiver).

Acknowledgments

This article is based on the paper “Combined Doppler and Time Free Positioning Technique for Low Dynamics Receivers” presented at PLANS 2012, the Institute of Electrical and Electronics Engineers / Institute of Navigation Position, Location and Navigation Symposium held in Myrtle Beach, South Carolina, April 23–26, 2012.

Manufacturer

Tests were conducted using a SparkFun (www.sparkfun.com ) SiGe GN3S USB front end.

NICHOLAS OTHIENO was an M.A.Sc. student in the Department of Electrical and Computer Engineering at Concordia University, Montreal, Canada. His research was in the area of software-based GNSS techniques and applications.

SCOTT GLEASON has been an assistant professor in the Department of Electrical and Computer Engineering at Concordia University since 2010. He received his B.S. degree in electrical and computer engineering from the State University of New York at Buffalo, an M.S. in engineering from Stanford University, and a Ph.D. from the University of Surrey in England. He has worked in the areas of astronautics, remote sensing, and GNSS for more than 15 years, including time at NASA’s Goddard Space Flight Center and Stanford’s GPS Laboratory, and the National Oceanography Centre, Southampton, England.

Innovation: Software GNSS Receiver: An Answer for Precise Positioning Research

GPS World staff — Sat, 01 Sep 2012 21:45:06 +0000

By Thomas Pany, Nico Falk, Bernhard Riedl, Tobias Hartmann, Günter Stangl, and Carsten Stöber

INNOVATION INSIGHTS with Richard Langley

WHAT IS THE IDEAL GNSS RECEIVER? Well, that depends on what you mean by “ideal.” If we take it to mean the simplest, conceptually, yet the most capable and adaptable receiver, then we would just connect an analog-to-digital converter (ADC) to an antenna and pass the converter’s output to a digital signal processor whose software would transform the received signal into the desired result with the utmost speed and precision. There are certain technological limitations that currently preclude fully developing such a device but we are getting very close to the ideal and practical implementations already exist.

Such a GNSS receiver is an example of a software-defined radio — a radio-communications architecture in which as much of the operation of a receiver (or a transmitter) as feasible is performed by software in an embedded system or on a personal computer (PC).

Now, we can’t simply connect an ADC to an antenna since the strength of GNSS signals falls well below the sensitivity threshold of real ADCs and those that can directly digitize microwave radio frequencies are rather power hungry. Therefore, the front end of a real software GNSS receiver includes a low-noise preamplifier, filters, and one or more downconverters to produce an analog intermediate-frequency signal that passes to a high-speed ADC. The digitized signal is provided at the output of the front end in a convenient format, which, for processing signals on a PC, is typically USB 2.0 with its maximum signaling rate of 480 megabits per second. All baseband signal processing is then carried out in the programmable microprocessor.

Software GNSS receivers offer a number of advantages over their hardware cousins. Foremost is their flexibility, which permits easy and rapid changes to accommodate new radio frequency bands, signal modulation types and bandwidths, and baseband algorithms. This flexibility is beneficial not only for multi-GNSS operation but also for prototyping algorithms for conventional hardware designs. Another advantage is their use in embedded systems such as smartphones and wireless personal digital assistants. Software GNSS receivers are also a boon for teaching, where a student can tweak a particular operating parameter and immediately see the effect. And given their remarkable flexibility, software GNSS receivers can be adapted to a variety of special scientific and engineering research applications such as reflectometry and signal analysis.

In this month’s “Innovation,” we look into the development and capabilities of one modern software GNSS receiver in an effort to answer the question “What is the ideal GNSS receiver for precise positioning research?”

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.

GPS World » Innovation

Innovation: Evil Waveforms: Generating Distorted GNSS Signals Using a Signal Simulator

Editor’s Note:Further Reading for this article will appear soon.

Additional Images

Innovation: Interfacing Clearly: A New Approach to the Design and Development of Global Navigation Satellite Systems

FURTHER READING

Innovation: A Better Way: Monitoring the Ionosphere with Integer-Leveled GPS Measurements

Standard Leveling Procedure

Integer-Leveling Procedure

Slant TEC Evaluation

VTEC Evaluation

Conclusion

Acknowledgments

FURTHER READING

Innovation: Getting Control: Off-the-Shelf Antennas for Controlled-Reception-Pattern Antenna Arrays

Antenna Array Pattern Analysis

Specifications of COTS Antennas

Signal Collection Hardware and Experimental Setup

Logging Carrier-Phase Measurements

Electrical Layout of Antenna Array – Procedure

Electrical Layout of Antenna Array – Results

Conclusions

Acknowledgments

Manufacturers

FURTHER READING

Innovation: Getting at the Truth: A Civilian GPS Position Authentication System

Using White Noise as a Watermark

An Intrinsic GPS Watermark

System Architecture

C/A Residual Filter

Position Calculation

Hardware and Software

Performance Validation

Conclusion

Acknowledgments

Manufacturers

FURTHER READING

Innovation: Getting Along: Collaborative Navigation in Transitional Environments

The Concept

Field Experiments and Methodology

Image-Based Navigation

Data Analysis

Conclusions

Acknowledgments

Manufacturers

FURTHER READING

Innovation: Easy Peasy, Lemon Squeezy: Satellite Navigation Using Doppler and Partial Pseudorange Measurements

Technique Overview

Doppler Positioning

Time-Free Position Estimation

Combined Doppler and Time-Free Positioning

Concluding Remarks

Acknowledgments

Manufacturer

FURTHER READING

Innovation: Software GNSS Receiver: An Answer for Precise Positioning Research

The Front End

GNSS Reference Station

Other GNSS Signals

Polyfit and Vector Tracking

Dual-Antenna Heading Determination

Conclusions

Acknowledgments

Manufacturers

FURTHER READING