GPS Satellite goes offline

[Dave]

On January 1st, a number of people reported problems with their GPS Receivers around the time of 18:00 to 23:00 GMT. At first it seemed a little strange, and not all were receiving problems. Mostly European countries, UK and Germany saw huge differences in altitude readings being in the thousands when realistically people were at sea level or at 90 meters above sea level. Others also reported problems with location where there position was suddenly reported 10km away.

After careful examination of the GPS Satellites and after many complaints, the GPS Support Center for Military and Civilians at Schriever Air Force Base in Colorado found a problem with Satellite SVN23/PRN23 which went off air due to a problem on the satellite. This has been reported at http://www.schriever.af.mil/GpsSupportCenter/advisories.htm

So if you experienced problems on January 1st, now you know why!

[andygrove]

That explains a huge amount. I was driving home from surrey just after 6pm, apparently in the middle of a dense wood, even though I knew perfectly well I was on a road!!

Andy

[DavidW]

The information at http://earth-info.nima.mil/GandG/sathtml/satinfo.html confirms that the in-use atomic clock on SVN23/PRN23 failed. It's unusable until further notice (ref. NANU 2004001 - see http://www.navcen.uscg.gov/ado/GpsActiveNanu.asp). Information at the first of those two sites indicates it's been swapped to another clock - so it'll be tested and marked healthy again in the almanac if it passes the tests.

If it fails the tests, it could land up being decommissioned; that means that the GPS payload is shut down and the satellite is, I believe, thrusted further away from the earth into a disposal orbit (to get it out of the way of new, working GPS satellites). Eventually the decommissioned satellite is permanently deleted from the GPS almanac so that GPS receivers no longer know anything about it.


SVN23/PRN23 is a satellite believed to be nearing end of life (three of the current GPS constellation are marked as such in the public listings), which is presumably one reason why the pace of new satellite launches is picking up after a slacker period. There's one new GPS satellite that launched in December that is not yet commissioned, and four more due to be launched in 2004.

That said, my understanding of the GPS planes is that the four satellites in each of the six planes are required for a full service. For optimal geometry, I believe a working satellite in each of the main 1 to 4 positions in each of the six A to F planes is what's wanted (think six circles around the earth, each with four equally spaced satellites orbiting in it - I can't lay my hands on exact orbital details, but that's certainly a good approximation). Six multiplied by four gives 24 satellites. Because those positions are equally spaced, no more than half can be above the horizon at any location, hence many of our GPS receivers have 12 channels. However, there's some working spares, so it's possible to have more than 12 satellites sufficiently far above the horizon to receive usable data from (a satellite barely over the horizon will be masked out by your GPS receiver - typically a satellite has to be something like 7.5 degrees above the horizon before a GPS receiver will use it as part of the positioning solution). The actual limit for GPS is 32 (or possibly 31) active satellites.

Looking through those 24 main positions, apart from D1 (filled by SVN24/PRN24 which has no spare clocks), E2 (which is the new SVN47/PRN22 satellite that's not yet part of the public GPS service) and F4 (filled by SVN32/PRN01 which has no spare clocks), there doesn't appear to be significant concern about the other satellites.

In the D plane, there's two of the three "believed nearing end of life" satellites at D5 and D6. The E plane should be at full strength within a fortnight, assuming the new satellite is OK - and there's the third of the "believed nearing end of life" satellites at E5. The F plane has an extra satellite at F5 already.

In other words, if my understanding is correct, there are some GPS satellites up there about which there are some concerns, but there's no imminent danger of significant GPS outage assuming nothing fails unexpectedly.

It seems that what happens is that satellites relegated to a secondary role are moved to an extra position (staying on the same plane, but moving away from one of the four main positions) to allow a new satellite to be launched into the main position. For example, if you look at the information for SVN29/PRN29 at the first link, it was allowed to drift into a position on the F plane that was designated F5 so that the new SVN41/PRN14 could be launched into F1.


Back to SVN23/PRN23. It was clock swapped onto the clock that has just failed in November 2003; that would almost certainly have been linked to an outage and performance degradation until the new clock was tested and it returned, though whether it caused positional anomalies as it went, or just went off air, I don't know. Unfortunately the clock selected in November didn't last very long!

Each GPS satellite carries several atomic clocks; it seems that they're the components that fail. The command stations for GPS can tell a satellite to switch to a different on-board atomic clock. The performance requirements of these clocks have to be tight for GPS to work properly.

In January 2004, SVN23/PRN23 continued to transmit signals, but the information in those signals was very wrong because of the faulty clock. Discussion in the sci.geo.satellite-nav newsgroup indicates that many systems spotted what was wrong - fixed receivers, such as those that transmit differential corrections for marine DGPS, are particularly well placed to spot an anomaly like this (they know they suddenly haven't moved!), and many systems using these fixed receivers shut down (apparently this was reported as happening to the Swedish and Finnish DGPS systems during this period).

There's some accusation in sci.geo.satellite-nav that the reason it took so long to mark the faulty satellite as "unhealthy" in the GPS almanac, so that people's GPS receivers stopped using it, was due to a lack of monitoring and control stations controlled by the USAF Second Space Operations Squadron who run the GPS system (with a comment that further modernisation, and hence investment is needed on the part of the US Government). I wouldn't feel qualified to make such a comment - after all, with anything to do with computers and the like, sometimes the unexpected happens, and there are limits as to how much provision you can make to fix rare faults quickly (or at least confirm a fault and hang up an electronic "out of order" sign, which was what was needed here to make GPS behave correctly again)


Our consumer GPS receivers don't have integrity checking functions, on the whole - if they get garbage GPS signals, their output is garbage. Even simple tests, such as calculating positions omitting each of the visible satellites in turn to see if one satellite is giving duff information when there's sufficient satellites visible not to need them all for a position, have a cost in terms of processing power and battery life.

More expensive receivers, such as those used in "safety of life" applications, have integrity checking built in (a feature often referred to as RAIM) - at the very least they can indicate when they believe they're not displaying an accurate position.

When a rare failure such as that that happened on 1 January 2004 happens, Space Based Augmentation Systems, such as WAAS and EGNOS can help out - not only do they carry error correction information for each GPS satellite, but I believe there's the capacity for an SBAS system to indicate that individual GPS satellites are faulty in the opinion of the SBAS system, and shouldn't be used, even if they're not marked "unhealthy" in the GPS almanac. SBAS systems certainly transmit system integrity information.


In case you're wondering why satellites have two designations, PRN, the pseudo-random noise code, is what your GPS receiver shows the satellite as. SVN is the actual satellite vehicle number. I believe originally SVN1 used PRN1, and they pretty much stuck to that system until they ran out of PRN codes. However, all of the original Block I GPS satellites and quite a few more recent ones have been decommissioned. The first linked web page shows which SVNs are using which PRN code.

SVN23 is one of the older satellites still in use - it launched in 1990 (see http://earth-info.nima.mil/GandG/sathtml/satinfo2.html for that information).


I don't know whether the gap at PRN12 is likely to be permanent. If you read down to the bottom of the first linked web page, you'll see that the satellite that was going to have PRN12 was "destroyed during launch" (I believe it was a fairly spectacular rocket failure). I have no idea whether PRN12 is now regarded as the GPS unlucky number or not - future satellites that have had a PRN code allocated are not going to use 12 (again, look towards the bottom of that page). It may be that they won't use it unless they have to - as I explained earlier, there is a hard limit to the number of active GPS satellites and eventually their hand may be forced.

The "got wet" satellite was, I understand, rather less spectacular - my understanding there is that the satellite's innards were found to have got wet before it was launched, and it was therefore scrapped. PRN20 was allocated to another satellite.


Finally, note that the SVNs don't run in launch order.

All I can find out about the satellites due to be launched (see the bottom of the page with the first link) that have an additional M designation is that that seems to refer to satellites that transmit additional focussed beam GPS signals for military use only. I guess that's why there's no public information; the military GPS signals are encrypted, and can't be used directly by civilian GPS equipment (though there are some uses of the encrypted signals by expensive surveying GPS equipment that doesn't require the decryption keys).

There are new GPS signals that are going to be introduced with later generations of satellites - from memory, there's going to be two additional civilian signals to add to the one we already have.


Maybe the M payloads have caused delay - or maybe the out of order nature of the SVNs is something to do with which contracts the individual satellites were ordered on. Not every GPS satellite is built by the same company.



This has got maybe far too technical - though I've tried to keep it as simple as possible. It is also possible that my own understanding of some of these topics is wrong - if anyone spots anything wrong, please reply and say so!

That said, I hope it is useful.



David

[AlunS]

I don't think that's the first time it's happened either. In the last year or so, I've had two separate occasions where I've downloaded track logs from my Garmin etrex after a hike, and found myself zooming about at incredible speeds (>700km/h) all over the mountains for an hour or longer and then all of a sudden settling down again.

At the time (15/02/2003) I couldn't find anything in the NANU's etc. to explain this. I suppose it could have been some weird kind of multipath intereference, but I've taken exactly the same route since with no problems.

[DavidW]

An official analysis of the 1 January 2004 incident has been posted at http://www.schriever.af.mil/GpsSupportCenter/archive/Frontpage/2004_j006_SVN23_Anomaly.htm. It was indeed a failure of the atomic clock in use on SVN23/PRN23.

NANU 2004008 reveals that SVN23/PRN23 was returned to the GPS constellation on 20 January - you can read NANU messages (Notice to All Navstar Users) at http://www.navcen.uscg.gov/ado/GPSSelectCurrentYearNanuByNumber.asp. This time it's using another atomic clock - hopefully this one will fare a little better than the last!



David

We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?.
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!