By Gerhard Beutler, Rolf Dach, Urs Hugentobler, Oliver Montenbruck, Georg Weber, and Elmar Brockmann
What Happened: On April 1, 2014, at 21:15 UTC, all GLONASS satellites started to transmit wrong Broadcast Messages (BM) as previously reported by GPS World. The satellite positions derived from these BM were wrong by up to ± 200 kilometers in each of the three coordinates x, y, and z of the Earth-fixed, geocentric, equatorial coordinate system. The problem disappeared after an hour (after two erroneous BM) for two GLONASS satellites; for other satellites, the problem lasted much longer: up to 10 hours. By about 07:30 UTC on April 2, the April Fools’ “joke” was over.
Effect on GPS/GLONASS Receivers
Essentially, we can distinguish two classes of receivers: those using the GLONASS BM for tracking and those not using them. The first class of receivers “became aware” of problems in real time, because GPS and GLONASS observations did not result in a consistent position estimation. In the best case, all affected GLONASS observations were flagged (and removed from further consideration) and the positioning worked properly with a reduced number of satellites. In the worst case, the receivers stopped tracking GPS and GLONASS satellites completely. The second class of receivers tracked GPS and GLONASS normally. The tracking problems created a major uproar in the user community of combined GPS and GLONASS receivers.
On June 3, 2014, at the 13th meeting of the U.S. National Space-based Positioning, Navigation, and Timing (PNT) Advisory Board, Gerhard Beutler, representing the authors of this article, delivered a presentation including an example of a permanent network of GPS and GLONASS dual-system receivers in Switzerland and neighboring countries, where about 40 percent of the approximately 60 receivers stopped tracking both GLONASS and GPS satellites. The malfunctioning receivers had to be reset manually on the morning of April 2 (for more information, see: www.gps.gov/governance/advisory/meetings/2014-06/beutler1.pdf).
Event as Viewed by the IGS
At first sight, the GLONASS April 1 and 2 event was actually a non-event for the International GNSS Service (IGS). The IGS is a voluntary federation of more than 200 worldwide agencies that pool resources and data from about 400 permanent GPS and GLONASS stations to generate precise GPS and GLONASS products.
The IGS product series, including precise GPS and GLONASS ephemerides, were generated as usual before, during, and after the event. On April 4, a quick analysis by Urs Hugentobler revealed that only the GLONASS BM were affected; the GLONASS code (pseudorange) and phase observations and the GLONASS satellite clock corrections, were not affected.
Figure 1 shows that the GLONASS event started simultaneously for all satellites (for stationary receivers, the first wrong positions were calculated for 21:00 UTC, based on the BM with Time of Clock (ToC) at 21:15 UTC). The problem was fixed for the first two satellites (the GLONASS satellites in orbital slots 6 and 23) one hour later; the last satellite wasn’t fixed until 07:30 on April 2 (using the correct BM at 07:45).
More than 60 percent of the more than 200 combined GPS and GLONASS receivers in the IGS network tracked the GLONASS satellites normally. Fewer than 40 percent of the combined-constellation receivers had serious data outages (for GLONASS or even for both GLONASS and GPS). The number of GLONASS observations used in the daily work of the IGS analysis centers (ACs) was, however, only reduced by about 10 percent on April 2 (and even to a lesser extent on April 1). The small reduction is explained by the fact that only the last three and the first seven hours of April 1 and 2, respectively, were affected.
As the IGS ACs do not need the BM (neither for GPS nor for GLONASS), but may rather use their predicted orbits derived from the precise ephemerides of the preceding days, the number of good observations was still amply sufficient to calculate precise GLONASS orbits for April 1 and 2, essentially at the expected accuracy level.
To further explore the structure of the problem, the BM-derived satellite positions were used as pseudo-observations in an orbit determination process. Orbit determination was successful when analyzing only “good” positions (prior to April 1, 21:00 or after April 2, 07:30). Orbit determination was successful, as well, when using only positions from “bad” BM. Successful means that the root-mean-square (RMS) error of the orbit determination process was of the order of about 0.5 meters per satellite coordinate — the expected order of magnitude.
As the bad satellite positions are now known to obey the laws of orbital motion, one may further investigate the nature of the differences between the “good” and the “bad” orbital positions. For that purpose, the precise GLONASS orbits of the IGS Center for Orbit Determination in Europe Analysis Center served as a reference. Its orbital positions were compared in the inertial coordinate system (one not rotating with the Earth) to the erroneous BM-derived positions by means of an orthogonal transformation, where only the three rotation angles around the x-, y-, and z-axes of the inertial equatorial coordinate system were estimated.
Table 1 shows that the positions derived from the normal (“good”) GLONASS BM compare very well to the IGS precise orbits. Except for a minor rotation about the z-axis, one obtains zero-rotations about the orthogonal axes in the inertial coordinate system.
Table 1 also shows that the “bad” positions were obtained from the reference positions by a rotation of about 0.5 degrees around the inertial x-axis. The RMS of 71 meters should be compared to the entire effect of up to 200 kilometers per coordinate. Comparing this RMS of 71 meters with the RMS of the orbit determination of about 0.5 meters per coordinate also says, however, that the “true” transformation is more complicated than one represented by just a series of three rotations.
We did not further investigate how this more or less consistent rotation could enter into the GLONASS BM. It seems to be clear, however, that a systematic error slipped into the realization of the GLONASS BM, which were activated at a common reference epoch for all satellites (but uploaded to individual satellites at different times).
Figure 1 suggests that the problem was almost immediately recognized by GLONASS operators: already an hour later the first two satellites started to transmit BM with the usual accuracy level.
Figure 1 also supports the idea that the problem was remedied satellite-by-satellite. A back-of-the envelope calculation revealed that the satellites were above the horizon of at least one of the Russian uplink sites at the times of switching back to the correct BM.
Summary and Conclusions
The GLONASS event was one that we might have described by the phrase “such a thing can never happen.” For the user community, the situation was aggravated by the fact that the event was not reported through the official Russian channel by issuing a Notice Advisory to GLONASS Users (NAGU). This definitely should have happened in the interest of transparency.
The above analysis was based on information available through the IGS. It was performed weeks after the event. It is worth noting, however, that the information needed for the analysis was available in real time. The reference orbit used in the analyses could have been replaced by the IGS predicted orbits generated in the ultra-rapid series.
In view of the importance of BM for all users and in particular for the users of IGS real-time products, the IGS might consider monitoring the quality of BM for all GNSS.
Fixing the GLONASS Bug: Report from Moscow
In a May 23 conversation with journalists, Javad Ashjaee, president of JAVAD GNSS, decried the recent controversy about monitoring stations on both U.S. and Russian soil, saying it was based in misinformation and misinterpretations, inflated by a political crisis. He also supplied a different perspective on the GLONASS signal outage than has been reported in other media outlets.
“There was speculation in early April that it took GLONASS 11 hours to correct a software bug because it took that long for all the satellites to pass over a control station on Russian soil. This was not the case, I have learned from conversations with their engineers and with the head person responsible for all of this. One engineer made a mistake and uploaded the wrong software. Until they could find it and debug it — and it took them 11 hours to do so — they could not upload correct software to the satellites.
“The 11-hour outage was not due to a wait for all satellites to pass over ground control stations on Russian soil to receive a fresh upload of data,” continued Ashjaee. “GLONASS has the capability, like GPS, to make updates via inter-satellite communication. The delay was caused by the time it took to find the bug in the erroneous software that had been uploaded and correct it.”
Ashjaee addressed the monitoring station controversy, saying that Russia had sought GLONASS monitoring stations in the United States, not for uploading any data, but for monitoring GLONASS satellites to provide more accurate orbit and clock information, for the free benefit of all users.
Click here for Ashjaee’s full discussion of the U.S.–Russian monitoring station controversy. For news updates on the situation, see http://gpsworld.com/tag/russian-monitoring-stations/.
A single GLONASS-M satellite was launched from the Plesetsk Cosmodrome on June 14. GLONASS-M 55 (with designation 755 once operational and also known as Kosmos 2500), was inserted into the constellation’s Plane 3 and will occupy orbital slot 21.
Manufacturer Reshetnev reported that the satellite is equipped with an experimental payload capable of transmitting signals in the L3 frequency band. The L3 signal, centered at 1202.025 MHz , is CDMA unlike the GLONASS legacy FDMA signals. The experiment will include flight testing of the new equipment and evaluation of its accuracy characteristics. The GLONASS-K1 test satellite also transmits an L3 signal.
European Space Symposium: Digest
Copernicus, “the younger brother of Galileo,” will be the main implementation of Galileo and other GNSS technologies going forward in Europe, according to to Paul Weissenberg, EC deputy director general for enterprise and industry. An Earth-observation satellite program administered by the European Space Agency to provide accurate and timely information to improve the management of the environment, understand and mitigate the effects of climate change, and ensure civil security, Copernicus was previously known as the Global Monitoring for Environment and Security (GMES).
Sliding to the Right. Galileo will make its “early-service declaration in the first half of next year,” said Matthias Patschke, director of EU satnav programs. This appears to back off slightly from previous dogged determination to declare services before the end of 2014.
The EC may propose legislation to make mandatory the use of GNSS technology in different areas: as with eCall, starting in 2015, including Galileo in the receivers inside cars, according to Marian-Jean Marinescu, member of the European Parliament.
Peter Large of Trimble spoke out against the mandating of a specific GNSS use in any market: “A bad policy outcome that moves backward into regionalization.”
For an expanded report, see the June GNSS Design & Test e-newsletter.