The Information Security researchers at University College London (UCL) analyzed an archive of 12.16 million GPS observations collected between 2007 and early 2026 to understand what the broadcasts actually contain.
To make processing this massive dataset practical, the researchers built a Julia pipeline to extract the bits directly into a DuckDB database. This setup allowed them to run queries across 19 years of global ground-station data in milliseconds.
Read the full analysis in the researchers’ blog here.
Viavi Solutions has unveiled the PNT-6200 Series Assured Reference for resilient positioning, navigation and timing (PNT). Viavi acquired Jackson Labs Technologies in November 2022.
The PNT-6200 Series Assured Reference provides resiliency and robust cybersecurity for critical infrastructure.
The compact system can supplement or replace GPS signals based on connectivity to the broadcast range of timing sources in the market including other GNSS satellites, and commercial satellite, terrestrial, wireline, and atomic clock services. The PNT-6200 Series will draw the timing signal from the most reliable source and use it as a replacement for the GPS input, enabling continuous operation.
The PNT-6200 Series will be showcased at Mobile World Congress in Barcelona, Feb. 27-March 2.
Ever since it came on-line in February 2022, the website GPSJam.org has shown what appears to be regular interference with GPS signals in Texas near San Antonio and Del Rio, and locations north and south of Oklahoma City, Oklahoma.
Only on normal workdays, however. Not on weekends or holidays. Furthermore, whatever was happening also took time off between the Christmas and New Year holidays GPSJam.org also shows similar, though less regular, activity in New Mexico. Experts say this is easily explained as White Sands Missile Range is often the site of electronic warfare training and tests. These are always announced in advance in FAA Notices to Air Missions (NOTAMs) when any interference with GPS reception is anticipated.
The regular patterns observed in Texas and Oklahoma and the lack of NOTAMs led some experts to speculate the source could be inadvertent interference from a commercial or government activity. Said one former official, “It’s just the kind of pattern you see from large organizations. They are off every weekend, federal holidays, and around Christmas.”
Aerobatic-capable Military Training aircraft reporting low NIC values (Image: Stanford University)
GPSJam.org is the brainchild of aviation analyst John Wiseman. The site uses crowdsourced ADS-B reports gathered by the ADS-B Exchange and displays it on a world map. Areas in yellow indicate that between two and ten percent of ADS-B reports for the day had low navigation accuracy. Areas in red had ten percent or more.
Information from the site has proved useful in identifying patterns of regular GPS jamming and spoofing in Russia and other conflict areas around the globe.
The workday patterns in Texas and Oklahoma have appeared on GPSJam.org displays since the site went live in February 2022.
GPS Interference and Aviation
Minor interference with GPS signals is fairly common. GPS jamming devices, while illegal to use, are inexpensive and easy to obtain from vendors on the internet.
Truck drivers wanting to defeat their company’s fleet tracking system, people concerned about being tracked by the government or others, even ministers trying to keep parishioners from texting during sermons – all have been known to use such devices.
Most GPS interference is unintentional. A two-year European Union study found hundreds of thousands of potentially harmful signals, but judged only about ten percent to be intentional. The rest were the inadvertent byproduct of poorly tuned electrical and electronic equipment.
ADS-B tracks of training aircraft performing aerobatics. Red indicates low NIC value reported. (Image: Stanford University)
While most GPS interference is unintentional and localized, spurious signals powerful enough to noticeably impact airborne operations are not unknown.
In two separate incidents last year strong interference near the Denver and Dallas airports impacted air traffic, each for more than a day. The Denver incident lasted for 33 hours before authorities found the source and shut it down. Air traffic was disrupted at Dallas for 44 hours according to government sources, though researchers found the actual interference only lasted for 24 hours. The source of the disruption was never identified.
In 2019 a passenger aircraft was almost lost due to GPS interference while on approach to Sun Valley, Idaho’s Friedman Memorial Airport. As the aircraft flew a GPS-based approach in smoke and haze, the interfering signal was just strong enough to lure it off course and toward a mountain. Fortunately, a sharp-eyed radar controller hundreds of miles away spotted the problem and intervened in time. The source of the interference was never identified.
As a result of the Sun Valley incident and input from numerous aviation groups, the International Civil Aviation Organization told its members there was an “urgent need to address harmful interferences” to satnav signals.
Texas and Oklahoma Mystery Solved
A researcher at Stanford University finally solved the puzzle of the strange recurring sequence of reports from Texas and Oklahoma.
While investigating last October’s GPS interference event near the Dallas airport, PhD candidate Zixi Liu noticed aircraft outside the main area of effect also reporting low Navigation Integrity Category (NIC) values. This began before and continued after complaints from commercial airlines about GPS not being available at Dallas-Fort Worth. These aircraft were in the same general area of Texas, but far enough away that there were large areas between them and Dallas that did not contain any reports with low NIC values.
Low navigation accuracy reports displayed at GPSJam.org. in New Mexico reports were due to GPS interference from military testing. In Texas and Oklahoma, military aerobatics training likely caused reports of low navigation accuracy. (Image: GPSJam.org)
At the same time MS Liu was also investigating anomalous ADS-B reports near San Antonio and Del Rio, Texas. She discovered in all three cases the reports of low NIC values were coming from military training aircraft regularly used for aerobatics. Other aircraft nearby reported good NIC values and showed no evidence interference.
In a recent presentation to the Institute of Navigation, she postulated that Interference with GPS signals was not the cause of the low navigation integrity reports. Rather, the rapid maneuvers and unusual aircraft attitudes of aerobatics caused the airplanes’ navigation receivers to intermittently lose lock on signals from GPS satellites. This caused their ADS-B equipment to report low navigation integrity.
Having solved that mystery, Ms. Liu continues to work on her original question – identifying the source of October’s 24-hour GPS disruption near the Dallas-Fort Worth airport.
Mr. Dana A. Goward is the President of the Resilient Navigation and Timing Foundation and a former US Coast Guard helicopter pilot.
Foxcom, a subsidiary of Global Invacom, has launched a solution that enables aircraft ground engineers to undertake 24/7 avionics testing of Inmarsat, Iridium and GPS satellite signals indoors.
The Hangar Repeater Solution enables engineers involved in maintenance, repair and overhaul (MRO) of aircraft to undertake testing 24/7 regardless of the weather, without having to move aircraft in and out of a hangar, as is the current practice.
The dedicated repeater greatly reduces aircraft-on-ground time, work hours and overall maintenance costs, providing a rapid return on investment.
While Inmarsat and Iridium satellite equipment has been deployed worldwide, its use was limited to outdoor, as building structures block satellite signals. Foxcom’s unique and all-inclusive repeater solution provides communication inside buildings or underground without the need for a direct line of sight to the sky. An existing Foxcom repeater can be easily upgraded to add Inmarsat compatibility.
Beyond the aviation sector, GPS, Inmarsat and Iridium repeaters can be deployed across a range of locations and industries, such as underground civil defence and military bunkers, oil rigs and ships and large buildings.
Foxcom launched its first range of repeaters in 2013. Established in 1993, Foxcom specializes in radio frequency over fiber equipment. It is a top supplier to satellite operators, broadcasters and integrators worldwide, with products that offer high performance, bandwidth and reliability.
Beginning Wednesday, Jan. 25, Air Force Space Command (AFSPC) will conduct a limited-duration test implementing an increase of the Ll C/A power level on the GPS Block IIR-M and llF satellites — a total of 19 satellites.
The C/A power will remain within IS-GPS-200-H specifications, and the power increase is not expected to increase the noise floor by more than 0.3 signal-to-noise ratio in the worst case.
“We assess that there will be no adverse impacts to civil, commercial or military GPS users, but anyone who experiences issues during this test should address them through established reporting channels,” said Gen. John W. Raymond, U. S. Air Force (USAF) commander, in a “Memorandum for Distribution.”
Military users can contact the GPS Operations Center at DSN 560-2541, while civilian users can contact the U.S. Coast Guard Navigation Center at 703-313-5900. In the event of unexpected critical impacts, a process to cease testing operations has been put in place.
The AFSPC point of contact for this test is Maj. Jeffrey Koch, DSN 692-0233, commercial 719-554-0233.
There has been a lot of GNSS-related news in the past month, so I thought I’d do a quick review of the importance (and possibly unimportance), of news you may have heard about.
Just because some GPS satellites weren’t broadcasting CNAV on L2C and L5 doesn’t mean your receiver isn’t using L2C or L5. On the contrary, if your receiver was designed to handle L2C and L5, it’s likely already been using them. The CNAV is just the message being transmitted on the L2C and L5 carrier along with the code. If your receiver tracks L2C and L5, it’s likely already using the carrier (phase) observations. However, even then there are only a limited number of satellites broadcasting L2C and L5 carriers. Specifically, there are 11 satellites broadcasting L2C and four broadcasting L5, meaning that your receiver is roughly tracking one L5 satellite at any one time during the day and several satellites broadcasting L2C.
The C/A code (NAV) message on L1 that your receiver already uses today is good enough. Your receiver doesn’t need the CNAV message on L2C or L5 to utilize the L2C or L5 carrier observations. That’s not to say there’s no benefit to CNAV on L2C and L5, but for RTK or post-processing, the value is largely in the carrier observations. In the future, when L2C and L5 are fully deployed (or near fully deployed), the L5 CNAV does have some distinct advantages, but that’s a few years down the road. To give you an idea of the benefit of L5 when there are enough GPS satellites broadcasting L5 , take a look at the following illustration published by Dr. Richard Langley from the University of New Brunswick comparing the reduction of code multipath on L1 and L5 of two WAAS GEO satellites.
Reduction of code multipath using L1 and L5 on WAAS GEO Richard B. Langley, Hyunho Rho
For the full text of the Langley/Rho article on L5 and WAAS that appeared in the May 2009 issue of GPS World magazine, click here.
Second GPS IIF Satellite of 2014 Launched May 16
On May 16, the second GPS satellite of 2014 was launched successfully from Cape Canaveral in Florida. It was the sixth model IIF GPS satellite, of which 12 are being built, before transitioning to the next-generation model GPS satellite named GPS III. It began transmitting on May 21, 2014, but is not yet set healthy.
Photo credit: Spaceflight Now.
The GPS model IIF satellite broadcasts the legacy GPS signals as well as the new civilian L2C and L5 signals.
Normally, a launched GPS satellite is set healthy (and automatically begin being used by your GPS receiver) within 30 days of launch, sometimes much sooner. However, the IIF GPS satellite launched in February of this year still hasn’t been set healthy, the reason reportedly being an extended navigation test reported here.
A third GPS IIF satellite is scheduled for launch this year on July 31.
During the post-launch interview last Friday, the Air Force stated that the remaining GPS IIF satellites (six) will be launched by the end of 2016. From previous conversations I’ve had with Air Force officials, they’ve stated that there could be an overlap between IIF and III satellite launches. In other words, the first GPS III satellite could be launched before all IIFs have been launched.
“Since March 15, 2014, the Air Force has been conducting functional checkout on a GPS satellite, designated Space Vehicle Number (SVN) 64. SVN-64 broadcasts a data message that clearly indicates SVN-64 is unusable for navigation. Nevertheless, the U.S. government has confirmed that certain GPS receivers are using data from SVN-64, in violation of GPS interface specifications, resulting in outages or corrupted, inaccurate position calculations.”
CGSIC reports that the GPS continues to operate and is fully functional.
In Australia, faulty GPS receivers on roughly 1,000 fleet vehicles caused an apparent GPS “outage” about a month ago.
The U.S. Air Force GPS Operations Center reported that in mid-May tests, “PRN 30 [was] broadcasting almanac datasets that do not reflect constellation changes that occurred since it was last uploaded with navigation message data. [. . . ] The utilization of these almanacs in a manner that regards the time of week, but neglects or mishandles the week number (effectively executing as if the current week number is the week number associated with these almanac parameters), will result in an increasing error in visibility determination and other almanac based estimations (elevation/azimuth, Doppler shift, SV clock offset from GPS time, etc) as the dataset’s actual week offset from the current week increases.”
First Two FOC Galileo Satellites Arrive in French Guiana for Launch Preparation
The first two Fully Operational Capability (FOC) Galileo satellites arrived in the French Guiana in preparation for launch this summer. When launched into orbit, they will join four IOV (In-Orbit Validation) Galileo satellites launched in 2011 and 2012.
The first FOC satellite launch may signal the beginning of Galileo “production” launches of one pair per quarter. Giuliano Gatti, Head of ESA’s Galileo Space Segment Procurement Office, stated that “A steady stream of satellites is foreseen, coming from OHB to ESTEC for acceptance testing and then on to French Guiana. Thanks to the preparatory work done with these pioneer satellites, future Galileos will be processed more rapidly.”
OHB is the prime contractor for a total of 22 FOC Galileo satellites. Those are in addition to the four IOV Galileo satellites.
The two Galileo satellites in the clean room.
Massive GLONASS System Failure
On April 1, the entire GLONASS system was inoperable for about 11 hours. A second, partial failure involving eight GLONASS satellites occurred on April 14 and lasted for about 30 minutes. There were many reports of RTK receivers not operating properly, and some manufacturers instructed their users to “turn off” GLONASS tracking capability on their receivers.
Subsequently, mathematical mistakes were blamed for the failures. The head of the Russian Space Agency, Oleg Ostapenko, stated that the problem would be fully resolved by mid-May and that there is almost no chance of a similar failure happening again.
Some news media are reporting that such an action by Russia would have an effect on GPS.
It would not.
What they’re talking about is discontinuing operations of some or all IGS (International GNSS Service) GPS stations in Russia. Those stations have nothing to do with the operation of GPS. They are simply CORS (Continually Operating Reference Stations). If anything, it will hurt Russian scientists (and scientists from other countries) more than anyone else.
Russian Rocket Launch Failure
Last week, Russia suffered its fifth rocket launch crash in the past four years. Fortunately for the GNSS user community, the rocket was not carrying any GLONASS satellites.
However, it raises serious concerns about the reliability of Russian rockets and launch procedures. Europe’s Galileo satellites are launched using Russian Soyuz rockets at Europe’s space port in French Guiana.
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.
Adding GLONASS to GPS gives a total of about 50 satellites, for a significant improvement in navigation availability, reliability, robustness, and convergence time through a new multi-GNSS precise point positioning (PPP) service. System performance and field results demonstrate that there is no need to await future constellations — better performance is available now.
By Tor Melgard, Erik Vigen, Ole Ørpen, Fugro Seastar AS, and Jon Helge Ulstein, Bourbon Offshore Norway AS
Precise point positioning (PPP) stands out as an optimal approach for providing global augmentation services using current and coming GNSS constellations. PPP requires fewer reference stations globally than classic differential approaches, one set of precise orbit and clock data is valid for all users everywhere, and the solution is largely unaffected by individual reference-station failures. There are always many reference stations observing the same satellite because the precise orbits and clocks are calculated from a global network of reference stations. As a result, PPP gives a highly redundant and robust position solution.
The results presented here represent a significant step forward in PPP GNSS research and development. Using GLONASS improves the availability and reliability of the solution. The G2 system’s horizontal positioning accuracy is at the decimeter level. These results derive from increasing the number of satellites in the constellation by 60 percent, from about 30 to 50 satellites. The outcome of the development of the G2 real-time combined GPS and GLONASS PPP service represents a next-generation GNSS augmentation. Further, the later GLONASS-M satellites have improved performance and lifetime over previous GLONASS satellites, so that results will continue to improve as that constellation is replenished.
G2 development has benefited from the close cooperation between Fugro and the European Space Operation Centre (ESOC), an establishment of the European Space Agency (ESA). ESOC has contributed its long experience and expertise on precise orbit and clock processing techniques, while the strength of Fugro is real-time positioning and navigation services.
Based on this work, Fugro has introduced the first real-time GPS and GLONASS precise orbit and clock service. The service utilizes Fugro’s own network of dual-system GNSS reference stations to calculate precise orbits and clocks on a satellite-by-satellite basis for all 50 satellites of the two global navigation satellite systems. The system comprises about 40 dual-frequency GPS and GLONASS reference stations distributed around the world as shown in Figure 1.
Raw GNSS measurement data for all satellites are transmitted to processing centers for calculation of the precise orbit and clock of each GPS and GLONASS satellite (Figure 3). The precise data generated is then broadcast to users via geostationary communications satellites with nearly global coverage, as shown in Figure 2.
FIGURE 1. The G2 reference station network consists currently of 40 GNSS receivers owned and operated by Fugro.
FIGURE 2. The G2 precise orbits and clocks are broadcast over redundant geostationary satellite beams together with the other Fugro services.
FIGURE 3. Dataflow from the reference stations to the redundant calculation servers producing precise orbits and clocks, then to the satellite uplink stations for broadcast over geostationary satellites to combined G2/GNSS user equipment.
Inside the end-user equipment a dual-frequency carrier-phase-based PPP solution gives horizontal positioning accuracy at the decimeter level. The PPP calculation module is provided by Fugro and is embedded in multiple GNSS receiver manufacturers’ products as well as Fugro’s own product line.
Like any GNSS technique, PPP is affected by satellite line-of-sight obstructions. Even the most precise orbit and clock data is useless if the user cannot track particular satellites. When satellite visibility is partially obstructed, a best possible service can be ensured by using the full range of satellites from both the GPS and GLONASS systems. This can occur during a survey of a dense urban environment, and for urban positioning in general. It can occur under heavy tree cover, when a cruise ship is in a high-sided fjord, when an offshore vessel is close to an oil rig or platform, or during ionospheric disturbances.
The trend clearly lies towards increasing availability of GNSS satellites on orbit; many studies predict the future benefits of combining the constellations of GPS and Galileo. There is no need, however, to wait for future constellations to reap the immediate benefits of access to additional GNSS satellites. The current GLONASS constellation may not have all the features of future GNSS systems, but it is available here and now. Recently, the Russian government has proven its commitment to enhancing the GLONASS constellation. Many receiver manufacturers have also acknowledged this fact and now provide combined GPS and GLONASS receivers.
G2 Accuracy and Statistics
In Figure 4, time-series plots show the 3D accuracy of GPS and GLONASS G2 real-time orbits on August 14, 2009. In the comparison, final orbit data from the International GNSS Service (IGS) is used as reference. PPP positioning is mainly affected by the radial orbit error, which is significantly less than the total 3D error shown here. The 95 percent 3D accuracy for GLONASS (22 centimeters) is more than double that for GPS (10 centimeters). The graph demonstrates how this difference in this case is mainly caused by a few GLONASS satellites being less accurate. Actually, several GLONASS satellites have orbit accuracy very close to the level of GPS for real-time G2 data.
FIGURE 4. GPS and GLONASS orbits compared to IGS final orbits.
Figure 5 shows the clock accuracy of the G2 real-time clocks compared to final IGS clocks. A constant bias has been removed to account for the differences in system reference time. Smaller individual clock biases for each satellite can still be observed. Small biases do not affect the final accuracy of the PPP solution, and achievable position accuracy with these clocks are significantly better than the 21-centimeter 95 percent number for GPS may indicate.
FIGURE 5. GPS clocks compared to IGS final clocks. GLONASS clocks compared to a combined solution based on IGS plus Fugro network to calculate a best possible reference solution.
The lower time series in Figure 5 shows the estimated GLONASS clock accuracy. Currently there is no comparable IGS product with precise GLONASS clocks. A post-processing of all available IGS plus Fugro GNSS stations has been made to establish a reference for the comparison. As shown, the GLONASS clocks are more variable, but still they are stable enough to allow for precise navigation.
Real-Time Positioning Results
Real-time position performance is continuously observed at the G2 operation and monitoring center in Oslo, Norway. The graph in Figure 6 shows typical G2 positioning results with the calculation engine running in dynamic mode at a fixed location for a 24-hour period. The blue lines in the north and east time series are at 20 centimeters and the scale is 61 meter. In the height graph the blue lines indicate the 30-centimeter level. The antenna is in a location with clear view of the sky, and in
dependently calculated reference coordinates are used as reference. 1-sigma accuracy statistics on August 14 are 3, 4, and 8 centimeters in easting, northing and height respectively.
FIGURE 6. G2 GPS-plus-GLONASS position monitoring results in Oslo on August 14, 2009.
Figure 7 shows GLONASS-only real-time positioning with clear view of the sky for the same day as in Figure 6 and the same antenna location. The blue line indicates the 50-centimeter level and the scale is 62 meters. For long periods, the GLONASS-only solution works quite nicely. There are, however, shorter periods with fewer than four satellites being tracked, causing the position output to stop, followed by a period of re-convergence.
FIGURE 7. GLONASS-only real-time PPP solution on August 14, 2009 for a 24-hour period.
Figure 8 displays results from May 11, 2009, when there were slightly more satellites available and just enough to have the GLONASS-only solution running for 24 hours without resets. 1-sigma accuracy statistics for this day are 11, 9, and 16 centimeters in easting, northing, and height respectively. Considering the average number of satellites of 6.14 and periods with high DOP values, this is very promising. In early 2010, 20 GLONASS satellites should be available, and by 2011, 24 are expected. In 2010, a performance similar to or better than that of May 11 should generally be expected with the new satellites. By 2011, even better performance is believed to become the norm of GLONASS-only real-time PPP navigation.
FIGURE 8. GLONASS-only real-time PPP solution on May 11 for a 24-hour period.
Even in some clear-view-of-sky situations, the addition of GLONASS may improve the navigation compared to GPS-only solutions. Figure 9 presents an example of such situations. Here the GPS-only solution suffers some multipath-like effects showing up, especially in the east component. Figure 10 shows the combined GPS+GLONASS solution for the same dataset. The distortion in position is practically eliminated. This is an example where adding GLONASS also improves redundancy and accuracy for navigation with clear view of the sky.
FIGURE 9. GPS-only results for a 3-hour period where some multipath-like effects distort the postition, especially the east component.
FIGURE 10. Adding GLONASS improves redundancy and accuracy for the same time period as presented in Figure 9.
The next test further analyzes the same dataset as in Figures 9 and 10 by simulating a virtual wall to the south, blocking all satellites below 40 degrees elevation. Figure 11 illustrates this virtual wall blocking both GPS and GLONASS satellites.
FIGURE 11. GPS and GLONASS satellites blocked between the azimuths 90 and 270 degrees and elevation lower than 40 degrees, effectively establishing virtual wall to the south.
With such data blockage, the GPS-only solution fails for more than 20 minutes, as seen in Figure 12, simply because the number of satellites goes below four. Then a period with slow convergence follows because of few satellites and high DOP.
FIGURE 12. GPS-only solution fails when simulating blockage to the south.
Again, adding GLONASS greatly improves the performance, as shown in Figure 13. Now a sufficient number of satellites are tracked all the time, and there is a continuous solution with the combined GPS+GLONASS throughout the time window when the GPS-only solution failed.
FIGURE 13. GPS+GLONASS solution continues working with simulated blockage to the south.
Even with more than 30 satellites in the GPS constellation, there are situations when the satellite geometry gets poor. This occurred in northwest Europe on February 2, 2010. One of the GPS satellites (PRN17) was not available due to maintenance, and even with five to six usable GPS satellites left, the horizontal dilution of precision (HDOP) was in the range of 7–11 for about 12 minutes (10-degree elevation mask), as shown in figure 14. Such high HDOP values lie above what most user installations are configured to accept, and Fugro received feedback from clients at sea losing positioning. The G2 solution was not affected by the poor GPS geometry and kept the HDOP below 2 during this period, as shown in Figure 15.
FIGURE 14. GPS-only performance during a period with poor GPS satellite geometry in Oslo, February 2, 2010.
FIGURE 15. GPS+GLONASS performance during the same period as in Figure 14 in Oslo, February 2, 2010.
Convergence-Time Analysis
As will be shown in the following analysis, adding GLONASS not only improves availability and robustness of the solution, it greatly improves convergence time. Real-time high-accuracy PPP solutions use carrier-phase measurements to achieve high-accuracy positioning. To do so, the carrier-phase ambiguities must be determined. This process takes a certain time depending on the observed satellite geometry and is commonly referred to as cold-start convergence time.
Figure 16 presents a theoretical study of the expected convergence time for a GPS-only compared to a combined GPS+GLONASS solution. The lower graph shows how the expected convergence time varies significantly for a GPS-only solution throughout the day, with a peak of 75 minutes. The combined solution shows much more consistent performance, with expected 50–60 percent average improvement over GPS-only.
FIGURE 16. Theoretical study of expected convergence time with actual GPS-and-GLONASS constellation in view of Oslo on June 26, 2009. Adding GLONASS gives a 50–60 percent theoretical convergence time improvement over GPS-only.
We compare this theoretical study to results using G2 data produced in real time in Figure 17. A cold start is performed every 5 minutes throughout the day, for six consecutive days, giving a total of 1,728 convergence tests. The convergence criterion is the time when the 3D position arrives within 40 centimeters of the reference position and remains there for a minimum of 10 minutes. The average convergence time improvement achieved in Figure 17 is 39 percent, with some variations from day to day. On the better days, the average improvement is almost 50 percent, and close to the expected performance based on the theoretical study. On other days, there is room for further improvement. Mainly two factors are expected to contribute: more and newer GLONASS satellites, and further improvements of the G2 precise GPS and GLONASS orbit and clock product.
FIGURE 17. Convergence results for six consecutive days starting June 24, 2009. Average convergence time of GPS-only is 27 minutes, and GPS+GLONASS is 16.5 minutes, a 39 percent improvement.
Dynamic Environment Results
Since late 2008, the G2 system has been installed on the vessel Bourbon Topaz, making frequent trips into the North Sea and back into port in Norway (see BOX).
All positioning data from both the G2 system and the GPS-only reference systems are logged in real time on the vessel. Figure 18 gives an example plot of the relative height estimated by the G2 GPS-GLONASS solution. In the beginning of the plot, the vessel is out at sea, clearly seen as a noise in the graph that actually is the vessel’s movement in the waves. Then the vessel comes into port and the slower tidal variations are observed for the next 12 hours until the vessel again goes back out to sea.
FIGURE 18. Relative G2 height measurements for a 24 hour period. The vessel is in harbor from 04:00 – 16:00 UTC.
On June 22, 2009, an incident was recorded where the combined GPS-GLONASS G2 solution improves performance. As seen in Figure 19, there is a period starting at 10:00 UTC where the GPS-only reference systems suffer from poorer DOP values, and this is reflected both in horizontal and vertical components of the calculated position. This particular plot shows how the height drifts off by roughly 1 meter while the G2 combined solution remains unaffected for the entire period. Generally, the G2 solution also shows a smoother height than the reference system even when such problems as shown here are not present.
FIGURE 19. Height graph from the Bourbon Topaz while in harbor on June 22, 2009. The GPS-only reference system has a period with poor DOP values while the GPS-plus-GLONASS solution is not affected.
The Bourbon Topaz carries the G2 system on operations in the North Sea, and continuously compares it with the GPS-only reference systems onboard.
Test of G2 onboard Bourbon Topaz
The Bourbon Topaz is a modern supply vessel equipped with the latest dynamic positioning (DP) systems, operating in the North Sea. The North Sea can be a harsh environment in which to operate, and we rely on good tools for maneuvering our vessels.
Early on, we recognized the need for stable, reliable reference systems, and our fleet is equipped with Kongsberg Seatex DPS700 system as standard. When we were asked to test the G2 onboard the Bourbon Topaz, we saw this as an opportunity to follow the development in the industry of such services. The DPS232 receiver was set up in connection with the vessel’s DPS700 system, and all information was logged and sent to Fugro Seastar.
We often experience that the vessel has to operate close to offshore installations, which could block good reception of signals. In these cases, the G2 offers a much better and more reliable signal reception. Our experience of the quality of the G2 system is overall positive.
User Equipment
G2 and the other Fugro services can be received from a variety of different user equipment; both Fugro-branded or manufactured equipment and third-party equipment. In most cases the L-band receiver decoding the data from the geostationary satellites, including Fugro subscription software and position calculation module, is integrated into the same box as the GNSS receiver. Both the GNSS and geostationary satellite signals can be tracked with a single antenna.
FIGURE 20. Receivers supporting the Fugro services. These are only examples, and not all third-party equipment manufacturers are shown. Fugro L-band data reception receiver and positioning/subscription software reside inside the receiver.
Conclusions
Test results confirm decimeter-level position accuracy in real-time navigation with G2, the first real-time combined GPS and GLONASS PPP service. Several examples show how G2 improves availability, robustness, and convergence time compared to GPS-only positioning.
More is better. There is no need to wait for future constellations like Galileo to reap the benefits of access to additional GNSS satellites now.
Tor Melgard is R&D manager at Fugro Seastar in Oslo, Norway. He holds an M.Sc. in electrical engineering from the Norwegian Institute of Technology and wrote his thesis at the Department of Geomatics Engineering, University of Calgary.
Erik Vigen is a senior developer at Fugro Seastar. He received his M.Sc. in Geodesy from the Norwegian Institute of Technology.
Ole Ørpen is senior scientist at Fugro Seastar. He received his M.Sc. from the Norwegian Institute of Technology in electrical engineering.
Jon Helge Ulstein is IT superintendent at Bourbon Offshore Norway AS, a subsidiary of the Bourbon Group, Marseilles, France.
PRN 17, the first IIR-M satellite launched in September 2005, began broadcasting the second GPS civil signal, L2C, in December 2005. PRN 17 is the first in the new generation of GPS satellites with a new feature called flex power. According to the U.S. Air Force, flex power adds the capability for the Department of Defense to increase power on both P- and M-code (both military) signals to defeat low-level enemy jamming.
When flex power was enabled for testing (for a very short period of time), a problem was observed by certain GPS users. This problem was associated with the definition of the phase relationship between L2C and legacy L2 P/Y. In this scenario, users who are operating L1/L2/L2C GPS equipment, in conjunction with legacy L1/L2 GPS equipment, could have a problem maintaining carrier-phase ambiguity resolution with any modernized satellite operating in modes where signal phase relationships are changing or are unknown.
This is not just a flex power issue, but a potential issue with any new modernized GPS signal if provisions are not included to inform users in real time of signal phase relationships. This is potentially a long-term problem because there will be a mixed set of modernized/legacy signals for an extended period of time, as well as a mixed set of modernized/legacy user equipment. The important thing is that these potential problems can be fixed by broadcasting appropriate data in the GPS navigation messages in a timely manner.
This fix to this potential problem would slightly change the GPS user interface specifications and add bits for defining the phase relationship between the modernized and legacy signals. This data would have to be added to both the L1 and L2C signals since, for the time being, there is no data on the L2C signals. For L1C, (in the draft L1C specification) the phase relationship between L1C and L1 C/A has been defined. For L2 and L2C interoperability during modernization, a similar parameter to provide the phase relationship between the L2 P/Y and L2C is needed for mixed equipment processing. (Refer to Section 3.5.4.6 subframe 3, page 7 signal phase of the newly released Draft IS-GPS-800 L1C specification dated April 19, 2006.)
Another possible solution is for L2C-capable receivers in a network to track both L2C and L2 P/Y simultaneously, to directly measure the phase difference between the two phases. However, the drawback is that the more robust L2C signal will be tracked at times when the legacy L2 P/Y cannot — the main reason for implementing L2C in the first place.
— Eric Gakstatter
Contributing editor of the Survey & Construction newsletter
When the new flex power feature aboard PRN 17, the first IIR-M GPS satellite,
was enabled for testing (for a very short period of time), a problem was observed
by certain GPS users.
PRN 17, the first IIR-M satellite launched in September 2005, began broadcasting
the second GPS civil signal, L2C, in December 2005. PRN 17 is the first in
the new generation of GPS satellites with a new feature called flex power.
According to the U.S. Air Force, flex power adds the capability for the Department
of Defense to increase power on both P- and M-code (both military) signals
to defeat low-level enemy jamming.
When flex power was enabled for testing (for a very short period of time),
a problem was observed by certain GPS users. This problem was associated with
the definition of the phase relationship between L2C and legacy L2 P/Y. In
this scenario, users who are operating L1/L2/L2C GPS equipment, in conjunction
with legacy L1/L2 GPS equipment, could have a problem maintaining carrier-phase
ambiguity resolution with any modernized satellite operating in modes where
signal phase relationships are changing or are unknown.
This is not just a flex power issue, but a potential issue with any new modernized
GPS signal if provisions are not included to inform users in real time of signal
phase relationships. This is potentially a long-term problem because there
will be a mixed set of modernized/legacy signals for an extended period of
time, as well as a mixed set of modernized/legacy user equipment. The important
thing is that these potential problems can be fixed by broadcasting appropriate
data in the GPS navigation messages in a timely manner.
This fix to this potential problem would slightly change the GPS user interface
specifications and add bits for defining the phase relationship between the
modernized and legacy signals. This data would have to be added to both the
L1 and L2C signals since, for the time being, there is no data on the L2C signals.
For L1C, (in the draft L1C specification) the phase relationship between L1C
and L1 C/A has been defined. For L2 and L2C interoperability during modernization,
a similar parameter to provide the phase relationship between the L2 P/Y and
L2C is needed for mixed equipment processing. (Refer to Section 3.5.4.6 subframe
3, page 7 signal phase of the newly released Draft IS-GPS-800 L1C specification
dated April 19, 2006.)
Another possible solution is for L2C-capable receivers in a network to track
both L2C and L2 P/Y simultaneously, to directly measure the phase difference
between the two phases. However, the drawback is that the more robust L2C signal
will be tracked at times when the legacy L2 P/Y cannot — the main reason
for implementing L2C in the first place.
