How will widespread deployment of 5G most benefit GNSS?
Greg Turetsky
“The connectivity options that widespread 5G offer will accelerate multiple GNSS benefits. The high bandwidth is starting to encourage many into the RTK domain, but I think the bigger opportunity may come from the low power versions that enable IoT applications. The combination of the ubiquity of cellular connectivity with the low power of NB-IoT could truly accelerate the real time asset management sector all the way down to the package/pallet level.” — Greg Turetzky
Allison Brown
“Widespread deployment and adoption of 5G is likely to continue to increase the demand for spectrum as broadband access continues to expand. The recent FCC decision allowing Ligado to operate terrestrial networks in bands near GPS is likely not the last decision that will result from this increasing demand. It is not clear to me that 5G deployment will ‘benefit’ GNSS and chipset vendors may need to prioritize developing products that have improved robustness in the presence of nearby interference.” — Alison Brown
Miguel Amor
“The benefit of 5G will be seen in the long term, when 5G ranging capability is available. Hybrid positioning algorithms using both 5G and GNSS observations will provide significant positioning benefits in challenging urban environments and seamless navigation between indoor and outdoor environments. Applications across markets will see the benefits of hybrid 5G and GNSS navigation, but the real advantage lies in how this hybrid will enable the future of autonomous mobility. We will see both technologies working closer together to deliver a seamless and ubiquitous positioning solution.” — Miguel Amor
Mitch Narins
“Like communications, the ability to precisely and securely position and navigate is an essential part of 21st century life. Together they must support both critical and non-critical operations. This requires finding a common understanding of spectrum needs and how to have the best of both. In the long run, end runs by either side may achieve myopic goals but will damage society. The problem is crying out for an enterprise-level systems engineering leadership that can plot our future spectrum course. Else, the push for spectrum will continue, fueled by ‘entrepreneurial spirit’ and often a lack of understanding of the importance of other spectrum uses.” — Mitch Narins
What is the single most valuable lesson GPS can learn from Galileo and/or BeiDou?
Bernard Gruber
“Service continuity. Given that GNSS are so ubiquitous today, similar to the electrical grid, it is imperative that GPS continue the superb system of outage reporting via NANUs, transparency via GPS.gov, and statutory commitments via U.S. Code. Aligning to the U.S. commitment, continued Open Service Signal-in-Space, such as GPS-Galileo-BeiDou, allows thousands of planned and interoperable “apps” such as Google Maps and Waze to thrive. Although not directly in line with the question, terrestrial timing backup systems, similar to what China and some other countries do, is a valuable lesson in continuity from BeiDou.”
Bernard Gruber
Northrop Grumman
Ellen Hall
“Perhaps the lesson could be, ‘It’s easier not to be first!’ Newer navigation constellations have the benefit of watching and learning from GPS — things done well and things to improve. From technology to operational procedures, a global navigation satellite system (GNSS) is difficult to execute. Would it have been easier or cost less if the United States had decided to land on the Moon after someone else had paved the way? Probably, but there is something very satisfying about being first! And, despite the fact that GPS satellites outlive their life expectancy, we keep launching new ones, with improved technology, to give the world better accuracy and more robust signals. The world of navigation welcomes Galileo, BeiDou, and all the others to follow.”
Ellen Hall
Spirent Federal Systems
Alison Brown
“GPS could benefit from lessons learned from BeiDou as to the importance of resilience in providing PNT services. BeiDou has a total of 42 satellites now in operation and open signals are broadcast on six frequencies (B1I, B1C, B2I, B2a, B2b, and B3I). In comparison, GPS has currently 29 operational satellites and provides open signals on three frequencies (L1, L2, L5). As the global threat to GPS grows, from frequency incursions by evolving 5G systems as well as deliberate interference or spoofing, the ability to operate on different frequencies to provide resilience against harmful interference will become increasingly important.”
Alison Brown
NAVSYS Corporation
Jean-Marie Sleewaegen
“While GPS remains a gold standard with decades of reliable service, the advent of BeiDou and Galileo has undoubtedly stirred up competition. While BeiDou is exceptionally fast at deploying new signals and services, Galileo is now transmitting the first ever authenticated OSNMA signals, helping secure GNSS receivers against spoofers. The main lesson is that it is better to have company than to be alone. Having multiple GNSS not only increases the number of satellites and signals, which improves positioning accuracy and reliability, but more importantly, it fosters continuous innovation, for the benefit of all users.”
Thirty years ago, NAVSYS was deep into the development of the Wide Area Augmentation System (WAAS). I had the honor of being the chair of the RTCA SC-159 Integrity Working Group, which developed the first concepts for what evolved into three integrity standards for GPS: multi-sensor integration, receiver autonomous integrity monitoring (RAIM) and wide-area differential GPS using a GPS integrity channel (GIC) to broadcast corrections over a geostationary overlay.
NAVSYS, working with Inmarsat Corporation, built the first prototype WAAS SIGGEN equipment, which was deployed at the Coonhilly Coast Earth Station and used to transmit an L-band C/A-code signal over the Inmarsat Atlantic Ocean Region MARECS-B satellite to a software GPS receiver that we had developed and installed at Inmarsat’s Test and Development Laboratory in London.
First Inmarsat Geostationary Overlay Test-Bed, 1991. (Image: NAVSYS)Image: FAA
This evolved into the FAA’s WAAS program, which used the NAVSYS SIGGEN for the initial deployment, test and evaluation. The algorithms developed by NAVSYS were ultimately licensed to Raytheon for use on the operational WAAS and MSAS systems.
By Alison Brown, Jarrett Redd, and Mark-Anthony Hutton
GNSS signal simulators can be expensive and beyond the limited budgets of many researchers. In this month’s column, we look at one company’s approach to providing GNSS signal simulation at a low cost — one that virtually any researcher can afford.
INNOVATION INSIGHTS by Richard Langley
WHY DO WE SIMULATE REALITY in mathematics, science, engineering, and other pursuits — even in our recreational activities? Well, we do it for a variety of reasons. In mathematics and science, we try to comprehend reality, which is complicated and variable and often has some degree of randomness. We build mathematical models of physical, chemical, or biological processes to better understand them or to predict a particular outcome given some initial conditions. The model may contain a stochastic component to reflect a degree of uncertainty associated with the processes. Weather forecasting is a prime example. Typically, the models are run on a computer where the model parameters and initial conditions can be readily adjusted and the varying outcomes analyzed.
Simulations of reality are often used in teaching where students can more easily grasp the behavior of complicated systems whether they be in the natural sciences or in economics or the social sciences. In medical education, simulated human patients are used initially because it is safer than having students operate on real patients. Similarly, flight simulators are used for the training of pilots because it is cheaper and safer than using real aircraft and a wide variety of “what if” scenarios can be experienced.
Simulation is used for a range of engineering activities to see how an existing system behaves under different conditions because it is faster or cheaper than performing tests in the “real world.” It can also be used to estimate how a proposed new system might behave before it becomes a reality — looking at traffic flow in road networks, for example.
We also use simulation for recreation, whether it is playing with the latest computer game or improving our swing with a golf simulator. And simulation is a mainstay of the movie industry.
But getting back to engineering and the main interest of this magazine, simulation is a useful technique in the design and operation of equipment used with global navigation satellite systems. With a radio frequency simulator, we can mimic the radio signals generated by the satellites. These devices allow us to define scenarios, including receiver trajectories, and to replay them while varying the operating parameters of the receiver. Some simulators allow us to record live signals and then to play them back under different assumed conditions.
However, such GNSS signal simulators can be expensive and beyond the limited budgets of many researchers. In this month’s column, we look at one company’s approach to providing GNSS signal simulation at a low cost — one that virtually any researcher can afford.
As the noted French sociologist and philosopher, Jean Baudrillard, pessimistically once said: “We live in a world where there is more and more information, and less and less meaning.” In the field of GNSS engineering, at least, simulation is helping to stem the tide and give us a better understanding of reality.
“Innovation” features discussions about advances in GPS technology, its applications, and the fundamentals of GPS positioning. The column is coordinated by Richard Langley, Department of Geodesy and Geomatics Engineering, University of New Brunswick. To contact him with topic ideas, email him at lang @ unb.ca.
Embedded GPS receivers have become commonplace with the proliferation of GPS navigation systems into all but the least expensive vehicle and cell-phone lines. As more manufacturers embed low-cost GPS receivers into their products, the need for low-cost GPS signal simulators has also grown. Controlled virtual testing is vital in ensuring the expected system performance.
Many GPS signal generators are available that are designed specifically for high-volume production test applications for devices that use commercial GPS/SBAS, GLONASS, and Galileo receivers. Often the cost of these high-end simulators is beyond the reach of small companies or universities. In response to this need, we have developed our low-cost, software-defined radio (SDR)-based GPS Signal Architect Test Set to address a broad range of research, academic, industrial, and defense applications. The system is designed to be flexible, scalable, and most importantly, inexpensive.
Our test set leverages the capabilities of the Universal Software Radio Peripheral (USRP) radio and our GPS Signal Simulation Toolbox to provide users with a GPS signal generation capability at a much lower cost than currently available on the market. The combination of the GPS signal simulation software coupled with the record and playback capability of the USRP makes for an extremely low-cost, yet highly flexible, GPS signal simulation capability.
FIGURE 1 shows the GPS signal simulator hardware. It is designed for use with commercial software-defined radios and is based on our GPS Signal Simulation Toolbox.
FIGURE 1. GPS signal simulator hardware.
Toolbox. The Toolbox is a complete set of GPS signal simulation, test, and analysis tools. This Matlab-based signal simulation toolbox simulates the effect of the signal degradation on a conventional commercial GPS receiver, including the effect of the ionospheric activity on the code and carrier tracking loops such as losing lock or cycle slipping. The Toolbox’s geographic tools facilitate the transformation of data between the various coordinate systems commonly used in GPS research, including latitude-longitude-altitude; WGS 84 Earth-centered, Earth-fixed (ECEF); north-east-down; and body-fixed reference frames. It also provides tools to read GPS almanacs and ephemerides and compute ECEF and line-of-sight vectors to GPS satellites as a function of user position and time. The receiver design and analysis tools model different receiver architectures and simulate different error scenarios by providing tracking and navigation algorithms, including phase lock loops and delay lock loops.
The user-configurable options allow the operator to define virtually all aspects of a GPS signal environment, including the GPS spreading code(s), navigation message, and interference scenarios. Such flexibility is particularly useful in simulating GPS jamming environments, where time, resources, and repeatability are generally scarce.
Because these tools are linked directly to Matlab, it is relatively simple to define and implement new signal components as they become available. Of primary interest are the GPS modernization codes as well as those of other global navigation satellite systems (GNSS). Also of interest are new and exotic categories of jammers, including frequency-modulated, amplitude-modulated, phase-modulated, and frequency-swept jammers.
An early version of the toolbox was reviewed in a previous Innovation column (see Further Reading).
Configuration. In the configuration shown in Figure 1, the signal control unit (SCU) is used to control the radio for record and playback operation. The USRP includes a 10-MHz frequency standard as well as an input for an external reference clock. The GPS Signal Architect software can produce custom GPS scenario data files, which can use the USRP to produce a GPS signal at RF.
This article provides a review of how the signal simulator uses the USRP family of radios as low-cost RF record and playback devices using the Signal Architect files. In addition, the hardware design and supported signals are described and test results are presented showing the USRP providing simulated GPS signals to conventional GPS user equipment.
Radio Hardware
The USRP radio family provides an inexpensive development platform for software-defined radios. The USRP can also be used to record and play back the GPS signal in a static or mobile environment. The system operator can then reproduce the signal on the bench either from a simulated profile or from a previously recorded test environment. An advantage of the USRP is that it supports a wideband transceiver front-end that can accommodate the full 20 MHz of the GPS signal band and can be tuned to operate at any of the GPS signal frequencies (L1 at 1575.42 MHz, L2 at 1227.60 MHz, or L5 at 1176.45 MHz). This allows record and playback of both the civil and military GPS codes.
While the GPS Signal Architect tools can be easily adapted for use with any commercial SDR, the USRP family was chosen because of its reasonable price, quality construction, and extensive support by the GNU Radio project.
USRPs are SDRs, which can, in principle, transmit or receive signals on any frequency under software control. Typically, USRPs connect to a host computer through a high-speed USB or gigabit Ethernet link, which the host-based software uses to control the USRP hardware and to transmit or receive data. Some USRP models also integrate the general functionality of a host computer with an embedded processor that allows the USRP to operate in a standalone fashion. The USRP hardware is controlled through a hardware driver, which supports Linux, MacOS, and Windows platforms. A framework running on the host computer then accesses the USRP through the driver. Several frameworks, including GNU Radio (a free software toolkit for learning about, building, and deploying SDR systems developed under the GNU Project — “GNU” is a recursive acronym that stands for “GNU’s Not Unix”), LabView, Matlab, and Simulink, use the driver. The driver’s functionality can also be accessed directly with an application programming interface (API), which provides native support for C++. Any other language that can import C++ functions can also use the driver. This is accomplished in Python through the Simplified Wrapper and Interface Generator, for example. The API allows users to develop their own custom frameworks, as we did with our SCU.
Of the available USRP radios, the N210 was chosen because it has the highest sample rate, greatest flexibility, and largest capacity for modification (see FIGURE 2).
FIGURE 2. Univeral Software Radio Peripheral.
The USRP provides an interface between high-speed analog to digital converters, high-speed digital to analog converters, and an Ethernet interface, as previously mentioned. Daughterboards available for the USRP provide an interface from the baseband signals present at the data converters to the GPS frequency bands and vice versa.
A daughterboard (or daughtercard or piggyback board) is a circuit board meant to be an extension or “daughter” of a motherboard. The USRP uses interchangeable daughterboards, plugging into the main board, to serve as the RF front end. Several classes of daughterboard modules exist: receivers, transmitters, and transceivers. Transmitter daughterboard modules can modulate an output signal to a higher frequency; receiver daughterboard modules can acquire an RF signal and convert it to baseband; and transceiver daughterboard modules combine the functionality of a both a transmitter and receiver.
For this project, a WBX (wide bandwidth) transceiver daughterboard was installed in the USRP. The tunable range of the WBX (50 MHz to 2.2 GHz) covers all the current GNSS frequencies. An RF pre-filter is used to band-limit the GNSS signals to the sample rate selected for use in the SCU to avoid spectral folding from the N210 40-MHz channel bandwidth. For example, a 2-MHz filter centered at L1 is optimal based on the Nyquist sampling frequency of 2 MHz of both the in-phase and quadrature (I/Q) components of the signal. If sampling at 20 MHz, then a 20-MHz pre-filter should be used.
Signal Control Unit
The SCU includes a Linux single-board computer with software developed to run under the GNU Radio Companion (an open-source graphical tool for creating signal flow graphs and generating flow-graph source code using the GNU Radio libraries) and management of the GNU SDR for RF record and playback under control of the GPS Signal Architect software through an Ethernet connection. This enables the user to tap into the excellent USRP community support for his or her project and benefit from the close relationship between the GNU Radio project and the USRP manufacturer. The Ethernet connection is also used to download and upload recorded or simulated signal files from the Signal Architect signal simulation software.
Signal Simulation Software
The GPS Signal Architect hardware and software provides users with a Matlab-based GPS signal generation capability. If our Matlab GPS Toolbox is provided, the Signal Architect GPS simulation can be run under the Matlab environment. For the non-Matlab user, the Signal Architect software is bundled as a stand-alone executable. The signal simulation flow is depicted in FIGURE 3.
FIGURE 3. Signal Architect simulation flow. (Click to enlarge.)
GUI. Using a simple, intuitive graphical user interface (GUI), the user specifies a trajectory and a complete set of simulation parameters to create an I/Q data file (see FIGURE 4). The user specifies a trajectory either from an NMEA file (most GPS receivers use the National Marine Electronics Association 0183 interface standard for logging positions and other data) or a KML file from Google Earth (Google’s Keyhole Markup Language has become a standard for describing geographically referenced features), and an almanac file used to define GPS satellites to be simulated. The user defines the mask angle for the satellite selection and the noise figure to be simulated. The Signal Architect software then generates a simulated digital storage file, including the selected pseudorandom noise codes (C/A and/or the unencrypted military P or M′ codes).
FIGURE 4. Signal Architect graphical user interface. (Click to enlarge.)TABLE 1. Signal simulator system specifications.
Scenarios. The Signal Architect software also ships with preloaded scenario files that the user can run right out of the box into the SCU using the USRP. The Signal Architect software supports computers with multi-core processors and will automatically configure itself to run on all available processors. The Signal Architect software will generate either static or dynamic simulation profiles. The Signal Architect GUI allows the operator to easily modify a wide range of scenario variables from the pre-set defaults. Complete scenarios are easily shared between signal simulation systems, supporting collaborative testing between similar projects and reducing the amount of time spent developing test tools.
The signal data file can then be used for subsequent analysis within Matlab using the Matlab GPS Toolbox, or can be provided to the SCU and USRP to create a GPS signal suitable for playback into a GPS receiver. If the Matlab GPS Toolbox is available, the user has complete flexibility to manipulate the signal at various stages of generation or post-generation to simulate GPS anomalies. Without the toolbox, the user is restricted to using only the standard error modeling provided by the compiled Signal Architect code.
Simulation Test Results
To demonstrate the high fidelity of our Signal Architect signal record and playback capability, a series of stationary GPS simulations were run. In these tests, the USRP was used to record and play back GPS C/A-code signals at the L1 band (1575.42 MHz). The SCU and USRP were connected to a rooftop-mounted GPS L1 antenna. The GPS signal was split between a commercial GPS receiver and the USRP to allow the operator to monitor the GPS receiver while the USRP was recording the GPS signal.
In record mode, the I/Q data is written from the USRP to a file on the SCU. In playback mode, the data is read from the file by the USRP to generate the RF signal. The RF signals are output to the GPS receiver through an external variable attenuator. The attenuator allows the operator to adjust the signal power into the GPS receiver as different lengths of antenna cable are added or as the signal is split to other GPS receivers.
To demonstrate the GPS Signal Architect Test Set performance, representative data was collected in a series of two laboratory tests. The first test demonstrates the system performance as a record and playback GPS signal simulator. The second test results demonstrate the system performance when using the Signal Architect software to generate custom GPS scenario files for playback into the GPS receiver.
In the first test, the GPS simulator hardware was configured as shown in FIGURE 5. The GPS receiver and USRP were connected to a commercially available antenna. The antenna was positioned at a known location with a clear view of the GPS constellation. The signal from the GPS antenna was split between the GPS receiver and the USRP so that the data could be logged by the receiver software at the same time as it was being recorded by the SCU.
FIGURE 5. GPS Signal Simulator record and playback GPS simulation.
The simulated satellite constellation is shown in FIGURE 6. Seven GPS satellites are in view.
FIGURE 6. Simulated satellite constellation.
The 2-D position error from the simulated signal is shown in FIGURE 7. The errors are representative of the accuracies achievable using GPS C/A-code pseudoranges.
FIGURE 7. North-east (2-D) position error.
We can examine the performance of our test set by looking at plots of the measurements of carrier-to-noise-density ratio (C/N0) from the GPS receiver for both the live sky data and for the recorded signal when played into the GPS receiver by the Signal Simulator for three of the GPS receiver channels (see FIGURE 8). The C/N0 data collected from the GPS antenna is shown in blue, while the C/N0 from the USRP is shown in green.
FIGURE 8. C/N0 record and playback vs. live sky collection.
As we can see, the C/N0 was 1–2 dB lower in playback mode when compared to the data collected from the GPS antenna. The signal loss is due to the 1-bit sampling of the incoming GPS signal by the Signal Architect software. One-bit and 2-bit quantization are used in many commercial GPS receivers. The rule of thumb states that 1-bit quantization degrades the signal-to-noise ratio by 1.96 dB, and 2-bit quantization degrades the signal-to-noise by 0.55 dB. These results show that 1-bit I/Q sampling is sufficient for reproducing GPS L1 C/A-code signals with the USRP.
In the second test, the Signal Architect software was used to generate a 10-minute static GPS C/A-code L1 scenario file. The SCU used the USRP to generate the GPS signal.
Shown in FIGURE 9 are the number of satellites the GPS receiver was able to track. When using the GPS Signal Architect Test Set to play back the scenario file, the GPS receiver was able to track all the simulated satellites in the file. The time necessary for the GPS receiver to acquire and track the satellites is consistent with the performance one would expect from the GPS receiver when connected to an external antenna.
FIGURE 10 shows the C/N0 measurements from the GPS receiver for three of the receiver channels. There were nine satellites in this static scenario file. The C/N0 for all the satellites is stable for the duration of the scenario playback.
FIGURE 9. Number of satellites tracked (digital signal file playback mode).FIGURE 10. C/N0 (digital signal file playback mode).
Another Hardware/Software Option
We have also worked with the manufacturer of the LabSat hardware signal simulator to include some of the software functionality of our USRP system.
The LabSat GNSS simulator (see FIGURE 11) can be used to record live navigation satellite RF data streamed onto a hard drive. This can then be played back as an RF signal. When integrated with the SatGen software, simulated digitized RF data can be generated and played back into the LabSat simulator in place of the recorded, digitized GNSS RF signals.
FIGURE 11. LabSat GNSS simulator.
The core of the SatGen software is our Signal Architect software component, which has been adapted to run on the LabSat platform to allow simulation of the multiple GNSS satellite signals.
Hardware. The latest version of the LabSat hardware design (LabSat 2) enables the record and playback of GPS and GLONASS synchronized RF data streams (see FIGURE 12). When recording the GPS or GLONASS signals, the RF L1 channels (1575.42 MHz for GPS and 1602.0 MHz for GLONASS) are down-converted to a 0-Hz intermediate frequency. The signals are sampled (2 bit I and Q) at 16.368 MHz to capture the full GLONASS set of frequency channels. The GPS and GLONASS data is then interleaved into a 4-bit data stream and recorded in an internal buffer as a binary file. A high-speed USB link then transmits the data to a PC before streaming onto the PC hard disk. For playback, the PC streams the stored binary data to the LabSat via the USB link. The recorded digital GPS and GLONASS signals are up-converted onto the GPS and GLONASS RF channels and played back into the receiver under test. A digital attenuator on the output can adjust the RF output level.
FIGURE 12. LabSat GNSS simulator hardware design.
Using the LabSat record and playback mode, all of the real-world effects on the GNSS signals are recorded, including multipath effects, drop-outs, and atmospheric effects, allowing repeatable tests to be performed on GNSS receivers under a variety of real-world conditions, such as operating in urban canyons. This is ideal for debugging fault conditions on GNSS equipment and software. For more extensive simulations in different environments, the LabSat SatGen software can be used to generate simulated scenarios at any time or place or for a dynamic environment.
SatGen Scenario Simulation. SatGen is a software package that allows users to define trajectories for use in generating simulated data files for playback into LabSat. A user-defined trajectory file can be used to create a LabSat-simulated scenario for a route anywhere in the world. Routes can be generated directly from NMEA files imported directly into SatGen from a GPS datalogger or from user-defined routes generated using Google Earth.
SatGen users can use Google Earth to define a route by creating a path using its “Add Path” tool. The user can use as many or as few waypoints as the user wants, and can edit routes by moving, adding, or removing waypoints. The path is saved as a standard Google Earth KML file, which is imported into SatGen, which then fills in and smoothes the trajectory between the waypoints. The user can also define velocity profiles, or SatGen can provide these automatically. SatGen creates an NMEA file that is used to generate a binary I/Q simulated signal file for replay on the LabSat hardware.
Signal Architect Simulation. The core of the SatGen software is GNSS Signal Architect, an upgraded version of our GPS Signal Architect, which provides the capability to simulate multiple GPS signals and also different GNSS signals.
Signal Architect imports the NMEA trajectory either from a prerecorded file or from one generated using SatGen, and uses this file to generate a GNSS-simulated scenario. The user specifies the input GPS satellite constellation through a Yuma-format almanac file and the GLONASS constellation through a GLONASS almanac file in “.agl” or RINEX format. These files are then used to generate the simulated pseudorange, Doppler, and carrier phase for the GPS and GLONASS satellites in view of the simulated GNSS receivers above a specified mask angle. This simulated range data is then used to generate the digitized I/Q signals for the GPS and GLONASS satellites. Users who have access to our GNSS Signal Simulation Toolbox (an upgrade of our GPS toolbox) will have the added ability to modify the GNSS signal strength and add additional high-resolution error models to the simulated signals including multipath or GNSS signal error characteristics. The resulting I/Q simulated data file for the GPS plus GLONASS constellation is then recorded in a data file, which can be loaded into the LabSat hardware for playback into a receiver under test.
Test results using the LabSat and SatGen combination have demonstrated that highly accurate navigation solutions can be obtained with a variety of playback modes.
Conclusion
The combination of our GPS Signal Architect software with either the SCU and USRP or LabSat has proven to be an ideal low-cost GPS signal simulation tool with the capability of simulating or recording the complete GPS signal spectrum, including both the civil and the military codes for playback. The initial release of the GPS Signal Architect Test Set supports L1 operation and C/A- and P-code and M′ signal simulation or C/A- and P(Y)-code and M′ record and playback, while both GPS and GLONASS signal generation and playback is available with LabSat.
Our team of GPS and RF experts is continually developing and updating the system to provide additional functionality. Future releases of our test set will include support for multi-frequency SDR hardware and the capability to simulate other civil and military GPS signals, and also those of other global navigation satellite systems. To reflect this capability, we have branded the latest version of our simulation system, the GNSS Signal Architect Test Set.
Acknowledgments
The authors acknowledge the support of Ettus Research LLC in the development of the technology associated with the USRP system, as well as Racelogic Ltd. for collaboration on the LabSat GNSS simulator. USRP is a registered trademark of National Instruments Corp.
The article is based primarily on the papers “GPS Signal Simulation Using Open Source GPS Receiver Platform” presented at the Virginia Tech Symposium on Wireless Personal Communication in June 2011 and “SatGen GNSS Signal Simulation Software” presented at ION GNSS 2011 in Portland, Oregon, in September 2011.
Manufacturers
The GNSS Signal Architect Test Set was developed by Navsys Corp. The USRP used for the test set is the Ettus Research LLC model USRP N210. The LabSat 2 GNSS Simulator and associated SatGen software is produced by Racelogic Ltd. The GPS equipment used in our tests was a Novatel DL-4 plus receiver and a GPS-702GG antenna.
Alison Brown is the president and chief executive officer of Navsys Corp., Colorado Springs, Colorado, which she founded in 1986. Brown has a Ph.D. in mechanics, aerospace, and nuclear engineering from UCLA, an M.S. in aeronautics and astronautics from MIT, and an M.A. and B.A. in engineering from Cambridge University. She is a fellow of the Institute of Navigation and an honorary fellow of Sidney Sussex College, Cambridge.
Jarrett Redd is a senior systems engineer with Navsys Corp. working on hardware, firmware, and embedded systems development for signal acquisition, processing, and transmission. He holds an M.S. and B.S. in computer engineering from Texas A&M University.
Mark-Anthony Hutton is a software engineer with Navsys Corp. working on GNSS signal simulation tools and the GPS Jammer Detection and Location System. He holds a B.S. in computer science from the University of Colorado at Colorado Springs.
FURTHER READING
• Authors’ Proceedings Papers
“SatGen GNSS Signal Simulation Software” by A. K. Brown, M.-A. Hutton, M. Quigley, and M. Sampson in Proceedings of ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 19–23, 2011, pp. 2031–2034.
“GPS M’-Code and P-Code Signal Simulation Using an Open Source Radio Platform” by A. Brown and B. Johnson in Proceedings of ION GNSS 2011, the 24th International Technical Meeting of the Satellite Division of The Institute of Navigation, Portland, Oregon, September 19–23, 2011, pp. 1494–1498.
“Modeling and Simulation of GPS Using Software Signal Generation and Digital Signal Reconstruction” by A. Brown, N. Gerein, and K. Taylor in Proceedings of the 2000 National Technical Meeting of The Institute of Navigation, Anaheim, California, January 26–28, 2000, pp. 646–652.
“GPS Simulation” by M. B. May in GPS World, Vol. 5, No. 10, October 1994, pp. 51–56.
• Matlab Simulation Toolboxes
“GPS MATLAB Toolbox Review” by A.K. Tetewsky and A. Soltz in GPS World, Vol. 9, No. 10, October 1998, pp. 50–56.
• NMEA 0183
NMEA 0183, The Standard for Interfacing Marine Electronic Devices, Ver. 4.00, published by the National Marine Electronics Association, Severna Park, Maryland, November 2008.
Figure 1. Autonomous air refuleing operational view.
By Alison K. Brown, Dien Nguyen, and Paige Felker, NAVSYS Corporation, Glenn Colby and Frank Allen, PMA-268 NAVAIR
An alternative precision GPS architecture, Precision RELNAV, enables an airborne tanker plane and a Navy unmanned combat aircraft to navigate independently to a high degree of precision without requiring carrier-cycle ambiguity resolution using precision GPS ephemeris updates to a tightly coupled GPS/inertial solution onboard each aircraft. The solution rivals that of conventional relative kinematic techniques while providing more robust positioning that reduces message traffic between aircraft and does not require a long filtering time.
Naval Unmanned Combat Air System (N-UCAS) is the U.S. Navy’s program to demonstrate technologies and reduce risk for unmanned, carrier based strike and surveillance aircraft. The Unmanned Combat Air System Carrier Demonstration (UCAS-D) program is specifically maturing technologies for unmanned carrier operations and Autonomous Aerial Refueling (AAR). Successful demonstration of UCAS-D technologies provides for transition and risk reduction to future unmanned and manned programs.
A key enabler for N-UCAS is the ability to perform AAR so that the N-UCAS can support long duration missions. As shown in Figure 1, the intent is for AAR operations to mirror current manned Aerial Refueling operations as much as possible and to operate using existing Navy probe and drogue and US Air Force boom receptacle refueling methods.
The planned refueling architecture for probe and drogue and boom-receptacle refueling developed by PMA-268 is shown in Figure 2 and Figure 3. For both of these architectures, the GPS/inertial navigation system on the UAS and tanker are used to calculate a precise relative position to be used by the UAS to approach the tanker from astern. For drogue systems, the final connection to the basket is performed using aiding from a laser-based drogue positioning system. In addition, an optional machine vision system is used to aid both methods of refueling from the receiver. Under the UCAS-D demonstration program testing is being conducted with surrogate aircraft to verify the CONOPS procedures and performance of the precision GPS/inertial navigation solution alternatives being evaluated. NAVSYS is supporting this program through a Small Business Innovation Research (SBIR) contract and is demonstrating a Precision-RELNAV (P-RELNAV) tightly coupled GPS/inertial solution that improves the robustness of the relative navigation solution as described in the following sections.
The first method that PMA-268 implemented for computing a relative GPS solution used the GPS/inertial integration approach illustrated in Figure 4. The inertial navigation solution from both aircraft was used to calculate the relative inertial vector e that is used for the real-time AAR guidance. The tanker’s raw GPS observations are also passed over the data link to the UAS where a relative kinematic solution is calculated to derive the carrier-phase based relative position between the aircraft, a. This approach relies on solving for the integer carrier cycle ambiguities on the observations from the two aircraft using the same algorithms that were previously developed for use in performing GPS precision approach and landings on the carrier. The precise GPS relative position is then applied to calibrate the inertial derived relative position and the resulting GPS/inertial solution is used to calculate an offset to the center of the refueling envelope (u) for guidance of the UAS to connect to the receptacle.
Figure 4. Precision-GPS relative GPS positioning.
With the P-RELNAV approach shown in Figure 5, Precision GPS Ephemeris data is provided to both aircraft across the tactical data links using the NAMATH system. As shown in Figure 6, NAMATH provides global services across military tactical data links through the Joint Range Extension (JRE) to provide real-time corrections to the GPS system errors using Zero-Age Precision GPS Ephemeris data, which is refreshed by the GPS Control Segment every 15 minutes. The NAMATH system is currently being used operationally by the U.S. military to improve navigation accuracy and also precision weapons delivery.
Using the PGE corrections significantly reduces the errors on the GPS observations allowing the GPS/inertial solution to rapidly converge and not exhibit step changes during satellite transitions from the GPS system bias errors. The GPS/inertial Kalman Filter on the tanker is used to observe the residual errors from the GPS satellites being tracked, and these residuals (δf) are sent from the tanker to the UAS which applies these as an update to its internal GPS/inertial Kalman Filter. As shown below, this final correction sets both the tanker and the UAS on a precise common reference frame resulting in a high accuracy relative position being derived from the vector difference of the two tightly-coupled GPS/inertial solutions (e*).
Figure 7 shows the difference in the GPS position that is calculated using the Precision GPS Ephemeris as opposed to the Broadcast Ephemeris. This shows that over a month, there can be peak position excursions as high as 5 meters in the horizontal and 10 meters in the vertical based on the GPS broadcast ephemeris. With a GPS/inertial solution, these bias offsets will cause the solution to “trend” between different position bias offsets whenever the satellite selected set changes. This trending introduces significant errors into the relative inertial vector between two aircraft (e).
Figure 7. GPS Peak Position Errors from Broadcast Ephemeris Offsets (March 2010).
P-RELNAV Flight Test Set-Up
The P-RELNAV performance was tested using data collected on a UH-1 helicopter at Eglin AFB. Two independent GPS/inertial systems were mounted on the equipment plate below the aircraft (Figure 8) and a GPS reference receiver on the ground was used to calculate a kinematic position post-test using a Magellan ZXW receiver on the aircraft as a truth system. The PGE corrections were uplinked to the aircraft through EPLRS for use in calculating a PGE-corrected navigation solution. NAVSYS used recorded GPS and inertial data from a Kearfott KN4073 and a NovAtel/LN-200 inertial system provided by Dahlgren NSWC. The raw GPS (Pseudo-range and carrier phase) and IMU (high rate acceleration and angular rate) data was processed using our InterNav solution and also recorded for post-processing. This data was then played back through InterNav to calculate independent GPS/inertial tightly coupled solutions from the two inertial systems with and without the PGE corrections and to compare the performance of the absolute and relative solutions against the kinematic positioning truth data.
Figure 8. Flight test equipment.
P-RELNAV Flight Test Results
The P-RELNAV algorithms were implemented in our InterNav software package. This has been previously used to generate very high accuracy relative kinematic solutions for providing high-rate Time Space Position Information (TSPI) for instrumenting F-16 aircraft. The InterNav software was upgraded to apply the tightly-coupled GPS updates to the inertial solution using the PGE Zero-Age Differential GPS (ZDGPS) corrections, and also to apply the GPS residual updates (δf) in the UAS Kalman Filter to compute the P-RELNAV relative position solution.
Dual-frequency observations from the GPS receivers were used to correct for the ionospheric group delays in the solution.
The performance of the P-RELNAV solution was evaluated by comparing the results from the two independent inertial solutions for the same location on the UH-1 aircraft. Tests were conducted over multiple flights with the GPS antennas at different locations on the UH-1.
The results from the first flight test are shown in Figure 9 through Figure 13. Figure 9 shows the GPS/inertial results during the flight with a tightly-coupled solution but without PGE corrections. Figure 10 shows the GPS/inertial results during the flight with a tightly-coupled solution but with PGE enabled. Figure 11 shows the satellite visibility during the flight test. These plots show that the satellite geometry changes, dramatically affecting the inertial position covariance, whenever the satellites used in the solution change. The inertial filters these errors, but the relative solution is biased and drifts resulting in over 2 meter errors. In Figure 12 the same plot is shown when the PGE corrections are applied. This shows that the relative position error has been reduced to better than 1 m per axis and 35 cm 1-sigma. For flight critical operations, such as AAR, minimizing position excursions is essential. Figure 13 and Figure 14 show a statistical measure of the percentage of time that the data exceeds a horizontal or vertical threshold. This shows the benefit of the PGE corrections in removing GPS excursions caused by satellite ephemeris errors from the navigation solution. (See the Appendix for a definition of the Inverse Circular Error Probable (ICEP) metric and its comparison with other statistical measures).
Figure 9. Flight 1: Relative position of KN and NovAtel/LN200 GPS/INS solutions.Figure 10. Flight 1: Relative position of KN and NovAtel/LN200 PGE enabled GPS/INS solutions.Figure 11. Flight 1: Valid PRNs used in KN GPS/INS solution.Figure 12. Flight 1: Relative Position of KN and NovAtel/LN200 PGE enabled GPS/INS solutions.Figure 13. Flight 1: Horizontal ICEP comparison for PGE enabled GPS/INS and GPS/INS solutions.Figure 14. Flight 1: Vertical ICEP comparison for PGE enabled GPS/INS and GPS/INS solutions.
Since both GPS receivers used in the test had a reasonably clear view of the sky, they were both tracking the same satellites. In the AAR CONOPS, the UAS approaches the tanker from below and so will have some satellites obscured from view by the tanker (see Figure 4). In this case, the use of different satellites can significantly increase the relative position error when PGE corrections are not available. In the case shown where one satellite was forced as a drop-out, the non PGE corrected vertical error grew to 4 meters for the relative solution.
Further improvements in the P-RELNAV performance will be achieved using the residual (δf) update mode in the InterNav Kalman Filter to set the estimated observation residuals for the common satellites to the same values for the UAS and Tanker GPS/inertial filters. This mode is currently being tested and the results will be presented in a follow-on paper.
Figure 15. Flight 1: Horizontal ICEP plot for PGE enabled GPS/INS and GPS/INS solutions. Different satellites tracked by the receivers.Figure 16. Flight 1: Vertical ICEP comparison for PGE enabled GPS/INS and GPS/INS solutions. Different satellites tracked by the receivers.
Conclusion
The P-RELNAV solution has the following advantages over using a conventional relative kinematic positioning solution in meeting the Automated Aerial Refueling precision positioning requirements.
Fast initialization — does not require time for carrier ambiguity cycles to be resolved.
Robust operation during satellite obscuration by the tanker — is not dependent on common satellites being maintained in view between platforms.
Insensitive to loss of carrier lock — does not require cycle ambiguity reinitialization if carrier lock is lost during the UAS approach to the tanker.
Work is proceeding on testing the P-RELNAV solution. Additional test data is being collected for performance evaluation under the UCAS-D demonstration program using dual aircraft as surrogates to demonstrate the P-RELNAV performance and compare the benefits of the P-RELNAV tightly coupled approach with the PGPS kinematic solution.
This work was sponsored under NAVAIR contract N68335-10-C-0094. The authors gratefully acknowledge the support of PMA-268 and the assistance of NSWC Dahlgren in collecting the flight test data and providing the truth reference for the P-RELNAV analysis.
Appendix: Inverse Circular Error Probable (ICEP)
For safety-of-life applications, the statistic of the excursion events, for example when a horizontal error is outside the safe error bound, is often more important than the knowledge of the percentage of points that are within a smaller error bound, such as CEP or DRMS. These excursion, or low probability, statistics can be examined with the Inverse Circular Error Probability (ICEP) function. The ICEP provides the horizontal position error (HPE) with a specified probability that a result could be outside this value. An optional input to the function is a filtering time constant, with the filter applied to the time-series horizontal error data before calculating the ICEP. This separates the effect of bias errors from short term noise errors that could be filtered (for example with an inertial unit) from the HPE.
HPE = ICEP (P%, τ)
Where
HPE= Horizontal Position Error value [m]
P% = Percent of total horizontal errors (x) that are larger than HPE
τ = filter time constant to reduce short term white noise
Note that the Circular Error Probable (CEP) which is the radial value that encloses 50% of the positioning results is closely related to ICEP, with
CEP = ICEP(50%, 0)
Also the R95 which is the radial value that encloses 95% of the positioning results is related to ICEP, with
R95=ICEP(5%,0)
Other common statistics used are the DRMS and 2DRMS values which are defined below, are also related to ICEP through the following equations.
For a Gaussian, uncorrelated error distributions with sigma of one meter in the range and azimuth axes, the ICEP is shown in Figure A-1 in blue. For each horizontal position error value, the ICEP gives the percentage of the distribution that has larger errors. Also shown on this plot are the CEP, DRMS, 2DRMS and R95 values which match the 1-sigma scale factors shown in the table above. Figure A-2 is the same data with a log10 plot. In this plot the y-axis is probability rather than percent. This plot is useful for examination of outlier behavior, as it shows low probability events more clearly.
Figure A-1. ICEP(P,0) for a Gaussian Distribution with 1 m 1-sigma.Figure A-2. Log Scale ICEP(P,0) for a Gaussian Distribution with 1 m 1-sigma.
Alison Brown is president and chief executive officer of NAVSYS Corporation, which she founded in 1986. NAVSYS Corporation specializes in developing next generation Global Positioning System (GPS) technology. She has a Ph.D. in mechanics, aerospace, and nuclear engineering from UCLA.
Dien Nguyen works for NAVSYS Corporation as a research engineer specializing in Kalman filtering estimations, kinematic positioning, and related navigational optimization techniques. He holds an M.S. in electrical engineering from Clemson University.
Paige Felker is a research engineer in the Algorithms and Analysis group at NAVSYS Corporation. She holds an M.S. in aerospace engineering from the University of Texas at Austin.
Glenn Colby is the chief architect for the Navy Unmanned Combat Air System at the Naval Air Systems Command in Patuxent River, Maryland. He has led the research, development, and testing of advanced aircraft, navigation and communications systems for more than 26 years. He received his B.S. in aerospace engineering with honors at the University of Virginia in 1984.
Frank Allen is the technology manager for the Navy Unmanned Combat Air System at the Naval Air Systems Command. In the last 16 years he has worked in management of research and development of advanced aircraft navigation and communications systems. Frank received his M.S. in physics from Northeastern University.
