Tag: constellation outage

  • The System: GLONASS in April, What Went Wrong

    The System: GLONASS in April, What Went Wrong

    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).

    Figure 1. Affected broadcast messages for each GLONASS satellite. Colors indicate the different orbit planes.
    Figure 1. Affected broadcast messages for each GLONASS satellite. Colors indicate the different orbit planes.

    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.

    Detailed Analysis

    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. Rotation of the entire system of good orbit positions (April 1, 0:00 – 20:45 UTC) with respect to precise IGS reference orbits (“good” BM) and rotation of the entire system of bad orbit positions (April 1, 21:00 – April 2, 07:00 UTC) with respect to precise IGS reference orbits (“bad” BM).
    Table 1. Rotation of the entire system of good orbit positions (April 1, 0:00 – 20:45 UTC) with respect to precise IGS reference orbits (“good” BM) and rotation of the entire system of bad orbit positions (April 1, 21:00 – April 2, 07:00 UTC) with respect to precise IGS reference orbits (“bad” BM).

    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://stage.globalpositioningnews.com/tag/russian-monitoring-stations/.

    Russian Launch

    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.

    GLONASS-launch-O

    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.

  • Disruption in Australia Traced to User Equipment

    User equipment incorrectly interpreting data from a satellite set “unhealthy” led to an apparent constellation outage for roughly 1,000 fleet vehicles across Australia in April. The problem was traced to the way a GPS/telecomm chip reacted to an extended navigation test aboard SVN-49, having to do with the recently launched IIF satellite, SVN-64.

    Although SVN-49 was set unhealthy at the time, the integrator-equipped fleet vehicles across the continent experienced periods of several hours without satellite visibility, in unobscured environments.

    The U.S. Air Force GPS Operations Center reported that in mid-May tests, “PRN 30 [was] broadcasting almanac datasets that do not reflect constellation changes that occurred since it was last uploaded with navigation message data.  [. . . ] The utilization of these almanacs in a manner that regards the time of week, but neglects or mishandles the week number (effectively executing as if the current week number is the week number associated with these almanac parameters), will result in an increasing error in visibility determination and other almanac based estimations (elevation/azimuth, Doppler shift, SV clock offset from GPS time, etc) as the dataset’s actual week offset from the current week increases.”

    The situation occurred once previously,  in 2011 with Mercedes in Europe. The problem was traced to chips from the same manufacturer, installed by the car-maker’s integrator partner, also misinterpreting data from a satellite set unhealthy while broadcasting system test data.

  • The System: GLONASS Fumbles Forward

    The System: GLONASS Fumbles Forward

    GLONASS PLOT from the Roscosmos GLONASS Information-Analytical Centre, showing the 12-hour outage, with full service eventually restored on April 2.
    GLONASS PLOT from the Roscosmos GLONASS Information-Analytical Centre, showing the 12-hour outage, with full service eventually restored on April 2.

    Two April Disruptions Furnish Fodder for Multi-GNSS Receivers and Alternative PNT

    In an unprecedented total disruption of a fully operational GNSS constellation, all satellites in the Russian GLONASS broadcast corrupt information for 11 hours, from just past midnight until noon Russian time (UTC+4) on April 2 (or 5 p.m. on April 1 to 4  a.m. April 2, U.S. Eastern time). This rendered the system completely unusable to all worldwide GLONASS receivers. Full service was subsequently restored.

    “Bad ephemerides were uploaded to satellites. Those bad ephemerides became active at 1:00 a.m. Moscow time,” reported one knowledgeable source. GLONASS navigation messages contain, as they do for every GNSS in orbit, ephemeris data used to calculate the position of each satellite in orbit, and information about the time and status of the entire satellite constellation (almanac); user receivers on the ground processed this data to compute their precise position.

    The GLONASS fix could not take effect until each satellite in turn could be reset, during its pass over control stations in Russian territory, in the Northern Hemisphere, thus taking nearly 12 hours.

    During the outage, CEO Neil Vancans of Altus Positioning Systems reported “We are currently experiencing calls from customers all over the world who are experiencing GLONASS ‘outages’ and we have advised customers to switch GLONASS tracking off on our receivers.”

    Such a — possibly human, possibly computer-generated — error could conceivably occur with GPS, Galileo, or BeiDou. “Another reason to have backups,” mused Richard Langley of the University of New Brunswick. “And not just other GNSS.”

    Trouble Chronolog. The constellation suffered a second failure two weeks later. On April 14, eight GLONASS satellites were simultaneously set unhealthy for about half an hour, meaning that most GLONASS or multi-constellation receivers would have ignored those satellites in positioning computations. In addition, one other satellite in the fleet was out of commission undergoing maintenance. This might have left too few healthy satellites to compute GLONASS-only receiver positions in some locations.

    The two blackouts followed two other high-profile disasters: the destruction-upon-launch of three new GLONASS satellites in July 2013, and the Pacific drowning-upon-launch of three satellites in December 2010.

    Internal Dialog. The semi-official Russian news daily Izvestia (“Truth”) reported that the loss of service was inconsequential for Russian users. Loose translation courtesy of Google:

    “Temporary GLONASS failure has not led to tangible consequences for consumers of services because chip manufacturing exclusively with GLONASS for the mass market is practically nil: there are chips that work only with the GPS signals, and there are those that see both GPS and GLONASS.”

    In other words, there are practically no mass-market devices, even in Russia, that use exclusively GLONASS.

    “In any case, the failure of the entire system for a long period is a serious blow to the image of GLONASS, especially in a situation where Russia has made efforts to promote domestic navigation system to external markets. Plus in 2012, the Russian government officially promised to maintain the characteristics of the international community GLONASS at the proper level for 15 years.”

    Industry View, Multi-GNSS. During the first outage, chip company Broadcom was conicidentally conducting multi-constellation receiver tests in Asia. Frank van Diggelen, the company’s chief GNSS scientist, stated, “We have definitive data to show how a multi-constellation receiver survives such an outage. Test data coincident with the GLONASS ephemeris disruption show how a GPS/GLONASS/QZSS/BeiDou receiver survives the complete disruption of one of the constellations.”

    A Broadcom 47531receiver tracking GPS/GLONASS/QZSS/BeiDou signals simultaneously and using logic to analyze redundant measurements to check the validity of all measurements successfully identified and removed the bad GLONASS ephemeris, maintaining position continuity and accuracy. Another receiver under test at the same time, tracking only GPS and GLONASS, wandered significantly in its position reports.

    Industry View, Back Up PNT. Calling it an “unprecedented and deeply worrying total disruption…[that] shook the industry,” Locata Corporation reiterated its call for redundant terrestrial systems to back up GNSS in the wake of the outage.

    Nunzio Gambale, Locata CEO, said “We have been telling the industry for years that you cannot have a critically important capability like GPS without also having a backup! What is Plan B if the satellite systems fail? What replaces the space signal when there is a problem? This event should terrify every nation, government, and company that depends on navigation satellites for their business or, in some cases, their very lives.”

    GNSS navigation and timing functions underpin the world’s banking systems, stock exchanges, digital TV and Internet, cell-phone networks, and, in some cases, the national electricity supply, Locata pointed out. GPS, in particular, plays a crucial role in transportation, shipping, and logistics, serving as the enabling technology for critical functions like air traffic control. Reliability is therefore not just important; it is essential across all applications.

    “We ignore the possibility of these ‘Black Swan’ events at our own peril,” added Chris Rizos of the University of New South Wales.

    eLoran Authorization in Progress

    Russia’s April 1 GLONASS blackout occurred, ironically, only hours after the U.S. House of Representatives passed legislation to preserve infrastructure that could support a backup system for GPS that could be used for critical infrastructure and applications in the event of a similar disaster occurring in the United States.

    The 2014 Coast Guard Authorization Act requires the Department of Homeland Security (DHS) to halt dismantling and disposal of infrastructure that could be used for a terrestrial system during times and in places where GPS is not available.

    DHS had announced in 2008 that it would build such a backup system, but it never did so, and actually began dismantling, destroying, and divesting itself of Loran equipment and properties. The equipment, facilities, and sites could be used to implement a new generation eLoran system for GPS backup, among other applications. Despite strong recommendations to the contrary by its own panel of experts, the Obama administration, DHS, and the Coast Guard moved in 2009 to kill the Loran program.

    Watchdogs. Congress has lately become more visibly concerned about the vulnerability of the nation’s space systems. The 2014 National Defense Authorization Act tasked the administration with reporting on how it was going to provide necessary national security capabilities when space systems were disrupted. More recently, Congressmen Duncan Hunter (Republican, California), chair of the House Coast Guard and Marine Transportation Subcommittee, held a hearing at which he expressed his concern that the nation has no backup for GPS. He also expressed his frustration with the Department of Homeland Security, reporting that “They said they need to do a study about their study.”

    Congressman John Garamendi (Democrat, California), commented “GPS will go down one day. The question is, is there a backup?”

    The legislation passed by the House authorizes DHS to partner with public or private entities to build a system that would not only back up GPS, but also work indoors, underground and underwater — all characteristics of long-wave Loran technology.

    Resilient PNT. Dana Goward, president of the Resilient Navigation and Timing Foundation, said such a project would be relatively inexpensive. “If the existing equipment and infrastructure are preserved and reused, the system could be restored and put into operation for less than half the cost to dispose of it.”

    “It isn’t an issue of money,” Goward continued. “It is a question of the government taking this problem seriously and acting on it.”

    The foundation has as offered to partner with the government to build the system.

    “Our government has known about this issue for a long time,” Goward said. “At least since 2001. And there has been a standing presidential direction to obtain backup capability since 2004. But for some reason, it hasn’t yet happened.”

    The government’s official website about GPS (www.gps.gov) has recently updated its page on eLoran and Loran-C with a tracking log for Coast Guard and Maritime Transportation Act of 2014, which now goes to the Senate.

    IRNSS’s Second of Seven

    India’s Space Research Organisation launched a navigation satellite on April 4. IRNSS-1B is the second of seven that will comprise the first-generation Indian Regional Navigation Satellite System (IRNSS). It joins IRNSS-1A, already in orbit.

    IRNSS will consist of three geostationary satellites and two pairs in inclined geosynchronous orbits. Each IRNSS satellite uses a rubidium-based atomic clock to keep time, transmitting signals on L and S-band frequencies at 1176.45 and 2492.028 megahertz respectively.

    Lag in Recent GPS IIF’s Health Status

    By Richard Langley

    The GPS Block IIF satellite, IIF-5 or SVN64 (PRN30), launched on February 21, had not as of press time been set healthy. Typically, GPS satellites are checked out and made operational within about a month after launch.

    The delay is due to an extended navigation test being performed by the GPS master control station. A navigation upload for SVN64 was performed in March with ephemeris and clock data as usual streching weeks in advance. However, unlike with operational satellites, no further updated uploads have been performed. The aging ephermis and clock data gradually becomes less and less accurate as time goes by, but should degrade gracefully.

    Some observers will have noticed that the received navigation data from SNV64 changes infrequently. Currently, the navigation data changes once per day with an epoch of 13:00 GPS Time, unlike every two hours with operational satellites. And the data fit interval is 26 hours, compared to four hours.

    The test is scheduled to run until mid-May.

     

  • Faulty Software Determined Cause of GLONASS Failures

    The two April failures in Russia’s GLONASS were caused by mathematical mistakes in software, according to Oleg Ostapenko, head of the Russian space agency Roscosmos.

    Russian newspaper Ria Novosti reported on a press conference where Ostapenko said that programmers who had designed the satellites’ new software had made several mathematical mistakes, but the problem was not major and has practically been solved. “There were some mathematical mistakes, but they have been corrected,” he said.

    Ostapenko said that the remaining problems would be solved by mid-May, and there is almost no chance of a similar failure happening in the future.

  • GLONASS Failure Inconsequential to Users, Says Russian Press

    Reports in the semi-official Russian news daily Izvestia indicate that finger-pointing has gotten underway regarding the April 1 GLONASS systemic blackout, which followed two other high-profile disasters, the destruction-upon-launch of three new GLONASS satellites in July 2013, and the Pacific drowning of three other satellites in December 2010.

    While we have neither full nor fluent translations from the Russian, we have done the best we can, aided and abetted by Google, with the following passages.

    “Temporary GLONASS failure has not led to tangible consequences for consumers of services for the reason that chip manufacturing exclusively GLONASS, the mass market is practically no: there are chips that work only with the signal GPS, and there are those that see both systems GPS and GLONASS.”

    Clarification: there are practically no mass-market devices, even in Russia, that use exclusively GLONASS.

    “In any case, the failure of the entire system for a long period a serious blow to the image of GLONASS, especially in a situation where Russia has made efforts to promote domestic navigation system to external markets. Plus in 2012, the Russian government officially promised to maintain the characteristics of the international community GLONASS at the proper level for 15 years.

    “The following statement was distributed at the XII International Forum ICAO Air Navigation in Montreal by the Head of the non-governmental organization ‘Promoting the development and use of navigation technologies.’ Alexander Gurko believes that now GLONASS is not controlled properly, causing increased risks of such failures.

    “There should be a system operator who is responsible for the quality of its operation, development and use, Gurko said. GLONASS still not officially put into operation, although it was promised two years ago and settled in many protocols, the Interagency Working Group. But it is still unclear who is responsible for the general quality of service.

    “GLONASS system is not commissioned by the Ministry of Defence and officially still under development.

    “Where to users with questions and explanations about the operation or development of the system? Asks questions Gourko. The Defense Ministry, Roscosmos? How are civil user requirements and market trends in the formation positioning system development plans?”

    Izvestia further notes that in March of this year, the Russian government cut the GLONASS budget by 16 billion rubles ($450 million). “Signal quality and composition of the orbital constellation sequestration will not affect, say Roscosmos. It is important to reduce not touched the ground part, experts say.”

  • GLONASS Blackout Coincides with Loran Authorization-in-Progress

    Russia’s April 1 GLONASS blackout occurred, ironically, only hours after the U.S. House of Representatives passed legislation to preserve infrastructure that could support a back-up system for GPS that could be used for critical infrastructure and applications in the event of a similar disaster occurring in the United States.

    The 2014 Coast Guard Authorization Act requires the Department of Homeland Security (DHS) to halt dismantling and disposal of infrastructure that could be used for a terrestrial system during times and in places where GPS is not available.

    DHS had announced in 2008 that it would build such a back-up system, but it never did so, and actually began dismantling, destroying, and divesting itself of Loran equipment and properties. The equipment, facilities, and sites could be used to implement a new-generation eLoran system for GPS back-up, among other applications. Despite strong recommendations to the contrary by its own panel of experts, the Obama administration, DHS, and the Coast Guard moved in 2009 to kill the Loran program.

    Ever watchful, Congress has lately become more visibly concerned about the vulnerability of the nation’s space systems. The 2014 National Defense Authorization Act tasked the administration with reporting on how it was going to provide necessary national security capabilities when space systems were disrupted. More recently, Congressmen Duncan Hunter (Republican, California), chair of the House Coast Guard and Marine Transportation Subcommittee, held a hearing at which he expressed his concern that the nation has no back-up for GPS. He also expressed his frustration with the Department of Homeland Security, reporting that “They said they need to do a study about their study.”

    Congressman John Garamendi (Democrat, California), commented “GPS will go down one day. The question is, is there a backup?”

    The legislation passed by the House authorizes DHS to partner with public or private entities to build a system that would not only backup GPS, but also work indoors, underground and underwater — all characteristics of long-wave Loran technology.

    Dana Goward, president of the Resilient Navigation and Timing Foundation, said such a project would be relatively inexpensive. “If the existing equipment and infrastructure are preserved and reused, the system could be restored and put into operation for less than half the cost to dispose of it.”

    “It isn’t an issue of money,” Goward continued. “It is a question of the government taking this problem seriously and acting on it.”

    The foundation has as offered to partner with the government to build the system.

    “Our government has known about this issue for a long time,” Goward said. “At least since 2001. And there has been a standing presidential direction to obtain back-up capability since 2004. But for some reason, it hasn’t yet happened.”

    The U.S. government’s official information website about GPS has recently updated its page on eLoran and Loran-C with a tracking log for Coast Guard and Maritime Transportation Act of 2014, which now goes to the Senate.

  • How to Survive a Total Constellation Outage

    How to Survive a Total Constellation Outage

    Yesterday we posted news of an 11-hour downtime for the full GLONASS constellation, due to an upload of bad ephemerides. Coincidentally, during that 11-hour period, the mass-market chip company Broadcom was conducting multi-constellation receiver tests in Asia. Frank van Diggelen, Broadcom’s chief GNSS scientist and vice president says, “We have definitive data to show how a multi-constellation receiver survives such an outage.”

    Here are the pictures, and the story they tell.

    Test data coincident with the GLONASS ephemeris disruption of April 1 and 2 showing conclusively how a GPS/GLONASS/QZSS/BEIDOU receiver survives the complete disruption of one of the constellations.

    On April 2 at 1:00 a.m. Moscow time, bad ephemeris was uploaded to all satellites (see chart at the bottom of this story).

    There are two receivers shown here, from two different manufacturers, both in smartphones. The yellow dots are for a GPS/GLONASS receiver; the blue dots are from the Broadcom 47531 receiver which tracks GPS/GLONASS/QZSS/BeiDou signals simultaneously. The 47531 receiver includes logic to use redundant measurements to check the validity of all measurements. It successfully identified and removed the bad GLONASS ephemeris 100 percent of the time, as can be seen by the continuity and accuracy of the positions.

    Broadcom2

    Here is the satellite outage chart from yesterday’s story.  All GLONASS satellites were restored to healthy state after the 11-hour interruption.

    Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.
    Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.

     

     

  • GLONASS Gone . . . Then Back

    GLONASS Gone . . . Then Back

    In an unprecedented total disruption of a fully operational GNSS constellation, all satellites in the Russian GLONASS broadcast corrupt information for 11 hours, from just past midnight until noon Russian time (UTC+4), on April 2 (or 5 p.m. on April 1 to 4 a.m. April 2, U.S. Eastern time). This rendered the system completely unusable to all worldwide GLONASS receivers. Full and correct service has now been restored.

    “Bad ephemerides were uploaded to satellites. Those bad ephemerides became active at 1:00 am Moscow time,” reported one knowledgeable source. For every GNSS in orbit, the navigation messages include ephemeris data, used to calculate the position of each satellite in orbit, and information about the time and status of the entire satellite constellation (almanac); this data is processed by user receivers on the ground to compute their precise position.

    According to another source, a GLONASS fix could not take effect until each satellite in turn passed back over  control stations in the Northern Hemisphere to be reset, thus taking nearly 12 hours.

    During the outage, CEO Neil Vancans of Altus Positioning Systems reported “We are currently experiencing calls from customers all over the world who are experiencing GLONASS ‘outages’ and we have advised customers to switch GLONASS tracking off on our receivers. We don’t have any better information on when normal service is likely to resume from GLONASS satellites. If you do, let me know!”

    Such a — possibly human, possibly computer-generated — error could conceivably occur with GPS, Galileo, or BeiDou. “Another reason to have backups,” mused Richard Langley of the University of New Brunswick. “And not just other GNSS.”

    A recent plot shows all satellites restored to normal service:

    Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.
    Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.

     

     

  • GLONASS 743 Set Healthy, Constellation Back to Full Strength

    News courtesy of CANSPACE Listserv.

    GLONASS 743, recently moved from orbital slot 2 to orbital slot 8, was set healthy on March 5 at 07:28 Moscow Time according to NAGU 017-130305. Although the NAGU states that Moscow Time is three hours ahead of UTC (and this is the time difference normally used for GLONASS as stipulated in the GLONASS ICD), officially, it is actually four hours and has been since the switch to year-round daylight saving time on 27 March 2011. In this case, the NAGU appears to be in error since GLONASS 743 was actually set healthy at 03:28 UTC and not at 04:28 UTC. This is confirmed by Roscomos monitoring and by the navigation data collected by stations of the International GNSS Service (IGS).

    There are once again 24 healthy GLONASS satellites on orbit.

    For those keeping track of frequency channel changes, GLONASS 743 was switched from frequency channel 6 to channel -6 on 1 March some minutes before 10:45 UTC and back to channel 6 on 2 March, again some minutes before 10:45 UTC as determined from IGS navigation files. Although a NAGU was issued for the first frequency change (stating that it occurred at “1344 MT (UTC+0300)”), no NAGU has been issued to document the second frequency shift although the set-healthy NAGU does give the frequency channel as 6.

    Meanwhile, in other GLONASS news, a single GLONASS-M satellite (Block 47s) is to be launched from the Plesetsk Cosmodrome on April 26 at 05:23:41 UTC according to the NASA Forum blog.