Early morning on February 2, 2011, I went to work in my job as a road surveyor in the Bungoma District of Kenya. Here, land disputes are common, though the government is trying to reduce the conflicts by issuing land titles and certificates.
I carried with me a small handheld GPS, the Magellan Explorist 100. While I was using it, a stout man in early fifties approached me and introduced himself as a surveyor, too. He was very interested in the way I was walking around with the “gadget,” trying to locate a control point. He asked me how the gadget worked. I explained it to him, showing him how its easy to use in general boundary surveys. He was satisfied, and we exchanged contacts and parted.
A month later, he called me for help. When I asked him what was wrong, he told me there were a group of land owners, or members, who were about to kill each other in a dispute over a 128-acre farm they had bought. These members had each contributed money to buy a single parcel with the intention of subdividing it fairly. They were engaged in a disagreement about the boundaries and the subdivision of the farm. The gentleman asked me if I could take a survey of the farm sometime in the next few days. Concerned about the conflict, I answered, “Yes, in hours not days.” Still, it wasn’t until two days later that he could assemble the members of the disputed farm and called me to mark the boundaries for them.
I arrived at the farm with my Magellan GPS and my laptop. To my dismay, I found that some of the members were armed with crude weapons, ready to fight each other. I asked them to be peaceful and wait for just a few hours while I surveyed the site.
I started picking the boundary corners of the farm all around the permiter. I was through with that task in less than 35 minutes. This parcel of land was to be divided into 18 pieces. I uploaded the data manually to my laptop, then I did the subdivision using AutoCAD Land Development 2000.
After two hours and fifteen minutes, I called the members and told them to ready themselves to be shown the boundaries of their property.
I walked around the property with them, guided by my handheld GPS, to each boundary beacon. After one and a half hours, the warring members were shaking hands and laughing, saying “So, it was that easy!”
The dispute had ended, and was solved peacefully. My small Magellan Explorist 100 acted as a peace mediator.
Noah Kertich is a surveyor with H Young Construction EA Ltd., which is under contract with the World Bank in conjunction with the government of Kenya. Kertich graduated from the Kenya Institute of Surveying and Mapping in 2004 and received a diploma in photogrammetry and GIS from Icaros Geosystems, Israel, in 2008.
When I first visited Beijing a few years ago, I came there from a stop in India. This was just before the Olympics in 2008, but there were signs then of big-scale preparations in terms of highway infrastructure and building. As the two most populous countries in the world, India (1.13 billion people) and China (1.3 billion people) both are making huge strides forward. China does appear for the moment, however, to be more focused on the commercialization of GNSS.
True, both countries are working towards their own GNSS constellations using their own launchers — China with Beidou/COMPASS and India with IRNSS — but China does appear to be ahead in this particular “space race.” While India plots a path towards IRNSS and GAGAN is up and running, Beidou Geostationary satellites are already in orbit, and western users have already reported tracking signals. With seven satellites already on orbit, Beidou/COMPASS is well on its way towards becoming first a regional and then a global satellite navigation system.
A whole heap of Chinese companies are working on GNSS in China — those who have developed low-end single-frequency, mass-market receivers and applications, and many who have imported receivers from the West and built applications around them, with lots of software applications, ancillary items such as antennas, handheld enclosures, and more. With this level of capability, it’s not surprising that indigenous multiple-frequency Beidou/GPS/GLONASS professional receivers may already be available.
I talked recently with some old friends in Beijing to catch up on Chinese GNSS and to learn more about the activities of their company — known as BDStar. Originally established in 2000, significant growth led in 2007 to an Initial Public Offering — this IPO in itself is a sign of significant economic change and growth in China. From an initial start-up staff of a few key individuals in 2000, this company has now grown to employ more than 650 people at several locations around China, working through the BDStar parent and in five subsidiary companies.
BDStar started off by importing Western survey-quality receivers and building them into survey-related applications, including high-precision vehicle tracking, geographic information systems, control, and telemetry. While port automation projects are not new, BDStar also undertook several of these as far back as 2003. It’s easy to see how Chinese companies are becoming world class when we look at the extensive skills and technical capabilities needed for these large-scale, complex projects.
BDStar took on a key project which propelled its growth when it successfully provided its first container inventory systems for a Chinese port. These containers are the large shipping boxes we see in the holds and on the decks of huge cargo ships, and sometimes flying by us on the backs of 18 wheelers. It takes enormous cranes and transporters to move them around when they leave or arrive at ports around the world. Huge dockside cranes unload containers from ships, then rubber-wheeled gantries move them from the dock to massive storage areas. These gantries acquire data when they hook up — such as where the container is coming from, where it’s going to, and when it will get its next ride — then location information is added to the container data file. When the gantry deposits the container at its temporary storage location, an RTK measurement tags the exact position at which it is stored within the vast maze of container stacks so workers can find it again later and move it onwards to its destination.
The system extends to the unloading quayside cranes, various forms of fork-lift trucks, and trailers used to transport containers about the yard. This all adds up to hundreds of radio links and radio management issues, difficult RTK receiver installations on vibrating, all-weather moving platforms — all of which need visibility of the sky and access to RTK correction signals — plus huge amounts of data acquisition and handling and display systems: a highly complex system solution that BDStar has now replicated at several ports.
Locating, tracking, and moving containers to and from their ships, in some of the largest shipping yards in the world, is no small problem. The BDStar system appears to have automated and simplified container movement for ports that include Ninbo Port Second Container Terminal, Shanghai Yangshan Container Terminals, Shenzhen Chiwan Container Terminals, Tianjin Container Terminals, and other container terminals in Shenzhen and Hong Kong. BDStar claims that the production efficiency of ports equipped with its system is improved by between 5 and 10 percent. Sure are a lot of containers at these “super-ports” in China and around the world, so improving the tracking and transit of containers through these ports can significantly improve profitability for the shipping companies.
Then, in a completely different direction, BDStar designed and implemented the ground control and monitoring command center for the early Beidou satellites. The system provides positioning, time-transfer, and short-message information for onwards distribution to Beidou users. The Beidou system not only provides positioning and timing data, but also has a “short-message” capability. BDStar has adapted this ground system so that China’s long-distance fishing fleet can be tracked and supported from mainland China. China has the largest marine fishing fleet in the world — about 280,000 vessels and a fishing industry with nearly 10 million people with the most dangerous jobs in China. It is estimated that 8,774 fishermen died and 22,345 vessels were lost while fishing between 1993 and 2004.
Vessel position data is transmitted over the Beidou short-message system, frequently from ships which are thousands of miles away from port. The BDStar system gathers this information and redistributes it to vessel operator companies on shore. The system also cross-connects the Beidou short message system with land-based cell-phone systems. Customers can respond over the Beidou short-message system; for instance, in the event that a ship is in distress, other ships in the vicinity can be routed to assist. This is currently the primary application for Beidou civilian usage, and through it BDStar has become the number one Beidou operator and terminal provider in China.
With an estimated 20m positioning accuracy, Beidou is well on its way to being a regional GNSS in 2012. By 2020 the system is planned to be global. Beidou capable receivers are clearly already being sold within China — mostly in applications using the short-message function. Unicore, a BDStar subsidiary, advertises Beidou/GPS/GLONASS receivers and chipsets developed in China.
A 2009 report estimated the GNSS market in China to be worth close to $9 billion U.S., mostly in consumer applications, and growing at around 50 percent annually! BDStar therefore has lots of local competition, and increasing competition from western GNSS suppliers aligned with other local GNSS companies. But as in most markets it’s likely that healthy, successful companies like BDStar will continue to thrive and prosper. Growth like this is good for the GNSS industry, as opportunities seem to abound for everyone in such an expanding Chinese marketplace.
Representatives of the GPS industry presented to members of the Federal Communications Commission (FCC) laboratory evidence of interference with the GPS signal by a proposed new broadcaster on January 19 of this year. The meeting and subsequent filing did not dissuade FCC International Bureau Chief Mindel De La Torre from authorizing Lightquared to proceed with ancillary terrestrial component operations, installing up to 40,000 high-power transmitters close to the GPS frequency, across the United States.
The document describing the testing states that the Lightsquared initiative “will have a severe impact on the GPS band” and “will create a disastrous interference problem for GPS receiver operation to the point where GPS receivers will cease to operate (complete loss of fix) when in the vicinity of these transmitters.”
On January 26, the FCC waived its own rules and granted permission for the potential interferer to broadcast in the L Band 1 (1525 MHz–1559 MHz) from powerful land-based transmitters. This band lies adjacent to the band (1559–1610 MHz) where GPS and other GNSSs operate.
The FCC called for further testing to be led by LightSquared and completed by June 15.
Prior to the decision, representatives of the U.S. GPS Industry Council and GPS manufacturers Garmin and Trimble presented “Experimental Evidence of Wide Area GPS Jamming That Will Result from LightSquared’s Proposal to Convert Portions of L Band 1 to High Power Terrestrial Broadband,” to five members of the FCC’s Office of Engineering and Technology, including its chief, two members of the FCC International Bureau, one from the Public Safety and Homeland Security Bureau, and two from the Wireless Telecommunications Bureau.
The document conveys results of testing on a common portable consumer automotive navigation device and on a common general aviation receiver. The consumer GPS device began to be jammed at a power level representing a distance of 3.6 miles (5.8 kilometers) from the simulated LightSquared transmitter. The consumer device lost a fix at 0.66 miles (1.1 kilometers) from the transmitter.
The Federal Aviation Administration (FAA)-certified aviation receiver began to be jammed at a distance of 13.8 miles (22.1 kilometers) and experienced total loss of fix at 5.6 miles (9.0 kilometers) from the transmitter.
During the laboratory testing, GPS signals were simulated by a Spirent GSS6560 GPS simulator, representing a constellation of 31 GPS satellites, the current configuration. LightSquared’s signal was simulated using a Rhode and Schwartz SMIQ-03S signal generator with digital modulation, amplified to achieve the relevant signal strengths. Full technical specifications and parameters are described in the Experimental Evidence document linked above.
The industry report concludes: “The proposed LightSquared plan . . . will deny GPS service over vast areas of the United States.”
In its decision document on January 26, the FCC not only authorized LightSquared to proceed, it turned up its nose at assertions that the entire process had been conducted in near-stealth mode as well as on an accelerated track.
LightSquared was established in mid-2010 by “an experienced team of global telecommunications executives and investors.” From 2001 to 2005, Lightsquared executive vice president Jeff Carlisle served as deputy chief and then chief of the FCC’s Wireline Competition Bureau.
The Galileo Test and Development Environment (GATE) in Berchtesgaden, Germany, officially opened on February 4. The system operator, IFEN GmbH of Poing, Germany, jointly with the German Federal Minister of Transport, Building and Urban Development, announced the opening for use by commercial and organizational entities seeking to test equipment with the coming Galileo signals. GATE was developed on behalf of the German Aerospace Center (DLR) with funding by the German Federal Ministry of Economics and Technology.
The test area extends across a valley of approximately 65 square kilometers, southeast of Munich, where antennae atop surrounding peaks broadcast the various Galileo signals. Technical details and specifications of the test environment are at www.gate-testbed.com.
The GATE infrastructure is capable of transmitting the Galileo Open Service, the Safety-of-Life Service (functional, with certification as a next step), the Commercial Service, and a Public Regulated Service dummy signal.
The GATE system upgrade has been further extended to also support user integrity testing, simulating simple alarm-triggering events on the system/satellite level, supporting GPS and GATE/Galileo dual-constellation receiver-autonomous integrity monitoring (RAIM), individual user integrity test scenarios, and tests of receivers with different RAIM functionalities.
Next-Generation GLONASS
As this magazine goes to press, a Soyuz rocket carring a new GLONASS-K1 satellite has moved to the Plesetsk Cosmodrome launch pad for a scheduled blast-off on February 24. Assuming all goes well, the satellite’s eventual transmissions will include Russia’s new CDMA signal on a GLONASS L3 frequency. Further information and photos will be posted to env-gpsworld-integration.kinsta.cloud/glonassk.
In Other Developments. Roscosmos, the Russian space agency, said it lost contact with a military satellite launched on February 1, a painful incident following the failed launch of three GLONASS-M satellites in December.
The Geo-IK-2 satellite, designed for geodetic studies, remains in its transfer orbit because the upper stage failed to restart for its second circularizing burn. Based on the GLONASS-M bus, Geo-IK-2 carries laser reflectors, GPS/GLONASS receiving equipment, and an altimeter. Communications with the satellite have been re-established but it is not clear how useful it will be in its current orbit.
Galileo IOV August Launch
The European Space Agency announced that the first two Galileo in-orbit validation (IOV) satellites will rise on August 31. They will ride aboard a Soyuz-ST-B rocket from the Kouros, French Guiana, Space Center. There was no word about the third and fourth IOV satellites, which had at one point been scheduled for an October launch, at a time when the first two were penciled for a June launch.
JAVAD Receivers Track Compass B1 Signal
JAVAD GNSS has announced that, with modified firmware, all of the company’s receivers can now track the Chinese Compass B1 signal. The company states that Compass is the sixth GNSS system that its receivers can track, joining GPS, GLONASS, Galileo (the two GIOVE in-orbit validation experimental satellites), SBAS (the European Geostationary Navigation Overlay Service or EGNOS), and Japan’s Quasi-Zenith Satellite System (QZSS).
JAVAD GNSS made available several plots, shown here. One is a log file, collected on JAVAD’s TR_G3TH board in Moscow during the last weekend in January, reporting up to 26 satellites from the various systems, locked simultaneously. Also provided below are several other plots showing the new capability.
The company further stated that it will add Compass tracking to almost all receivers in near future, as a firmware upgrade.
According to a Roscosmos report, the state commission governing rocket launches will launch GLONASS-K1 on February 26 at 03:06 UTC. The launch of GLONASS-K1 has been pushed back for “technical reasons.” The original schedule called for a February 24 launch.
Quoting the commander of the Russian Space Forces, Lieutenant-General Oleg Ostapenko, an Interfax news item stated that there was insufficient time to ready the rocket for launch february 25, though it was announced as a launch date following the scrub on February 25. “The probability of a launch on the 26th is very high,” Ostapenko said.
Meanwhile, Komsomolskaya Pravda quoted an unnamed space industry official as saying that if the launch is not held tomorrow, it will be put off for a month. “[The decision will be] once again to be safe, rather than to carry out the launch, which for technical reasons, was postponed for the second day in a row. Without further checks, and to eliminate technical problems, no one [wants to] take responsibility to conduct the launch,” he said.
Gazeta.ru, an online Russian newspaper, has carried a report in which Nikolai Testoedov, the chief designer and CEO of Information Satellite Systems Reshetnev states that seven GLONASS satellites will be launched this year. In addition to GLONASS-K satellites being launched this month and in December, five GLONASS-M satellites will be launched. Three will be launched on a Proton-M rocket from Baikonur (this launch is expected in June). He said that, in addition, two GLONASS-M satellites will be launched on the Soyuz-2 rocket from Plesetsk. The first of the five GLONASS-M satellites is to be delivered to the customer on February 28.
How GLONASS helps fill in gaps in GPS coverage for a user with a combined GPS/GLONASS receiver.
When the Russian GLONASS system lost three new satellites in a recent launch failure, did this long-standing navigation system lose some momentum? The reports out of Russia had indicated renewed enthusiasm and commitment to put a revived, complete constellation back in its rightful GNSS place. Launch of an L3 CDMA demonstrator satellite is apparently forecast for late February, and work on the Russian SBAS ground network (known as SDCM) also appears to be proceeding. We can only hope that Russia does not back away from its strong push to not only restore one of the world’s primary satellite navigation systems to its former glory, but to also “modernize” the signals it broadcasts.
But why do commercial users care about GLONASS? Everyone is already enjoying an enhanced and growing GPS signal in space with loads of satellites and the promise of a rejuvenated GPS constellation with even more signals and features. Well, actually GLONASS has been around for a long time and it has become a system that a lot of users rely on, especially those in the high-accuracy real-time kinematic (RTK) community.
GLONASS may not itself directly enhance accuracy, but the availability of ~21 healthy satellites certainly helps fill in gaps in GPS coverage for a user with a combined GPS/GLONASS receiver. Those extra space vehicles (SVs) when added into an RTK solution can make the difference between accurate, reliable RTK and no RTK or only intermittent RTK.
Back in the early days of a complete, reliable GLONASS constellation, at least one manufacturer embraced and integrated these signals with GPS and was able to demonstrate the best RTK it had ever seen. Other manufacturers followed, and soon high-precision GPS/GLONASS receivers became the norm. As the GLONASS constellation decayed over the next several years, the advantages of dual-constellation receivers fell away somewhat, and GPS-only RTK receivers became more common. Then, almost 10 years ago, as the news of an impending GLONASS revitalization filtered into users and manufacturers, at first in Europe and then throughout the rest of the world, a new generation of dual-function GPS/GLONASS receivers was developed and fielded.
In the process, manufacturers outside Russia dusted off their old GLONASS tracking algorithms, and it became clear that some inside knowledge might be needed. Over time, it became clear that some GLONASS satellites had their own distinct personality, each of which had to be accommodated in a more complex tracking, position, and RTK solution. Allowances were made, and the ultimate goal of more robust, more reliable RTK using both GPS and GLONASS was eventually achieved.
Robust, reliable RTK mean that survey missions can be completed without intermittent or total loss of high-accuracy measurements. Crews operating in difficult locations could avoid the expense of making repeated measurements or avoid the drastic solution of a subsequent complete re-survey. Dual-function, dual-frequency receivers became cost-effective for these users and those involved in machine control, construction, high-precision mapping, precise shipping-container location, and for many other high-value, difficult operations requiring RTK.
But what happens to users with GPS/GLONASS receivers when Galileo, Compass, IRNSS, QZSS and other regional, more capable SBAS systems around the world all come on line? The promise of huge numbers of additional usable signals has yet to be realized, but provided that momentum is maintained with these developing systems, the signal “landscape” will change considerably in the future. And manufacturers are already anticipating those changes — multiple constellation receivers are already available in the market — but RTK is only possible with signals that exist, so GPS/GLONASS RTK is still king.
It may be reasonable to assume that GLONASS users in countries that are politically aligned or who are trading partners with Russia will hang onto these signals. India and China may have their own systems in the future, but users in both countries already appear to subscribe to the GLONASS club, and politics may play a role in maintaining this user base. Of course, GLONASS use is now mandated in Russia. Surprisingly, European and even North American users may also currently form a significant part of the existing GLONASS user group. As Galileo comes on line, the situation in Europe and elsewhere might well change.
And when GPS L5 comes on line some time in the future, manufacturers will be able to dump their complex P-codeless tracking techniques. Low-cost RTK will become a real possibility, and the advantages of lower-cost receivers may begin to outweigh the cost-benefits of complex multi-constellation receivers for some niche users. But with Galileo E5 and IRNSS L5 on the same (well almost) frequency, its likely that multi-constellation receivers will fall in price with volume and will ultimately become commonplace.
And if you already have all those GLONASS gates in your ASIC and GLONASS tracking algorithms implemented in your future powerful processor, its possible that GLONASS will still form a basic element of precision navigation for most future GNSS users.
Now, should the promised GLONASS innovations keep pace over time with all these other investments in GNSS system growth — and a complete GLONASS constellation with CDMA signals allows manufacturers to reduce receiver complexity and still hang onto GLONASS capability — then it’s a good guess that GLONASS will remain with us all for a long time as a basic system which we will all depend on.
The Galileo Test and Development Environment (GATE) in Berchtesgaden, Germany, officially opened on February 4. The system operator, IFEN GmbH of Poing, Germany, jointly with the German Federal Minister of Transport, Building and Urban Development, announced the opening for use by commercial and organizational entities seeking to test equipment with the coming Galileo signals. GATE was developed on behalf of the German Aerospace Center (DLR) with funding by the German Federal Ministry of Economics and Technology.
The test area extends across a valley of approximately 65 square kilometers, south-east of Munich, where antennae atop surrounding peaks broadcast the various Galileo signals. Technical details and specifications of the test environment are at www.gate-testbed.com.
GATE has completed its signal upgrade phase according to the latest version of the European Space Agency’s Galileo Signal-In-Space (SIS) Interface Control Document (ICD) and the European GNSS Agency’s Public Galileo Open Service (OS) ICD. The GATE infrastructure is capable of transmitting the Galileo OS, the Galileo Safety-of-Life (SoL) Service (functional), the Galileo Commercial Service (CS), and a Galileo Public Regulated Service (PRS) dummy signal.
The GATE system upgrade has been further extended to also support user integrity testing. GATE can simulating simple alarm-triggering events on the system/satellite level, supporting GPS and GATE/Galileo dual-constellation receiver-autonomous integrity monitoring (RAIM), individual user integrity test scenarios, and tests of receivers with different RAIM functionalities.
The next step will be certification of the GATE test infrastructure as an officially accredited open-air test infrastructure to perform the necessary tests needed for the process to certify Galileo SoL equipment.
Günter Heinrichs, head of customer applications and business development for IfEN GmbH, described the goals and capabilities of GATE in a 2007 GPS World article. He gave an update on developments in a 2009 video interview. A recent simulation of emergency response scenarios using the Galileo signal is described at Galileo to the Rescue.
Using the Augmentation System with GPS-Equipped Mobile Phones
By François Boullete, Boris Kennes, Michaël Mastier, and Lee Banfield
GPS corrections from the European Geostationary Navigation Overlay Service can improve the positioning accuracy and user experience of GPS-enabled mobile phones, even if EGNOS satellites are not visible and even when the GNSS chipset in the phone does not support satellite-based augmentation systems.
Today, more than 20 percent of mobile phones in use in Europe include a GNSS chipset, and the penetration is expected to exceed 50 percent in the next 5 years. Despite its success in other sectors such as agriculture since the launch of its Open Service in October 2009,
EGNOS has received limited adoption in location-based services (LBS) and consumer applications, due to two main obstacles. First, the signals from the three EGNOS geostationary satellites that are easily received in open-sky environments are difficult to receive in cities, due to masking by buildings. Second, most GNSS chipsets embedded in today’s mobile phones are GPS-only without SBAS support, or use SBAS for ranging only, a function not supported by EGNOS at this stage.
The European GNSS Agency (GSA) and the European Commission (EC) supported the work described here to provide mobile phone operating system and application developers with a library of functions to allow them to benefit from EGNOS in all their applications. It works by receiving correction data via mobile communication networks when EGNOS satellites are not visible to the user device and even when using a standard GPS chipset, overcoming these two main obstacles for adoption.
Targeted mobile operating systems now include Nokia Maemo, Google Android, and Microsoft WinMobile. Further work will extend to this list to other compatible platforms.
This article demonstrates the feasibility and shows the performance of a software-based EGNOS solution and seeks to create awareness among mobile operating system and application developers on EGNOS.
User Benefits and Constraints
Although the sources of GPS positioning errors in urban areas are mainly due to multipath and GPS satellites availability, SBAS corrections on GPS satellites clocks and orbits and ionospheric correction model can still add value in case of moderate multipath environment characteristics. Although GPS stand-alone accuracy is nowadays generally sufficient, it is expected to degrade in the next couple of years as solar activity increases. Availability of free EGNOS corrections delivered via the mobile communication network will help maintain accuracy during these high solar activity periods.
The limited visibility of EGNOS satellites in urban areas requires the use of the mobile communication network to retrieve the EGNOS corrections. This can be perceived at the first sight as a drawback to the proposed solution as it involves communication costs. However, the required bandwidth is negligible compared to today’s mobile applications such as music and video streaming; further, mobile operators increasingly offer smartphones with unlimited data-access packages.
Implementation Overview
Implementation of EGNOS in current-generation mobile phones requires the introduction of a new library of functions at the software level that will allow application developers to get the best possible accuracy in their application regardless of the underlying algorithms used for position calculation. Such a library of functions can eventually be integrated directly in the application programming interface (API) of the phone operation system. At this point, application developers will simply request a position using the API, and the API will return the EGNOS improved position.
The main computations performed by this EGNOS library (see Figure 1) can be summarized as:
Reception: the GPS user position, satellites used, and their elevations and azimuths in NMEA format are requested to the phone’s GPS chipset, and the EGNOS correction message and Klobuchar ionospheric model parameters are received from a distant server (for example, EGNOS Data Access Service EDAS) using the communication link available at the mobile phone;
Preparation: collected input data are decoded and prepared for next step;
Calculation: the new position corrected by EGNOS is calculated by re-creating the line-of-sight or design matrix (using user position and satellite geometry), applying the EGNOS fast, long-term (including clock), and ionospheric corrections (included in the EGNOS message) and subtracting the Klobuchar ionospheric correction that was (assumed to be) applied at chipset level;
Output: the EGNOS corrected position is encoded in NMEA format and returned to the application.
Figure 1. Overview of EGNOS library implementation.
Data Access via the Internet
The EGNOS correction message and Klobuchar ionospheric model parameters are requested by the mobile phone to a distant server. Although the parameters and ephemeris data are stored on the phone’s GPS chipset once it has decoded the messages from GPS satellites, this data is not made available to other phone applications, hence the need to recover it from a remote source. Today, two alternative servers are available: the EGNOS Data Access Server (EDAS) developed by the EC and Signal-in-Space through the Internet (SISNeT) developed by the European Space Agency (ESA).
SISNeT’s advantage is the simplicity of the message (hundreds of bits per second) and the availability of specific functions that allow requesting all the necessary data for our application. However, SISNeT messages are produced from EGNOS signals in space, not from the ground segment: an EGNOS receiver installed at ESA’s ESTEC center receives the signals, demodulates them, extracts the correction message, and re-broadcasts it via the Internet. The reliability and availability of this approach depend upon the good reception of EGNOS signals at this site. Interference or EGNOS broadcast failure could disrupt service.
Unlike SISNeT, EDAS takes the EGNOS correction message directly from the EGNOS system, which guarantees higher service reliability and availability. Nevertheless, the EDAS message is complex and contains much more than the data required for the present application (hundreds of kilobits per second). Therefore a direct connection to EDAS would be inadequate. As a result an EDAS proxy needs to be interfaced between the EDAS server and the mobile platform in order to filter the data flow and extract only the required data. This proxy provides the same kind of messages and functions as SISNeT, whose specifications are ideal for such an application, however it is using data directly from the EGNOS system and not from EGNOS signals in space, improving reliability. In addition, planned EDAS improvements include the provision of such a simplified service directly from the server, removing the need for a proxy.
Independently of the data server used, the mobile platform must retrieve the EGNOS correction messages, and the Klobuchar ionospheric model parameters. The correction message is composed of a number of different message types (MT) as defined in the SBAS standard established by the International Civil Aviation Organization. For our application, the most important messages are:
MT1, the PRN mask that shows to which satellites (PRN) the data contained in the other, subsequent messages are related;
MT2-5, containing data to correct rapid variations in the ephemeris and clock errors of the GPS satellites. The important bits for us in these messages are the fast corrections for each satellite used to calculate the user position;
MT25, with data to correct long-term vari
ations in the ephemeris errors and clock errors of the GPS satellites;
MT18, the ionospheric grid points (IGP) mask that associates ionospheric corrections in MT26 with the IGPs to which they relate;
MT26, providing data to compute the ionospheric corrections for the IGPs present in the IGP mask. In particular it contains the grid ionospheric vertical delay.
The eight Klobuchar ionospheric model parameters must also be obtained from the distant server (using, for example, the GPS_IONO request with SISNeT).
Corrections from GNSS Chipset
The correction algorithm on the phone takes the original position provided by GNSS chipset and identifies the GPS satellite measurements which were used in this computation. It then determines a pseudorange correction for each of the GPS satellites used, and using knowledge of the user-satellite geometry, translates these to a combined position-domain correction.
Most mobile phones’ operating systems allow access to the NMEA sentences from the GNSS chipset using native API functions, for example, onNmeaReceived() with Google’s Android. In order to apply the EGNOS correction algorithms developed in this paper, the minimum required NMEA sentences are GGA, GSA, and GSV.
To construct pseudorange corrections, the Design matrix containing of line-of-sight vectors to the satellites is reconstructed using the elevation and azimuth data. All EGNOS corrections for the satellite orbit and clock errors and the ionospheric delay are applied in this range domain. The algorithm assumes that the Klobuchar model will have been applied to correct for the ionospheric delay in the original GNSS chipset positioning solution. Therefore it provides an adjustment to this original correction to exploit the greater accuracy of the EGNOS ionospheric data. Finally these range corrections are propagated into the position domain using the Design matrix. This provides a 3-dimensional position shift to apply to the original chipset position.
Implementation with Google’s Android
To obtain NMEA strings from an Android phone requires the ‘onNmeaReceived’ function, a function of the LocationManager class. The LocationManager uses the function ‘requestLocationUpdates’ to get a continuous update of the position input, which in this case is GPS. To implement the LocationManager, a LocationListener must be implemented either by the current activity or as a variable. The ‘onNmeaRecieved’ function will be called every second from the instant the Android’s GPS is switched on. The function provides the NMEA strings with a timestamp using the phone internal clock. This timestamp is not derived from GPS and should be used only for logging.
The HTC Legend produces the $GPGSV, $GPGGA and $GPGSA messages that are needed for the application. The Legend also produces $GPRMC and $GPVTG strings. The $GPGSV provides the elevations and azimuths needed for the algorithm, the $GPGGA provides the time, original position and number of satellites in the fix and the $GPGSA provide the PRN numbers of the satellites used in the fix.
For the present testing, necessary data are received via a TCP/IP connection to the SISNeT server (the EDAS proxy server described previously can be used in exactly the same way). For a snapshot solution a continuous connection is not needed and all the information is collected via ‘GETMSG’ and ‘GPS_IONO’ calls. ‘GETMSG’ calls get the last of a specific message type going back up to 30 messages. The types 0,1,2,3,4,5,18,24 and 26 were needed to provide the information for the position domain correction matrices. Only the last message types 0,1,2,3,3,4,5 were needed with type 18 needing 4 and many more of type 24 and 26.
The ‘GPS_IONO’ message gets the current Klobuchar values. By asking for all of the specific message types, almost instantly all the information is gained without having to wait for the 3 minutes Ionospheric grid cycle (message types 18 and 26) and the variable speed, dependant on number of satellites, complete slow correction set. Once the data has been downloaded from the server the connection is closed.
A streamed input could be used with the above approach by continuing to receive data after the initial connection and not closing the connection until the application using the service requested. This would require a continuous stable connection to a high speed mobile network and a limited use of the internet from other applications. As mobile technology improves this will not be a problem but is difficult to achieve with GPRS and 3G networks at present.
Figure 2 shows the current application running on the HTC Legend phone with corrected positions displayed alongside the original GPS positions.
Figure 2. Application running on HTC Phone.
Test Results
Before testing the implementation of the concept on a mobile platform, some initial tests were performed on an offline basis in order to assess the impact of the position correction and verify the approach. This was achieved through the use of 30s data recorded at continuously operating IGS reference stations, freely available over the internet. The data was processed using an in-house PVT engine designed to be representative of LBS implementations, in order to produce stand-alone and conventional EGNOS solutions. The algorithm described in this paper was then applied to the stand-alone solutions, after downloading EGNOS data from ESA’s EGNOS Message Server (EMS) which allows access to past broadcast messages, to produce a third set of solutions. The accuracy of each solution set was then computed based on the precise coordinates of the reference station made available by the IGS. Whilst this approach replicates the mobile phone correction algorithm it should be noted that there is less uncertainty involved in this offline approach as we can ensure that the assumptions made regarding the original PVT solution are valid. We must assume that the phone chipset PVT is a snapshot solution (no filtering) using the Klobuchar ionospheric model and an elevation-dependent weighting scheme.
The plots from Figures 3, 4, and 5 show the errors in position estimates obtained from a 24-hour dataset recorded at the HUEG IGS station in Huegelheim, Germany on May 5, 2010. Table 1 shows the statistics associated with the figures.
Figure 3. Stand-alone GPS horizontal positioning performance over 24 hours at HUEG IGS station.Figure 4. Conventional EGNOS horizontal positioning performance over 24 hours at HUEG IGS station.Figure 5. Position domain EGNOS horizontal positioning performance over 24 hours at HUEG IGS station.TABLE 1. Horizontal positioning performance statistics from 24hr HUEG IGS station analysis.
The results demonstrate that the conventional EGNOS solution improves the horizontal positioning performance of GPS, with an improvement in the 95th percentile of around 2 meters in this example. Importantly, it can be seen that the position domain EGNOS algorithm achieves a similar level of performance to conventional EGNOS. This can be seen more clearly by comparing the instantaneous horizontal error over this period from the three alternative solutions, as shown in Figure 6. It is clear that the position-domain EGNOS correction shown in yellow reduces the horizontal error of the GPS solution (red) in a similar way to conventional EGNOS (blue).
Figure 6. Time series of horizontal positioning errors for stand-alone GPS, conventional EGNOS, and position domain EGNOS solutions at HUEG IGS station.
Similar behavior was found in other datasets tested. With the ability of the algorithm to replicate conventional EGNOS performance verified, we assessed the performance when integrated on an HTC Legend phone. The key differences here were the real-time connection to the EGNOS data server and the uncertainty in the assumptions made regarding the chipset positioning algorithm.
Testing began by assessing the performance of the application over a static point. Two precisely surveyed points were used for this purpose at four separate time periods. The test method simply involved holding the phone over the point (vertical accuracy was not assessed) and requesting a corrected solution from the application, along with the original GPS chipset solution. The chipset applies stand-still detection to avoid generating multiple GPS positions for a single user location which would be unnecessary in typical phone applications. To generate a sample of position estimates therefore the phone was repeatedly moved away from the reference point then returned to it over the test period. This makes the collection of very large datasets over extended periods impractical. The samples from the four test periods were combined in order to generate results with greater statistical significance. 261 samples were collected to produce the results shown in Figures 7 and 8, and the statistics in Table 2.
Figure 7. Stand-Alone GPS Horizontal Positioning Performance from online static point testing.
Figure 8. Position Domain EGNOS Horizontal Positioning Performance from online static point testing.TABLE 2. Horizontal Positioning Performance from online static point tests.
The results indicate a small improvement in horizontal accuracy as a result of the position domain EGNOS correction. The statistical significance of these results is perhaps questionable given the limitations of the test method and relative small sample size. The reduced level of improvement compared to the offline tests is thought to be due to imperfect assumptions made about the chipset positioning algorithm. The correction algorithm must make many assumptions about the way in which the original GPS position has been computed by the phone chipset. These include assumptions on the measurement weightings used, an assumption that a filtered solution is not applied, assumptions that no additional sensors or systems (accelerometers, digital compass or cellular positioning) influence the computed position, and also assumptions that all information reported in the NMEA strings is accurate. Further work seeks to determine if the algorithm can be improved to better replicate the processes applied in the initial GPS solution in order to make a more significant improvement.
The phone GPS positioning achieves similar levels of accuracy to processing single-frequency data collected at an IGS station. This level of accuracy would be more than adequate for most LBS applications in which the main requirement is to be able to reliably relate a user location to a map or imagery feature. With increasing solar activity over the next few years, leading to larger ionospheric delays on satellite signals, the performance of standard GPS solutions will degrade, making the benefits of the more accurate and timely EGNOS corrections more significant.
Conclusions and Way Forward
By a relatively simple translation method, EGNOS data may be mapped into the position domain, allowing a user position solution to be corrected for signal-in-space (satellite orbit and clock) and ionospheric errors detected and predicted by EGNOS. User position solution provided by the phone chipset may be corrected in near-real time based on data downloaded from a distant server.
The method replicates conventional EGNOS performance (corrections applied at the pseudorange level) when all assumptions regarding the stand-alone GPS user position are valid. Ongoing work seeks to determine if the correction algorithm can be enhanced to provide a greater level of improvement to GPS positions on the phone platform. Ideally, it should be able to provide improvements similar to those produced when EGNOS data is applied in a conventional manner in the position solution. Developers would need to judge the significance of any potential improvement for their intended application.
The EC has launched a project to port this EGNOS library to other mobile platforms and complement it with additional functions that are needed by the application developers and that can bring user benefits. The software library can be obtained free upon request to [email protected].
Acknowledgments
Special thanks to Nottingham Scientific Ltd. for its work on this topic and cooperation in preparing this paper. This article is based on a paper presented at ION-GNSS 2010.
François Boullete was market development officer at the European GNSS Agency at the time of this work. He holds a diploma in project management from HEC and a diploma in engineering from Ecole Centrale.
Boris Kennes is R&D and market monitoring officer at the European GNSS Agency. He has a background in engineering and strategy consulting.
Michaël Mastier is policy officer at the European Commission in the Galileo/EGNOS applications unit. He has an engineering education and diploma in public works from ENTPE in Lyon, and a computer science post-graduate diploma from Saint-Etienne University, France.
Lee Banfield is a software engineer at Nottingham Scientific Limited (NSL) in the UK. He has developed applications which use EDAS data to provide EGNOS corrections, GNSS assistance messages and GNSS performance metrics for a range of road and LBS applications.
In November, December, and January, a regulatory drama with high potential impact on the GPS signal and domestic U.S. GPS users began unfolding before the Federal Communications Commission (FCC). As this magazine goes to press on January 24, the issue remains far from resolved, although hearings and far-reaching decisions may have transpired by mid-February.
A company called LightSquared applied to the FCC in late November for modification of its authority for ancillary terrestrial component (ATC). It asked the FCC to grant it permission to broadcast a co-primary terrestrial wireless service in the L-band frequencies typically reserved for space systems and radionavigation satellite services. Lightsquared wants to broadcast in those frequencies, not only from space but from powerful terrestrial transmitters that could effectively overload the GPS signal for millions of users in metropolitan areas across the United States. LightSquared asked the FCC to fast-track its request.
The National Telecommunications and Information Administration (NTIA) has expressed its concern that LightSquared’s proposal to sell wholesale terrestrial-only services could interfere with navigation and E-911 systems. NTIA is concerned that terrestrial-based devices operating in the mobile satellite services band could interfere with GPS timing receivers, aeronautical communications, and the Inmarsat mobile satellite service used by the Department of Defense.
Write to Congress. Members of the GPS community who are concerned by the proposal may contact their Congressional representatives, to advocate for a fully independent technical study by the NTIA before the FCC takes any action. Contact information and appropriate case file numbers are given at env-gpsworld-integration.kinsta.cloud/fcc.
The FCC may have decided not to follow the Administrative Procedures Act, which directs it to consider a waiver request under an open and transparent rule-making, so that all affected parties may comment. It appears that the FCC could grant a waiver to LightSquared for a terrestrial wireless broadband service, but condition the service going operational on interference studies. Lightsquared has proposed that such studies be conducted under its own direction.
Voices within the GPS community have asked for an independent, third-party, unbiased technical analysis to precede a fact-based rule-making, rather than a study organized and led by the interested party.
LightSquared previously received authorization to build a hybrid network using satellite and terrestrial-based communications. The waiver would allow its wholesale customers to offer terrestrial-only services. The company’s buildout is scheduled to include a 40,000-cell-site terrestrial network deployed by Nokia Siemens Networks that will cover around 90 percent of the population of the United States.
The trade publication RCR Wireless reported that Lightsquared may have run short of funds. “The company has raised about $2 billion to date. Reuters is reporting that Harbinger Capital Partners, which is funding LightSquared, has let some employees go as it attempts to right-size the company. The Harbinger fund now is valued at about $7 billion, a steep drop from the $26 billion it once counted.” The finding may shed light on why Lightsquared sought fast-track approval over winter holidays.
24+3 GPS Configuration
The U.S. Air Force 50th Space Wing announced completion of phase one of the two-phase GPS constellation expansion called Expandable 24, also known informally as 24+3, to increase global coverage and provide users with more robust satellite availability.
Phase one concluded when the last of three satellites that began repositioning maneuvers in January, 2010, completed its journey on January 18. Phase two, a repositioning of three more satellites, started in August 2010 and is expected to end in June of this year. At that time, the GPS constellation will attain the most optimal geometry in its 42-year history, maximizing GPS coverage for all users.
GPS IIF-2. The second satellite of the next generation, GPS IIF-2, received a launch date of June 23 from Cape Canaveral, Florida.
EC: $1 Trillion in Europe Depends on GPS
The European Commission (EC) presented its mid-term review on the development of Galileo and the European Geostationary Navigation Overlay Service (EGNOS). The report reiterates previous statements that Galileo will deliver initial services in 2014 — despite outside and unofficial speculation that the date may slip to 2015. The report also estimates that 6–7 percent of the gross domestic product (GDP) of developed countries in Europe, an amount that equals €800 billion ($1 trillion U.S.) depends on satellite navigation; that is, on GPS, for the time being.
A December editorial in this magazine hypothesized that, on that basis, roughly $3 trillion of the global economy depends on GPS.
Costs Rising. An EC message to the European Parliament and European Council served notice that reaching full operational capability for Galileo will cost €1.9 billion more than the €3.4 billion already allocated. The EC foresees an average annual expense of €800 million to operate Galileo and EGNOS.
The administrative body for the European government issued one of its strongest statement yet as to the value of the satnav systems, however. “The ultimate objectives are not being called into question.” EC Vice President Antonio Tajani added, “We are satisfied with the progress made so far and committed to bringing this project to fruition.” The EC indicated its willingness to find alternative methods of financing the project.
Check-up. Meanwhile, the first in-orbit validation (IOV) satellite goes through readiness testing at the European Space Agency’s technical center in the Netherlands. Four identical Galileo IOV satellites are in preparation, and the first to be completed has been selected for qualification testing, as the Protoflight Model (PFM). Satellite payloads were designed, developed, and assembled by EADS Astrium in Portsmouth, UK, with the overall satellite designed and developed by Astrium in Ottobrunn, Germany, and assembled by Thales Alenia Space in Rome, Italy.
The PFM will endure simulated launch vibrations on an electrodynamic shaker, followed by sudden shocks simulating those during separation from the launch vehicle. Finally, it will take an acoustic battering matching the launcher’s sound pressure and frequency. The Galileo IOV satellites will be launched two at a time; a dispenser will hold them together within the launcher fairing and eventually release them in orbit. Pyrotechnic devices will shoot them safely away from the dispenser and each other.
Once ESTEC testing is complete in February, the PFM will be reunited with the rest of the IOV quartet in Italy for a follow-up round of thermal vacuum testing, to prove that they can withstand the temperature extremes of space. Finally, the satellites will travel to Europe’s spaceport in Kourou, French Guiana in South America, to be launched on Russian Soyuz rockets.
Pictured: Galileo protoflight model runs through its test paces at ESA.
Michibiki Produces 3-Centimeter Accuracy
According to a report in the Japanese business daily Nikkei, researchers in Japan conducted a test that yielded continuous 3-centimeter positioning accuracy for a car driving at 20 kilometers (approximately 12 miles) per hour, using a conventional GPS receiver equipped to receive corrections from the new QZSS satellite Michibiki. The authors imply that, unaided, the same equipment would have produced accuracy in the range of about 10 meters.
The report also states that the Japan Aerospace Exporation Agency (JAXA) and Mitsubishi, who have partnered to develop and launch the Quasi-Zenith Satellite System (QZSS), have conducted further tests shown that the augmentation system maintains its accuracy with cars driving up to 80 kilometers (48 miles) per hour.
QZSS’s current Michibiki satellite can cover Japan for eight hours a day; two additional satellites, planned for the future, will join it to provide continuous coverage and GPS corrections over mainland Japan and parts of Australia.
As a commenter from the United States pointed out, “There’s nothing new about 3-centimeter GPS accuracy. The surveying, construction, and agriculture industries have been using 2–5 centimeter level real-time kinematic GPS technology for well over a decade. Post-processing can get GPS accuracy down to the millimeter level and measure tectonic plate movements. By the way, Michibiki (aka QZSS) does not work without GPS. The United States helped Japan build QZSS.”
Nonetheless, if the tests used a conventional, consumer-grade GPS receiver, the results are indeed impressive. The availability that a full QZSS constellation will bring — the explicit goal of the project — in Japan’s skyscraper-dominated urban landscape should enable many heretofore impractical or impossible projects in car navigation, construction, tracking and monitoring, and location-based services.
Shelton Space Commander
Gen. William L. Shelton assumed command of Air Force Space Command (AFSPC) on January 5. Shelton replaces Gen. C. Robert Kehler, who will take over at the U.S. Strategic Command.
Shelton has served in various assignments, including research and development testing, and space operations. As commander of AFSPC, he is responsible for organizing, equipping, training, and maintaining mission-ready space and cyberspace forces and capabilities for North American Aerospace Defense Command, U.S. Strategic Command, and other combatant commands around the world. Shelton also oversees Air Force network operations; manages a global network of satellite command and control, communications, missile warning and space launch facilities; and is responsible for space system development and acquisition. AFSPC is comprised of more than 46,000 professionals, assigned to 88 locations worldwide and deployed to an additional 35 global sites.
Des Dorides for European GNSS Supervisory Agency
Carlo des Dorides of Italy will head the European GNSS Agency, formerly known as the European GNSS Supervisory Authority (GSA). The Czech Republic’s Transport Ministry joined the European Commission (EC) in making the announcement. The GSA will gradually move its headquarters to Prague over the next two years.
“The election of the Italian candidate is unambiguously good news for both the Czech Republic and Galileo itself,” said Karel Dobes, the Czech government envoy for the Galileo system. “His idea of the future shape of the agency rests in a stronger and greater agenda than nowadays, which would provide greater opportunity for our firms to get lucrative orders. It is a business with the highest value added, thanks to which local firms and the whole Czech Republic may get billions of crowns in the future.”
Des Dorides was profiled by GPS World magazine as one of the 50 Leaders to Watch in GNSS in 2006. At that time he was head of the Concession Division of the Galileo Joint Undertaking, the GSA’s predecessor.
GLONASS Goes for Ten-Year Plan
The GLONASS plan for 2011–2020 is ready and now undergoing the final stages of approval, Sergey Revnivykh, Deputy Director General of the Central Research Institute of Machine Building of the Federal Space Agency, told a Russian business newspaper.
“In March–April, the program will be presented to the government. I can say that the amount [of funding] is sufficient to meet the prospective demands of consumers and ensure parity with other navigation systems. During the program period, 2012-2020, GLONASS, in [terms of its] parameters will not yield to the planned development of the GPS and Galileo systems.”
According to Revnivykh, by 2019 the GLONASS constellation will consist entirely of new-generation GLONASS-K satellites. In addition to existing FDMA signals, they will transmit CDMA signals in the format of CDMA (the same format as GPS and Galileo) and their service lifetime will increase to 10 years. Flight testing of a GLONASS-K prototype, originally scheduled for December 27, was postponed to a later date, to be determined in early February.
Two prominent executives associated with GLONASS were dismissed, and the program came under increased scrutiny after a launch disaster drowned three new satelites in the Pacific Ocean.
The alarm operations center for the state of Bavaria receives this message from the accident location, and swiftly moves into coordinating activity, gathering and distributing real-time geospatial data and other key information to all emergency teams and medical facilities in the area. A demonstration of large-scale rescue operations showed how Galileo-based positioning signals in the Galileo test-bed in Berchtesgaden, Germany can more efficiently organize complex and costly rescue work through use of GNSS-supported mobile navigation devices.
Current decision-making aids in the field of search-and-rescue offer only a limited IT-supported common operational picture (COP). Many components for a full solution are still lacking. Heterogeneity in sensor networks and proprietary system designs limit interoperability and flexibility, hampering the creation of a full COP across collaborating organizations.
“E mergency Alert: Bus collision in Berchtesgaden, parking area Salzbergwerk. Many injured. Bus overturned, some thrown from vehicle, some trapped inside. Local temperature below freezing, snow falling. All crews respond immediately.”
An extensive training exercise (photo above) performed by the Fire Brigade, Bavarian Red Cross, and German Federal Agency for Technical Relief focused on challenges and advantages in this framework. The ERA-Star Project G2Real integrates real-time Earth-observation data and onsite measurements, leveraging existing and emerging open geospatial consortia. Spanish, Austrian, and Bavarian research institutes and enterprises collaborated to prepare and upgrade a COP based on integrated live information, satellite-navigation, and remote sensing. The overall aim is utilization of GNSS-enabled tools and Global Monitoring for Environment and Security (GMES) services to support search-and-rescue operations. The specific goal is a common, real-time COP that can be used by the local primary control unit/service command vehicle and by higher ranking administrations.
The common operational picture (COP).
Mission control, decision, and guidance was coordinated from a remote control room, where the mission leader, through the COP, knew everything about the position of accident vehicles, victims, rescue vehicles, and rescue team personnel, and could track their status and locations in real time. Local team chiefs on the ground also had access to this data through their mobile devices.
The mission leader could plan resources for the ensuing phases of transport and treatment, and teams on the ground could communicate with each other via a simple mobile phone application, which replaced existing calls and radio voice signals and facilitated operations and coordination.
GNSS receivers were installed in a fire engine using Galileo, GPS, and GLONASS signals to achieve best practice across all phases of emergency management. The Galileo signals were furnished by the Galileo Test and Development Environment (GATE), provided by eight transmitters atop the Alpine ridges surrounding Berchtesgaden.
Lars Holstein is project manager for Initiative Satellite Navigation Berchtesgadener Land.
Last week, I conducted a webinar along with Dr. Michael Whitehead titled “SBAS, DGPS or Post-processing? Which Should You Use?” It was one of the best webinars I’ve conducted to date. More than 600 people registered. We barely squeezed it into 65 minutes and could have kept going for the better part of two to three hours, given the subject matter to cover and the number of questions we received before and during the webinar. Thank you for attending, if you did. If you weren’t able to you, can download it by registering here. After registering, you’ll be provided a link to download it.
I knew that only having 65 minutes would be a serious issue for the webinar because the discussion could take many worthwhile tangents. And it was. But alas, we stuck to the presentation agenda, stayed on schedule, and were able to address several audience questions.
We had a lot of questions before and during the webinar. As customary, I’d like to address some of those as well as present the poll results here. First, the poll questions and results with accompanying pie charts to illustrate the results.
Poll #1: For those of you who use post-processing, what are the reasons you use it?
Total votes: 117
Gakstatter comment: This is an interesting spread with no clear dominating reason. Based on data I’ve seen and data we collected, I’m not convinced that post-processing is more accurate. If it is, is it worth the extra 10%, 20%, or ??% accuracy? I understand the votes for more reliable corrections. There’s something to say for reverse processing (forwards and backwards).
Poll #2: For those of you using post-processing, from where do you access GPS base station data?
Total votes: 129
Gakstatter comment: These answers don’t surprise me. National and regional CORS have become very prolific in the past 10 years.
Poll #3: For those of you who use real-time DGPS/SBAS, what is the reason you use it?
Total votes: 110
Gakstatter comment: These answers surprised me a little. I thought more people would vote for “less complicated.” Does that percentage of users really need corrected coordinates in the field? Why? E-mail me a quick answer if you have a chance.
Poll #4: For those of you using real-time DGPS/SBAS, from where do you access DGPS/SBAS corrections?
Total votes: 129
Gakstatter comment: This answer doesn’t surprise me at all. I suspect RTK networks will increase due to their continued proliferation and different levels of accuracy offered.
Poll #5: When I purchase GPS/GNSS equipment in the future, I will likely select equipment that utilizes the following correction method (select all that apply):
Total votes: 144
Gakstatter comment: This was the only multi-answer poll. People could select more than one answer. These answers were surprisingly close. That surprised me. It didn’t surprise me that SBAS was the leader. It surprised me that post-processing is still as predominant as it is. If you have a chance, e-mail me a quick explanation as to why you will use post-processing in the future.
Before diving into some audience questions, I’d like to clarify the slide illustrating the post-processing plot shown below.
During the webinar, we were discussing PPP (precise-point positioning) when this slide was displayed. This data was not corrected via PPP, but rather post-processing the pseudorange data, which is the equivalent of L1 SBAS and L1 DGPS. The point was to show how SBAS/DGPS accuracy compares to post-processing. In the real world, you won’t post-process 24 hours of data. Some of you will post-process only a few minutes of data per session in cases where you need to turn off the receiver and travel between points. In other cases, users will keep the receiver tracking between points, allowing reverse processing to work more effectively.
On to the Questions
Question #1: Will there ever be a way in which the position of a rover can become fixed by using two fixed base stations?
Gakstatter comment: SBAS does this already. SBAS’s consist of a number of base stations within the coverage area (e.g., WAAS has 38). Data from many base stations is used to compute the correction information sent to an SBAS-enabled GPS receiver.
I’m assuming your reasoning is to improve position integrity.
Another method of accomplishing this is by post-processing against more than one base station or switching between DGPS beacon stations. If they differ significantly, then you might want to compare against a third base station.
Question #2: At what point in time will the strength of the GPS signal be increased? To what strength will this occur? 500 times more powerful? What improvements in signal reception will be experienced? Indoor my house reception?
Gakstatter comment: The GPS broadcast strength is increased with new GPS satellite model. For example, the current Block IIF satellite broadcasts the new L5 signal about four times stronger than L2C. While no one can be sure yet as to how much this will improve indoor positioning, there will be some marginal improvement in conditions where GPS doesn’t operate very well today. Also helping will be the improved code and error-correcting techniques that should make operating in difficult conditions a bit better, especially where there are a mixture of satellites with strong and weak signals.
Also, it raises the issue of a viable L5 single frequency receiver, which should outperform the L1 C/A single frequency receivers of today.
Question #3: NAD83, WGS84, ITRF differences, how to make the best choice?
 
;
Gakstatter Comment: I don’t think there is an incorrect choice, except maybe that NAD83 is a 2D system and will eventually give way to a 3D system, but that won’t happen in the U.S. for many years.
Otherwise, it’s a question of matching disparate data sets. Probably the #1 question I hear from users is “why doesn’t my GPS data line up with my basemap?” The answer is almost always a difference in datums. Many papers have been written on this. Click here for a good PowerPoint presentation created by Dave Doyle of the National Geodetic Survey.
Question #4: Are there any open source post-processing software programs available?
Question #5: If a person uses real-time correction satellites, is there a need to post-process?
Gakstatter Comment: It’s rare that someone would do both, but not out of the question. For example, one might rely primarily on real-time corrections and record raw data for post-processing in case there is a problem receiving the real-time corrections. The opposite is true, too. One might rely primarily on post-processing and use real-time corrections as a back-up in case there is a problem with post-processing.
Caveat emptor: There are probably datum differences between the sources of real-time and post-processing corrections. This needs to be reconciled when combining data that has used the two sources.
Question #6: Is it possible to post-process data without using a DGPS?
Gakstatter Comment: Yes, all that is required for post-processing is the ability to record raw observation data.
Question #7: Are there geographic areas in the U.S. that are not covered by NGS CORS stations?
Gakstatter Comment: No, not for pseudorange (L1) differential corrections. The distance to the base station will vary depending on where you are located and thus may affect your accuracy to some degree, but the density of CORS in the U.S. is such that you will never be more than a couple of hundred kilometers from a base station and likely much closer.
A side note: Back in the mid-1990s, I remember experimenting with post-processing software we were developing. At that time, I tried post-processing data collected in Oregon with a base station located in Atlanta, Georgia. This was a 2,500 km baseline. It produced a result, albeit not one I would necessarily trust. The only limitation is that the two units must track common GPS satellites. With that length of baseline, it’s possible that only half of the satellites tracked may be in common.
Question #8: What is the ideal distance range from a CORS station to your site to use post-processing?
Gakstatter Comment: Ideally, as close as possible. The further you are from a base station, the more potential error will be introduced due to atmospheric differences between the two locations. As stated above, the density of CORS (at least in the U.S. and many parts of the world) are such that the nearest base station is quite near and likely no more than a couple of hundred kilometers away.
Question #9: What is the trade-off between short observation time (couple of minutes) to position accuracy when using post-processing?
Gakstatter Comment: Ok, remember we are talking about pseudorange corrections (as opposed to carrier phase). Given that the receiver has been tracking satellites for a period of time (let’s say two minutes), the observation times only need to be a few seconds for each feature to be mapped.
For example, if you are mapping utility poles and don’t turn off the receiver between poles, you only need a few seconds (5-10 seconds) of data for each pole and average it for the final coordinate. Think about if you’re mapping a road centerline. You’ll likely record data while moving, so each second you are recording a new position.
Question #10: What about the vertical correction? I see in the slide an antenna carried in a backpack. Is the antenna placed at ground level for point? Is there a constant correction required?
Gakstatter Comment: Vertical accuracy is typically worse than horizontal accuracy by a factor of 1.5-2.0 due to the inferior satellite geometry, especially in areas of hilly terrain and/or trees/buildings where the horizon is blocked. Good geometry for vertical positioning requires tracking a number of GPS satellites that are low on the horizon.
Question #11: What is the future of DGPS? I heard Coast Guard beacons were going away?
Gakstatter Comment: The beacon stations operated by the U.S. Coast Guard are not in jeopardy and never have been. Neither have the marine beacons in the other 40+ countries that broadcast GPS corrections. However, the U.S. Department of Transportation operates 29 inland stations in the U.S. which have faced budget challenges the past few years. In April 2008, the U.S. DOT issued a policy decision to continue operating the 29 inland sites. Construction of seven sites remains that would allow the Nationwide DGPS to reach Initial Operating Capability (IOC), which would provide coverage to 99% of the continental U.S. No budget has been approved for the construction of those seven sites.
Question #12: Can you briefly explain the difference between DGPS & RTK?
Gakstatter comment: Here are a couple of good websites that explain each of these techniques. Essentially, DGPS is a real-time GPS positioning technique accurate to about 30 centimeters at the very best. RTK is a real-time GPS positioning technique accurate to about 1 centimeter.
Question #13: How much time do you need to get the position from the base station for real-time DGPS?
Gakstatter comment: Assuming both receivers are already tracking satellites, your receivers will begin using the base-station corrections as soon as the data link is made between the two.
Question #14: Can you comment on advantages (if any) of using corrections from a network RTK service for DGPS corrections. Any advantages on eliminating base separation?
Gakstatter comment: I’ve heard that DGPS corrections are optimized within an RTK Network. However, I need to research this a bit further to better understand the true advantages, if any.
Whitehead Comment: A virtual base station (VBS) solution could be formed using the network. Thus differential GPS could exhibit the same advantages using such a network that RTK does (cancellation of atmosphere errors). The software would have to support this.
Note though that if close to one of the Reference Stations in the network, it is probably best to just use the nearest Reference station as this will best cancel the atmosphere errors. When in the middle the network, the VBS solution would use surrounding reference stations to provide a good approximation of atmospheric errors and then output a correction that looked like it originated from a reference station (virtual station ) near to the users receiver.
Question #15: What is up with PRN 135? Still on station?
Gakstatter comment: Communication has be re-established with WAAS PRN 135 and is being tested by its owner, Intelsat, as well as the Federal Aviation Administration (FAA). See a detailed article by clicking here. The latest information I heard is that it’s currently at 93°W longitude undergoing testing. If the testing is successful, it will be re-located back to 133°W longitude and brought back into WAAS service. A timeline has not been published, but I’m guessing within the next 30-60 days.
Question #16: We used to hear that your point accuracy degraded as the distance from the base station increased. One reason we used to post process. Is this still a factor?
Gakstatter Comment: Due to advancements in GPS technology, it’s not as much of an issue as it used to be. I think this is illustrated in the results we achieved in our 24 hr test data.
Ten years ago, it would be hard to find a GPS L1 receiver that would receive DGPS corrections from a beacon station 184km away and still achieve sub-meter horizontal accuracy at the 95% confidence level.
I’m not saying the distance is negligible. There still the issue of tropospheric, ionospheric and satellite orbit errors as you move farther away from the base station. But, it’s certainly less of a factor than it was before.
Whitehead Comment:
Question #17: If we use WAAS correction, does it really help to try to use a post-processing type of software afterward? So far we just use WAAS correction.
Gakstatter Comment: One of the reasons we collected data using several sources of real-time corrections and also showed the results of post-processing was to illustrate the differences between the two.
If you follow proper procedures, there’s no reason to think that accuracy obtained using WAAS will differ significantly from accuracy obtained using post-processing. This is assuming that you’re using a single-frequency GPS receiver and post-processing using pseudorange corrections and not carrier-phase processing. Some receivers like the Trimble GeoXH are actually dual-frequency receivers and so data from it will likely surpass the accuracy of WAAS if you’re using its dual-frequency antenna and equivalent post-processing software.
By proper WAAS procedures, I mean letting it track for five minutes upon initial start-up to allow it to download a current ionospheric map.
Question #18: Does SBAS use 1 receiver and no base station? Expensive?
Gakstatter Comment: SBAS uses 1 receiver and a lot of base stations. You just don’t have to pay for the SBAS base stations (or to use them.) The signal, like GPS, is provided free of charge.
SBAS consists of a network of base stations (WAAS has 38) and communications satellites that broadcast corrections to users on the ground (or aviation users in the air).
Question #19: How far north in Alberta is WAAS coverage available and useful?
Gakstatter Comment: The primary concern would be visibility of the WAAS GEO satellite that broadcasts the correction data. Following is a map that illustrates the coverage. The contour lines are degrees above the horizon for which the two WAAS GEO satellites are visible.
Solid line = PRN 138, Dashed line = PRN 133
Question #20: Do you have any comments about CDGPS in Canada/US?
Gakstatter comment: Sadly, the CDGPS service is being decommissioned March 31. You can read about it here.
Question #21: I am hearing from my state specialists (NRCS) regarding the LightSquared issue. We are advising working through the PNT ExComm and our cooperating partners.
Gakstatter comment: This is a potentially serious issue for GPS users. Click here for the latest news as of February 1.
Question #22: Where do you find the DGPS beacon station list and what is available to you?
Gakstatter comment: I’m not sure if this is 100% complete, but it’s the most complete list I’ve seen. Click here.
Question #23: Are most mapping-grade GPS receivers (for example Trimble GeoXh) equipped off the shelf to receive beacon signals?
Gakstatter comment: Some receivers are equipped off-the-shelf, others are not (such as the GeoXH) and require additional hardware.
Question #24: In which areas is it possible to use corrections from OmniSTAR?
Gakstatter comment: Click here to view worldwide maps of OmniSTAR coverage.
Question #25: Was the Garmin set to WAAS?
Gakstatter comment: Yes, during the 24-hour data collection session, the Garmin unit was receiving WAAS 100% of the time as far as we could tell. The purpose of the 24-hour test period was to able to randomly sample data during that period to arrive at the accuracy statistics we presented. I randomly sampled the dataset several time
s (averaging 10 seconds worth of positions 200 times) and the results were consistent with what we presented.
Question #26: How does post processing account for ionosphere or troposphere errors if receiver is geographically far away from the base station? If not, does DGPS and WAAS provide better accuracy and integrity?
Whitehead comment: Post Processing using a CORS station would take the nearest station and do differential GPS which cancels common errors in ionosphere and troposphere (ionosphere and troposphere are both temporally and spatially correlated) so if the CORS station is close, there will be good cancellation. If the receiver is far, the algorithms could use a troposphere model to account for the differential troposphere (as was done in the Presentation for BeaconT) and this would probably cancel troposphere so that remaining errors were sub-decimeter level. Differential Ionosphere errors could also be easily modeled with good results. It is likely that the performance could be made to easily surpass SBAS.
DGPS would suffer from the same effects as does post processing, and maybe even more so since a model of differential atmosphere errors is rarely used. SBAS will likely provide better accuracy in situations where you are far from a base station.
Question #27: What is Beacon T?
Gakstatter Comment: While collecting data to present at the webinar, Mike noticed there was a bias in the beacon measurements. The beacon station is located ~184km away at about 7,000 ft elevation while the test site was at about 1,000 ft elevation. Initially, Mike wasn’t modeling the troposphere difference between the base and rover.
To model the troposphere, Mike said he used a troposphere model to figure out troposphere in both locations, and then subtract the two. Although the models are not necessarily that accurate in an absolute sense, the differential tropo between the two locations is fairly accurate using the models. This differential tropo allows the receiver to correct the tropo in the base station differential to make it appear as if it originated in the rover location. Mike said he could’ve done the same for the ionosphere, but he didn’t since that is it usually less of a factor. After using the modified tropo model (Beacon T), the height bias was around 1/2 meter, which could be attributable the ionosphere. The horizontal bias is small, as you can see in the results.
Using this troposphere model resulted in a significant improvement over the original solution.
Question #28: Why is VBS better than WAAS?
Gakstatter Comment: It surprised me too. The receiver used was the same that was used for beacon and WAAS. I contacted OmniSTAR for their opinion.
John Pointon of OmniSTAR responds: “There have been incremental improvements in the VBS service over the years, mostly improvements in modeling and processing. We have added two or three extra reference stations but that hasn’t been the most critical improvement, just helped in some specific areas. These, combined with the relatively benign solar environment, result in VBS accuracy which, although not equivalent to our dual-frequency and multi-system solutions, is consistently better than either Beacon or WAAS.”
Whitehead Comment: In the past, we’ve seen similar performance from both OmniStar VBS and WAAS. Different atmosphere conditions and different locations can affect the performance of both. We’ve seen situations where WAAS is better. It is probably fair to say that OmniStar is more focused on accuracy, whereas WAAS is focused on integrity. It may be wise to do a comparison in the particular area where you operate. Note, however, that in the US, OmniStar is referenced to NAD83 whereas WAAS is references to ITRF so positions reports between the two can differ by several meters.
Question #29: When I look at your scatter plot, I have to ask if short-term point averaging is really effective at achieving more accurate positions?
Gakstatter Comment: I think it’s well accepted that you are wasting time by occupying a point for 180 seconds. That said, there’s something to be said for letting the receiver track satellites for a period of time (1-2 minutes) before storing 5-10 seconds of data. Of course, if the receiver is already tracking satellites, then it’s not necessary to wait. The idea is to let the measurements settle down and take advantage of carrier-phase smoothing if the receiver uses that technique.
Question #30: Could you go into PPP a bit more? How does it work?
Gakstatter Comment: We opened a can of worms by discussing PPP. It’s an entirely different subject that I will cover in a future article. In the meantime, you can read Dr. Richard Langley’s article on PPP here.
Question #31: How do you test the accuracy of SBAS collected data?
Gakstatter Comment: In the U.S., it’s easy. Find a local survey mark using the National Geodetic Survey website. Printout the ITRF coordinates of the survey mark. If they aren’t on the datasheet, you can convert from NAD83/CORS96 to ITRF using the HTDP program. Compare the coordinates output by your GPS receiver to the coordinates of the survey mark.
If you’re located outside of the U.S., look for a similar government agency in your country that maintains a record of survey marks. It’s vital that you are comparing coordinates referenced to the same datums.
Question #32: Will there be any disadvantage if we use a EGNOS corrections in Kuwait, if we receive EGNOS?
Whitehead Comment: Kuwait is outside the EGNOS coverage zone, so satellites to the south may not even have Clock and Orbit correctors available, which means the Receiver could not compute a correction for these satellites. Unless the receiver can mix differentially cor
rected ranges with non-differentially corrected ranges, it would likely drop the satellites in the south that had no corrections. This would then reduce PDOP and thus accuracy. Mixing differentially corrected ranges with non-differentially corrected ranges may give worse accuracy than no corrections at all since the SBAS system may have clock or other biases relative to GPS.
By the way, I wish the SBAS providers would get together and share data so that they each could provide world-wide orbits and clocks. Then it would matter less if you were outside the coverage area.
Gakstatter Comment: I’ve heard that EGNOS is planning an expansion to the south and east, so Kuwai may eventually be within the EGNOS coverage footprint. Also, you’ll want to monitor the progress of India’s GAGAN system, which is a similar SBAS. It’s possible you might fall within the GAGAN extrapolated footprint for non-aviation users.
We covered most of the questions posed by the audience. If we didn’t address yours or didn’t provide a complete enough answer for you, please e-mail me and I’ll do my best to answer you.
As I mentioned above, we had quite a few questions about PPP. It’s a technology that’s worthy of further coverage and discussion. Look for a future article on it.
Back in December 2006, I wrote about the momentum of Galileo (Europe’s planned satellite navigation system) in an article discussing GNSS trends. Galileo has been discussed off and on for well over a decade and was a hot topic for a number of years. In fact, back around 2001, the U.S. really didn’t want the European Union to embark on the project. While there was not a clear policy against Galileo, certainly the sentiment was questioning the creation of another satellite navigation system when GPS already exists that’s free for everyone to use. Ok, it probably wasn’t that simple, but you get my point. No bueno from the U.S. at that time.
The following is an EU slide that illustrates why the EU wants to develop its own satellite navigation system similar to GPS:
Source: European Commission – Montpellier, France – October 2010
Then, in 2004, the U.S. government abruptly changed its tune. It really doesn’t matter why and I’m not sure I’d believe the answer if I was given one, but President George HW Bush instituted a new policy that encouraged international cooperation. The U.S. SPACE-BASED POSITIONING, NAVIGATION, AND TIMING POLICY issued in 2004 stated, among other things, that the United States shall:
“Seek to ensure that foreign space-based positioning, navigation, and timing systems are interoperable with the civil services of the Global Positioning System and its augmentations in order to benefit civil, commercial, and scientific users worldwide. At a minimum, seek to ensure that foreign systems are compatible with the Global Positioning System and its augmentations and address mutual security concerns with foreign providers to prevent hostile use of space-based positioning, navigation, and timing services;”
Also in 2004, the U.S. and European Union signed the landmark GPS-Galileo Agreement that established a basis of cooperation. This was great news for the GNSS user community. More satellites and more signals usually equates to better performance.
The next policy update after 2004 was last year (2010) and it was simply titled “NATIONAL SPACE POLICY“. The sentiment regarding international cooperation was the same, if not leaning more towards cooperation:
“Engage with foreign GNSS providers to encourage compatibility and interoperability, promote transparency in civil service provision, and enable market access for U.S. industry;”
After the 2004 GPS-Galileo policy was published, the question from the civil user community was, “When are we going to have satellites in orbit broadcasting signals we can use?”
The answer to that question wasn’t easy, and took longer to answer than anyone predicted, including myself.
Now, we have the answer.
Unlike GPS and GLONASS, Galileo is a civilian project, not a military-funded one. I’m not saying GPS and GLONASS were easy to fund, but the core application was defined (military use), and the funding required to develop and maintain GPS and GLONASS is drawn from the military budget. Furthermore, the European Union is comprised of 27 member countries. The political dynamics are, obviously, very complex.
The Galileo funding modeling initially was to be a public-private partnership (PPP). Part of it would be funded with public money and part of it would be funded by a consortium of companies. But, that wasn’t so easy. How much funding would each contribute? What’s the return on investment? How would it generate revenue? Would there be a tax receiver sales? Would there be a user charge?
We’re not talking about small sum of money. We’re talking about several billion Euros just to get it off the ground.Think about it, how much money has the U.S. military spent to develop GPS? $30-$35 billion for development, deployment and long-term maintenance. Granted, Galileo will cost a lot less than that, but it’s still a healthy sum that no company would be willing to gamble without a solid return-on-investment (ROI) argument.
Eventually, the PPP (Private-Public Partnership) funding model was abandoned and in late 2007, and as described in a January 2008 GPS World article:
“European officials responsible for the EU budget said they had found funds for Galileo, proposing to draw unused money originally earmarked for natural resources programs this year and next. The move would provide some €2.4 billion ($3.3 billion) for Galileo — the budgetary shortfall left with the dissolution of the public/private partnerships — over the course of the next six years. The following month, European parliamentarians agreed with the plan, but felt it didn’t go far enough. They boosted proposed funding for Galileo, increasing the money set aside for the program in 2008 to €739 million ($1.06 billion), up from the much more modest €151 million under the transport officials’ original proposal for next year.
Not all were sold on public funding for Galileo. But in November, European officials said they had ironed out their differences. At the 11th hour came heated debate about how Galileo funding and contracts would be awarded among member states and their respective aerospace companies. Eventually, a final accord was reached. Europe anticipates spending €3.7 billion on Galileo through 2013.”
(Updated figures: €2.1 billion for IOV and €3.4 billion for FOC)
That was three years ago. The EU folks have been working hard since then, but talk is cheap and people stopped talking about Galileo with the exception of a few information spikes here and there. There was nothing else to say until now.
2011 is the Year for Galileo
Galileo will likely meet a major milestone this summer, launching their first two satellites for in-orbit validation. But unlike the two Galileo test satellites already in orbit (GIOVE-A and GIOVE-B), these satellites will be part of the planned 30-satellite operating constellation.
For you Galileo naysayers, the EU is past the point of no return. Eighteen satellites are contracted. There is no reversing the process. And, if I were to place a bet, it’s very unlikely to stall at 18. That would be sort of like building a structure, but not finishing the interior.
Although I haven’t seen a detailed launch schedule or control segment plan, the latest Galileo public document I’ve read (European Commission – Montpellier, October 2010) presents the following timeline:
2011/2012 – In-Orbit validation: Four IOV satellites and ground segment (based on European Commission presentation from October 2010).
2014/2015 – Initial Operating Capability for early services — 18 satellites (based on European Commission presentation from October 2010).
L1/L5 dual-frequency receivers are going to be cheap, and accurate. Today, dual-frequency (L1/L2) receivers are thousands of dollars. L1/L5 receivers will be a fraction of that cost because open signal specifications will lead to increased competition.
As I mentioned in the article last summer, the GPS Directorate is planned to have 24 satellites broadcasting L5 by 2019. The beauty of Galileo is that it can cut that time in half and make it happen by 2014, only three years from now. Here’s how.
Since Galileo supports L1 and L5 similar to GPS, you only need 12 x GPS satellites broadcasting L5 and 12 x Galileo satellites broadcasting L5 to have something close to 24 satellites broadcasting L5.
The BIG question is if the U.S. and EU will coordinate orbit slots so the 12 x GPS and 12 x Galileo satellites are in a somewhat optimal 24-slot constellation instead of an uncoordinated configuration. The civil economic benefit from taking advantage of L5 as soon as possible would be substantial. Just this week, the EU issued a report stating that 6-7% of the GDP of EU countries is dependent on satellite navigation. Better accuracy enabled by L1/L5 will spur a mind-boggling number of new applications that will further broaden the GNSS user base and economic impact. It would also stimulate GNSS receiver development from a much broader range of GNSS receiver designers than we see today.
With a combined GPS/Galileo constellation, not only will accuracy become cheaper, but availability will increase significantly. The new GPS 24+ 3 configuration is certainly a big help for high precision users with respect to availability. Can you imagine how much precise positioning availability will improve when 18 Galileo satellites (not to mention 30) are added to the mix? Last summer, the EU-U.S. Cooperation on Satellite Navigation Working Group C published a report entitled “Combined Performance for Open GPS/Galileo Receivers.” The report succinctly draws the following conclusion, with which I wholeheartedly agree:
“The studies demonstrate and quantify the improvements that can be expected when using GPS and Galileo open services in combination under different environmental conditions. In all studied cases, the combination of GPS and Galileo led to noteworthy performance improvements as compared to single system performance. The most significant improvement is for partially obscured environments, where buildings, trees or terrain block portions of the sky. The increased number of satellites available provides robust performance even as some signals are blocked, which is reflected in a significant increase of positioning accuracy and availability.”
Following are some data from the report that back up the conclusions on availability.
Availability with a 15° elevation mask
GPS only – 99.10%
Galileo only – 100%
GPS/Galileo – 100%
Availability with a 30° degree elevation mask
GPS only – 57.28%
Galileo only – 75.02%
GPS/Galileo – 98.93%
Granted, you should take these numbers with a grain of salt. These are based on positioning with four satellites in view. The reality is that for high precision users, we need data from at least six satellites for robust positioning. But, I think the scale of improvement when going to GPS/Galileo constellation is obvious and will scale similarly when considering six satellite positioning.
For all the reasons above, I’m putting my stamp on 2011 as being The Year of Galileo. Look forward to further coverage on Galileo in the coming months.
Eric Gakstatter, Editor, Geospatial Solutions and Survey Scene newsletter &
Dr. Mike Whitehead, VP of Technology at Hemisphere GPS
Event Date: 01/26/2011 10:00 AM Pacific Standard Time, 5 PM GMT
Tens of thousands of users around the world utilize GPS/GNSS receivers for mapping, surveying and navigating. Since autonomous GPS/GNSS typically does not provide the needed accuracy, users must rely on a source of GPS/GNSS corrections. There are three sources of GPS/GNSS corrections available to users who desire reliable GPS/GNSS accuracy in the sub-meter to three meter range: SBAS, DGPS and post-processing. Dr. Michael Whitehead, Chief Scientist at Hemisphere GPS, will join me in presenting a background on the three technologies as well as the strengths and weaknesses of each. I’ve known Mike for a number of years. He was an early innovator in the development of SBAS technology at Satloc as well as SBAS and DGPS receiver technology at Hemisphere GPS. He is one of the leading GNSS engineers in the world. I’m particularly excited about this event and promise a lively discussion that’s full of useful information, data and concepts that anyone using or considering using GPS/GNSS for mapping, surveying or navigating will find useful.
Look back with me at the five 2010 GNSS events that most affected surveying, mapping, engineering, construction, and natural resource users. Each one had, or could have had, a significant effect on you and your work. Taking it from the top:
GPS 24+3 Constellation. The most important event occurred a year ago, when the Air Force began implementing a new GPS 24+3 configuration. They had their military reasons, but the benefit for you and me is eliminating GPS brownouts — periods with fewer GPS satellites in view. When combined with obstructions such as terrain, trees, or buildings, they made GPS hard to use.
It’s especially an issue with real-time kinematic (RTK) high-precision users because RTK technology is satellite-hungry. It needs six or more satellites to provide a robust position solution.
The Air Force moved three satellites, SVNs 24, 26 and 30, from their original slots. SVNs 26 and 30 have already reached their destinations, and SVN 24 will do so this month.
Three other satellites are being shifted slightly. SVN 55 found its new slot in December, while SVNs 46 and 56 start this month and should have completed their journeys by May/June 2011.
By now, you should be seeing some improvements in GPS satellite visibility. Although you’ll see fewer peaks (high number of GPS satellites in view), you’ll also see fewer valleys (low number of GPS satellites in view). This should increase productivity for RTK users and those in obstructed environments such as tree canopy.
First GPS Block IIF. Although it doesn’t really help users at this point other than being another satellite to enter service, the Block IIF satellite launched in May is the first to broadcast the third civil signal. L5 marks the beginning of a new era in high-precision GPS positioning. The Block IIF launch was the catalyst for my June column “What Happen When High Accuracy is Cheap?”
This IIF is just a teaser though, and its fellows will launch at a snail’s pace. Remember though, it costs upwards of $200 million to launch a satellite and since there ares already 30+ operational GPS satellites in orbit, it’s hard for Congress and the Air Force to justify speeding up the launch schedule. The last target I heard was to have 24 satellites broadcasting L5 by 2019.
GLONASS Growth. Despite the recent catastrophe, the Russian Federation was still able to launch seven new satellites in 2010, including a new K1 satellite that will test a new CDMA signal for better compatibility with GPS.With 21 operational satellites and three more coming in March, a consistent and healthy number of GLONASS satellites in orbit has given receiver manufacturers more confidence to develop GPS/GLONASS receivers. This year, we’ve seen several manufacturers integrating GPS/GLONASS into handheld receivers as well as OEM board products.
User benefits are clear: more robust positioning and improved productivity due to decreased down-time.
Solar Activity. The big news is no news: the sun was eerily quiet in 2010. If your GPS receiver didn’t work at times this year, it wasn’t due to solar activity. But it may ramp up in 2011.
GAGAN, WAAS Failures. The Indian Space Research Organisation and the U.S. Federal Aviation Administration received a hard lesson in SBAS GEO management. In April, an Indian rocket launch failed, and one of the FAA WAAS satellites lost communication with its ground control.
If you’re an SBAS user, don’t let it bring you down. SBAS is here to stay, and likely you were not affected by either incident — unless you work in northwest Alaska. A new U.S. SBAS satellite came online, and India is regrouping for more launches.
Shelton Space Commander
Des Dorides for European GNSS Supervisory Agency
