The 2nd Space Operations Squadron last month put into play an optimization scheme for the GPS satellite constellation that will bring better accuracy to GPS users worldwide.  Prior to now, GPS was only required to have 24 satellites operating in 24 specific orbital slots.  Of course there have been many more than 24 satellites on orbit for over 12 years.  Because of the 24 satellite requirement though, their orbital positions were determined by optimizing constellation performance on only those 24 slots.  That has now changed.  There is a new 24+3 constellation slot definition that allows GPS satellite orbital positions to be optimized based on a 27 satellite  constellation rather than 24.  This means that your GPS receiver’s positioning accuracy will get better – for free!  I’m not covering the specifics of the satellite moves for this Nog, those are covered in articles linked above.  Here, I’m focusing on the end user’s gain based on this change.

Remember that your position accuracy depends generally on two things: the orientation of the the GPS satellites at a given time and the accuracy of the the GPS signals themselves.  I know, I know, there are other factors involved in accuracy, but let’s just look at the big picture here : ).

The metric defining the orientation of the satellites is Dilution of Precision (DOP), the metric defining the accuracy of the satellite signals is User Range Error (URE).  Because the GPS orbital slot positions are changing based on this new optimization, we expect to see a change in DOP, not URE.  The new positions presumably have been chosen to optimize DOP – let’s see how much better the DOP will be when the satellites have completed their move.  There are several types of DOP, representing the effect of satellite orientation on different coordinates.  For example, Horizontal DOP (HDOP) represents how much satellite orientation affects your navigation positioning error on the surface of the Earth (2 dimensions).  Vertical DOP (VDOP) represents how the satellite orientation affects on your altitude positioning accuracy.

For my analysis, I’ll look at HDOP and VDOP values for the entire globe for today’s constellation, and for the constellation once all the satellite moves have been completed for the optimization.  I’ll call this the optimized constellation.  I’m also going to constrain the DOP calculations by requiring that each point on Earth not be able to see any GPS satellite below 10 degrees from the horizon.  This is a typical mask angle used for these types of analysis.  Note that clicking on each picture will bring up a full size version, for closer examination.

Horizontal DOP

Today’s average HDOP values are shown in Figure 1.  The HDOP average is taken over a 24 hour period from Jan 1, 2010 to Jan 2, 2010.  The color at each point on the grid represents the daily average HDOP for that grid point.

Figure 1 – Average HDOP, January 1, 2010

Now we’ll look at how HDOP changes with the new optimized constellation.  Figure 2 shows the average HDOP with the newly optimized constellation.

Figure 2 – Average HDOP, Optimized Constellation

The changes here aren’t too striking, but you’ll notice that the bands where the average HDOP is greater that 1.0 (the red bands) have shrunk a bit.  Let’s see if Vertical DOP is any better.

Vertical DOP

Today’s average VDOP values are shown in Figure 3.  Again, the VDOP average is taken over a 24 hour period from Jan 1, 2010 to Jan 2, 2010.  The color at each point on the grid represents the daily average VDOP for that grid point.

Figure 3 –Average VDOP,  January 1, 2010

Next is the average VDOP for the new, optimized constellation, shown in Figure 4.

Figure 4 – Average VDOP, Optimized Constellation

It appears that VDOP is getting improved more than HDOP – but by how much?

Let’s look at some numbers.

I’ll take a global average of all the HDOP and VDOP values and put them into a table:

	Optimized	January 1, 2010	Percent change
Average HDOP	0.9491	0.9759	-2.743%
Average VDOP	1.651	1.699	-2.855%

Table 1 – DOP Percentage Changes

So the VDOP change is slightly better than the HDOP improvement and both changes reflect roughly a 3% increase in DOP performance.

How do these changes in DOP affect what we really care about though – our GPS positioning error?  Using the same methodology as above, I’ll now look at navigation accuracy for the January 2010 constellation and the optimized constellation.  To complete a navigation accuracy analysis, I need User Range Error (URE) information for each satellite. I’ll use the GPS User Range Errors from January 1, 2010 for both the current and the optimized constellations.  The green bars in Figure 5 show the values I’m using for each satellite.  Because PRN 1 (SVN 49) is a critical piece of this optimization, I’m including it in the analysis, with a URE of two (2) meters.  I’ve also included a receiver error value of two (2) meters in the following accuracy analysis.

Figure 5 – GPS User Range Error values: Dec 30, 2009 – Jan 01, 2010

Horizontal Accuracy

Figure 6 shows the average horizontal accuracy for January 1, 2010.   The color at each grid point is the average horizontal navigation error over 24 hours, for the constellation on January 1, 2010.  I tend to use navigation accuracy and navigation error interchangeably – to me, they mean the same thing.

Figure 6 – Average Horizontal Navigation Accuracy, January 1, 2010

With the new constellation, we do see some improvements.  Figure 7 shows the horizontal accuracy using the optimized constellation.

Figure 7 – Average Horizontal Navigation Accuracy,  Optimized Constellation

Vertical Accuracy

The vertical navigation accuracy plots show improvement as well.  Figure 8 shows the average vertical navigation error for January 1, 2010.

Figure 8 – Average Vertical Navigation Accuracy, January 1, 2010

Figure 9 shows the improved average vertical accuracy with the optimized constellation.

Figure 9 – Average Vertical Navigation Accuracy, Optimized Constellation

Table 2 shows the percent improvement in average accuracy with this change in constellation orientation.

	Optimized	January 1, 2010	Percent change
Average Horizontal Accuracy (meters)	2.244	2.291	-2.05%
Average Vertical Accuracy (meters)	3.949	4.027	-1.93%

Table 2 Average Accuracy Percent Change

The changes aren’t eye-dropping – you do get an overall accuracy improvement, but you may not notice it.  But hey, it’s free right?

Number of Satellites Visible

One last piece of analysis.  Typically you might equate the number of GPS satellites available to your receiver with better accuracy.  This does make some sense, but it’s important to remember that quality trumps quantity – fewer satellites oriented optimally are better than more satellites oriented sub-optimally.  This is shown in the following figures.  Figure 10 shows the minimum number of GPS satellites you’d see over 24 hours at a given location with the current constellation.

Figure 10 – Minimum number of GPS satellites visible over 1 day, January 1, 2010

Figure 11 below shows the same plot but with the optimized constellation.

Figure 11- Minimum number of GPS satellites visible over 1 day, Optimized constellation

Note that the scale starts at four (4) satellites visible and goes up to nine (9). So far so good – it looks like we have larger minimums over the globe, except at the poles.  Also note that the two areas that had a minimum of 4 satellites available  currently (in red in Figure 10)have been eliminated in the optimized constellation.

What about the maximum number of satellites available?

Figure 12 – Maximum number of GPS satellites visible over 1 day, January 1, 2010

Figure 12 shows the maximum number of satellites visible over one day for the current constellation.  Note the scale on this graph has changed – it starts at ten (10) and goes up to fifteen (15).  Figure 13 shows the same plot, but for the optimized constellation.

Figure 13 -  Maximum number of GPS satellites visible over 1 day, Optimized constellation

The maximum number of visible satellites has gone down in most cases.  This is counter intuitive, but it echoes the idea that the orientation is what’s important, not the sheer number of satellites visible.

All in all the new optimized GPS constellation will improve average DOP and navigation accuracy, but not substantially so.  Another way to approach this analysis is to look at the maximum errors of today’s constellation versus the optimized constellation.  This may (or may not!) show more improvement, but those maximum errors only occur rarely in any case.  What we usually have is the average case as we cruise about with our GPS receivers.  Thanks for the optimization 2SOPs, we’ll take it!

Remember fresh batteries.

2 comments

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

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

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!

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

• 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:

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

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:

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:

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

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:

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!

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:

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:

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

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

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

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:

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

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

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

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

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