Saturday, August 27, 2011

Recalled SVN-35 Not Doing Well

On August 16th, 2011, according to the 2SOPs Satellite Outage File (Outage Calendar link) and NANU 2011-062, PRN-30 (SVN-35) was set healthy, bringing back a satellite previous removed from the constellation.  SVN-35 had been labeled a spare, making it reusable in case it was needed.  That’s just what happened  over the last few months.  According to InsideGNSS:
SVN-35, also a Block IIA satellite, had been decommissioned from active service back in 2009 to make room in the constellation for the launch and eventual deployment of the latest new GPS Block IIR vehicle.
Even while it was removed from the almanac of the active constellation, SVN-35 maintained accurate timing and navigation signals; so, when the need arose for a spare, 2 SOPS analysts knew just where to go.
However, over the last few days, SVN-35 is showing it’s age.

The Clock

The atomic clock onboard SVN-35 that’s currently active is showing signs of instability.  Atomic clocks are quantum mechanical devices and by nature they have random outputs.  Fortunately we have developed the technology to the point where we can use the devices for positioning, navigation and timing (PNT) applications that require sub-nanosecond accuracy.  When the clocks start to age however, the random outputs become less controllable, causing larger PNT errors.

Predictable Behavior

The Second Space Operations Squadron (2SOPs), using Master Control Station algorithms, predicts the behavior of all the clocks on orbit in the GPS constellation.  They upload those predictions to the satellites which then broadcast them to your GPS receiver.  Your receiver then calculates clock parameters necessary for your position determination.  When a clock becomes unstable their predictions no longer match the behavior very well, leading to potentially large PNT errors.

The Last 10 Days

Over the last 10 days, since SVN-35 was set healthy again, the output of the clock is becoming less predictable.  The figure below shows the 10 day history of SVN-35’s clock error, the larger the error, the less predictable it’s behavior:
PRN 30 Last 10 Days
Each time the error goes back to zero (or close to zero), 2SOPS has intervened and uploaded new clock predictions to the satellite.  There are times when it behaves well (just after Aug 22) then there are times it behaves badly (Aug 23).  This instability is a key indicator of a dying clock.
Here’s a picture of the last three days:
PRN 30 Last 3 Days
On August 23, 2SOPs uploaded new predictions to SVN-35 six times, that’s 6 times the normal tempo.  A normal tempo is once per day.  Here’s a picture showing a comparison of SVN-35 (PRN-30) to arguably the best clock in the constellation, SVN-41 (PRN-14):
PRN30PRN14Compare
You can see that SVN-41 has a much more stable, predictable clock that SVN-35 has.

Unusable

On Friday, August 26th, 2SOPs again set SVN-35 unusable until further notice (NANU 2011-070), and has delayed maintenance on SVN-43 (PRN-13) presumably because of this.  Will SVN-35 come back?  Can its clock be saved once again?  Are there additional clocks on SVN-35 that might be better?  We may not know for awhile.  Unlike with a jury however, the longer it takes for SVN-35 to return, the less likely it is for a favorable outcome.

PS: All of the graphs were produced from my GPS Satellite Performance website here: http://adn.agi.com/GNSSWeb/PAFPSFViewer.aspx.  A GPS Satellite Outage Calendar is also available, where you can track each satellite’s outage history and future outages: http://adn.agi.com/SatelliteOutageCalendar/SOFCalendar.aspx.

2 comments:

  1. My satellite tracking program shows relative motion for SV35 is slow westward drift. It currently cannot improve DOP because it's orbiting so close to SV62, a new IIF satellite with a signal in space error (SIS) of 0.5 meters.

    So why has the USAF set SVN35, with its poor SIS, usable? Will its unpredictable SIS error actually increase positioning error if my receiver selects SVN35 rather than SVN62?

    ReplyDelete
  2. HIPAR,
    I can't answer why they set it usable, but I'll bet it was acting better before they did. Now it's acting up again. If your receiver does select it instead of SVN62, you will have worse performance, no doubt about it.

    ReplyDelete