Jan 24

GPS Control Segment software “Glitch”

Category: General Navigation
Technorati Tags: ,,,

There was an interesting NANU sent out by 2SOPs on January 24th: NANU 2010011:

NOTICE ADVISORY TO NAVSTAR USERS (NANU) 2010011 NANU TYPE: GENERAL
*** GENERAL MESSAGE TO ALL GPS USERS ***
On 11 January 2010, the GPS Master Control Station loaded new
operational control system software to support future GPS modernization
capabilities and signals.  The software has been in operational soak and
the GPS Master Control Station has received a few user concerns related
to the software update.  Military users can find additional information
at the GPSOC SIPRNet website at http://gpsoc.afspc.af.smil.mil.  The GPS
Master Control Station is preparing to complete soak of the new software
in preparation for final install.  In support of the final install
decision, the GPS Master Control Station requests that operational
military and civil users provide any impacts encountered that are
believed to be related to the new software or started after the 11
January 2010 install.   Military or civil users please contact the GPSOC
(military) or NAVCEN (civil) at the numbers listed below no later than
29 January 2010.  Any user impacts will be presented at the decision
brief for final install of the new GPS Master Control Station software.
*** GENERAL MESSAGE TO ALL GPS USERS ***

We all know that “glitch” is the term applied when you really have no clue what’s going on with the software.  In this case they just can’t talk about what’s going on.  I believe they do know though, because GPS World is printing that the software changes…

…require absolute compliance with the published GPS Interface Control Document (ICD).”

So some receivers in the field (read military GPS receivers) are having trouble doing their job because of the new software upgrade in the Control Segment.  Let’s talk about Interface Control Documents (ICDs) for a moment.

If you develop software you’re probably aware of ICDs – you know they describe an interface – beyond which you have no control, to which you can write code and expect that it will perform correctly.  My house has an ICD – when the designer laid down the plans for my house, he knew that if he drew the plan for a door in one room, that plan should have a door on the other side as well – so I could actually get from one room to the other.  Sounds simple.  In software we do the same thing – for AGI components we write what’s typically called an API (Application Programming Interface) that allows you, the user of our software, to confidently use our libraries and return results.  An API is something sacrosanct  to a developer – you do not change it unless there is a VERY good reason – many, many developers have written their code expecting the API to work the way it’s written – if it changes in the future, the user of the API can never upgrade to a new version - hurting them and the developer of the API.

Now, if you’re a military GPS user, you have a receiver that must use the GPS Space Segment, which is controlled by the GPS Control Segment.  When either of those are upgraded you don’t have a choice – you’re upgraded too.  So what happens when someone doesn’t follow the ICD and you don’t have a choice about upgrading?  Let’s go back to my house.  Suppose the designer didn’t follow the “ICD” and put doors wherever he liked in my house.  In some rooms, my doors might lead to the back of the stove, or into the back wall of the shower.  I’d be stuck in my room, or worse yet not even be able to use my house.  We expect the designer to adhere to the API of the house so it’d be useable.

So, who didn’t adhere the the GPS ICD?  From the tone of the GPS World article, GPS World thinks the GPS Receiver manufacturers are to blame:

Corrective action could encompass either the Air Force rolling back the update or revising its software, or the manufacturers modifying GPS software within the receivers to be totally compliant with the ICD.

This has happened before – 2SOPs has written papers explaining why adhering to the ICD is critically important.  If you don’t – your receivers don’t work. It doesn’t get much simpler than that.

No comments

Dec 24

The Grumpy Positioning System

Category: Navigation Humor

I checked my Google News feeds this morning, and this popped up:

The Grumpy Positioning System

Lost in all the news and controversy about health care, almost nobody has noticed the legislation introduced by the Minority Leader, Senator Mitch McConnell (R-KY), intended to revamp the Global Positioning System. This is unfortunate, as Senator McConnell’s bill would have profound effects on the daily lives of millions of people.

Curious, I read on and had a good laugh: http://seminal.firedoglake.com/diary/20537

Merry Christmas and Happy Holidays everyone, and don’t forget your favorite drink of the Season – here’s to The Nog!  Cheers!

No comments

Nov 19

GPS Satellite Outage Calendar – updates

Technorati Tags: ,,,

After looking at the sorry state of the GPS Satellite Calendar App, I decided to make some updates.  Ok, it wasn't that sorry, after all it did show all the GPS outages in calendar format.  But, once you're used to that, it gets boring.  So, I added a few features and I'll be adding more in the weeks to come.

New features

  • One thing I hated about the old calendar, is that to see the outages for February of this year, you had to click the << arrows multiple times to get to February.  Heaven help you if you wanted to see the outages from a previous year.  So, I added some drop down boxes that let you pick any month and year for which there is data - much easier!

image

  • Next I added some tables below the Calendar, listing the Current or Predicted outages.  This gives you a quick look at what's currently out and what's predicted to be out.  Note that current outages are always in red in the calendar, and predicted outages are always in yellow.

image

  • I also updated the text in some of the fields of the tables to link to the definitions for the outage types, or the NANU itself for a given outage.  All links are referenced to the Celestrak NANU web pages.
  • You can also click on the table column header to sort the outage data on that column.
  • The Historical listing of NANUs was ok, but it was just a big list of all NANUs published since 1998.  I updated that listing to be on a separate page, and have the same links and sorting capability.  I also added a column that lists the duration of the outage, defined by the NANU start and end times.  Click the Historical Outages link at the bottom of the page:

image

and a new page or tab will open with the Historical outages table:

image

Looking at the last three outages (at the bottom of the table), we can see that the SVs were only out for 5-7 hours:

image

Which outage was the longest?, which was the shortest?  Sort on the Duration Column.

Which Satellite had the fewest number of outages?  Sort on the SVN or PRN column and see how many rows there are.

As I mentioned above, I'll be making some further updates in the coming weeks:

  • Some of you may have seen Richard Langley's article in the November 2009 issue of GPS World, about the GPS constellation being maxed out at 30.  For that article, I produced a picture of the number of healthy GPS satellites since 1998:

image

I'll be updating this picture each time a new outage is posted, and placing it on the page as well.  This way we'll have a running tally of the outages and the number of healthy satellites in the constellation.

  • I'll also add some controls to the page that will allow you to explore outage information by PRN, time or PRN and time, as this sample application does.

If you have anything you'd like to see on this calendar, let me know, I'll see what I can do.

Happy navigating!

No comments

Sep 25

Navigation Potpourri

Category: General Navigation

Here's a few tidbits from the navigation world.

PRN 24 and PRN 25

PRN 24 (SVN 24) was recently set unhealthy due to some unusual problem.  According to the GPS Operations Center:

An undisclosed user has reported an issue and 2 SOPS is switching SVN24
(PRN24) to test and turning SVN25 (PRN25) to operational while 2 SOPS investigates the situation.  Constellation will remain optimized and there will be no impact to DOP.

So, not sure what the undisclosed user is seeing from PRN 24, has anyone else seen anything funny there?  Also, restoring PRN 25 is interesting - is this to cover a DOP spike created by removing PRN 24?  PRN 24 and 25 have completely different orbital positions (different planes even) as seen here.  PRN 24 is red, PRN 25 is yellow:

PRN24PRN25

A quick PDOP coverage calculation shows that there isn't much difference with PRN 25 in our out.

Overdetermined PDOP Coverage for Sept 15, 2009 (PRN 24 unhealthy)

Global Statistics

Minimum    Maximum    Average
-----------    -----------    ----------
1.997167    6.281824    2.960669

Overdetermined PDOP Coverage for Sept 15, 2009 (PRN 24 and PRN 25 unhealthy)

Global Statistics

Minimum    Maximum    Average
-----------    -----------    ----------

1.907827    6.226181    2.889114

Also, PRN 24 was set unhealthy using a general NANU.  What's up with that?  If this means nothing to you, not to worry - for those of us who track this kind of stuff - ouch!  This breaks established processes and causes all sorts of automated process chaos.  We can do better.

Major speed improvement in AGI Components Release 2009R5

With the release of AGI Components 2009 R5 in September 2009, a big decrease in calculation time was introduced.  This graph shows the computation time for various tests using the Navigation Accuracy Library.  Notice the log scale for the Y-Axis.  Results for 2009R4 are missing, but the results for 2009R5 are clearly a big step in the right direction.  This is the fastest the components have run to date.  Nice!

NavLib Performance

Newest, last IIR PRN 5, Poor Performer

So far, the newest GPS Satellite, PRN 5 (SVN 50) is no Einstein.  The SIS errors are higher than almost all other satellites, as seen on this graph:

PRN5

The clock seems to look ok, but looking at the ephemeris error (along with PRN 8 and PRN 27, the two worst performers), something just doesn't seem right:

PRN5Ephemeris

It's not in Eclipse season, the minimum Sun/Earth angle is about 55 degrees:

PRN5Beta

Here's a VDF file for the scenario I grabbed the picture above from.  Be sure to download the free AGI Viewer to animate and view PRN5 using the 3D globe.

There was a maintenance outage on PRN 5 recently (see the missing data on the last day on the graph above), let's wait and see if that has helped the ephemeris errors any.

Miscellaneous

I've always had a good sense of direction and because of that, I have yet to buy a 'GPS' for personal use.  I usually can figure out where I'm going.  Recently I was on a business trip to somewhere I hadn't been before (big metropolitan) and I decided to get a GPS in the rental car.  I was on a short timeline and I didn't want to risk getting lost and missing my appointment.  The unit I got locked on quickly and showed me the streets I would turn on, even talked to me.  The talking was a bit late, but the arrows on the map helped make up for that.  All in all it wasn't too bad - especially since they have other features like helping you find food, etc.  It sure was a lot more helpful than the guy behind the desk at the hotel.

Later on, in a taxi ride, the taxi driver had another type of GPS on the dash - this one had all the same features, except it allowed you to download voices from the Internet.  This is interesting.  She played Darth Vader for awhile, then she turned on Kenny from South Park.  I enjoyed hearing him tell the taxi driver to turn right..into the Johnson's car.  Now THAT's worth buying one for.

Happy Navigating!

No comments

Sep 23

Navigation Error Predictions – Part 3

I know, it's been a long time coming.  Last February, I wrote a Nog on predicting GPS navigation errors in the long-term - over days and weeks.  In this Nog, I'll cover predicting short term navigation errors, which is a little more tricky believe it or not.  This is because for long-term errors, we can use statistics to predict the general behavior of GPS clocks and ephemeris, distilling that down into a statistical position error prediction.  That type of prediction results in an error covariance, an error ellipsoid around the true position.  For the short term (several hours), we have access to the latest clock and ephemeris errors and by using them we can create a predicted error vector, which is a better thing to have.  The difference between an error ellipsoid and an error vector can be explained by example.  Suppose you lose your car keys.  Having an error ellipsoid may tell you that they are in your house somewhere, not too bad of a search, but you have to search the entire house.  If you have an error vector, it would tell you that they are under last weeks mail in the kitchen junk drawer - much better information! A lot less searching.  In the navigation world, and error ellipsoid tells you the treasure is in the general area, but an error vector points to the giant X on the map.

So, now that we have a basic understanding of the types of errors, let's look at how we might use the data we already have (in a PAF file) to predict error vectors for several hours.  If you're not sure how a PAF file leads to a navigation error assessment, be sure to catch up with these Nogs.

Read more

No comments

Aug 17

Last GPS Block IIR Satellite now in Orbit

Category: Launch

Monday, August 17 at 10:35 GMT, the last Lockheed Martin built Block IIR satellite lifted off.  There were a lot of lasts with this launch:

  • This is the last Block IIR satellite
  • This was the last time the Air Force would use the Delta-II rocket
  • This is the last scheduled launch from pad 17A, in use since the 1950's

SVN 50 (PRN 05) will be located in the same orbital slot as SVN 40 (PRN 10), eventually taking its place.  SVN 40 is on its last clock (of four original clocks) and it also has a reduced navigation payload capability.  It's User Range Error (URE) is not too bad though, as can be seen from these graphs:

PRN10EphemerisError3Days

This plot shows the ephemeris error for SVN 40 (PRN 10) for the last three days.

PRN10Clock3Days

This plot shows the clock error for SVN 40 (PRN 10) for the last three days.

PRN10URE

This last bar chart shows a three day history of the RMS URE for all satellites in the constellation.  PRN 10 is a nice, middle-of-the-road satellite.  I'd expect to to remain in use until it can no longer perform it's duties.  There may even be some benefit in moving it within plane to optimize the Dilution of Precision (DOP) for the entire constellation.

Job well done on the Block II Replenishment satellites!

Next up: Block IIF with the first launch for this new series of satellites scheduled for early 2010.

No comments

Jun 24

SVN 49 Navigation Data parameter changes

At a telecon held by Air Force Space Command (AFSPC) last Friday, I asked a question regarding which GPS navigation data parameters were being modified to fix the elevation-based, excessive ranging errors that SVN 49 (PRN 01) is producing.  The answer on the telecon was not as detailed as I would have liked, so I followed up with an e-mail asking for the definitive terms that are being adjusted.  I received their reply today; here is the answer:

"Two methods are being evaluated for mitigating the effects of the SVN-49 problem.  This first method involves adjusting the AF0 and Tgd terms in the broadcast NAV message from SVN-49.  The second method involves adjusting the AF0 and Tgd terms as well as the square root of the semi-major axis and the mean motion difference terms in the broadcast NAV message.  The pros and cons of each method are still being assessed.  The satellite is currently being operated using the second mitigation method without the Tgd adjustment."

So, now we know what's being considered and tested.  I don't doubt that they would consider other parameters as well, if they think they can model the fix better, so this may not be the final answer.  I'll keep the Nog updated if I hear anything further.

More detailed analysis can be found on another blog by Tim Springer.

All comments and questions are appreciated, thanks for following!

Happy Nogging...

1 comment

Jun 19

AFSPC Media Telecon for IIR-20M (svn 49, prn 01) problem

Today I attended the Air Force Space Command (AFSPC) media telecon specifically addressing the high User Range Error (URE) problems on the newest GPS satellite.  PRN 1 was launched on March 24, 2009, carrying the new L5 payload.  The L5 payload was turned on and successfully guaranteed it's spot in the spectrum for future L5 payloads on GPS.  But, while L5 worked, L1 and L2 were having problems; problems no one on the ground had seen before.  The URE from PRN 1 was inconsistent with the other IIR vehicles in that family, causing quite a stir.  Notes from today's telecon describe the situation, detail what happened, who's affected and what the resolution is.

Telecon started at 12:00 PM PDT, June 19, 2009

Col. Dave Madden and Col. Dave Buckman answering questions.

Several media representatives asked questions.

Note that I've paraphrased the questions and answers for brevity and clarity

Question: Does the problem affecting this satellite extend to GPS III?

Answer: (Madden) No, this problem is specific to this satellite only.  It turns out that the L5 payload was added to an existing IIR vehicle using the Auxiliary port [I'm assuming it's the RAP functionality on the satellite - the Reserve Auxiliary Payload]. All ground tests were normal and everything seemed fine.  This Auxiliary port is not the same architecture intended for implementing L5 on the GPS III vehicles.  It turns out that by connecting the L5 payload to the Auxiliary port, L1 and L2 energy is reflected and not compensated for.  To correct this, we've effectively moved the antenna phase center of the antenna and adjusted the navigation message.

Question: Is there any risk to the military's use of GPS?

Answer: (Madden) No.  This satellite, even without a fix, is still well within specification.  The [SIS]URE is between 2-4 meters  depending on where you are on Earth, and it's elevation dependant.

Question: Will L5 on SVN49 be turned off when the next L5 payload is turned on?

Answer: (Madden) We'll probably wait until the 2nd L5 payload is on orbit and active before considering turning the SVN 49 L5 payload off.  The problem on SVN 49 is with L1 and L2, not L5.

Question: Is this problem something that needs to be addressed for the upcoming IIR launch in August 2009?

Answer: (Madden) Initially we were concerned, so we performed a root cause analysis to determine the issues.  This analysis lead to the finding about the Auxiliary port.  We then recreated this situation on the ground in Denver and, with more extensive testing, found the same issue that we have on orbit.  This verifies to us that we've found the problem, clearing the next GPS satellite for launch.

Question: How is the fix for this problem modeled?  Is it a constant bias or something else?

Answer: (Madden) The fix effectively moved the antenna phase center for the satellite to 150 meters behind the satellite.

Question: What navigation parameters are being changed to implement this fix?

Answer: (Thomas Powell, Aerospace) The ephemeris phase center value (later determined to be the Tgd value) and the clock offset values are being modified to allow user's receiver to get a correct URE for this satellite.

Closing remarks from Col. Madden covered the Air Force's concern in the tone of the GAO's analysis for the future of GPS.  Col. Madden reiterated that the Air Force has always met GPS performance commitments and that they have a robust plan for continued health of the constellation. Another issue the GAO neglected he continued, was that the Air Force uses power management to increase the lifetime of satellites in certain cases.

See my Nog on the GAO report issue.

Ok, so now we know the scoop - this is a one vehicle hiccup and one that can be corrected, not too bad!

In the next Nog, I get more technical I promise.  The faithful among you have been waiting for the third installment on predicting GPS accuracy - it's next!  I promise! First two Nogs on that topic here and here.

Until then, smooth sailing.

2 comments

May 23

GPS Accuracy Failing – Seriously?

The scare level regarding the General Accounting Office report on the risk of future GPS failures is rising precipitously.  Let me be one of the first to say - hold on, there's no reason to panic, or sell your Garmin (GRMN) stock.  Many consumers have purchased the now ubiquitous GPS handhelds that tell you where to go.  Providing accurate positioning maps and voice response, they are a tempting buy (but not for me yet, somehow...).  Most folks even regard their device as the GPS, not the system that provides the location signals to their device.  So, what's the truth behind the failure cry and how bad is it really?

The General Accounting Office report, available here: GAO GPS Report, states there is increased risk of future GPS coverage failures because of acquisition problems - basically the next generation of GPS satellites; the Block IIF satellites, are behind schedule.  Also, there are several GPS satellites that are "single-string" meaning they have lost redundancy on one or more components.  This means that if the current component fails, the satellite may not be able to perform its navigation mission.  The GAO report is reporting on increased risk, it is not reporting on GPS failure.  The conclusion in their report is essentially, let's keep a close eye on it - by recommending the appointing of a single GPS oversight authority.

Let's talk specifics - what if the risks the GAO reports were actually to occur?  What if 6 or more satellites were to fail, with no additional satellites being launched and no GPS satellites being moved in orbit to counter poor coverage?  How bad would it get - really?

With that problem statement, I made the following conservative assumptions in order to analyze the problem:

  • A GPS user has a 12 channel receiver (able to track 12 GPS satellites at once)
  • A GPS receiver won't use any GPS satellites within 5 degrees elevation from their horizon.
  • The GPS Receiver will have a combined error of 2 meters (Signal-In-Space and receiver noise, multipath, etc)

Let's look at today's GPS coverage:

Baseline

This picture shows the maximum navigation error, over 1 day, for the world.  The legend is:

MaxLegend where I've used 10 meters as the max because it's about the width of a typical neighborhood street.

So, everywhere in the US for example, the maximum error you'll see during the day is under 6 meters - roughly half the width of the street.

What about the dark areas?  How bad is the accuracy in those areas, and more importantly, how long is it bad?

The plot below shows that in the dark area in Canada, over the entire day, only a small amount of time is spent with the larger navigation error - roughly 10 minutes.  Even then, the error is only about a street width and a half.

DarkRegion-Baseline

Ok, now on to the fretful stuff.  The GAO is reporting that, because of acquisition issues, GPS accuracy may begin to suffer starting as early as 2010.  Let's look at the situation where GPS starts to lose 1, 2, 3 and more satellites and see how bad our accuracy suffers as a result.

This video shows, in each frame, one additional GPS satellite removed.  There are a total of 9 frames, corresponding to 9 satellites removed.  To decide which satellites to remove, I used data that shows which satellites are most likely to fail based on their loss of redundancy.  I did not use any reliability numbers for these satellites, simply the state of their on-orbit hardware as of March 2009.  The most likely to fail satellites are taken out first, and so on.

The video starts to show some scary colors as we begin to remove large numbers of satellites, but remember - this is the maximum error you will see over the day.  The video points out that instead of localized larger navigation errors like we have today, many more people experience these large errors - but again, for only a short time.  Here's a plot of the worst case scenario along the Eastern seaboard, where 9 GPS satellites have failed, none have been launched, and no movement of GPS satellites has taken place to optimize the coverage.

DenverWorstCase-9-Out

Throughout the entire day, the accuracy never exceeds 22 meters (about two street widths) and averages roughly 4 meters (less than half a street width).

To counter the scary picture the video paints, I created the plot below to show the average navigation error for the world over one day, with 9 GPS satellites missing.

AverageFailed9

This result shows that we will still have sufficient GPS coverage for most navigation needs even if the worst was to happen.  For those users in more constrained environments (like canyons, urban or natural) or that have more stringent navigation requirements than knowing which road they are on, there will be additional effects.  It is unlikely that any of this will happen however, given the Air Force's track record for management of the GPS constellation.

So, keep you GPS unit, which ever kind you have, and don't over react when we hear more stories about how GPS will fail - we're nowhere near that result.

Smooth sailing, with an eye toward the sky...

No comments

May 3

SVN 49, PRN 1 URE too high

After the last Nog, someone pointed me to the following picture, published by the GPS Operations Center from this site: http://gps.afspc.af.mil/gpsoc/performance_reports.aspx, (pick the Position Errors By Satellite value in the drop down box)

prn01

This shows that PRN 1, on April 30, 2009, had a very large User Range Error (URE), larger than any other satellite in the entire GPS constellation. If you've been following the Nog for awhile, you know that a URE this big can lead to large navigation errors.  This is certainly the reason PRN 1 is not healthy yet.  URE's are calculated using ephemeris and clock errors.  Ephemeris errors are rarely a problem, so it's likely that this satellite has a clock problem.

2 comments

Next Page »