Tag: GNSS modernization

Innovation: Faster, Higher, Stronger
Proposed GNSS Navigation Messages for Improved Performance

By Wentao Zhang and Yang Gao

INNOVATION INSIGHTS by Richard Langley

TIME-TO-FIRST-FIX, commonly known by the initialism TTFF, is the elapsed time between the powering on or starting up of a GNSS receiver and when it successfully computes either a two-dimensional (height constrained) or three-dimensional position fix and sets its clock to the correct time. A three-dimensional fix requires simultaneous receiver measurements on the signals from a minimum of four satellites along with the satellites’ positions (ephemerides) and the offsets between the individual satellite clocks and the GNSS system time.

TTFF depends crucially on the availability and timeliness of the satellite ephemerides and clock information when a receiver starts up and, accordingly, there are three types of start-up with correspondingly different TTFF.

A cold start (sometimes also called a factory start) occurs when the receiver has no knowledge of its current position, time or the positions of the satellites and their clock offsets. The receiver must do a blind search of the sky trying different possible Doppler frequency shifts and pseudorange delays for all the satellites in the constellation. Once satellites are found and tracked, the ephemerides and clock information must be collected. This is repeated in each satellite’s navigation message every 30 seconds. In addition, the information on the offset between GNSS system time and UTC must be collected along with the ionospheric delay correction parameters and the almanac (an approximate ephemeris for all active satellites in the constellation) to be used for faster subsequent signal acquisition. This data is only transmitted once in the 12.5-minute-long navigation message. Therefore, the TTFF for a cold start can take up to 12.5 minutes and even longer especially if the GNSS signals are hard to acquire such as in obstructed environments.

A warm start, or what we might call normal operation, occurs when the receiver has some a priori information on its position, the time and the approximate locations of the satellites. Typically, this means knowing the receiver position to within a few hundred kilometers, time to within 10 minutes or so, and a reasonably fresh almanac. Armed with that information, a receiver knows which satellites should be visible to it and can quickly acquire and track satellite signals and obtain the satellite ephemeris and clock information. Since that information is repeated every 30 seconds, TTFF for a warm start can be 30 seconds or less.

A hot start occurs when a receiver is powered on after being off and stationary for a short interval and it therefore has a very good estimate of its position and the current time and valid satellite ephemeris and clock data. TTFF for a hot start, therefore, is typically only a few seconds. This mode of receiver operation would also apply to scenarios where all signals are temporarily lost in road or rail tunnels or where a number of signals are momentarily blocked by obstructions causing a break in position fixing.

Fast first fixes were traditionally only possible when a receiver had a clear view of the sky and could readily acquire the navigation messages. Pseudorange measurements can be made, however, even if satellite signals are somewhat attenuated in strength to the point that navigation messages cannot be acquired. Position fixing in this case would be possible if the receiver could obtain the navigation information from elsewhere. Over the past decade or so, assisted GNSS techniques have been developed to provide frequently refreshed navigation information over cellular telephone networks, for example. But would there be a way to achieve fast first fixes autonomously without reliance on these assisted techniques? Not with the signals presently being transmitted by either the mature or nascent constellations, it seems, but in this month’s column, we look at proposed changes to the way navigation messages are formulated that could result in a future satellite navigation system providing faster fixes effectively giving receivers higher sensitivity and stronger performance.

“Innovation” is a regular feature that discusses advances in GPS technology and its 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. Email him at lang @ unb.ca.

Despite some differences in their structures, different GNSS broadcast navigation (NAV) messages usually consist of two parts: immediate (primarily ephemeris) and non-immediate (primarily almanac) data. The immediate data is repeated at a much shorter interval than the non-immediate data, and expires much sooner than the non-immediate data. Taking GPS as an example, the civilian navigation (CNAV) messages consist of five subframes with each lasting six seconds, as depicted in FIGURE 1. The first three subframes provide the ephemeris, with the content repeated every 30 seconds and updated every two hours, while the last two subframes provide the almanac for each satellite in 25 pages, with the content updated nominally every six days (according to the GPS Interface Specifications document), but updates are actually daily.

FIGURE 1. Frame structure of GPS CNAV messages.

Depending on the accuracy of receiver time and the availability of previously collected ephemerides (the immediate data) when powered on, GNSS user equipment (UE) might experience cold, warm or hot starts, among which the warm start is the most common case. In the widely accepted definition for warm start, no valid ephemeris is available, but the receiver time is roughly known at startup.

As depicted in FIGURE 2, the position fix sequence by a standalone GNSS UE normally consists of signal acquisition, tracking, bit synchronization, frame synchronization, ephemeris downloading, measurements taking and position computation. In performing a regular warm start, signal acquisition usually takes only a few hundred milliseconds for a GPS device in open-sky environments. However, under weak signal conditions, signal acquisition might take much longer (say a few tens of seconds). Once the signal is acquired, the tracking loop is activated, and immediately after the signal is pulled in the process of data-bit synchronization is started. This process takes a few hundred milliseconds to several seconds depending on signal strength and algorithm efficiency. In a stable tracking status, the navigation bits are collected sequentially one by one. Collecting a complete copy of a GPS ephemeris takes about 18 seconds in open-sky environments but may take minutes or even forever in weak signal environments due to an increased bit error rate (BER). As soon as the ephemeris downloading from three to four satellites is completed and the measurements are made, the user position fix usually can be obtained immediately. Therefore, in weak signal environments, the obstacles to fast time-to-first-fix (TTFF) are primarily signal acquisition and ephemeris downloading, and in open-sky environments the obstacle mainly lies in the time needed for ephemeris downloading.

FIGURE 2. Typical sequence of position fix process in standalone GPS user equipment (Msr=measurements).

For a GNSS UE in an open-sky environment on the Earth’s surface, the minimum received signal level for GPS L1 is around -130 dBm according to the interface specifications. For other GNSS signals, the nominal received signal levels are approximately the same.

However, in some extreme cases, such as urban canyon, foliage and indoor environments, the signals finally arriving at a receiver’s antenna could be heavily attenuated by 30 dB or even more. Working under such conditions requires GNSS UE to have high-sensitivity capability.

When the GNSS signal strength drops to a certain level, it causes immediate difficulties in the GNSS receiver tracking loop and for ephemeris downloading. Firstly, the parameters of the tracking loop, designed for normal signal strengths, are no longer optimum for either obtaining enough gain for signal detection or for maintaining signal tracking. Secondly, BER increases with decreasing signal strength. When the signal carrier-to-noise-density ratio drops below 27 dB-Hz, even if signal tracking is maintained, the increased BER would make it difficult for successful decoding of NAV messages.

Sensitivity improvements for a GNSS receiver can involve contributions from the antenna, the RF front end and baseband signal processing. In the signal processing, to obtain adequate processing gain in signal-to-noise ratio for signal detection, combined coherent and non-coherent integrations are needed. An approximate relationship for calculating such processing gain is given in Equation (1). Considering that non-coherent integration is subject to squaring loss, for a fixed total integration period (T_I), increasing the coherent period (T_c) is more efficient for achieving higher processing gain. However, without knowing the navigation bits, the coherent integration is limited within a 1-bit period or 20 milliseconds for GPS signals.

(1)

To improve sensitivity to -160 dBm, coherent integration over multiple bits is desired. Therefore, valid navigation bits as well as the bit boundaries are needed for data wipe-off. For this purpose, previously collected navigation bits can be directly used if they are still valid or fresh navigation messages from different sources, including ephemeris and almanac, can be used to recover the navigation bits.

GNSS Assistance Technologies

The existing efforts for improving TTFF and sensitivity for GNSS UE include developing assistance systems and implementing new algorithms for UE. The concept of AGPS goes back to the late 1990s when lots of patents were filed and then granted in early 2000s. Seeing the challenges of TTFF and sensitivity for standalone GPS devices, the general idea from the patents is to provide assistance information to GNSS UE, such as time, rough location, a list of visible satellites, the Doppler shift of each satellite, ephemerides and so on, in a way to speed up each stage in the process of a position fix (Figure 2). With a series of AGPS specifications embodied in the 3GPP and Open Mobile Alliance standards since 2001, AGPS-enabled products have become quite popular in the GNSS marketplace.

The assistance data definitely brings enhanced performance in TTFF and sensitivity for GNSS UE, but it is a challenge when network connectivity is not available. A technology often referred to as ephemeris extension (EE) was introduced by Global Locate and SiRF, which enables fast TTFF and high sensitivity for GNSS UE even without network connectivity. According to the descriptions of the long-term orbit used by Broadcom and InstantFix used by CSR, both are based on orbit determination theory and provide alternative ephemerides with a validity period extending to a few days, rather than two hours for the regular GPS ephemerides. As of today, a variety of EE products are available from many companies and research institutes, and EE has become a standard feature for GNSS products in the market place.

Limitations of Existing GNSS Assistance Technologies

In spite of the benefits to TTFF and improved sensitivity, the assisted GNSS (AGNSS) and EE technologies have obvious limitations, as detailed in TABLE 1. Building and maintaining the AGNSS infrastructure require significant efforts and continuous cost. Any AGNSS-capable UE, unlike standalone GNSS UE, are tied to good signals from the subscriber cellular phone networks to get assistance data on time, which substantially limit their areas of operation. The EE technologies consist of server-based and client-based modes. Client-based EE is good for standalone UE, but the accuracy is subject to the validity of the embedded Earth orientation parameters (EOPs), and the quantity and quality of the local data collection. Server-based EE is able to provide better accuracy, but it also needs support from the global infrastructure for data collection and is subject to network connectivity. Table 1 clearly indicates that AGNSS and EE can only be beneficial under certain prerequisite conditions, such as with network connectivity and data availability. In other words, even with the above-described technologies, fast TTFF and high sensitivity may still not be obtainable when those prerequisite conditions are not met, which is not uncommon in practical use.

TABLE 1. Comparison of assisted GNSS (AGNSS) and extended ephemeris in improving time-to-fist-fix (TTFF) and sensitivity.

Suggested New GNSS NAV Messages

The fundamental cause of the problem related to TTFF and sensitivity, in our view, lies in the congenital weakness of the design of the existing GNSS NAV messages. Taking GPS as an example, the contents of GPS subframes 1–3 are updated every two hours, although the ephemeris is valid for up to four hours. It is challenging for standalone GPS UE working in weak signal environments to catch up with such frequent ephemeris updates. Working properly during the past two hours does not mean that the UE can work properly in the next two hours if ephemerides are not downloaded in time. The NAV messages received two hours ago cannot be used for data aiding in the subsequent two hours to improve tracking sensitivity. For startups under normal signal conditions, the UE, if missing the start of subframe 1, have to wait 30 seconds to get to the next subframe 1 to download a complete copy of the ephemeris. Successful startups four hours ago also do not help much to reduce the TTFF in the subsequent startups, as time is needed again for ephemeris downloading.

For other GNSSs, some specifications of their NAV messages are listed in TABLE 3. According to these specification, the downloading of Galileo ephemerides takes at least 30 seconds, and if the start of the first ephemeris page is missed, it will take at least 50 seconds to get a complete copy. So, from this perspective, the Galileo TTFF for standalone devices is expected to be longer than that for GPS. As to BeiDou, given the high degree of similarity between BeiDou D1 and GPS CNAV messages, it is expected that for standalone BeiDou UE, TTFF is also similar to standalone GPS UE. For GLONASS, the downloading takes just about10 seconds, and it will take about 30 seconds to get a complete copy of the ephemeris if the start of the first ephemeris string is missed. Therefore, in this regard, the GLONASS TTFF for standalone devices is expected to be the fastest among the GNSSs. It is worth noting that the GLONASS ephemeris, unlike that of other GNSSs, comprises Cartesian coordinates, velocity components and solar/lunar gravitational accelerations at the reference time, with the content valid over about 0.5 hours. Upon receiving the ephemeris, the UE is to calculate the satellite orbit by numerically integrating the motion equations that include the second zonal geopotential coefficients through a fourth-order Runge-Kutta method. Since the designed NAV messages for GPS, GLONASS, BeiDou and Galileo are all valid for only short periods (see Table 3), they are all subject to the aforementioned limitations.

TABLE 3. Comparison of the NAV messages for GPS/GLO/BD(D1)/GAL(F/NAV)/New GNSS.

The common weaknesses in the NAV messages of GPS, GLONASS, BeiDou and Galileo described above can be overcome and fast TTFF and high sensitivity can be facilitated through the design of new NAV messages, when the following guidelines are followed:
- Update interval, as short as possible
- Repeat interval, as high as possible
- Length of ephemeris content, as short as possible
- Ephemeris life expectancy, as long as possible
Let’s take a closer look at the GPS CNAV messages in terms of the above four guidelines. In the GPS CNAV messages, the primary content includes:
- Satellite clock
- Satellite ephemeris
- Ionosphere information
- UTC parameters
- Almanac
Two types of atomic clocks, rubidium and cesium, with stabilities of 10^-12 to 10^-13 are used on the GPS satellites. Given such stabilities, it is possible to have the clock parameters updated at an interval much longer than two hours, without introducing significant errors in the pseudorange observations. For the Keplerian parameters in the GPS ephemerides, they are derived from the fitting of four-hour orbit curves. The orbit, represented by the Keplerian parameters plus perturbation corrections, gives the overall best fitting of the whole orbit segment. If fitting over a longer orbit curve, it would be harder for the fitted orbit to agree well with each small portion of the original orbit. A set of Keplerian orbital parameters can be a good approximation of a short orbit segment (say four hours), but can hardly be the case over a long period (say 24 hours). Frequent updating of the ephemeris content is therefore indispensable in order to guarantee the orbit accuracy using this approach. As a result, there is not much room for extending the ephemeris update interval or equivalently to lower the update frequency.

GPS CNAV messages include ionosphere information using the Klobuchar model, UTC parameters for relating GPS Time to UTC, and the almanac providing the rough orbits for all GPS satellites in service. According to the GPS Interface Specifications, all these messages will be updated at least once every six days, but they are typically updated on a daily basis.

Based on the above analysis, it can be concluded that, in GPS CNAV messages, the only part that changes frequently is the ephemeris (primarily the Keplerian parameters). To facilitate fast TTFF and high sensitivity, we should reduce the update frequency of the GPS CNAV message. For that, the key is to find a way to minimize the update frequency of the ephemerides.

Taking a close look at the satellite orbit may help us find a hint. For a satellite in space, given the initial conditions (position, r, velocity, , and so on) in Equation (2) at time t₀, the succeeding orbit, r(t), can be obtained by integrating the accelerations, , in Equation (3), as illustrated in Equation (4).

(2)

(3)

(4)

To ensure the accuracy of the derived orbit, r(t), the forces exerted on the satellites that result in the acceleration, (t), should be well modeled. The forces are both gravitational and non-gravitational.

Standard gravitational force models embedded in UE can be independently used for years without introducing significant accuracy loss. As to the force of solar radiation, it is related to the reflectivity and attitude of the solar panels of the satellite, which can also be well modeled by some slow-varying and satellite-dependent parameters. If a set of such solar radiation parameter(s) along with some satellite initial conditions (position and velocity) can be provided with a certain period (say one day), the satellite orbit can be derived in the UE through some embedded force models.

By now, we have found what we are looking for — namely, the solar radiation parameter(s) together with the satellite initial condition at a reference time, which can be the ideal content for our new ephemeris that can deliver a long orbit even if updated at a low frequency.

Consider that, at any epoch, the satellite position and velocity expressed in Cartesian form (r, ) can also be identically expressed in Keplerian form through the set of standard elements as is currently done with GPS.

The initial condition expressed in Keplerian form may give a better idea of what the orbit looks like and may have advantages for message encoding and sanity checks when it is adopted as the ephemeris content.

The above fundamental analysis leads us to propose the new GNSS NAV messages provided in TABLE 2, which comply with the previously mentioned guidelines and therefore should be able to inherently facilitate fast TTFF and provide UE with high sensitivity.

Note that the EOP data in the above table, used for relating coordinates in an Earth-centered Earth-fixed (ECEF) frame and those in an Earth-centered inertial (ECI) frame, are slowly varying parameters. The update interval for each part of the new NAV messages in Table 2 is one day, but for the almanac part, the update interval can be possibly extended to a few days similar to that currently used for GPS. In the ephemeris part, the proposed messages contain the six basic Keplerian elements and one solar radiation parameter for a selected reference time (t₀). Once the ephemeris is downloaded, the six Keplerian elements can be immediately transformed to Cartesian position, r(t₀), and velocity, (t₀), in the ECEF frame, and further converted to the initial condition in the ECI frame to derive the entire orbit through Equation (4).

TABLE 2. Proposed content of new GNSS navigation messages.

Compared to the current GPS ephemeris, Table 2 contains many fewer parameters, so it is possible to have the new GNSS ephemeris and clock data packed in only two subframes, assuming that the data rate, word structure and subframe length are the same as for GPS CNAV messages. For the remaining parts listed in Table 2, they can be packed into multiple pages of 2 subframes in a similar way as the pages of subframes 4 and 5 in GPS CNAV messages. Therefore, we have the frame structure of the proposed new GNSS NAV messages as depicted in FIGURE 3. Considering that the contents of the first two subframes play a primary role in TTFF, the pages of subframes 3 and 4 are not further discussed here.

FIGURE 3. Frame structure of the new GNSS NAV messages.

Advantages of the New NAV Messages

The content of the new NAV messages have been proposed in the last section, but the detailed format design is beyond the scope of this article. In TABLE 3, a comparison of the new NAV messages to the current GPS, GLONASS (GLO), BeiDou (BD) and Galileo (GAL) messages is presented. For the convenience of comparisons, the same data rate (50 bits per second [bps]) and the same length of subframe (6 seconds) as for the GPS CNAV messages have been used for the new GNSS NAV messages.

Compared to other GNSS NAV messages, the new NAV messages have a smaller size, but the contained ephemeris has a longer life and, as a whole, the new NAV messages just need to be updated once every 24 hours. To help understand the advantages of the new NAV messages, we have made several comparisons.

Standalone UE, New GNSS vs. GPS. For any new GNSS that deploys the new NAV messages, the UE just need to download the ephemeris from the satellites once in a whole day, whereas current GPS UE need to do it 12 times. In each downloading, it takes about 18 seconds for current GPS UE compared to about 12 seconds for the new GNSS UE. So there is no doubt that, from the TTFF perspective, the new NAV messages have incomparable advantages over the current GPS ones. Once a complete copy of the new NAV messages is downloaded, it can be used for data aiding in tracking loops for the rest of the whole day, even without network connections in weak signal environments. However, for current standalone GPS UE, they have to be in a strong signal environment to acquire fresh NAV messages every two hours. Otherwise there could be no position fix available in the next two hours due to the stale NAV bits and expired ephemerides. So, from a sensitivity point of view, a GNSS with the new NAV messages (referred to as new GNSS below) will also have incomparable advantages over GPS.

Assisted UE, New GNSS vs. GPS. There are three purposes for assistance information for mobile devices: 1) to expedite signal acquisition; 2) to save time in ephemeris downloading; and 3) to have navigation bits for data aiding in the tracking loops. For assisted GPS UE and assisted GNSS UE with the new NAV messages, there is not much difference in the first aspect, as the assistance data, such as a satellite vehicle list, Doppler frequency, code phase, location and time, are common to both. For the second and third purposes, the assistance data sent from the assisting network to the UE are only needed once per day using the new NAV messages because they are updated only once per day. For assisted GPS UE, the assistance data are needed once every 2 hours, which means that GPS UE need frequent network connectivity and more network bandwidth for data transportation. In addition, as the size of a GPS frame is larger than the frame of the proposed new NAV messages, the time delay in transporting the assistance data will be longer in a GPS assistance network.

New GNSS, Standalone vs. Assisted. When the new GNSS NAV messages are deployed, as the messages are only needed to be downloaded once a day, the assisted UE mostly show advantage in sensitivity and the required time for signal acquisition. Since signal acquisition is difficult only when the signal becomes weaker than a certain level, the performance of standalone and assisted new GNSS UE is expected to be comparable under normal signal conditions. Under weak signal conditions, as long as the NAV messages are received once a day, the performance in tracking sensitivities for both standalone and assisted UE is also expected to be comparable.

Feasibility Considerations

Since the proposed update interval for the new NAV messages is 24 hours, a period much longer than that currently used by all constellations, some immediate concerns may arise, such as:
- Is the orbit/clock derived from the ephemeris good enough for 24 hours?
- Is the calculation load for deriving satellite orbits affordable for a UE?
The advancement in orbit determination and EE technologies can help relieve the worry on the first concern. For the JPL predicted orbit and clock states, it is claimed that the user range error (URE) of around one meter for one day and URE of less than 10 meters for seven-day predictions can be obtained.

For a future GNSS that deploys the proposed new NAV messages, an orbital determination center (ODC) on the ground should be able to provide orbit predictions better than or at least comparable to those already obtained. Every 24 hours, as the intermediate results of the orbit predictions are obtained in the ODC, the new ephemeris data can be extracted and packed as one part of the new NAV messages. Once uploaded to the satellites and broadcast to GNSS UE on the ground, they can be used in deriving satellite orbits. The accuracies of the orbits/clock finally derived by GNSS UE will be subject to the accuracy of ephemeris, clock coefficients, EOPs and force models embedded in UE.

The EOP data, describing the irregularities of the Earth’s rotation, are needed for coordinate transformations between ECEF and ECI, so the up-to-date EOP data carried in the new NAV messages ensures no accuracy loss in such transformations. For the force models embedded in GNSS UE, accuracy is not a problem as long as they are the same as that used by the ODC.

As to the satellite clock, it is desired that, even if the clock coefficients are updated once per day, the accuracy of the predicted clock is still sufficient for navigation. For the current spaceborne clocks on GPS satellites, they are primarily rubidium atomic clocks with stability not better than about 10^-13. The advancement of atomic clock technologies is fast, especially in recent years, and the era of rubidium, cesium and hydrogen maser clocks is evolving to ytterbium and even optical atomic clocks. As of today, atomic clocks as stable as 10^-18have been operated in laboratory settings. A project called the Space Optical Clock aims to put a lattice optical clock with a stability of 10^-16on the International Space Station by 2020. So it is foreseeable that new GNSSs should be able to deploy atomic clocks with stability several orders better than those currently deployed. At the stability of 10^-16, the clock will only introduce millimeter-level errors in ranging in a 24-hour period. With such a stable satellite clock, there should be no accuracy concerns with clock data being updated once per day.

Once the broadcast ephemeris is received by a UE, numerical integration can be started to derive the satellite orbit. During the numerical integration, the calculation load is primarily dependent on the following factors: 1) the length of numerical integration; 2) the numerical integration step size; 3) the order of the integrator; and 4) the complexity of local force models. Regarding the run-time necessary for orbital numerical integration on an embedded system, some published results indicate that a three-day prediction (numerical integration) takes only around 0.6 seconds on a 600-MHz processor with floating point unit. So a 12-hour integration would take only about 0.1 seconds on the same platform. As of 2014, for the popular high-end smartphones on the market, the speed of embedded processors ranges from 1.2 to 2.5 GHz with dual- or quad-cores. Considering the drastically growing computation power of mobile processors and the potential of further algorithm optimizations in orbital integration, the calculation load of numerical integration for a 12-hour interval is not at all an issue on a mobile device today, much less in the future.

The GPS system designers four decades ago might not have realized that GPS would become so popular in the 21st century. Fast TTFF and high sensitivity have become standard requirements. The growing power of the application processors has also been beyond the imagination of people 40 years ago. So in their design, fast TTFF and high sensitivity might not have been given too much attention. The GPS modernization program is an attempt to meet the growing expectation on the system performance in the applications for today and the near future. In view of this, there is no reason not to give special considerations to inherently support fast TTFF and high-sensitivity applications when investigating and designing a new GNSS. Certainly, such efforts can be found both in recently launched GPS (Block IIF) and Galileo satellites, such as the pilot channels, but navigation under weak signal conditions for future standalone GPS and Galileo devices is still susceptible to the frequent change of NAV messages (see Table 3).

Conclusions

In this article, we have analyzed the benefits and limitations of the existing technologies (AGNSS and EE) widely adopted to improve TTFF and sensitivity performance, and pointed out the weakness in current GNSSs. Instead of seeking solutions in the user terminal, this article proposes to deploy new NAV messages on future GNSSs, with the contents updated once a day, to inherently facilitate fast TTFF and high sensitivity in the standalone GNSS UE. A future GNSS that uses such new NAV messages will have significant advantages for both standalone and assisted UE.

Acknowledgment

This article is based, in part, on the paper “New GNSS Navigation Messages for Inherent Fast TTFF and High Sensitivity” presented at the 2015 Pacific PNT Meeting of The Institute of Navigation, held in Honolulu, Hawaii, April 20–23, 2015.

WENTAO ZHANG is a Ph.D. student in the Department of Geomatics Engineering at the University of Calgary. His research interest lies in different location technologies, and he is focusing his research on potential new GNSS navigation messages in an attempt to inherently improve time-to-first-fix and receiver sensitivity.

YANG GAO is a professor in the Department of Geomatics Engineering at the University of Calgary. His research expertise includes both theoretical aspects and practical applications of satellite-based positioning and navigation systems. His research focuses on high-precision GNSS positioning and multi-sensor integrated navigation systems.

FURTHER READING
- Authors’ Conference Paper
“New GNSS Navigation Messages for Inherent Fast TTFF and High Sensitivity” by W. Zhang and Y. Gao in Proceedings of The Institute of Navigation 2015 Pacific PNT Meeting, Honolulu, Hawaii, April 20–23, 2015, pp. 131–141.
- Assisted GNSS
A-GPS: Assisted GPS, GNSS, and SBAS by F. van Diggelen, published by Artech House, Boston and London, 2009.

“First AGPS–Now BGPS: Instantaneous Precise Positioning Anywhere” by I. Petrovski, H. Hojo and T. Tsujii in GPS World, Vol. 19, No. 11, Nov. 2008, pp. 42–48.

“Assistance When There’s No Assistance — Long-Term Orbit Technology for Cell Phones, PDAs” by D. Lundgren and F. van Diggelen in GPS World, Vol. 16, No. 10, Oct. 2005, pp. 32–36.

“Assisted GPS: Using Cellular Telephone Networks for GPS Anywhere” by R. Bryant in GPS World, Vol. 16, No. 5, May 2005, pp. 40–45.

“Assisted GPS: A Low-Infrastructure Approach” by J. LaMance, J. DeSalas and J. Järvinen in GPS World, Vo. 13, No. 3, March 2002, pp. 46–51.
- Satellite Orbits
Satellite Orbits: Models, Methods and Applications by O. Montenbruck and E. Gill, published by Springer-Verlag, Berlin and Heidelberg, 2000.

“The Orbits of GPS Satellites” by R.B. Langley in GPS World, Vol. 2, No. 3, March 1991, pp. 50–53.
- Predicted Orbits and Clocks
Predicted GNSS Ephemeris, Rx Networks Inc., Vancouver, Canada.

Multiple GNSS Assistance Services for u-blox GNSS Receivers: User Guide, UBX-13004360 – R02, u-blox AG, Thalwil, Switzerland, March 2015.

“Predicted Orbit & Clock States,” Global Differential GPS System, Jet Propulsion Laboratory, Pasadena, Calif., Nov. 14, 2013.

“SiRF InstantFix II Technology” by W. Zhang, V. Venkatasubramanian, H. Liu, M. Phatak and S. Han in Proceedings of ION GNSS 2008, the 21st International Technical Meeting of the Satellite Division of The Institute of Navigation, Savannah, Ga., Sept. 16–19, 2008, pp. 1840–1847.

Long Term Orbits (LTO™), Technical Brief, Broadcom Corp., Irvine, Calif., 2007.
- Assisted GNSS Standards
Enabler Release Definition for Secure User Plane Location (SUPL), Candidate Version 3.0, OMA-ERELD-SUPL-V3_0-20140916-C, Open Mobile Alliance Ltd., San Diego, Calif., September 2014.

“GNSS Test Standards for Cellular Location: Multi-Constellations Working in a Dense Urban Future” by P. Anderson, E. Anyaegbu and R. Catmur in GPS World, Vol. 24, No. 5, May 2013, pp. 27–37.

Universal Mobile Telecommunications System (UMTS); LTE; Universal Terrestrial Radio Access (UTRA) and Evolved UTRA (E-UTRA) and Evolved Packet Core (EPC); User Equipment (UE) conformance specification for UE positioning; Part 1: Conformance test specification (3GPP TS 37.571-1 version 9.0.0 Release 9), European Telecommunications Standards Institute, Sophia Antipolis, France, 2012.
- GNSS Interface Control Documents
BeiDou Navigation Satellite System Signal in Space Interface Control Document, Open Service Signal, Version 2.0, China Satellite Navigation Office, Dec. 2013.

Navstar GPS Space Segment / Navigation User Interfaces, Interface Specification, IS-GPS-200 Revision H, Global Positioning Systems Directorate, Systems Engineering and Integration, Los Angles, Calif., Sept. 2013.

European GNSS (Galileo) Open Service Signal in Space Interface Control Document, Ref : OS SIS ICD, Issue 1.1, European Union, September 2010.

GLONASS Interface Control Document, Navigation Radiosignal in Bands L1, L2, Edition 5.1, Russian Institute of Space Device Engineering, Moscow, 2008.
October 8, 2015
Recording and Replay for Multiple Constellations and Frequency Bands
The design and verification of a new class of portable wideband record-and-playback system considers the relative merits and limitations of both simulator and record/replay approaches. The authors also discuss the benefits of the different test approaches to the development and characterization of various GNSS receiver types.

By Steve Hickling and Tony Haddrell

As new GNSS systems become available, and users take receivers to ever more challenging environments, the need for repetitive and repeatable testing during development grows ever stronger. Simulators have traditionally demonstrated performance and repeatability in the laboratory environment, and this approach remains the only option for planned signals not yet broadcast from space. However, this approach is becoming more complex as the number of GNSS signals and their reception environments increase.

Another way of testing receivers is through field trials. This allows investigation of conditions difficult to simulate, such as multiple reflections and interferers. These environments, however, are time-varying, and thus not repeatable in the true sense. Therefore, proper comparisons can only be made by assessing all competing receivers in the same trial, and any performance anomalies seen cannot necessarily be tracked down by returning to the same location at some point in the future. Furthermore, developers would like to see for themselves any such anomalies and try to understand and correct them, but it is not always desirable or practical (and certainly not economical) to put development engineers in locations scattered all over the globe.

To tackle this problem, GNSS signal record-and-replay capability is gaining acceptance as a practical tool for recording a signal environment at a single point in time and replaying at will. In real terms this means a device must receive the radio signals from the GNSS satellites, reduce them to a form suitable for storage, and then recreate signals from the stored data in a manner that makes them look completely real to any receiver under test or development.

Some receiver manufacturers developed their own capability to do this. Early devices were of necessity restricted in the signals they could handle and store, limited both by budget and available technologies. The basic problems are the amount of data to be stored in real time and the ability to recover it in real time. Even the GPS L1-only low bandwidth C/A code requires at least 2 Mbytes per single second of recording, or more than 100 Mbytes per minute.

Fortunately, with digital storage technology advances, we can now make use of higher storage capacities (1 TByte of storage is readily available at reasonable cost) and also higher write/read bandwidths (100 MBytes per second is realistic). All we need is some hardware and a processor that can handle the data rates.

Once we have our wanted signals reduced to some form of digital representation, we can simply store and retrieve them at will, handling the recordings as simple, if somewhat large, data files. This allows file distribution between equipments, and a split between making the recording in the field and replaying it in the laboratory. In fact, many manufacturers have dedicated field recording teams who send the files back to the engineers interested in the signal environments.

Replaying the signals is in some ways similar to generating simulated signals. In both cases, the starting point is digital data, on the one hand recorded in the field, on the other hand calculated by mathematical algorithms using the scenario specified in the simulator. In both cases the signal is created by generating radio frequency (RF) carriers and modulating them according to the GNSS signal formats.

Contrast of Two Approaches. None of the characteristics of the record/replay device replace the functionality of the simulator; in fact, both are valid tools for development and testing. For instance, it is not possible with a record/replay device to manipulate individual satellite signals, nor to introduce specific errors in the radio signals. Equally, it is not really possible with a simulator to recreate a particular physical environment made up of many reflected signals, jammers, manmade noise, and moving scenery. With a simulator, the user has control over the power of the received satellite signal, whereas in the recorder the entire signal-to-noise ratio observed at the point of reception has been recorded, and the user can only control the amplitude of the entire noise plus signal.

Permanent Signal Monitoring

One other aspect of raw signal recording lies outside the receiver testing topic, but is of interest for GNSS signal monitoring. It uses the ability to record GNSS signals all of the time, in this case from a good signal environment, and then to retain any time spans where an anomaly in the signals has been detected by a monitor receiver. This is comparable to recording security CCTV pictures, where we expect nearly all of the resulting files to be redundant, but can retain the interesting bits to replay over and over for further analysis. For example, if it is known that a given timing receiver installation suffers periodic loss of lock, it is possible to make a recording using the loss of lock to signpost the interesting region in much the same way as a reverse trigger on an oscilloscope.

Limitations and Compromises

The sheer function of recording GNSS signals off-air has some built-in limitations. First, the signal recorded represents only a snapshot of the environment, although numerous recordings can be made at, say, busy and quiet times, day and night, etc. This is really a reversal of the “non repeatability” aspect of measuring performance in a particular location. In the recording sense, we only get repeatability, with no guarantee that the scenario captured represents worst case conditions. Thus, going back to the location in the future may or may not provide similar results.

In addition to this, there are some signal processing aspects that limit the fidelity of the replayed signals. The first is that any recorder must have an external GNSS antenna and a GNSS receiver front-end built in, and this combination will receive both the satellite signals and thermal noise. The level of the noise is much higher than that of the signals if we don’t do any correlation related processing, and the receiver will contribute some more noise of its own (the noise figure of the system). The second aspect is that in downconverting the radio signals to a usable frequency for sampling and storage, the recorder must use some frequency reference of its own, which will contribute some frequency uncertainty and some phase noise (or jitter on the frequency). The final aspect is the digitization of the downconverted signal to get it into a suitable form for manipulation and storage. Since we are essentially sampling noise here (with the GNSS signal buried in it) we need to look at fidelity in reproduction of the noise during playback, and the effect of any signal (a jammer or interferer) that is above the amplitude of the noise. In analyzing this last aspect, we may include the effect of any automatic gain control (AGC) used to present the correct amplitude signal to the analog to digital (A2D) converter.

A New Simulation Requirement

We wanted to create a much more comprehensive and flexible device than hitherto available, going part way towards the much more general (and expensive) instrumentation recorders that are currently the only alternative.

The requirement is for a flexible, self-contained device that can be easily carried or transported for recording purposes, so having an internal battery and built-in control functionality, and simultaneously a device that fits neatly into a networked and externally controlled laboratory environment.

The first approach was to cover all of the possible GNSS frequency bands, although as more are added with time, we realized that this needed to be moderated somewhat. So the product covers L1, L2, L5 and their derivatives for the differing GNSS systems GPS, GLONASS, Galileo, and BeiDou, and also the Inmarsat commercial band to cover the proprietary augmentation signals used by many high-accuracy receivers (see Figure 1, red outlines).

FIGURE 1. Frequency bands, outlined in red, supported by the new record-and-replay device.

The next decision was what bandwidths to allow at each frequency, and how much of this bandwidth could be covered at once. The limitations here are driven by the data storage requirements of the signals being recorded, and the speed that they can be written to disk. The resulting solution allows bandwidths (BW) of up to 30 MHz at each frequency, and any three such bandwidths to be recorded at once. Physically, this is implemented with three channels with the ability to record any of the available frequencies or bandwidths. The user has, therefore, flexibility to set up recording for his particular needs, which may be just L1 covering BeiDou, GPS, Galileo, and GLONASS, or an L1,L2,L5, combination for a survey type application.

Of course, there are always requests for more capability, and we envisaged early on the ability to stack two devices to give six channels of 30-MHz BW for recording, say, GPS/Galileo and GLONASS at L1, GPS and GLONASS at L2, Galileo/GPS at L5, and an Inmarsat data carrier. See later for how this is achieved.

The whole product has to fit in a portable box with enough battery power for more than one-hour field campaigns, and also be capable of running from mains or vehicle power. The associated antenna needs to cover all of the frequency bands. Figure 2 shows the end result in its standalone configuration.

Figure 2. Portable solution for recording.

One additional requirement was placed upon the design, and that is the ability to record and replay non-GNSS data simultaneously with the GNSS signals, and reproduce them, if desired, in synchronism with the replayed signals. This allows time ticks, events, assistance data, sensor data, or even video to be stored and replayed along with the raw signals.

Architecture and Implementation

The new record-and-replay device uses a fast computer running the Linux operating system as its control center and storage/retrieval engine. Dedicated hardware is used to format or recover the raw data, and this has access directly to the computer bus to minimize the delays in writing or reading the mass storage, which in this case is a solid state hard drive (SSD). The overall architecture is shown in Figure 3.

Figure 3. Concept-level architecture.

The signal recording capability hinges around the RF planning, which has the task of supplying the necessary flexibility without adding more than minimal signal degradation.

For the RF functionality, the device contains a broadband front end and a three-channel RF amplifier (L1, Imarsat, and L2/L5), filtering the signal down to reasonable bandwidths for later downconversion. Three independent channels of downconversion to baseband I and Q analog signals have access to any of the RF channels and are based upon satellite TV technology architectures. The downconverters have baseband filters that can be commanded to a desired bandwidth by the control processor. This allows the use of narrower bandwidths where possible, allowing more recording time for a lower sampling rate. The baseband signals are sampled at 10 MHz or 30 MHz, paying attention to the Nyquist requirements for pre-digitisation filtering. Two bits for each of the I and Q signals are utilized for packing into the recorded file format. Figure 4 shows the arrangement.

Figure 4 . The RF architecture.

At this stage any additional synchronous data to be recorded, such as truth or assitance data, is inserted into the bit stream, and the data from all the channels in use is combined in a pre-determined format. Dedicated hardware is used for this, and large data buffers are provided to alleviate bottlenecks in sending data to the disks. Each file has an associated definition in a header, and contains synchronization data to allow the device to set up the replay path and recover the data bits in order to reproduce whatever combination was recorded. Note that resulting data files are given the same extension, regardless of content. Data files can be very big (at maximum bandwidth we record about 2.7 Gbytes per minute) and may be difficult to handle once recorded. To assist with this, the device has a second, removable SSD on board, allowing recorded files to be simply popped out of the caddy and shared with another device, or even mailed or couriered. The RF path for the replay consists again of three independent channels, able to generate any of the supported frequencies and modulate upon them the original signals recovered from the stored file. Once again, dedicated hardware and large buffers are needed to unpack the files and send the RF data to the correct channels or to the synchronous data outputs in the case of recorded digital data, as determined by the file header.

The data representing the recorded RF is converted back to analog form and filtered before being applied to modulators which regenerate the original channelized signals. Each channel has a programmable attenuator to “level” the amplitude, and the three channels are then combined together before passing through a common attenuator to provide user control over the replayed carrier to noise ratio (C/N0). Figure 5 shows the upconverter arrangement.

Figure 5. An upconverter channel.

All frequencies created within the device need to be traceable to a common reference. In addition, this reference needs to be at least as good as the reference in any receiver to be tested, since both its offset from true frequency and its rates of change will be superimposed on the replayed data. Many commercial-grade GNSS receivers (such as those used in mobile phone) are specifically designed to cope with poor oscillators, for instance a low-grade temperature controlled crystal oscillator (TCXO), whereas more professional receivers may expect a couple of orders of magnitude better performance. We decided, therefore, to include an ovenized oscillator (OCXO) for use both in record and playback modes. One challenge presented by this decision is that the oven is necessarily thirsty for power, and therefore a bigger battery is needed than would otherwise be the case.

The OCXO used is a 10.23-MHz component, thus allowing direct generation of the wanted GNSS frequencies using integer ratios and avoiding as much phase noise as possible in the various RF channels. A dedicated phase locked loop (PLL) generates a reference for output to other devices, and a 10-MHz input connector is provided to lock the OCXO to an external reference. These capabilities are utilized when combining two such devices, since we must have the same frequency reference in each. Apart from locking the two oscillators together, this configuration also needs time synchronization between the sampling in both devices, and this is achieved via an additional cable connected between the accessory connectors. Once time and frequency synchronized, the devices behave as a single six-channel unit, using external RF splitter/combiners for the RF connections.

Design Challenges

RF Total Bandwidth. The GNSS bands covered by the device range from the L5 band to the GLONASS L1 band, a total range of 480 MHz allowing for signal bandwidths. Table 1 shows the relevant bands.

Whilst the RF front end must be wide open to this range, assuming the use of a single RF input port, it is obviously necessary to provide bandwidth narrowing by filtering as soon as possible, to exclude jammers or carriers using the space between the GNSS bands, and to avoid the sheer noise power overwhelming the RF circuits. Examination of the supported GNSS services shows them essentially packed into two clusters of frequencies, which provide a convenient way of filtering down the RF input into two RF “channels.” This gets the total bandwidth down to about 180 MHz. Figure 1, the opening graphic for this article, shows the groupings. Beidou B3 and Galileo E6 are currently out of scope for this product, but will be supported in a later version.

The Inmarsat-supported signals are assigned their own RF path, since their structure is data modulated carriers, usually with low SNR. Elsewhere in the Inmarsat band there are more powerful carriers supporting comms traffic, which can “grab” the AGC and therefore cause loss of SNR during the digitization process. Hence this band is processed though its own RF path, maintaining as low a bandwidth as possible consistent with the frequency allocations of the various (proprietary) GNSS augmentation data carriers.

Tradeoffs. Throughput of the recording or replay paths is the performance limitation of the current architecture. Thus a lot of discussions and simulations concerning possible bandwidth, sampling rates, and bit depth tradeoffs was undertaken at the outset of the design. In addition, we needed to decide whether to sample signals at an IF frequency or at baseband. Trials were conducted to determine the real rates of disk access, which are different to the often quoted write and read speeds of computer interfaces.

The results of the trials and simulation led us to adopt a maximum average data rate to/from the storage system of 50 Mbytes/second, this being shown to be available over a period of many hours. Actually, at this rate we fill up a 1-Tbyte disk in about five hours.

To service the GNSS signal bandwidths of interest, again there are two groups of signals. This time we are looking at either the commercial signals (“open service signals” in some systems’ parlance) used by consumer-type receivers, which are relatively narrow band, and the military, high-accuracy, or resilient signals of interest to surveying and precision applications. Therefore, we offer two sampling rates, approximately 10 and 30 MHz, to avoid building large files where more than half of the bandwidth was of no interest to the user.

Next, we have to look at bit resolution. Given that we have generally a noise-like signal with Gaussian characteristics, if we were looking at digitizing at an intermediate frequency (IF), it can be shown that a 2-bit analog-to-digital converter (A2D) would be sufficient to keep the digitization losses to less than 1dB. Obviously, the fewer number of bits we need to store the better, commensurate with achieving the performance targets.

Frequency planning for all of the possible frequencies and bandwidths of interest is a complex task. The requirement here was to downconvert each signal of interest to a low IF suitable for digitizing, whilst having control of the bandwidth to eliminate unwanted signals and fulfill the Nyquist criterion. In addition, we wanted each channel to be isolated from the others even when the replay path involving the generation of the IF carriers was considered.

We therefore decided to downconvert to baseband for each channel, to avoid cross-contamination via the various IFs that would have to be generated for replay. In other words, we adopted an IF of zero Hz. This in turn means that the final bandwidth-determining filters are at baseband, and can readily be controlled by software means rather than having to switch RF paths. By downconverting into quadrature baseband channels, all stored signals are at the same (zero) IF, and crosstalk and imaging during upconversion is avoided.

Thus the A2D architecture of 2 bits in the inphase (I) and 2 bits in the quadrature (Q) arms of the downconverted signal was adopted. Doing the calculation in terms of stored data, we see that we can operate three channels inside our target storage bandwidth, with a margin left for other features such as storing video at the same time.
- For 30M samples per second (SPS), each channel has 4 bits or 0.5 bytes
- Therefore, for three channels the storage bandwidth is 0.5 * 3 * 30 MSPS, or 45 Mbytes/s
To keep the optimum A2D characteristics, the AGC is designed to adjust the signal amplitude at the converter to give a Gaussian response to the four states determined by the two bits in each arm. The AGC operates independently in each channel. Figure 6 shows the final architecture for the device in block diagram form.

Figure 6. Final architecture.

Real-Time Data Handling. Storage and retrieval of the digitized signals is carried out by dedicated hardware connected to the RF downconverter, the playback upconverter, and the main computer that “owns” the storage media. Large buffers allow the storage media to lag (record) and lead (playback) the real-time signals in time, and to take short breaks for housekeeping functions. Data is packed into a binary file according to a pre-determined sequence, which in turn is set by the number of channels and bandwidths in use. A file header is generated which contains all of the information necessary for reconstructing the data streams for replay. A synchronization sequence is added at the start of the file to allow recovery of the correct bits for each channel and each baseband quadrature arm, and to the correct timeslots for each component. Destroying the correct time reproduction is the most likely issue to cause faulty replay in any record/replay device. GNSS receivers don’t like discontinuous or slewing time!

This approach also allows the insertion of external digital data into the file. Providing the data processing hardware is aware of the individual bits into which this data is placed, digital data recorded at the same time as the raw signals may be regenerated synchronously during replay. Thus any data that is applied to a receiver in a real time trial can be available for the same trial any time after the event. Two streams of synchronous data can be recorded per channel potentially making six serial data streams per chassis available.

User Interfaces

A final challenge presents itself in the case of user interfaces. Although the operational options of the device are quite complex, there is a requirement to be able to capture field data with just the equipment itself and any necessary antenna setup. Consequently, the product has a display and control keys implemented on the front panel, allowing the user comprehensive access to the internal functions using a menu system and scrolling displays. Alternatively, for operation in a lab environment, a network connected user interface is specified, and this requirement is supported by a webserver running on the main processor in the device. Thus, simply opening a web browser and connecting to the device’s IP address allows full functional control.

In addition, connecting a mouse, keyboard, and monitor to the device allows access to the main processor, allowing the running of scripts thus providing full control of replays and receiver functions for running continuous tests in an automated laboratory environment. Using this approach, receiver modifications can be tested over many scenarios and locations many times each, to provide statistically relevant results, without taking up operator time. Remote monitoring is possible using the webserver.

Performance Testing

A range of tests and trials have been carried out to verify that the product meets its specifications, and to measure the performance in a number of real life scenarios.

Repeatability, Degradation, Attenuation. The first and most obvious thing to explore is the effect of the record and playback on signal-to-noise ratio. Since the RF circuits add some noise to the signal recorded, we would expect some degradation to take place here. Also, during replay, the receiver under test adds more noise, depending on its noise figure, although this should be the same as would be added when using “live” signals. Many receivers adjust for their noise figure when reporting C/N0 numbers (C/N0 is a signal to noise measurement normalized to a 1-Hz bandwidth and is the standard reported measurement for most GNSS receivers). However, by replaying back the recorded signal and noise at a higher level than would have been received in “live” conditions, we can eliminate almost all of the degradation. In live versus replayed tests for individual satellites using a JAVAD receiver, which allows us to test all of the supported bands and constellations, we found that replay is possible within ±1 dB of the original live signals. Replayed signals were about 10 dB above the original recorded level to achieve this, effectively swamping the receiver’s noise contribution.

An interesting aspect of controlling the C/N0 this way is the ability to attenuate the replayed signal and, therefore, increase the contribution of the test receiver’s noise figure. Thus, although the recorded C/N0 hasn’t changed, we can attenuate the replay level and use the receiver to add noise.

This process is not linear, and we obviously have to remove nearly all of the 10-dB excess to get started. The device keeps a table of attenuation vs C/N0 reduction, allowing the user to simply dial up the required C/N0 loss. Since this depends on the receiver noise figure, effects may differ slightly from receiver to receiver. Usefully the table is user definable allowing tailoring to a specific receiver.

Losses from Phase Noise, Other Factors. This category of degradation is more difficult to quantify, since the effects are on tracking and therefore range and phase measurement rather than signal to noise ratio. One way of looking at this is, therefore, to establish the positioning performance during live and replayed sessions, and measure the differences. This has some complexity, though, since putting the same signals into a receiver multiple times yields differing performance each time, meaning that we have to use some statistical analysis. Of course this isn’t possible on live signals, and is one reason why repeatable replayed signals are so important in developing GNSS receivers. Another aspect is the fact that some of the effects are differential among frequency bands (filter delays, for instance) and across bands as well (group delay) and also occur in the receiver under test, which will have been calibrated to mitigate its own contribution.

Figure 7 shows a comparison of static positioning for live and replayed signals using only GPS L1 and a 10-MHz sampling rate with an ST-Ericsson receiver, whilst Figure 8 is from a JAVAD receiver using all possible signals in live mode and GPS L1/L2 and GLONASS L1 in replay. In both cases the degradation is within 1 meter always, and much less than this when statistically analyzed.

Figure 7. Static position GPS L1 comparison: live left, replayed right.

Figure 8. GPS L1/ L2 with GLONASS L1 comparison.

Another opportunity to measure the effects is to run a zero baseline phase solution, whereby the receiver is used as the “base station” when receiving live signals which are simultaneously recorded. During replay, the same receiver is used as the “rover” with RTK corrections coming from the previously captured live session. In this setup, therefore, we are really only measuring differences in the replayed and live signals, and the usual measurement limitations of the receiver.

Figure 9 shows the results of one such test, with the pseudorange and carrier phase residuals plotted. This was carried out using two devices in master/slave mode recording GPS L1, L2, L5, and GLONASS L1, L2. As can be seen, the residuals are within “normal” expectations and are measured as 0.42 m RMS for the pseudorange and 1mm RMS for the carrier phase.

Figure 9. Residuals from zero baseline replay.

Drive Test

One of the most common uses for the recorder is to capture the signals at a particular time in a chosen “difficult” environment, A number of representative trials were carried out and we were able to demonstrate consistent results and repeatability. In some cases, the replayed signals yield better performance than live ones, which of course is possible given the differing receiver responses per signal run.

Also, the more times a receivers sees the same time span, the more ephemeris and iono data it can build up, especially true of built up areas where data acquisition is difficult. Figure 10 shows a small section of the City of Coventry in the UK, where the green trace is the “live” plot and the replayed one is in orange. Much of this route is under roads or buildings.

Figure 10. Live and replayed drive around in Coventry.

Dynamic Range and Fidelity

When jamming signals are introduced, the dynamic range comes into play. The earlier discussion of the 2-bit I and 2-bit Q architecture is tested here as the performance of the AGC and A2D is critical in maintaining the fidelity of the GNSS signals in a jamming environment. Note that we are not addressing deliberate jamming here, any “controlled” jammers can be added with an RF mixer at replay. Instead, we are concerned with the everyday jamming environment encountered just about everywhere electronic equipment is deployed.

A test was carried out to determine the dynamic range of record/playback paths. A simulator was used as a GPS L1 signals source, and progressively larger jamming signal added via an RF power combiner. The resultant C/N0 in a test receiver was plotted using the live signals which were recorded at the same time. A subsequent replay of those signals was then plotted on top of the original C/N0s. The result is in Figure 11.

Figure 11. Results of the increasing jammer test.

As can be seen, with low jammer powers the real-time and replayed C/N0s track very closely. The ST-Ericsson receiver we used has some signal processing mitigation built in, and so only shows slow degradation as the jammer power is increased. In the real-time run, it was able to track satellites with the J/S ratio greater than 44 dB (and therefore >25 dB above the noise)

On the replayed line, we see the dynamic range limitations start to dominate the replayed signal when the J/S reaches about 30 dB, or 11 dB above the noise, which aligns well with the theoretical analysis of the digitization strategy. This range is sufficient for most environments encountered in real tests.

In Use and Additional Capabilities

With so much flexibility we find that users have a diverse range of applications for the device. These range from multi-constellation usage at L1 only, allowing BeiDou, Galileo, GLONASS, and GPS to be captured, to full six-channel recordings using GPS, GLONASS, and Galileo at L1, L2, and L5 along with an Inmarsat-based assistance channel. For the first time in this class of device, recording of the “military” bandwidth signals is possible. User feedback has been favorable, especially since the unit opens up new capabilities for receiver development and testing.

A small margin of recording bandwidth has been put to use with the ability to record video alongside the raw GNSS signals, and to replay it simultaneously. This allows developers not only to see the performance of their receiver in difficult signal environments, but also to gain a visual idea of the physical environment. Figure 12 shows a receiver control panel along with video pictures of the recorded environment.

Figure 12. GPS L1 and video synchronized replay

Conclusion

Early user feedback has validated the concept behind the device. Although the device will cover additional GNSS constellations and bands as they become operational, for the present the technology is stretched about as far as it can be consistent with the development of a timely and cost effective device. We will continue to address the compromises in the search for more performance, no doubt pushed by user demands.

Acknowledgment

The authors thank their colleagues at Integrated Navigation Systems and Spirent UK for support and access to design and user information.

Manufacturer

This article describes the GSS6425 from Spirent Communication.

Steve Hickling obtained his joint physics and electronics degree from the University of Birmingham. He is responsible for Spirent’s GNSS test solutions as lead product manager in the positioning business.

Tony Haddrell obtained his degree in physics at Imperial College, London, and is technical director at integrated Navigation Systems. He is a consultant to GNSS companies and a visiting lecturer at Nottingham University.
March 1, 2014
Moving the Game Forward: Transceivers Aboard Light Vehicles

By John Carr and James Earl

Perspectives from a senior technical specialist and a production engineer at Newmont Boddington Gold Mine.

Newmont Fleet Management Services now continually monitors and plots the performance of JPS Locata alongside traditional GNSS in an effort to fine-tune the installed infrastructure. Learning to sculpt the perfect network continues as we move our JPS LocataLite transmitters to accommodate an ever-changing and expanding pit design.

Large twelve-meter benches and an aggressive mining plan have seen both North Pit and South Pit at NBG rapidly increase in depth, bringing the problems associated with GPS coverage in a deep-pit environment.

As mine sites develop and evolve, for the first time ever, we have the ability to dictate and control which areas we direct our own positioning coverage, and guarantee we can sustain accurate high-precision navigation wherever we need it. This level of control has just never been available before, and is literally impossible with satellite-based positioning signals. With GPS you just get what you get.

We are rapidly re-evaluating what may now be possible. We believe we are only at the very beginnings of where we can go with the LocataNet in the mining environment.

See also:
Synchronized Ground Networks Usher in Next-Gen GNSS

Staying One Step Ahead. Shape changes from week to week keep operations continuously relocating around the mine benches; this can, in some instances, make optimal positioning of the Jps LocataNet challenging. In the early stages of the project, we relied on producing computer-generated radio-coverage heat-map models of the pit to determine optimum positions for the individual LocataLite transmitters on the pit rim, and this is still a valid path if given the time.

However, with more Jps rovers becoming available, we now tend to make highly accurate predictions about network configuration on the fly. We can now install spare rovers as portable units in light vehicles (LVs) used by technicians onsite. This roaming functionality allows use of the Jps web browser in the rover to instantly validate, in the pit, any changes that may be required for the network before drilling and digging equipment is moved into place. Thus we can monitor real-world signal conditions in specific areas and adjust LocataLite positions to optimize positioning availability for machines that will soon arrive.

The typical network monitoring scenario nowadays is to quickly move a JPS-enabled LV onto a bench or area yet to be drilled or excavated, and review the signals from the individual LocataLite transmitters in real time. Technicians then make any necessary placement changes to the network in advance of any mining equipment arriving. Our ability to now ensure maximum possible positioning and navigation coverage at all times was undreamt of even 12 months ago.

Dual Rover. A modified HP Leica Drill JS System utilizing a Dual Jps Locata Rover has been installed into the drilling supervisors’ LV wagon. The drilling superintendent and supervisors had been exploring ways of moving towards a paperless system that could not only check the drill pattern itself, but also the areas being mined around the pattern. They identified a use-case example where having accurate positional information available in a vehicle enables supervisors to quickly review the construction and positioning of the protective windrows around the drill patterns. Access tracks and bench heights could also be checked without needing to call surveyors in to help. This degree of instantaneous clarity removes the guesswork associated with windrow construction, designed to provide a safety barrier between trucking and drilling operations. Incorrectly placed windrows can lead to potential flow restrictions in either operation, so getting it right the first time in active areas is important.

Mark-up by Night. Drilling supervisors can now accurately measure and monitor progress across the drill patterns using Locata technology to display virtual maps of all active drilling areas. Another spin-off benefit has been the introduction of a fixed point mounted to the front vehicle bullbar, to provide emergency mark-up of patterns during the nightshift when surveyors are not available on site. This helps particularly when a localized Wi-Fi outage prevents drills from downloading the blast pattern to commence drilling operations in an area of the mine. Before Jps, use of this high-precision GPS technology in vehicle had been considered ineffective and impractical because of the unreliable GPS coverage in the bottom of both pits. Plans are now under way to install a similar system into the shovel and auxiliary supervisors’ vehicles.

Forward! Recent group discussions found consensus that the best way to move forward with this technology now is continued integration into GPS, rather than stand-alone systems. Miners are generally a cautious lot: we could hedge our bets through a combined GPS+Locata solution package. Full-scale integration of Locata technology into future standard GPS products is perceived as a way companies such as NovAtel can provide the total package. We envisage a unified system available from all positioning receiver manufacturers that combines the benefits of GPS technology with the evident improvements and back-up that Locata has provided for environments where GPS is unable to function.

We have been in the enviable position of gaining a glimpse into the future, when the power of GPS-style positioning is improved to fill the GPS holes. The results we have obtained are, frankly, addictive. Having experienced this revolution first-hand, it would now be extremely painful to even contemplate going back to our previous GPS-only world.

October 1, 2013
Synchronized Ground Networks Usher in Next-Gen GNSS
LocataLite installation showing Jps transceiver tower.

Locata Fills Satellite Availability Holes in Obstructed Environments

By Chris Rizos, Nunzio Gambale, and Brendon Lilly

An integrated GNSS+Locata system installed on drills, shovels, and bulldozers — the full complement of high-precision machines on site — at Australia’s Newmont Boddington Gold Mine has increased positioning accuracy and availability, as well as mine operational efficiencies, demonstrating an improvement in availability over GNSS-only of 75.3 to 98.7 percent.

Many of the new paradigms in mining have at their core the requirement for reliable, continuous centimeter-level positioning accuracy to enable increased automation of mining operations. The deployment of precision systems for navigating, controlling, and monitoring machinery such as drills, bulldozers, draglines, and shovels with real-time position information increases operational efficiency, and the automation reduces the need for workers to be exposed to hazardous conditions.

GPS singly, and GNSS collectively, despite their accuracy and versatility, cannot satisfy the stringent requirements for many applications in mine surveying, and mine machine guidance and control. Increasingly, open-cut mines are getting deeper, reducing the sky-view angle necessary for GNSS to operate satisfactorily.

A new terrestrial high-accuracy positioning system can augment GNSS with additional terrestrial signals to enable centimeter-level accuracy, even when there are insufficient GNSS (GPS+GLONASS) satellite signals in view for reliable positioning and navigation. Locata relies on a network of synchronized ground-based transceivers that transmit positioning signals that can be tracked by suitably equipped user receivers.

In September 2012, Leica Geosystems launched the first commercial product integrating GNSS and Locata capabilities into a single high-accuracy and high-availability positioning device for open-cut mine machine automation applications: Leica Jigsaw Positioning System (Jps) – Powered by Locata. This article describes technical aspects of this technology and presents positioning results of actual mine operations.

In the near future — perhaps by 2020 — the number of GNSS and augmentation system satellites useful for high-accuracy positioning will increase to almost 150, with perhaps six times the number of broadcast signals on which carrier phase and pseudorange measurements can be made. However, the most severe limitation of GNSS performance will still remain: the accuracy of positioning deteriorates very rapidly when the user receiver loses direct view of the satellites. This typically occurs in deep open-cut mines as well as in skyscraper-dominated urban canyons.

Locata’s positioning technology solution provides an option either to augment GNSS with extra terrestrial signals, or to replace GNSS entirely. Locata relies on a network of synchronized ground-based transceivers (LocataLites) that transmit positioning signals that can be tracked by suitably equipped user receivers. These transceivers form a network (LocataNet) that can operate in combination with GNSS, or entirely independent of GNSS.

See also:
Moving the Game Forward: Transceivers Aboard Light Vehicles

Next-Generation Positioning

Pseudolites are ground-based transmitters of GPS-like signals. Most pseudolites developed to date transmit signals at the GPS frequency bands. Both pseudorange and carrier-phase measurements can be made on the pseudolite signals. The use of pseudolites can be traced back to the early stages of GPS development in the late 1970s, when they were used to validate the GPS concept before launch of the first GPS satellites.

In 1997, Locata Corporation began developing a technology to provide an alternate local GPS signal capability that would overcome many of the limitations of pseudolite-based positioning systems by using a time-synchronized transceiver. The LocataLite transmits GPS-like positioning signals but also can receive, track, and process signals from other LocataLites. A network of LocataLites forms a LocataNet, and the first-generation system transmitted signals using the same L1 frequency as GPS. Time-synchronized signals allow carrier-phase single-point positioning with centimeter-level accuracy for a mobile unit. In effect, the LocataNet is a new constellation of signals, with some unique features such as having no base station data requirement, requiring no wireless data link from reference station to mobile receiver, and no requirement for measurement double-differencing.

Improvements dating from 2005 use a proprietary signal transmission structure that operates in the license-free Industry Scientific and Medical (ISM) band (2.4–2.4835GHz), known globally as the Wi-Fi band. Within this ISM band, the LocataLite design allows for the transmission of two frequencies, each modulated with two spatially-diverse PRN codes. From the beginning the driver for the Locata technology was to develop a centimeter-level accuracy positioning system that could complement, or replace, conventional RTK-GNSS in environments such as open-cut mines, deep valleys, heavily forested areas, urban and even indoor locations, where obstruction of satellite-based signals occurs.

Leica Geosystems has been testing Locata in the Newmont Boddington Gold Mine (NBG) in Western Australia for several years. In 2006, NBG started installing Leica Geosystems high-precision GPS-based guidance systems for fleet management. The mine operators determined early on that as the pit grew deeper, they would need an alternative positioning system for these guidance systems to continue working for the life of the mine. In March 2012, Leica Geosystems deployed a world-first production version of its Jigsaw Positioning system, integrating GNSS+Locata, at the NBG mine.

Expected to become Australia’s largest gold producer, the mine consists of two pits (Figure 1). The North Pit at NBG is currently about 1 kilometer long, 600 meters wide, and now approaching 275 meters deep.

Figure 1. Location of 12 LocataLites at NBG Mine.

Figure 2. The Newmont Boddington pit, 900 feet deep and going deeper all the time, creates difficulties for GNSS equipment positioning the mine’s heavy machinery.

A single LocataNet consisting of 12 LocataLites was deployed during April and May 2012 in an initial installation designed to cover both pits in the mine. The results presented here are taken from tests in the North Pit.

Leica’s version of the LocataLite is solar-powered and designed to be placed in the best locations to achieve the maximum benefit. As no special consideration for the location of a transmitter base station is required, the LocataLites can be placed in areas on the rim of the pit or just above the machines operating in the pit floor. The only set-up requirement is that they are able to see at least one other LocataLite to synchronize their transmissions to around 1 nanosecond or better throughout the mine.

Each Jps transmit tower has four small patch antennas mounted in an array. The uppermost is a GNSS antenna used to self-survey the top of the tower, and hence derive the positions of the other antennas below it on the tower. The Locata transmit 1 antenna is mounted directly under the GNSS antenna. The Locata receive antenna is directly under that, and the Locata transmit 2 antenna is around two meters lower down on the tower.

All the antennas are separated by a known distance, and the LocataLite transmit antennas can be tilted down into the pit to maximize the signal broadcast into the area. Each LocataLite transmits four independent positioning signals, two signals from each transmit antenna. These signals provide a level of redundancy and greatly assist in the mitigation of multipath problems in the pit, thereby contributing to the robustness and reliability of the positioning solution.

Jps receivers were first installed on two production drill rigs in April 2012. Installation on drills was the highest priority because they are the machines at NBG that operate closest to pit walls and other obstructions, and therefore stood to benefit most from having more reliable positioning. Each Jps receiver incorporates two GNSS and two Locata receivers (Figure 3). One GNSS and Locata receiver pair is connected to a co-located antenna on one side of the machine and the other GNSS and Locata receiver pair is connected to the other co-located antenna. The GNSS receivers obtain their RTK corrections from an RTK base station. The Locata receivers do not require any corrections. The system uses the NMEA outputs from both pairs of receivers to determine the position and heading of the drill rig for navigation purposes.

Figure 3. Jps receiver with integrated GNSS and Locata receivers and two receiver antennas.

The goal of the Jps receiver is to improve the availability of high-accuracy RTK positions with fixed carrier phase integer ambiguities. The results presented here are therefore divided into three sections:
- Improvements in availability over a two-month period for all the data in the North Pit.
- Improvements in availability for an area in the pit where the GNSS savings are expressed in dollar terms.
- Accuracy results achieved and maintained in this GNSS-degraded area.
The performance results shown here are real-world samples of the system operating on drills at NBG. However, it will be appreciated that GNSS satellites are in constant motion, so GNSS-only position availability in different parts of the pit changes by the hour. The results therefore only apply to those drills in those positions in the pit at that time.

Another drill a little distance away in the same pit could experience far better or far worse GNSS availability at exactly the same time.

Overall Availability

Figure 4 shows the performance difference between using GNSS-only (left) and Jps GNSS+Locata (right). The data for these plots was recorded for the two drills that contained the Jps receiver in the North Pit during the months of April and May 2012. A green dot represents the time the receiver had a RTK fixed solution, and a red dot represents all other lower-quality position solutions — essentially when the receiver was unable to achieve the required RTK accuracy because of insufficient GNSS signals or geometry.

Figure 4. Plots of availability and position quality in the North Pit at NBG for April and May 2012 for GNSS (left) and Jps (right). Green = RTK (fixed) solution, Red = all lesser quality solutions.

Although the availability of GNSS-only RTK fixed position solutions was reasonably good over this entire area, being at the 92.3 percent level at that time, the Jps nevertheless provided a measurable improvement of 6.5 percent to availability, bringing it up to 98.8 percent. Considering that during those two months, the two drills spent a total of 72.24 operational days in the North Pit, this improvement equates to nearly 4.7 days or 112.7 hours of additional guidance availability.

Figure 5 highlights the low positional quality for the GNSS-only solutions and how Jps significantly improved the availability in areas of limited GNSS satellite visibility.

Figure 5. Plots showing non-RTK quality positions, demonstrating that Jps can help reduce lesser-quality RTK solutions. (Performance in the circled area is highlighted in more detail in Figure 6.)

Availability in Poor GNSS Visibility

The ellipse in Figure 5 highlights a particular location in the North Pit where GNSS positioning consistently struggles due to the presence of the northern wall and to a lesser extent from the eastern wall. The integration of GNSS and Locata signals improved availability as shown in Figure 6, which in this case increased by 23.4 percent.

Figure 6. Zoomed-in area where GNSS performance was poor between May 2 and May 4, 2012. The circled area shows where the accuracy tests were performed.

As the machine downtime due to not having a RTK position costs the mine approximately U.S. $1000 per hour for each drill, the improvement in availability of 112.7 hours for just the two drills shown in Figure 5 over the two months equates to a savings of $112,700 in operational costs. This productivity increase is significant, considering that the GNSS-only availability in this case still seems relatively good at 92.3 percent. If the GNSS availability for those two months was more like 75 percent — as was the case shown in Figure 6 for the two days in May — then the cost savings become far greater, approaching nearly $400,000, for just two drills over two months. Even a small increase in productivity brings a significant financial benefit ($110,000 per hour) when all 11 drill rigs running in the mine are affected by loss of GNSS positioining availability, yet continue to operate with Jps.

Today all 11 drills in the pits have been fitted with the Jps GNSS+Locata Receivers. As a point of reference to emphasize the level of operational savings: if the Jps had been fitted to all 11 drills during the April and May 2012 period shown in the above results, the cost savings at that time would have been on the order of $1,000,000. It is clear that the savings in production costs that can be gained from improving the availability to the fleet guidance system has a significant impact on the return-on-investment, potentially covering the installation costs within months of deployment. It should also be emphasized that as the pits get deeper, GNSS availability will only degrade further, and the evident production and dollar benefits of the integrated GNSS+Locata system become even larger.

Relative Accuracy

The above levels of improvement in availability are of no benefit if the position accuracy is not maintained within acceptable limits. In order to compare the relative accuracy between the two systems, a dataset was taken from the same data above (circle in Figure 6) when the machine was stationary.

The average position difference between the GNSS-only and Jps receivers for the hour-long dataset was 1.2 centimeters horizontally and 2.7 cm in the vertical component (Table 1). The spread of the position solutions for the two receivers were comparable in the horizontal, with Jps providing a slightly better horizontal RMS value due to the extra Locata signals being tracked and the stronger overall geometry. Additionally, Jps showed a better RMS in the vertical compared to GNSS-only.

Table 1. Comparison of relative accuracy and RMS between the GNSS-only and GNSS+Locata solutions.

Figure 7a shows the spread of horizontal positions for the Jps receiver, where 0,0 is the mean horizontal position during this time. Note that all the positions are grouped within +/-2 cm of the mean without any outliers. Figure 7b shows the corresponding spread in the vertical positions. These are well within the acceptable accuracy limits required by the machine guidance systems used at the mine.

Figure 7A. Scatter plot of the positions from the Jps receiver over a period of over an hour.

Figure 7B. Vertical error for same sample set as Figure 7a.

Concluding Remarks

Based on the experiences at Newmont Boddington Gold, use of Jps has improved the operational availability of open-pit drilling machines by at least 6.5 percent by reducing the outages in 3D positioning caused by poor GNSS satellite visibility commonly associated with deep pits. When Jps is subjected to much harsher conditions closer to high walls, the Jps continues to perform and the improvement in availability compared to GNSS-only is more significant while still maintaining RTK-GNSS levels of accuracy. The additional availability achieved translates directly into cost savings in production for the mine.

Acknowledgments

The first author acknowledges the support on the Australian Research Council grants that have supported research into pseudolites and Locata:
- LP0347427 “An Augmented-GPS Software Receiver for Indoor/Outdoor Positioning,”
- LP0560910 “Network Design & Management of a Pseudolite and GPS Based Ubiquitous Positioning System,”
- LP0668907 “Structural Deformation Monitoring Integrating a New Wireless Positioning Technology with GPS,”
- DP0773929 “A Combined Inertial, Satellite & Terrestrial Signal Navigation Device for High Accuracy Positioning & Orientation of Underground Imaging Systems.”
The authors also thank the many people that have contributed to the development of the Leica Jps product. The Leica Geosystems Machine Control Core and CAL teams in Brisbane and Switzerland, other Hexagon companies such as Antcom Corporation and NovAtel, the Locata team in Canberra and the United States, and the people at Newmont Boddington Gold that have gone out of their way to make this a success.

Chris Rizos is a professor of geodesy and navigation at the University of New South Wales; president of the International Association of Geodesy; a member of the Executive and Governing Board of the International GNSS Service (IGS), and co-chair of the Multi-GNSS Asia Steering Committee.

Nunzio Gambale is co-founder and CEO of Locata Corporation, and represents the team of engineers who invented and developed Locata.

Brendon Lilly is the product manager for the Leica Jps product at Leica Geosystems Mining and has worked for more than 20 years in both software and hardware product development. He has a Ph.D. from Griffith University.
October 1, 2013