Tag: OEM

  • ION GNSS+ 2013 Program and Registration Available Online

    Registration is now open for the Institute of Navigation (ION) GNSS+ 2013 to be held September 16-20 (tutorials September 16 and 17) at the Nashville Convention Center in Nashville, Tennessee.

    ION GNSS+ 2013 is the 26th International Technical Meeting of the ION Satellite Division and the world’s largest technical meeting and showcase of GNSS technology, products and services.

    ION GNSS+ brings together international leaders in GNSS and related positioning, navigation and timing fields to present new research, introduce new technologies, update current policy, demonstrate products and exchange ideas. The addition of “+” to the conference name reflects the growing emphasis on GNSS and the rapidly evolving field of alternative navigation methods.

    This year’s conference will feature pre-conference tutorials September 16-17, policy and panel discussions, commercial and applications oriented sessions, and more than 250 technical papers on a diverse array of topics including:

    • Advanced Inertial Sensing and Applications
    • Advances in Military GNSS Systems and Applications
    • Algorithms and Methods
    • Alternatives and Backups to GNSS
    • Aviation Applications
    • Clock/Timing and Scientific Applications
    • Emerging GNSS (Galileo, COMPASS, QZSS, IRNSS) (both a Panel Discussion and a technical session)
    • Future PNT and Its Applications
    • Geodesy, Surveying and RTK for Civil Applications
    • GNSS Algorithms and Methods
    • GNSS and the Atmosphere
    • GNSS Compatibility, Interoperability, and Interchangeability
    • GNSS Ground Based Augmentation Systems (GBAS)
    • GNSS Simulation and Testing
    • GNSS Space Based Augmentation Systems (SBAS)
    • GNSS-MEMS Integration
    • GNSS Program Updates (Panel Discussion)
    • GPS and GLONASS Modernization
    • High Integrity Systems (Panel Discussion)
    • Indoor Navigation and Timing
    • Interference and Spectrum Issues
    • IP Policies Related to GNSS (Panel Discussion)
    • Land Based Applications
    • Marine Navigation and Applications
    • Multi-Constellation/Portable Navigation Devices
    • Multi-Sensor and Integrated Navigation in GNSS-Challenged Environments
    • New Products and Commercial Services (both a Panel Discussion and a commercial applications oriented session)
    • Next Generation GNSS Integrity
    • Non Traditional PNT Applications
    • Portable Navigation Devices
    • Precise Point Positioning
    • Receiver/Antenna Technology
    • Remote Sensing with GNSS and Integrated Systems
    • Safety Critical Applications
    • Software Receivers
    • Space Applications
    • Standalone GNSS Services in Challenging Environments
    • Timing and Scientific Applications
    • Unmanned GNSS (Panel Discussion)
    • Urban Navigation Technology

    New this year will be two For Official Use Only (FOUO) U.S. only sessions: Multi-Sensor Integrated Navigation and Networked-Related Navigation. These sessions are sponsored by the ION’s Military Division and The MITRE Corporation.

  • NVS Technologies Releases Firmware Update for NV08C Receivers

    NVS Technologies has released updated firmware for its NV08C receiver series. Firmware v0206 is compatible with current and preceding hardware revisions of the NV08C receiver series. Firmware v0206 can be downloaded free of charge.

    Firmware v0206 offers:

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

    Benefits include:

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

    Innovation: Evil Waveforms

    Generating Distorted GNSS Signals Using a Signal Simulator

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

    GPS World photo
    INNOVATION INSIGHTS by 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).
    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).
    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/N0 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 f0, where f0 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.
    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/N0, 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 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.
    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 6. Fault-free vs. EWFA GPS L1 C/A signal.
    FIGURE 7. Fault-free vs. EWFA GPS L1 C/A signal power spectrum density.
    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 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.
    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 10. Fault-free vs EWFB GPS L1 C/A signal.

     

    FIGURE 11. Fault-free vs EWFB GPS L1 C/A signal power spectrum density.
    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 f0 (40 nanoseconds). Again, spikes appear at intervals of f0, 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 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.
    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 f0 ≈ 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.
    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.
    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.
    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.
    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 18. Fault-free vs EWFB Galileo E1 signal.
    FIGURE 19. Fault-free vs. EWFB Galileo E1 signal power spectrum density.
    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.
    GEMS graphical interface.
    Observation of EWF type A on GPS L1 C/A signal with an oscilloscope.
    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.
    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.
    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 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.
    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.
    Navys hardware equipment – Blackline edition.

    Further Reading

    • Authors’ Conference Paper

    “Generating Evil WaveForms on Galileo Signals using NAVYS” by M. Raimondi, E. Sénant, C. Fernet, R. Pons, and H. AlBitar in Proceedings of Navitec 2012, the 6th ESA Workshop on Satellite Navigation Technologies and the European Workshop on GNSS Signals and Signal Processing, Noordwijk, The Netherlands, December 5–7, 2012, 8 pp., doi: 10.1109/NAVITEC.2012.6423071.

    • Threat Models

    “A Novel Evil Waveforms Threat Model for New Generation GNSS Signals: Theoretical Analysis and Performance” by D. Fontanella, M. Paonni, and B. Eissfeller in Proceedings of Navitec 2010, the 5th ESA Workshop on Satellite Navigation Technologies, Noordwijk, The Netherlands, December 8–10, 2010, 8 pp., doi: 10.1109/NAVITEC.2010.5708037.

    “Estimation of ICAO Threat Model Parameters For Operational GPS Satellites” by A.M. Mitelman, D.M. Akos, S.P. Pullen, and P.K. Enge in Proceedings of ION GPS 2002, the 15th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 24–27, 2002, pp. 12–19.

    • GNSS Signal Deformations

    “Effects of Signal Deformations on Modernized GNSS Signals” by R.E. Phelts and D.M. Akos in Journal of Global Positioning Systems, Vol. 5, No. 1–2, 2006, 9 pp.

    “Robust Signal Quality Monitoring and Detection of Evil Waveforms” by R.E. Phelts, D.M. Akos, and P. Enge in Proceedings of ION GPS-2000, the 13th International Technical Meeting of the Satellite Division of The Institute of Navigation, Salt Lake City, Utah, September 19–22, 2000, pp. 1180–1190.

    “A Co-operative Anomaly Resolution on PRN-19” by C. Edgar, F. Czopek, and B. Barker in Proceedings of ION GPS-99, the 12th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 14–17, 1999, pp. 2269–2271.

    • GPS Satellite Anomalies and Civil Signal Monitoring

    An Overview of Civil GPS Monitoring by J.W. Lavrakas, a presentation to the Southern California Section of The Institute of Navigation at The Aerospace Corporation, El Segundo, California, March 31, 2005.

    • Navys Signal Simulator

    “A New GNSS Multi Constellation Simulator: NAVYS” by G. Artaud, A. de Latour, J. Dantepal, L. Ries, N. Maury, J.-C. Denis, E. Senant, and T. Bany in  Proceedings of ION GPS 2010, the 23rd International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 21–24, 2010, pp. 845–857.

    “Design, Architecture and Validation of a New GNSS Multi Constellation Simulator : NAVYS” by G. Artaud, A. de Latour, J. Dantepal, L. Ries, J.-L. Issler, J. Tournay, O. Fudulea, J.-M. Aymes, N. Maury, J.-P. Julien , V. Dominguez, E. Senant, and M. Raimondi in  Proceedings of ION GPS 2009, the 22nd International Technical Meeting of the Satellite Division of The Institute of Navigation, Savannah, Georgia, September 22–25, 2009, pp. 2934–2941.

  • On the Road under Real-Time Signal Denial

    On the Road under Real-Time Signal Denial

    Testing GNSS-Based Automotive Applications

    Emerging GNSS applications in automobiles support regulation, security, safety, and financial transactions, as well as navigation, guidance, traffic information, and entertainment. The GNSS sub-systems and onboard applications must demonstrate robustness under a range of environments and varying threats. A dedicated automotive GNSS test center enables engineers to design their own GNSS test scenarios including urban canyons, tunnels, and jamming sources at a controlled test site.

    By Mark Dumville, William Roberts, Dave Lowe, Ben Wales, NSL, Phil Pettitt, Steven Warner, and Catherine Ferris, innovITS

    Satellite navigation is a core component within most intelligent transport systems (ITS) applications. However, the performance of GNSS-based systems deteriorates when the direct signals from the satellites are blocked, reflected, and when they are subjected to interference. As a result, the ability to simulate signal blockage via urban canyons and tunnels, and signal interference via jamming and spoofing, has grown fundamental in testing applications.

    The UK Center of Excellence for ITS (innovITS), in association with MIRA, Transport Research Laboratory (TRL), and Advantage West Midlands, has constructed Advance, a futuristic automotive research and development, and test and approvals center. It provides a safe, comprehensive, and fully controllable purpose-built road environment, which enables clients to test, validate and demonstrate ITS. The extensive track layout, configurable to represent virtually any urban environment, enables the precise specification of road conditions and access to infrastructure for the development of ITS innovations without the usual constraints of excessive set up costs and development time.

    As such, innovITS Advance has the requirement to provide cityscape GNSS reception conditions to its clients; a decidedly nontrivial requirement as the test track has been built in an open sky, green-field environment (Figure 1).

    Figure 1 innovITS Advance test circuit (right) and the environment it represents (left).
    Figure 1. innovITS Advance test circuit (right) and the environment it represents (left).

    NSL, a GNSS applications and development company, was commissioned by innovITS to develop Skyclone in response to this need. The Skyclone tool is located between the raw GNSS signals and the in-vehicle system. As the vehicle travels around the Advance track, Skyclone modifies the GNSS signals to simulate their reception characteristics had they been received in a city environment and/or under a jamming attack. Skyclone combines the best parts of real signals, simulated scenarios, and record-and-replay capabilities, all in one box. It provides an advanced GNSS signal-processing tool for automotive testing, and has been specifically developed to be operated and understood by automotive testing engineers rather than GNSS experts.

    Skyclone Concept

    Simulating and recreating the signal-reception environment is achieved through a mix of software and hardware approaches. Figure 2 illustrates the basic Skyclone concept, in which the following operations are performed.

    • In the office, the automotive engineer designs a test scenario representative of a real-world test route, using a 3D modelling tool to select building types, and add tunnels/underpasses, and jammer sources. The test scenario is saved onto an SD card for upload onto the Skyclone system.
    • The 3D model in Skyclone contains all of the required information to condition the received GNSS signals to appear to have been received in the 3D environment.
    • The Skyclone system is installed in a test vehicle that receives the open-air GNSS signals while it is driven around the Advance track circuit.
    • The open-air GNSS signals are also received at a mobile GNSS reference receiver, based on commercial off-the-shelf GNSS technology, on the test vehicle. It determines the accurate location of the vehicle using RTK GNSS. The RTK base station is located on the test site.
    • The vehicle’s location is used to access the 3D model to extract the local reception conditions (surrounding building obstructions, tunnels attenuations, jamming, and interference sources) associated with the test scenario.
    • Skyclone applies satellite masking, attenuation, and interference models to condition/manipulate raw GNSS signals received at a second software receiver in the onboard system. The software receiver removes any signals that would have been obstructed by buildings and other structures, and adds attenuation and delays to the remaining signals to represent real-world reception conditions. Furthermore, the receiver can apply variable interference and/or jamming signatures to the GNSS signals.
    • The conditioned signals are then transmitted to the onbaord unit (OBU) under test either via direct antenna cable, or through the air under an antenna hood (acting as an anechoic chamber on top of the test vehicle). Finally, the GNSS signals produced by Skyclone are processed by the OBU, producing a position fix to be fed into the application software.
    Figure 2. Skyclone system concept.
    Figure 2. Skyclone system concept.

    The Skyclone output is a commercial OBU application that has been tested using only those GNSS signals that the OBU receiver would have had available if it was operating in a real-world replica environment to that which was simulated within the Skyclone test scenario.

    Skyclone Architecture

    The Skyclone system architecture (Figure 3) consists of five principal subsystems.

    Office Subsystem Denial Scenario Manager. This software has been designed to allow users to readily design a cityscape for use within the Skyclone system. The software allows the users to select different building heights and styles, add GNSS jamming and interference, and select different road areas to be treated as tunnels.

    Figure 3. Baseline Skyclone system architecture.
    Figure 3. Baseline Skyclone system architecture.

    City Buildings. The Advance test site and surrounding area have been divided into 14 separate zones, each of which can be assigned a different city model. Ten of the zones fall inside of the test road circuit and four are external to the test site. Each zone is color-coded for ease of identification (Figure 4).

    Figure 4. Skyclone city zones.
    Figure 4. Skyclone city zones.

    The Skyclone system uses the city models to determine GNSS signal blockage and multipath for all positions on the innovITS Advance test site. The following city models, ordered in decreasing building height and density, can be assigned to all zones: high rise, city, semi urban, residential, and parkland.

    Interference and Jamming. GNSS jamming and interference can be applied to the received GNSS signals. Jamming is set by specifying a jamming origin, power, and radius. The power is described by the percentage of denied GNSS signal at the jamming origin and can be set in increments of 20 percent. The denied signal then decreases linearly to the jammer perimeter, outside of which there is no denial.

    The user can select the location, radius, and strength of the jammer, can select multiple jammers, and can drag and drop the jammers around the site.

    Tunnels. Tunnels can be applied to the cityscape to completely deny GNSS signals on sections of road. The user is able to allocate “tunnels” to a pre-defined series of roads within the test site. The effect of a tunnel is to completely mask the sky from all satellites.

    Visualization. The visualization display interface (Figure 5) provides a graphical representation of the scenario under development, including track layout, buildings, locations, and effects of interference/jammers and tunnels. Interface/jammer locations are shown as hemispherical objects located and sized according to user definition. Tunnels appear as half-cylinder pipes covering selected roads.

    Figure 5. 3D visualisation display.
    Figure 5. 3D visualisation display.

    Reference Subsystem

    The reference subsystem obtains the precise location of the test vehicle within the test site. The reference location is used to extract relevant vehicle-location data, which is used to condition the GNSS signals.

    The reference subsystem is based on a commercial off-the-shelf real-time kinematic GPS RTK system, capable of computing an accurate trajectory of the vehicle to approximately 10 centimeters. This position fix is used to compute the local environmental parameters that need to be applied to the raw GNSS signals to simulate the city scenario.

    A dedicated RTK GNSS static reference system (and UHF communications links) is provided within the Skyclone system. RTK vehicle positions of the vehicles are also communicated to the 4G mesh network on the Advance test site for tracking operational progress from the control center.

    Vehicle Subsystem

    The vehicle subsystem acquires the GNSS signals, removes those that would be blocked due to the city environment (buildings/tunnels), conditions remaining signals, applies interference/jammer models, and re-transmits resulting the GNSS signals for use by the OBU subsystem.

    The solution is based on the use of software GNSS receiver technology developed at NSL. In simple terms, the process involves capturing and digitizing the raw GNSS signals with a hardware RF front end. Figure 6 shows the system architecture, and Figure 7 shows the equipment in the innovITS demonstration vehicle.

    Figure 6. Skyclone hardware architecture.
    Figure 6. Skyclone hardware architecture.

    The digitized signals are then processed in NSL’s software receiver running on a standard commercial PC motherboard. The software receiver includes routines for signal acquisition and tracking, data demodulation and position determination.

    In the Skyclone system, the raw GNSS signals are captured and digitized using the NSL stereo software receiver. The software receiver determines which signals are to be removed (denied), which signals require conditioning, and which signals can pass through unaffected. The subsystem does this through accurate knowledge of the vehicle’s location (from the reference subsystem), knowledge of the environment (from the office subsystem), and knowledge of the satellite locations (from the vehicle subsystem itself).

    The Skyclone vehicle subsystem applies various filters and produces a digital output stream. This stream is converted to analog and upconverted to GNSS L1 frequency, and is sent to the transmitter module located on the same board.

    The Skyclone transmitter module feeds the analog RF signal to the OBU subsystem within the confines of a shielded GPS hood, which is attached to the vehicle on a roof rack.  An alternative to the hood is to integrate directly with the cable of the OBU antenna or through the use of an external antenna port into the OBU.  The vehicle subsystem performs these tasks in near real-time allowing the OBU to continue to incorporate non-GNSS navigation sensors if applicable.

    Onboard Unit Subsystem

    The OBU subsystem, typically a third-party device to be tested, could be a nomadic device or an OEM fitted device, or a smartphone. It typically includes a GNSS receiver, an interface, and a software application. Examples include:

    • Navigation system
    • Intelligent speed adaptation system
    • eCall
    • Stolen-vehicle recovery system
    • Telematics (fleet management) unit
    • Road-user charging onboard unit
    • Pay-as-you-drive black-box
    • Vehicle-control applications
    • Cooperative active safety applications
    • Vehicle-to-vehicle and vehicle-to-infrastructure systems.

    Tools Subsystem Signal Monitor

    The Skyclone Monitor tool provides a continuous monitoring service of GNSS performance at the test site during tests, monitoring the L1 frequency and analyzing the RF singal received at the reference antenna. The tool generates a performance report to provide evidence of the open-sky GNSS conditions. This is necessary in the event of poor GNSS performance that may affect the outcome of the automotive tests. The Skyclone Monitor (Figure 8) is also used to detect any spurious leaked signals which will highlight the need to check the vehicle subsystem. If any spurious signals are detected, the Skyclone system is shut down so as to avoid an impact on other GNSS users at the test site. A visualization tool (Visor) is used for post-test analysis displaying the OBU-determined position alongside the RTK position within the 3D environment.

    Figure 8. GNSS signal and positioning monitor.
    Figure 8. GNSS signal and positioning monitor.
    Figure 9. 3D model of city.
    Figure 9. 3D model of city.

    Performance

    Commissioning of the Skyclone system produced the following initial results. A test vehicle was installed with the Skyclone and RTK equipment and associated antennas.. The antennas were linked to the Skyclone system which was installed in the vehicle and powered from a 12V invertor connected to the car power supply. The output from the RTK GPS reference system was logged alongside the output of a commercial third-party GNSS receiver (acting as the OBU) interfaced to the Skyclone system. Skyclone was tested under three scenarios to provide an initial indication of behavior: city, tunnel, and jammer.

    The three test cenarios were generated using the GNSS Denial Scenario Manager tool and the resulting models stored on three SD cards. The SD cards were separately installed in the Skyclone system within the vehicle before driving around the test site.

    City Test. The city scenario consisted of setting all of the internal zones to “city” and setting the external zones to “high-rise.”

    Figure 10A represents the points as provided by the RTK GPS reference system installed on the test vehicle. Figure 10B includes the positions generated by the COTS GPS OBU receiver after being injected with the Skyclone output. The effect of including the city scenario model is immediately apparent. The effects of the satellite masking and multipath model generate noise within the position tracks.

    Figure 10A. City scenario: no Skyclone.
    Figure 10A. City scenario: no Skyclone.
    Figure 10B. City scenario: withSkyclone.
    Figure 10B. City scenario: withSkyclone.

    Tunnel Test. The tunnel scenario consists of setting all zones to open sky. A tunnel is then inserted along the central carriageway (Figure 11). A viewer location (depicted by the red line) has been located inside the tunnel, hence the satellite masking plot in the bottom right of Figure 11 is pure red, indicating complete masking of satellite coverage. The output of the tunnel scenario is presented in Figure 12. Inclusion of the tunnel model has resulted in the removal of all satellite signals in the area of track where the tunnel was located in the city model. The color shading represents signal-to-noise ratio (SNR), an indication of those instances where the output of the test OBU receiver has generated a position fix with zero (black) signal strength, hence the output was a prediction. Thus confirming the tunnel scenario is working correctly.

    Figure 11. 3D model of tunnel.
    Figure 11. 3D model of tunnel.
    Figure 12. Results.
    Figure 12. Results.

    Jammer Test. The jammer test considered the placement of a single jammer at a road intersection (Figure 13). Two tests were performed, covering low-power jammer and a high-power jammer. Figure 14A shows results from the low-power jammer. The color shading relates to the SNR as received within the NMEA output from the OBU, which continued to provide an output regardless of the jammer. However, the shading indicates that the jammer had an impact on signal reception.

    Figure 13. Jammer scenario.
    Figure 13. Jammer scenario.
    Figure 14 Jammer test results: top, low power interference; bottom, high-power interference.
    Figure 14A. Jammer test results: low power interference.
    Figure 14 Jammer test results: top, low power interference; bottom, high-power interference.
    Figure 14B. Jammer test results: high-power interference.

    In contrast the results of the high-power jammer (Figure 14B) show the effect of a jammer on the OBU output. The jammer denies access to GNSS signals and generates the desired result in denying GNSS signals to the OBU. Furthermore, the results exhibit features that the team witnessed during real GNSS jamming trials, most notably the wavering patterns that are output from GNSS receivers after they have regained tracking following jamming, before their internal filtering stabilizes to nominal behaviors.

    The Future

    The Advance test site is now available for commercial testing of GNSS based applications. Current activity involves integrating real-world GNSS jammer signatures into the Skyclone design tool and the inclusion of other GNSS threats and vulnerabilities.

    Skyclone offers the potential to operate with a range of platforms other than automotive. Unmanned aerial systems platforms are under investigation. NSL is examining the integration of Skyclone features within both GNSS simulators as well as an add-on to record-and-replay tools. This would enable trajectories to be captured in open-sky conditions and then replayed within urban environments.

    Having access to GNSS signal-denial capability has an immediate commercial interest within the automotive sector for testing applications without the need to invest in extensive field trials. Other domains can now benefit from such developments. The technology has been developed and validated and is available for other applications and user communities.

  • GNSS Test Standards for Cellular Location

    GNSS Test Standards for Cellular Location

    Downtown Seattle, a typical test-case environment.
    Downtown Seattle, a typical test-case environment.

    Multi-Constellations Working in a Dense Urban Future

    GNSS receivers in cell phones will soon support four or more satellite constellations and derive additional location measurements from other sources: cellular location, MEMS sensors, Wi-Fi, and others. The authors propose test standards covering these sources, meeting industry requirements for repeatable testing while considering the user experience.

    By Peter Anderson, Esther Anyaegbu, and Richard Catmur

    Cellular location test standards include well-defined and widely used standards for GPS-based systems in both the 3rd Generation Partnership Program cellular technologies of GSM/WCDMA/LTE, typically referenced as the 3GPP standards, and for CDMA technologies in the 3GPP2 standards. These standards provide a reference benchmark for location performance in the laboratory, when the unit under test is directly connected to the test system via a coax connection. In addition, standards are being rolled out, such as the CTIA ­— The Wireless Association total isotropic sensitivity (TIS) requirement, for over-the-air (OTA) testing and developed further with LTE A-GPS OTA using SUPL 2.0. These tests are typically performed in an anechoic chamber and allow the performance of the antenna to be included.

    Recently developed standards such as the 3GPP Technical Specification (TS) 37.571-1 cover multi-constellation systems, typically GPS and GLONASS for a two-constellation system, or GPS, GLONASS and Galileo for a three-constellation system, with options for additionally supporting QZSS and space-based augmentation system (SBAS) satellites. During 2014, the standards will encompass additional constellations such as the BeiDou satellite system.

    Figure 1A. GNSS systems available in the 2015-2020 timescale.
    Figure 1A. GNSS systems available in the 2015-2020 timescale.
    Figure 1B. GNSS systems available in the 2015-2020 timescale.
    Figure 1B. GNSS systems available in the 2015-2020 timescale.

    Significant change is also happening with the additional technologies such as cellular location, Wi-Fi, and micro-electromechanical systems (MEMS) sensors providing location information. Hybrid solutions using all/any available location information from these multiple technologies present significant challenges to both the test environment and the related test standards.

    The acceptance levels required for the platform integrators and their customers are becoming much more stringent, as the use cases of the location become more diverse. These present further challenges to the performance requirements for test standards for cellular location.

    Measuring Performance

    The rapid growth in the GNSS applications market has driven users to demand improvements in the performance and reliability of GNSS receivers. The test standards currently employed by cellular phone and network manufacturers to evaluate the performance of GNSS receivers are even more stringent than the regulatory mandates for positioning of emergency callers and other location-based services. Emergency-call positioning is an example of a service that must provide a position fix in both outdoor and indoor environments.

    A user’s experience with a GNSS receiver begins when he switches on the device. The quality of his experience defines the basic performance criteria used to assess the performance of a GNSS receiver.

    • How long did it take to get a position fix?
    • How accurate is the position fix?
    • When the fix is lost, how long did it take the device to reacquire satellites and re-compute the fix?

    These expectations  define the performance of the GNSS receiver. Manufacturers use these performance metrics to compare the performance of different GNSS receivers.

    The receiver’s time-to-first-fix (TTFF) depends on the initial conditions; that is, the type of acquisition aiding data (almanac data, ephemerides, knowledge of time and frequency, and so on) available to the receiver when it is switched on.

    Users now expect location-based applications to work regardless of where they are and whether they are in a fixed location or on the move. They expect the same level of performance when they are indoors at home or at work, as outdoors in a rural or urban environment. This has led to an increased demand for accurate and reliable outdoor and indoor positioning.

    Reacquisition time — how quickly a receiver recovers when the user goes through a pedestrian underpass or under a tunnel or a bridge, for instance — is not tested in any of the existing test standards discussed here.

    The useable sensitivity of any GNSS receiver is key to its performance. It defines the availability of a GNSS positioning fix. The acquisition sensitivity defines the minimum received power level at which the receiver can acquire satellites and compute a position fix, while the tracking sensitivity of a receiver defines the minimum received power level at which a GNSS receiver is still able to track and maintain a position fix.

    Different applications use different criteria to characterize the performance of a GNSS receiver. In an E911 scenario, for instance, position accuracy and response time are critical, whereas for navigation while driving, accuracy and tracking sensitivity are important. The test criteria employed by different manufacturers are intended to verify the suitability of a particular device for the required application.

    The initial test conditions are defined by the manufacturers to ensure that the different devices are tested in the same way. These conditions describe how the test sessions are started, and what acquisition aiding data are available at the start of the test session.

    The main divisions among performance tests are:

    • Laboratory-based tests, either conducted versus OTA RF testing, or simulated versus record-and-playback signal testing.
    • Real-world testing (field testing). This can be difficult because the test conditions are never the same. Fortunately, it is possible to record these scenarios using an RF data recorder. This allows the same real-world scenario (with the same test conditions) to be tested repeatedly in the lab.
    • Static scenario testing versus moving scenario testing.
    • Comparison tests — relative testing (comparing one receiver against another): for reported signal-to-noise ratio (SNR), reported accuracy, and repeatability tests.

    Current GNSS Test Standards

    Varying performance requirements test the TTFF, accuracy, multipath tolerance, acquisition, and tracking sensitivity of the GNSS receiver. The first three following are industry-defined test standards:

    3GPP2 CDMA Performance Standards. The 3GPP2 CDMA test standards (C.S0036-A) are similar to the 3GPP test standards. The 3GPP2 is for CDMA cellular systems, which are synchronized to GPS time.

    3GPP GNSS Performance Standards. The latest 3GPP TS 37.571-1 test standard describes the tests for the minimum performance requirements for GNSS receivers that support multi-constellations. It is slightly more stringent than the original 3GPP TS 34.171 test standard. In the 3GPP TS 37.571-1 coarse-time sensitivity test case, signals for only six satellites are generated, whereas in the TS 34.171 coarse-time sensitivity scenario, signals for eight satellites are generated.

    Table 1 shows the power levels and satellite allocation for a multi-constellation 3GPP TS 37.571-1 coarse-time sensitivity test case. In this scenario, the pilot signal will always be GPS, if GPS is supported. The signal level of the pilot signal for GPS and GLONASS have been set as –142 dBm, while the non-pilot signal level for GPS and GLONASS have been set as –147 dBm.

    Table 1. 3GPP TS 37.571-1 Satellite allocation.
    Table 1. 3GPP TS 37.571-1 Satellite allocation.

    For the 3GPP TS 37.571-1 fine-time assistance test case, six satellites are generated. For the dual-constellation fine-time test, the split is 3+3, and for a triple-constellation test case, the split is 2+2+2, as shown in Table 2.

    Table 2. 3GPP TS 37.571-1 fine-time satellite allocation.
    Table 2. 3GPP TS 37.571-1 fine-time satellite allocation.

    OTA Requirements. Testing standards have been rolled out for OTA testing, where the testing is typically performed in an anechoic chamber, allowing antenna performance to be included, with tests for the receive sensitivity referenced to an isotropic antenna and over partial summations such as the upper hemisphere. They measure the TIS of the final receiver, and operator requirements typically require  OTA acquisition sensitivity of –140 dBm and tracking sensitivity of –145 dBm or lower.

    Other modified test standards used by manufacturers to assess the performance of the GNSS receiver include:

    Nominal Accuracy Margin Test. This test is based on the 3GPP nominal accuracy test case. All signals are reduced in steps of 1 dB till the test fails to achieve a fix in 20 seconds.

    Dynamic Range Margin Test. This test is based on the 3GPP dynamic range test case. All signals are reduced in steps of 1 dB till the test fails to achieve a fix in 20 seconds.

    Sensitivity Coarse-Time Margin Test. This test is based on the 3GPP sensitivity coarse-time test case. Both the pilot and non-pilot signals are reduced in steps of 1dB till the test fails to achieve a fix in 20 seconds.

    Pilot Sensitivity Coarse-Time Margin Test. This test is based on the 3GPP coarse-time sensitivity test case. The non-pilot signals are always kept at –152 dBm while the signal level of the pilot signal is reduced in steps of 1 dB till the test fails to achieve a fix in 20 seconds.

    Non-Pilot Sensitivity Coarse-Time Margin Test. This test is based on the 3GPP coarse-time sensitivity test case. In this test, the pilot signal is always kept at –142 dBm while the signal levels of the other seven non-pilot signals are reduced in steps of 1 dB till the test fails to achieve a fix in 20 seconds.

    These modified performance tests are used because they map directly to the end-user’s experience in the real world, measuring the position accuracy, response time, and sensitivity of the GNSS receiver.

    Current Equipment. The equipment required for the current test standards are all GNSS multi-satellite simulator-based, either using a single constellation (for GPS), or a multi-constellation GNSS simulator as a component of a larger cellular test system.

    Limitation of Current Standards

    So far, tests for GNSS in cellular devices have been very much customer/manufacturer specific, starting with 3GPP-type tests, but adding to them. Each will have its own preferred type of tests, with different configurations and types of tests. They have included primarily GNSS simulator tests, either directly connected to the device under test or using radiated signals, together with some corner cases. With chips such as the ST-Ericsson CG1960 GNSS IC, this means that different tests need to be performed for each customer.

    Typically the tests are focused on cold or hot TTFF type tests, or sensitivity type tests. Live signal tests have typically been used for drive tests, with a receiver being driven around an appropriate test route, normally in an urban environment. More recently RF replays have become much more widely used, but do require truth data to give validity. RF replay tests are typically used for specific difficult routes for urban drive tests or pedestrian tests.

    The 3GPP types of test standards were developed to provide a simple set of repeatable tests. However, they are idealistic, and they do not relate closely to any real-world scenario, and the test connection is defined to be at the antenna port of the system. In reality, different manufacturers and network operator standards take these tests as a given, and define margins on the tests to allow for typical losses due to antennas and implementation on a platform. These margins might be as much as 8 or 10 dB. In addition, manufacturers and network operators define their own variants of the 3GPP tests to match typical real-world usage cases, such as deep indoor.

    Challenges

    Current location test specifications assume that the key input to the location calculation is always the GPS constellation. With the rise of additional constellations and alternative location sources, and the challenges of the urban environment, GPS will be one of many different inputs to the location position. The key for the future will be for standards focused on testing location performance, irrespective of which constellations are visible, and also being able to fully test the system performance. Tests will be suggested that allow the basic functionality of a system to be checked, but can be enhanced to stress-test the performance of a receiver. As future location systems will use all available inputs to produce a location, there will be challenges to the supporting test standards and test equipment to handle all of these in parallel.

    The initial challenge for location test standards has been the use of GNSS constellations in addition to GPS. Current leading GNSS receivers in cellular devices make use of GPS, GLONASS, SBAS, and QZSS, and network-aiding information for A-GLONASS is being rolled out in the cellular networks. The 3GPP TS 37.571-1 specification has been derived from the original GPS-only specification TS 34.171, with the addition of GLONASS and Galileo constellation options. These allow single-, dual-, or triple-constellation tests to be performed. If there is GPS in the system, then GPS is viewed as the primary constellation, and tests like the sensitivity coarse-time assistance test would have a satellite from the GPS constellation with the highest signal level. The test standards also accommodate the use of some satellites from SBAS such as WAAS and QZSS. These tests require that the performance shall be met without the use of any data coming from sensors that can aid the positioning.

    This is only the first stage in the rollout of new GNSS constellations, and in the near future, GNSS receivers in cellular phones will support four or more constellations, and possibly also on frequencies additional to the L1 band, covering some or all of: GPS, GLONASS, Galileo, BeiDou Phase 2, BeiDou Phase 3, QZSS, SBAS, and IRNSS.

    Table 3. Suggested four-constellation mix (Pilot signal to rotate round constellations).
    Table 3. Suggested four-constellation mix (Pilot signal to rotate round constellations).

    The challenge for the minimum-performance specifications is to accommodate these different constellations as they become fully available. For the new constellations, this will initially be purely simulator-based, but could be extended to use of live data for certain test cases as the constellations are built up. A further challenge for the test specifications is that some of the systems are regionally based, so a performance specification based on a global approach is not applicable.

    Further, tests must be severe enough to stress the receiver. With multiple constellations, it can be simple to pass a test without using all available satellites or constellations.

    Other Location Sources (Hybrid Solution). Within the cellular platform, location can be provided by a number of different technologies, either separately or compositely, to provide a location to the accuracy required by the user. Technologies currently available include:

    • Cellular network: cell ID and cell network triangulation
    • LTE Positioning Protocol
    • Fine time assistance (for aiding)
    • Wi-Fi network name (service set identifier, or SSID)
    • Wi-Fi ranging
    • MEMS sensors
    • Near-field communication
    • Bluetooth
    • Pseudolites, other beacons, coded LED lights, and so on.

    Real-World Environments. Measuring performance in a real environment is becoming much more important, as the user experience becomes much more key. The product must not only pass particular specifications, but must also meet customer expectations. In the age of the blog, negative customer feedback can damage a product’s reputation. But with the various GNSS constellations and other sources of location information, performance testing is growing significantly in complexity, and test standards needed to cover this complexity will also become more complex. The simple user criteria could be stated as “I want the system to provide a rapid, accurate position wherever I am.” But how accurate?

    The end-user of a location system does not use a GNSS simulator with clean signals, but a location device with live signals, often in difficult environments. This has been recognized by platform integrators, and live test routes for both urban drive and urban pedestrian routes are now required. The performance required of the receiver in these locations has also changed, from “just need to get a fix of limited accuracy” to getting accurate location information, both from a fix (even from a cold start in a built-up area), to continuous navigation (better than 30-meter accuracy 99 percent of the time) throughout a test run.

    Typical environments for these test cases include locales in many major cities, such as the environment in the OPENING PHOTO  of Seattle and one shown here of Seoul, Korea.

    Seoul, Korea, a typical test-case environment.
    Seoul, Korea, a typical test-case environment.

    Coexistence and Interference. Recent controversies have raised the profile of GNSS interference from other wireless technologies. However, within the cellular platform, significant coexistence and potential interference issues are already present. These can occur due to adjacent channel interference, or from harmonics of cellular frequencies on the platform, for example, the second harmonic of the uplink channel for LTE Band 13 overlays the BeiDou-2 frequency of 1561MHz, and the second harmonics of both Bands 13 and 14 create out-of-band emissions in the GPS band (Figures 2 and 3).

    Figure 2. BeiDou and LTE bands 13/14.
    Figure 2. BeiDou and LTE bands 13/14.
    Figure 3. GPS and LTE bands 13/14.
    Figure 3. GPS and LTE bands 13/14.

    Test Proliferation. The increase in the number of GNSS constellations together with the use of other location sources to provide a hybrid solution could increase the number of tests to be performed exponentially. When this is then combined with the need to test over a range of simulated and real-world locations, together with customer specific requirements, a set of tests could easily take weeks to run. It is therefore important to ensure that the cellular location test standards are carefully constructed to not significantly proliferate the number and time for tests to be performed.

    Future Test Equipment

    A new generation of test equipment is emerging to meet the new challenges and requirements of multi-constellation GNSS and hybrid location systems. These include:

    GNSS Simulators. Simulators currently provide up to three GNSS constellations, together with augmentation systems. With the roll-out of BeiDou-2, four-constellation simulators will now be required. Currently all GNSS devices integrated in cellular platforms use the L1 band. This will also potentially change to multi-frequency use. The appropriate GNSS simulator will need to be included in the cellular test system.

    New Hybrid Test Systems. As the need for testing hybrid positioning systems in cellular devices emerges, hybrid location test systems (HLTS) are becoming available that can simulate and test hybrids of A-GNSS, Wi-Fi, MEMS sensors, and cellular positioning technologies, all in one system.

    Today, these test systems use separate simulators for the different individual technologies (like GNSS, Wi-Fi, and so on), but these are now being merged into multi-system simulators that combine a number of different technologies into one device (see Figure 4).
    RF Replay. The use of RF replay units for replicating live trials is already widespread. This will extend with further constellations and further frequency bands.

    The advantages of using RF recorded data include:

    • Gives real-world data, which if the location is chosen carefully will stress the device under test;
    • Allows use of recorded test data from several/many urban locations;
    • Good for drive and pedestrian test applications;
    • Will be integrated in the HLTS type of test system.

    The disadvantages of using RF recorded data include:

    • Results not deterministic;
    • Taken at one point in time, do not allow for future development of satellite constellations;
    • Proprietary recording devices, difficult to define a standard;
    • Need to include an inertial measurement unit (IMU) to get accurate truth data.

    The difficulties of using RF replays include:

    • Successfully integrating all the signal environment (cellular, Wi-Fi, MEMS, and so on);
    • Multiple runs required to give reliable data (for example, 13 runs at different times of day to give a range of satellite geometry and user speed, between rush hour and middle of night);
    • Multiple locations required to stress the system;
    • Test time can be up to a day of real-time testing to re-run tests on one location.

    Proposal for Hybrid Positioning

    Tests should include a mixture of simulator-based tests, RF-replay-based tests, and live tests. This would comprise the following suite:
    GNSS Performance Tests. The 3GPP type of tests (TS 37.571-1) are a good starting point for a minimum performance test, but they rely on the person running the test to define the number of constellations. To automate this, there could be a single test at the start of each test sequence to identify which constellations are supported (one to four), and then the formal test run for that mix of constellations. The constellations supported should be reported as part of the test report.

    An option should be provided to allow margin tests for specific tests to be run, and these should again be reported in a standard method in the test report, specifying how far the device under test exceeds the 3GPP test. The typical margins expected for a GPS-only test would be between 8 and 10 dB in the 2014 timeframe. For a multi-constellation test, it will depend on the specific constellations used, but could be between 5 and 8 dB margin.

    Ideally, a multipath scenario should be created that more closely matches the environment seen in a real urban environment.
    Hybrid Location Tests. The main purpose of the hybrid location test is to prove that the different components of a cellular platform providing location are all operating correctly. A basic test would provide a sequence where the different combinations providing location are tested for correct operation separately, and then together. This would not be envisaged as a complete stress test, but each technology should be running in a mode where a location solution is not simple.

    A simple example sequence of tests would be:

    • GNSS performance test;
    • Cell ID static test;
    • Wi-Fi SSID static test
    • Cell ID and Wi-Fi SSID static test
    • Cell ID and GNSS static test (GNSS –142 dBm)
    •  Wi-Fi SSID and GNSS static test (GNSS –142 dBm)
    • Cell ID, Wi-Fi SSID, and GNSS static test (GNSS –142 dBm)
    • Cell ID, Wi-Fi SSID, GNSS, and sensors moving test.

    See how easily tests can proliferate!

    A more stringent test could then be performed to stress-test the performance if required, and if required a playback test could be performed (see RF Replay test below).

    The additional location sources can also aid in providing initial states and information for the position-determination system, in addition to the common assisted-GNSS information provided by the network. This will be particularly important in indoor and other environments where GNSS performance is compromised.

    Further developments such as the LTE Positioning Protocol Extensions (LPPe) from the Open Mobile Alliance will also allow the sending of additional information to the device to improve the accuracy of the position. This additional information could include accurate time, altitude information, and other parameters. Future assistance standards should enhance the use of this information, and test standards should verify the correct use of this information.

    RF Replay (or Playback) Tests. GNSS performance is statistical, and it is important to ensure that any tests have sufficient breadth and repetition to ensure statistical reliability. This applies to the more normal standard simulator tests, as well as to the uses of tests in the urban environment. For example, performance in the urban environment can vary significantly between two closely spaced runs, and can also be very dependent on the time of the day. A test done in the daytime may hit rush-hour traffic, whereas tests done at night will have relatively free flow, and hence faster average speeds. Additionally, the space-vehicle constellation geometry is constantly changing, which can enhance or degrade the GNSS performance. These factors need to be considered in generating any test routes.

    For RF replay tests, a number of specific locations for urban driving and pedestrian routes should be specified. These locations should be based on network-operator test requirements, and include a mixture of suburban and deep urban environments (such as Tehran Street, Seoul). For each location, ten different data sets should be used, captured at different times, including peak rush hour at a specified hour. The data set should also include separate high-performance IMU data to provide truth data. To provide test consistency, a golden-standard data set should be used. But with different suppliers this would be difficult.

    For pedestrian tests, a similar number of different routes should be defined, and data captured similarly. Ideally, all data useable for a hybrid solution should be captured, and available for replay. The test criteria analyzed for this could include: yield; horizontal position error, along-track error, across-track error, heading error, and speed error.

    Interference Tests with Different Cellular Bands. It is important to have a standard test to demonstrate that the device under test does not have performance degradation due to interference from particular cellular subsystems interfering with the GNSS. For this test, the device should be tested in an OTA environment to ensure that all interference coupling mechanisms are present. Two tests should be performed: first, a tracking test. In this the A-GPS performance is tested by measuring the GNSS carrier-to-noise ratio for each GNSS band, while all the wireless channels on the platform are exercised sequentially. The test result would indicate the maximum number of dBs degradation that occurs.

    Second, a cold-start test at –140 dBm should be performed separately while each wireless channel on the platform is exercised. Any extension in cold-start TTFF should be noted.

    Conclusions

    The challenges for cellular location test standards have increased significantly with the availability of new GNSS constellations, and the use of all available technologies within the cellular platform to provide the best appropriate location for the required use case. For test standards to be relevant, and also able to be run in an appropriate time, they must consider both the requirements to prove that the appropriate technology is operating correctly, and also bear a relationship to the final system performance required. This means, for example, that a multi-constellation GNSS receiver is really using all the constellations appropriately, and also that the end-user performance requirement is considered.

    Existing cellular test standards are minimum performance requirements, but future standards should encapsulate the minimum performance requirements while also allowing standard extension to provide a consistent performance description.
    Further to this, platform performance must be proved in all standing operating modes, which means, for example, that the cellular system be checked when operating in all supported bands.

    Test equipment to support future cellular test standards is in development, but the significant challenges will be in providing equipment to fully support urban drive and pedestrian performance requirements.

    In conclusion, the ability to appropriately test a hybrid location system, comprising multi-constellation GNSS and additional location technologies, presents almost as many challenges as generating the hybrid solution in the first place.

    Acknowledgments

    Many thanks to the GNSS team at ST-Ericsson, and at Spirent, and also to our customers for the challenges that they have presented as the required location performances have changed and increased.

    Manufacturers

    Figure 4 is taken from a Spirent Hybrid Location Test System (HLTS).


    Peter Anderson received master’s degrees in electrical sciences from Cambridge University and in microelectronics from Durham University. Until recently, he was a GPS systems manager and the GNSS Fellow at ST-Ericsson; he is now a consultant with PZA Systems Ltd.

    Esther Anyaegbu is a senior systems architect at ST-Ericsson. She earned her Ph.D. in data communications systems from the University of Leeds, where she focused on the processing of GNSS signals in the frequency domain.

    Richard Catmur is head of standards development at Spirent Communications. He holds an M.A. in engineering science from Oxford University. He has served as rapporteur, editor, or major contributor to all 3GPP and OMA standards on the testing of positioning in wireless devices.

  • 2013 Simulator Buyers Guide

    Photo: CAST Navigation
    CAST Navigation
    CAST-SGX GPS Satellite Simulator

    CAST Navigation

    CAST-SGX GPS Satellite Simulator

    The SGX GPS satellite signal simulator from CAST Navigation provides the user with dynamic, repeatable GPS RF signals for use in the laboratory or in the field for a wide range of GPS applications. The SGX simulator is housed in a portable, lightweight handheld enclosure measuring 7 × 11× 3 inches and weighing just over 4 pounds.

    The SGX replaces the CAST-SIMCOM simulator, a 17-inch, 50-pound simulator. The SGX is lightweight, portable, operates on AC or battery power, features 16 channels of L1 C/A- and P-codes, and is extremely accurate and repeatable. It is based on CAST technology that has been developed for use in the company’s larger military products.

    The SGX is controlled via an intuitive touchscreen interface that allows the user to select start and stop scenarios, change screen views, and change satellite RF power levels while a scenario is running. Three test scenarios are delivered with the simulator.

    XGen Scenario Generation Software. This optional software gives the user the ability to generate custom scenarios for use with the SGX. The software allows for complete control over GPS almanac, ephemeris, and all satellite error sources, including multipath. The user can select from a variety of vehicle types and simulate static or dynamic motion for land, sea, air, and space-based vehicles. The user may also employ antenna gain patterns and vehicle silhouettes.

    www.castnav.com
    phone: 978 858-0130
    email: [email protected]

    Photo: IFEN Inc.
    IFEN Inc.
    NavX-NCS Professional / Essential

    IFEN Inc.

    NavX-NCS Professional / Essential

    IFEN Inc., located in California, offers the IFEN NavX-NCS (Navigation Constellation Simulator), a premium-grade RF GNSS simulator. It is available in either the Essential or Professional version, tailored to the customer’s individual test and research needs.
    The NavX-NCS Essential simulates dynamic and static GNSS scenarios with up to 42 channels in the upper L-band (such as GPS / SBAS L1, GLONASS G1, Galileo E1, BeiDou B1, and QZSS / IMES L1) and is designed mainly for product testing and system integration.

    The NavX-NCS Professional offers up to 108 signal channels in virtually all frequencies and signals. Superior simulation options such as various feared events can be performed by the NavX-NCS Professional.
    Both versions of NavX-NCS offer high precision and numerous simulation options. Intuitive, user-friendly software makes test scenarios easy, fast, and clear, whether pre-defined or set up individually.

    These IFEN simulators have a unique modular hardware and software architecture, which offers great flexibility when it comes to changes in a company’s strategic test requirements. Every NavX-NCS is fully upgradeable, not only in the number of RF signal channels or available frequencies, but in a possible subsequent supplement of up to four RF outputs.

    www.ifen.com, Mark Wilson, VP Sales
    phone: 951-739-7331
    email: [email protected]

    Photo: Aeroflex
    Aeroflex
    GPSG-1000: Portable GPS/Galileo/SBAS Positional Simulator

    AeroFlex

    GPSG-1000: Portable GPS/Galileo/SBAS Positional Simulator

    Designed to be a versatile yet affordable satellite simulator, the GPSG-1000 is used by those validating and testing GNSS receivers in a variety of applications in the transportation, consumer electronics, aerospace, and military industry segments, to name a few. The GPSG-1000 is a single carrier, multi-channel GPS/Galileo simulator. Portable and ruggedized, it can be safely and confidently deployed in a variety of outdoor and indoor environments. The unit is available in a 6- or 12-channel configuration, and supports L1, L1C, L2C, L5, E1, E5, E5a, E5b, and SBAS (WAAS and EGNOS) signals.

    The GPSG-1000 can be directly connected to a GNSS receiver under test. It can also simulate actual “open sky” situations, whereby the unit can generate its signals through the included antenna coupler system that isolates and transmits to the UUT’s antenna(s). Utilizing an integrated GPS receiver, the GPSG-1000 simulates actual time of day and date as well as the real constellation that would be available for navigation at that specific time. Multiple almanacs and route files can be saved to memory, enabling current and past history dynamic motion, constellation environment creation/recreation, and other troubleshooting capabilities. During any given static or dynamic simulation, space vehicle parametrics and health can be user controlled.

    At less than 10 pounds, the GPSG-1000 features a touch-screen user interface that can be remotely hosted via an integrated Ethernet port. The unit uses a rechargeable, lithium-ion battery, enabling hours of untethered use, or can be used while the battery is recharging.

    www.aeroflex.com/gpsg-1000
    phone: 316-522-4981 or 800-835-2352
    email: [email protected]

    Photo: RaceLogic
    RaceLogic
    LabSat Turntable

    RaceLogic

    LabSat, LabSat 2, SatGen v2

    LabSat and LabSat 2 are record and replay multi-constellation GNSS simulators. Designed as lightweight, easy-to-use standalone systems, the LabSat range has the ability to provide and deliver solutions for a wide range of testing requirements. Equipped with pre-recorded test scenarios and the ability to record and replay the user’s specific scenarios, LabSat delivers precise and accurate test results — replicating real-world situations in the lab or testing facility.

    The range also has the ability to record and replay data from a wide range of data sources, including vehicle CANbus, inertial sensors — such as gyrometers and wheel speed sensors — and reference receivers. A recent innovation is the LabSat Turntable Solution, which allows for the replay of dead-reckoning turn-rate signals to be played into a navigation device to simulate use through built-up areas and urban canyons. Both LabSat and LabSat 2 can observe all satellites in view; while LabSat observes GPS, Gallileo, and SBAS, LabSat 2 includes GLONASS and BeiDou-2.

    Reliability of the gathered data can be assured when used together with SatGen v2, Racelogic’s simulation software. This scenario-generation software enables users to create scenario files based on user-defined trajectories, which can be replayed on LabSat. With SatGen v2, a scenario can be generated anywhere in the world, with position, route, speed, and time defined by the user. This high-performance software allows users to verify that their GNSS equipment performs as required in a variety of locations that maybe geographically remote or unavailable due to hostile environments.

    www.labsat.co.uk
    phone: +44 (0)1280 823803

    Photo: Rohde & Schwarz
    Rohde & Schwarz
    R&S SMBV100A: GNSS Simulator on Vector Signal Generator

    Rohde & Schwarz

    R&S SMBV100A: GNSS Simulator on Vector Signal Generator

    The GNSS simulator in the vector signal generator R&S SMBV100A is designed for development, verification, and production of GNSS chipsets, modules and receivers. The simulator supports all possible scenarios, from simple setups with individual, static satellites all the way to flexible scenarios generated in real time with up to 24 dynamic GPS, GLONASS, and Galileo satellites.

    • GNSS simulator with support of GPS L1/L2 (C/A- and P-code), GLONASS L1/L2, and Galileo E1, including hybrid constellations.
    • Simulation of realistic constellations with up to 24 satellites in real time (no precalculated waveforms).
    • Flexible scenario generation including moving scenarios (import of NMEA waypoints), multipath, dynamic power control, and atmospheric modeling without the need for additional software tools.
    • Unlimited simulation time with automatic, on-the-fly exchange of satellites.
    • User mode in the GNSS simulator for full flexibility to select the satellites and to define the navigation data (import of RINEX files).
    • Full localization for static and moving receivers with up to eight satellites with GPS P-code plus commercial C/A-code for complete testing of military receivers.
    • Support of predefined and user-defined A-GPS test scenarios, including generation of assistance data.
    • Easy way for time synchronous setup with two instruments for L1 and L2 band simulation.
    • Support of digital communications standards.
    www.rohde-schwarz.com
    email: [email protected]

    Photo: Spectracom
    Spectracom
    GSG-6 Series GNSS Simulator

    Spectracom

    Advanced GNSS Simulators

    Spectracom’s line of simulators provides fast, comprehensive navigational, position, and timing testing for devices with GPS receivers. Designed for manufacturers and development engineers, Spectracom’s simulators provide complete testing of multi-channel GPS signal performance with high throughput and ease of use without unnecessary complexity or expense. All GSG-5 and GSG-6 series models are portable and fully operational via front-panel, web-based remote control, or SCPI protocol, and they operate with StudioView for easy scenario creation and file management. Most models are software upgradeable so users can easily add features as requirements change.

    GSG-5 Series. The GSG-5 series is a GLONASS and GPS constellation simulator that provides the basic set of features for testing GNSS systems. With a base of four channels, upgradable to 8, 16, or more, it provides navigational fix and position testing for in-line product testing or basic engineering and development testing.

    • Versatile multi-channel GLONASS + GPS signal generator with pre-configured test scenarios.
    • Includes advanced features such as SBAS (WAAS, EGNOS, MSAS, or GAGAN), white noise generation, and multipath simulation.

    GSG-6 Series (pictured). The GSG-Series 6 family offers multiple frequency band operation, multiple GNSS constellation simulation, and expansion to many more channels. Incorporating all of the features of the popular Series 5 family, the Series 6 line expands the capability to simulate all the new, emerging GNSS signals. With a base of 32 channels, upgradable to 48, 64, or more, it provides navigational fix and position testing for engineering and development testing.

    • GPS standard, new (L2C, L5) GLONASS, Galileo, and Beidou/Compass coming soon.
    • Simultaneous multi-frequency P-code (unencrypted) and C/A code.
    • Simultaneous GNSS Constellation P-code and C/A codes.
    www.spectracom.com
    email: [email protected]
    phone: 585-321-5800

    Photo: Spirent Federal Systems
    Spirent Federal Systems
    GSS8000 Simulator

    Spirent Federal Systems

    GNSS Simulators

    Spirent provides simulators that cover all applications, including research and development, integration/verification, and production testing.

    GSS8000 (pictured). Spirent’s flagship simulator, the GSS8000, is fully approved for Y-code, SAASM, AES M-code, and SDS M-code testing. Spirent provides options and configurations for testing GNSS interference effects and interference mitigation techniques, such as integrated GPS/inertial testing, CRPA testing, and jamming/anti-jam simulation.

    Spirent has delivered simulators that produce both legacy signals as well as modernized signals such as 2C, L5, and L1C. In addition to GPS, systems can include GLONASS L1/L2, Galileo, and Beidou-2, plus SBAS (WAAS, MSAS, and EGNOS) and Japan’s QZSS.
    CRPA Test System. Spirent’s Controlled Reception Pattern Antenna (CRPA) Test System generates both GPS L1/L2 and interference signals; multiple GSS8000 chassis may be combined to coherently control up to seven antenna elements. Null-steering and space/time adaptive CRPA testing are both supported by this comprehensive approach.

    GSS7790. Spirent’s GSS7790 Multi-Output Simulation System allows the signal from each satellite to be mapped to a separate RF output. These signals can then be fed to individual transmit antennas, which, when suitably deployed in an anechoic chamber, replicate the spatial diversity of satellite and jammer signals incident on the receiver antenna. Additional flexibility is offered as the signal is further split into its GPS L1 and L2 components, as appropriate.

    www.spirentfederal.com
    Jeff Martin, Director of Sales
    Kalani Needham, Sales Manager
    email: [email protected]
    phone: 801-785-1448
  • Expert Advice: The Challenge of BeiDou

    Mark Sampson
    Mark Sampson

    By Mark Sampson, Racelogic

    GNSS is changing. The days of only American GPS satellites providing signals to the civilian population are gone as new constellations are launched. GLONASS was a slow starter, but is now well established, and its signal architecture is now commonly implemented in manufacturers’ chipsets. Galileo is still very much in test phase with global coverage planned for 2019, although position fix using only Galileo satellites has already been demonstrated. The Japanese QZSS system, designed to aid navigation in urban canyons, is partially operational with further launches announced for the near future.

    The latest openly documented network to come online is BeiDou-2, or BDS. Formerly known as Compass, the Chinese constellation now provides signals to China and surrounding areas, but plans for global coverage should come to fruition by the end of the decade.

    Full control over its own constellation gives a country military, socio-political, and commercial advantages, especially if additional functionality — such as search and rescue services — is introduced alongside the standard navigational broadcast. BDS is unique in its use of a combination of standard-orbit and geo-synchronous satellites, the latter giving it a wider range of signal designed to carry more information.

    The populace stands to benefit from a wide variety of localized and global satellite coverage, but only if there are end-user products available that actually make use of the new signals. Any manufacturer wanting a share of the market in China, for instance, will need to get BeiDou-2 integrated into its chipsets quickly, especially if an import levy is placed upon devices that don’t support it (as nearly happened with GLONASS).

    How do you go about implementing BDS support in your new GPS product if you’re based in Europe or America? The coverage isn’t global yet; you can’t just go out into the office car park to test, and how are you going to incorporate the signals from the three geostationary satellites without actually being underneath them? Moving to China isn’t very practical, so the solution is a GNSS record-and-replay device.

    Manufacturers and other customers will want to seek out simulators from companies that have been highly proactive in ensuring their products provide full support for each constellation, even before they come fully online. The convenience in being able to test new designs, applications, and system integration with reliability and consistency can bring significant savings in development cost and time.

    With 14 BDS satellites currently in operation, and the recent release of the Interface Specification, we find more and more companies in the marketplace have been asking for BeiDou functionality. An added benefit for existing users would be flexible hardware capable of taking a simple firmware upgrade in order to record and replay BeiDou as well as GPS and GLONASS.

    Icing on the system-testing cake would be a hard drive containing pre-recorded scenarios from China and Europe, with good BDS visibility, so that bench testing can commence immediately. Given that such a device can record raw signals, live recordings can be taken in Asia and then transferred to test facilities around the world.


    Mark Sampson is Racelogic’s LabSat product manager. He has more than 15 years of experience in the development of GNSS technology. Working closely with leading businesses such as Bosch, Intel, Samsung, and Telefonica, he provides knowledge and expertise in testing any GNSS device, application, or integration.

  • Expert Advice: Keeping up with Multi-GNSS

    Expert Advice: Keeping up with Multi-GNSS

    By Steve Hickling, Spirent

    GNSS have been with us for more than 30 years, giving rise to a wealth of positioning and navigation technologies for military, civilian, and consumer use. Today, we’re entering a new era of experimentation and innovation in satellite and hybrid positioning. In turn, this drives new test challenges and introduces an ever wider group of engineers to the art and science of GNSS test.

    Where Is the Testing Panacea? I am sometimes asked, “What is the best way of testing a GPS receiver?” — as if there existed some laboratory panacea to all GNSS test and characterization woes. Well, there is a saying, “There are horses for courses,” meaning what performs well in one situation may not deliver in another, and nowhere is this more true than in the field of GNSS test. Not only is there a wide range of different test equipment available, but there are no universally applicable test objectives, test methods, or parameter definitions, in exactly the same way as there is not one universally applicable GNSS receiver. Just as the rapid time-to-first-fix of an automotive receiver may be less relevant in a maritime environment, so different test approaches have their place.

    A Systematic Approach. If there is one thing, it is this: be systematic in your test design. Consider the purpose of the test, the test conditions, and the measurements you plan to take, and be wary of generic tests that may not achieve your objectives.

    Equipment. A wide range of GNSS testing equipment is available, ranging from basic single-constellation RF simulators to highly configurable, multi-GNSS constellation simulators. Single-channel, multi-channel, and record and playback systems all have their place, and to get the best results in the fastest time, it’s essential to choose the kit that’s right for the kind of testing you need to do.

    Vulnerability, Fidelity, Integrity, and Time Travel. More and more, receivers need to be tested for their vulnerability to interference, jamming, and spoofing. As GNSS-derived position and time become more ubiquitous, so the motivation for confounding the system grows. This has a double impact on test.

    First, performance requirements around vulnerability may be introduced, with tests to match. Second, and perhaps less obvious, is the way in which this concern is reflected in the receiver’s design and potential rejection of the laboratory test signal. Yes, I mean receivers getting more fussy about the signals they lock onto. Anyone who has tested a receiver with an out-of-date recording or simulation scenario will have experienced a receiver refusing to track a satellite showing a time and date prior to its firmware release date. The receiver, discounting time travel, knows there has to be something wrong with a satellite showing a date before it was born. With the risk of spoofing, receivers will only get more picky and likely to reject poorly simulated signals. To avoid such effects, it is important to have very high integrity and fidelity in any simulator system. Getting these details right is not esoteric, but is essential to allow the proper attribution of any problems observed and if test results are to have any meaning.

    Conclusion. Be systematic in your approach to test; beware the universal and generic; “good enough,” it rarely is.


    Steve Hickling is lead product manager for Spirent’s GNSS simulator business and is based at the factory in Paignton, England. Previously he held a variety of marketing, technical, and management roles in the telecoms and optical components industries. He holds a bachelor of science degree in physics and electronic engineering from Birmingham University, an MBA from Open University Business School, and a post-graduate diploma from the Chartered Institute of Marketing.

  • Expert Advice: Product Testing: Simulation and Beyond

    By Pierre Nemry and Jean-Marie Sleewaegen, Septentrio Satellite Navigation

    Today’s customers ask for high-accuracy positioning everywhere, even in the most demanding environments. The time is long gone that the only requirement for a receiver was to track GPS L1 and L2 signals in open-sky conditions. State-of-the-art receivers operate in increasingly difficult conditions, cope with local radio-frequency interference, survive non-nominal signal transmissions, decode differential corrections from potentially untrusted networks — and more!

    Difficult real-life operating conditions are typically not addressed in textbooks or in the specialized literature, and yet they constitute the real challenge faced by receiver manufacturers. Most modern GNSS receivers will perform equally well in nominal conditions, or when subjected to nominally degraded conditions such as the ones that correspond to standard multipath models. However, the true quality of a GNSS receiver reveals itself in the environment in which it is intended to be used.

    In view of this, a GNSS manufacturer’s testing revolves around three main pillars:
    ◾    identifying the conditions and difficulties encountered in the environment of the intended use,
    ◾    defining the relevant test cases, and
    ◾    maintaining the test-case database for regression testing.

    In developing new receiver functionality, it is important to involve key stakeholders to comprehend the applications in which the feature will be used and the distinctive environment in which the receiver will function. For example, before releasing the precise-point-positioning (PPP) engine for the AsteRx2eL, we conducted a field-test campaign lasting a full month on a ship used for dredging work on the River Thames and in the English Channel. This enabled engineers to capture different types of sea-wave frequency and amplitude, assess multipath and signal artifacts, and characterize PPP correction data-link quality.

    Most importantly, we immersed the team in the end-user environment, on a work boat and not simply in a test setup for that purpose. As another example, in testing our integrated INS/GNSS AsteRxi receiver for locating straddle carriers in a container terminal, we spent months collecting data with the terminal operator. This was necessary to understand the specificities of a port environment, where large metal structures (shore cranes, container reach-stackers, docked ships) significantly impair signal reception.

    Furthermore, the close collaboration between the GNSS specialist, the system integrator, and the terminal owner was essential to confirm everything worked properly as a system. In both examples, in situ testing provide invaluable insight into the operating conditions the receivers have to deal with, much surpassing the possibilities of a standard test on a simulator or during an occasional field trip.

    Once an anomaly or an unusual condition has been identified in the field, the next step is to reproduce it in the lab. This involves a thorough understanding of the root cause of the issue and leveraging the lab environment to reproduce it in the most efficient way. Abnormalities may be purely data-centric or algorithmic, and the best approach to investigate and test them would be software-based. For example, issues with non-compliance to the satellite interface control document or irregularities in the differential correction stream are typically addressed at software level, the input being a log file containing GNSS observables, navigation bits, and differential corrections.

    Other issues are preferably reproduced by simulators, for example those linked to receiver motion, or those associated to a specific constellation status or location-dependent problems. Finally, certain complicated conditions do not lend themselves to being treated by simulation. For example, the diffraction pattern that appears at the entrance of a tunnel is hard to represent using standard simulator scenarios. For these circumstances, being able to record and play back the complete RF environment is fundamental.

    Over the years, GNSS receiver manufacturers inventoried numerous cases they encountered in the field with customers or during their own testing. For each case, once it has been modeled and can be reproduced in the lab, it is essential to keep it current. As software evolves and the development team changes, the danger exists that over time, the modifications addressing a dysfunctional situation get lost, and the same problem is reintroduced. This is especially the case for conditions that do not occur frequently, or do not happen in a systematic way. Good examples are the GLONASS frequency changes, which arise in an unpredictable way, making it very difficult for the receiver designer to properly anticipate. This stresses the importance of regression testing. It is not enough to model all intricate circumstances for simulation, or to store field-recorded RF samples to replay later. It is essential that the conditions of all previously encountered incidents be recreated and regularly tested in an automated way, to maintain and guarantee product integrity.

    The coverage of an automated regression test system must range from the simplest sanity check of the reply-to-user commands to the complete characterization of the positioning performance, tracking noise, acquisition sensitivity, or interference rejection. Every night in our test system, positioning algorithms including all recent changes are fed with thousands of hours of GNSS data, and their output compared to expected results to flag any degradation. Next to the algorithmic tests, hardware-in-the-loop tests are executed on a continuous basis using live signals, constellation simulators, and RF replay systems, with the signals being split and injected in parallel into all our receiver models. Such a fully automated test system ensures that any regression is found in a timely manner, while the developer is concentrated on new designs, and that a recurring problem can be spotted immediately. The test-case database is a valuable asset and an essential piece of a GNSS company’s intellectual property. It evolves continuously as new challenges get detected or come to the attention of a caring customer-support team. Developing and maintaining this database and all the associated automated tests is a cornerstone of GNSS testing.

  • GNSS PPP Workshop Early Registration Extended to May 3

    The International Association of Geodesy, Natural Resources Canada, the International GNSS Service, and York University will be hosting GNSS Precise Point Positioning: Reaching Full Potential in Ottawa, Canada, June 12-14, 2013.

    The primary objective of this workshop is to provide a forum for international experts from academia, government and industry to discuss PPP-related matters, including data processing, error modelling, data products, dissemination, applications, and associated policy.

    The preliminary program is now available on the workshop website, along with details about accommodations and registration. Note that early registration has been extended until May 3, 2013.

    Given recent rapid developments in PPP technology, the objectives of this workshop will be to:

    1. Provide a forum for international experts from academia, government and industry to discuss PPP-related matters, including data processing, error modelling, data products, dissemination, applications, and associated policy.
    2. Define the current state of PPP performance and communicate global PPP activities and applications in all sectors.
    3. Identify and investigate the technical and non-technical issues that need to be addressed to improve the technology.
    4. Suggest PPP performance and utility in the next five to ten years.
  • ESA Telecom and Navigation Vehicle Ready for Test Driving

    The radio spectrum is about to get even busier, as Europe’s Galileo satnav system starts services, at the same time the European Space Agency (ESA) tests novel satellite-based telecommunication services. Supporting these developments from the ground, ESA’s new custom-built Telecommunications and Navigation Testbed Vehicle will measure the resulting signals from all over Europe.

    Adapted from a Mercedes Benz Sprinter van, this unique measurement vehicle has been delivered to ESTEC by Austria’s Joanneum Research institute. “This is a dual-purpose vehicle, suitable for both telecommunications and navigation system testing,” explained Simon Johns of ESA’s Radionavigation Systems and Techniques Section.

    “For navigation, we have the Galileo constellation coming on stream, as well as the stepping up of ESA’s GNSS Evolution programme — designing what comes next after Galileo’s first generation.”

    The four wheel-drive vehicle can host a three-person team, and is crammed with dedicated navigation and telecommunication monitoring equipment.

    Testbed vehicle screen.
    Testbed vehicle screen.

    “One of the main goals driving the design was to have an ‘easy to adapt’ test platform suitable to set up test campaigns for different mobile satellite systems and standards that would require different types of antennas and specific receiver/transmit equipment,” explained Olivier Smeyers of ESA’s Communication-TT&C Systems and Techniques Section.

    “On the telecommunications side, there is a continuous effort to enhance current and create new mobile satellite-based broadcast and interactive services via the evolution of current systems or developing new standards,” Smeyers said. “Testing in the field is an essential element for validating and eventually establishing evolved or new standards. The vehicle has built-in multimedia equipment, including storage and control computers, multimedia gateway, passenger LCD screens, cameras and microphones, to serve this purpose.”

    The vehicle features include two removable roof plates to mount specialized antennas (one currently hosts the antenna of a Broadband Global Area Network satellite terminal for Internet connectivity and multimedia and data streaming), an 8-meter-high telescopic mast capable of carrying 25 kilograms, a rubidium atomic clock synchronized to GPS time with nanosecond accuracy, a high-end spectrum analyzer and oscilloscope for signal measurements, and mobile temperature sensors to monitor the rack equipment.

    A fish-eye video camera incorporating onscreen GPS timing and positioning performs continuous recording of its surroundings — to throw light on high buildings, trees, or other factors that might affect results.

    Internal and external generators yield up to 5 kilowatts to keep everything running — sufficient power to supply two typical European households.

    “The challenge was to fit in all the equipment and provide the necessary power and air conditioning, while still weighing less than 3.5 tonnes,” said Thomas Prechtl of Joanneum Research. “Exceeding this weight would have meant drivers would have needed a special license, and potentially limited its operations in some European nations.”

  • Aeroflex Adds Capability to Simulate WAAS LPV Approaches

    Aeroflex Incorporated, a wholly owned subsidiary of Aeroflex Holding Corp., has announced its capability to simulate WAAS (Wide Area Augmentation System) LPV (Localizer Performance with Vertical Guidance) approaches by adding this new feature to their GPSG-1000 Portable GPS Simulator.

    Aeroflex has developed the capability of simulating WAAS LPV approaches to expedite and validate the installation of WAAS-enabled navigation systems in aircraft. The GPSG-1000 offers the following features to installers of these systems:

    • Ability to perform structured, repeatable dynamic motion tests (actual flight) of a WAAS/LPV installation,
    • Ability to check and validate the sensitivity and dynamic range of an airborne GPS receiver, either statically or while in motion,
    • Reduce aircraft down time and flight demonstration time required by FAA,
    • Additional support data for documenting proper FAA processes of WAAS/LPV system upgrades or installs without leaving the hangar.

    New orders for the GPSG-1000 are ready for immediate delivery. For existing GPSG-1000 customers, a no-charge software upgrade will be available by mid-April 2013.

    The FAA created the WAAS program in 1992 to provide the necessary integrity to utilize GPS signals for precision approach. The WAAS consists of a network of precisely surveyed wide area reference stations (WRS). These reference stations monitor GPS satellites to determine errors in the GPS satellite signal. Each reference station relays the information about the GPS satellites to the WAAS wide area master stations (WMS). The master station then develops corrections to the GPS position information and provides timely notification of unreliable GPS data. These corrections are sent to ground uplink stations (GUS) where they are transmitted in the form of a WAAS correction message to a Geostationary Earth Orbit (GEO) satellite. The WAAS signal is then broadcast to users on the same frequency as GPS. This WAAS corrected signal provides three-dimensional guidance to aircraft.