See you there!

From now on, I’ll be blogging on our new site: http://blogs.agi.com, as one of the regulars.  On The Nog, I’ve been restricted to topics relating to navigation, but on our new site http://blogs.agi.com, I can branch out and discuss other things as well.  I will still post navigation related posts at our new site, http://blogs.agi.com, and I’ll always tag those posts with the word “Nog” – so we’ll have something special together.  Those of you that have followed me here will know that you are one of the old-timers – “I followed Ted before he started blogging on AGI’s blog site at http://blogs.agi.com- did you know you can find all of his nav related topics by searching for the tag, Nog?” Right, I’m thinking the same thing.

Some other cool things you can learn at the new site today are:

Show me the perigee! Kicking off the AGI University Grant Competition – Yes, AGI will actually give you money to play with our tools  and create something cool.

How To Transform Between Earth Centered Fixed and Earth Centered Inertial reference frames using Vector Geometry Tool API – I do that all the time, do you?  Find out how here.

A new way to get help on your STK scenarios – did you know about the AGI Data Federate?  Checkout how you can get your scenario to support for them to look at using this technology.

These are just a few of the blogs up today at our new site, http://blogs.agi.com, stop by and see what else is happening in our world.

Here’s the address of our new blog site: http://blogs.agi.com ; ), be sure to visit often, and grab an RSS feed or two – we update daily.

So, a farewell to the Nog, but as with all good spirits, they live on in new forms, in new blogs. The ship’s lumber may change, but her heart is still at sea.

As always, smooth sailing.

Ted Driver

I decided to see how I could use AGI’s navigation library to prove the point - so I wrote a small application that runs over a single day, at 60 second intervals.  You can choose to calculate over one site or more, randomly picked around the globe.  So, over one site, I’ll get 1440 points of data.  The sites use a 5 degree mask angle above the horizon and the tool uses a SEM almanac and PAF file for July 1, 2010.

I want to show graphs of the following:

• The PDOP value against the number of GPS satellites
• The position navigation accuracy against the number of GPS satellites
• The position navigation accuracy against the PDOP value
• Oh, and a histogram of the number of available GPS satellites

So this tool serves two purposes – it let’s you play with the generated data, using as many sites as you like, to determine how much or how little the number of GPS satellites available affects your navigation error.  It also shows you how to create a simple program using (and how easy it is to program with!) our AGI components.  The components are free for development and personal use and can be downloaded here: http://adn.agi.com/detailedView.cfm?resourceId=240.

The Gizmo

So let’s look at the tool I created.  I built it using the C# .Net language (my favorite).  It’s a standard Windows form application, built using MS Visual Studio 2008.  If you want to build and run this tool yourself (HIGHLY recommended) you’ll need some things.  See the Appendix at the end of this Nog for details.  The main tool looks like this:

As the well-spelled-out instructions state, you just pick the number of sites you want the tool to use for the analysis, then press the calculate button.  Once the calculations are finished, you can select any of the four buttons to plot the results.

Let’s look at some typical results.  I’m going to pick 30 sites to use – that gives a better average number.

Number of GPS SVs v. PDOP

Here’s the plot of the Position DOP against the number of GPS Satellite’s available for solution.

As you may have expected, the PDOP value does decrease as we get more satellites visible above the mask angle – there is a clear decreasing trend in the data.

Number of GPS SVs v. Navigation Error

Let’s see how the navigation error looks against the number of GPS SVs.

There is no clear trend here, we get roughly the same spread of errors with 13 satellites in view as we do with 8.  There is a slight decreasing trend after 13 satellites though.  Build the tool yourself and play with the number of sites to see if this is an artifact of the random sites used for my run, or if these results are repeatable.

PDOP v. Navigation Error

So it doesn’t look like the number of satellites affects my navigation error – but does PDOP affect my navigation error?  Mathematically, we know it does:

Here Delta-X is the positioning error vector, G is the geometry matrix and delta-rho is the vector of corrected pseudorange errors.  The relationship is linear, though in a matrix framework.  Let’s see how this looks graphically:

Not as linear as you might see in a textbook example.  In fact, some areas of relatively high PDOP (4-5) have very low navigation error, meaning the  pseudorange errors are very small there.  Conversely, some low PDOP data points have a comparatively high navigation error, meaning the pseudorange errors are large at those points.

Number of GPS SVs Histogram

Just for fun, here’s the histogram of the number of GPS SVs at all 30 locations over the entire day.

There are roughly 10-11 SVs in view on average with the current constellation, above a 5 degree mask angle.

Conclusions

Based on this single run (and the 100 or so I’ve already done and seen), It is evident that the more SVs available to you, the better your DOP is.  This does not mean that your accuracy will be better though, as evidenced by the other graphs.  So, not to worry if you have fewer satellites after the optimization, it doesn’t really matter with the current level of performance 2SOPs provides us.

Appendix:  How to get and build the gizmo

You’ll need the following:

• MS Visual Studio or Visual Studio Express (free)
• The gizmo’s source code, unzipped to your favorite folder:
• AGI Components: http://adn.agi.com/detailedView.cfm?resourceId=240.

Once you have all of these installed and unzipped, do the following:

1. Open the project in Visual Studio
2. Be sure the Solution Explorer is visible (View|Solution Explorer)
3. Expand the References area and right-click, then select Add Reference…
4. Browse to the AGI Components install \ Assemblies folder and select the following assembly files:
   1. AGI.Foundation.Navigation.dll
   2. AGI.Foundation.Core.dll
   3. AGI.Foundation.Platforms.dll
   4. AGI.Foundation.Models.dll
5. Once those are added, right-click on the Project name and select Add | Existing Item…
6. Browse to the AGI Components install \ Assemblies folder again.
7. This time, add the licenses.licx file.  You may have to use the “All Files (*.*)” filter to see it.  Be sure you are adding the .licx file and not the .lic file that is also in that directory. (You should have placed the .lic file in that folder as part of the AGI Components install) Note the the .licx file tells the compiler to compile in the .lic file and thus license your application for use.  Without this, the application will throw a license exception.
8. Build and run the tool.  I've tested on Win 7 and Win XP.

Feel free to e-mail me with questions about running the tool, analysis results you see or any other general comments: navigation@agi.com.

Smooth sailing,

Ted

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:

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.

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.

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.

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!

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!

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!

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.

An initial thought would lead us to perform a linear extrapolation of the the data in a PAF file.  This will definitely produce navigation accuracy predictions, but not ones you'd want to use to search for your keys.  The plot below shows how the navigation error prediction grows dramatically as time goes on.  This is just not good at all,  in fact, I'd call this prediction: FAIL.  In the plot, the data prior to 12:00 is actual data, the data after 12:00 is predicted, based on the data before 12:00.  The linear extrapolation routine uses the information in the last data points of a PAF file, and extrapolates them based on their value and the values rate of change (first derivative).

So, besides linear extrapolation what else can we do?  I spent a lot of time thinking about this (which is why there have been so few Nogs lately) and I've come up with an algorithm that better mimics the PAF data and leads to much better predictions.  There are further refinements I make to this algorithm, but  I wanted to share the results I have so far.

The plot below shows two different satellite's clock error - a major contributor to the navigation position error.  This plot was taken directly from the GPS Satellite Performance page here.

With such different behaviors amongst satellites, I needed a method of prediction that was also varied.  The first cut at the prediction algorithm produced the results below:

These results are in the ballpark!  We're now getting closer to our navigation error prediction.  Using the same prediction algorithm on all data in the PAF file, using the same scheme as before, data before 12:00 is actual, data afterwards is predicted, I generated 30 samples of predicted PAF data.  The prediction algorithm is based on random numbers, so 30 different samples will all look different.  With these samples, I plotted them with the truth navigation error to see how well we faired.  This plot shows the results:

The thick red line shows the true position error, and the thick blue line shows the mean of the 30 prediction samples.  The other lines each represent one of the 30 predictions of the navigation position error.   These results are much better than the linear extrapolation method from above.  We can see the effect of Dilution of Precision (DOP) on the accuracy - where the truth data rises, we see similar rises in the predicted accuracy, but because half of the navigation accuracy calculation is based on data that is inherently random, we'll never match exactly.  The idea here is to get as close as we can.  I'd much rather use this new algorithm to find my lost keys - at least I know they are still somewhere near the kitchen!

Prediction is a tricky game, but the better we understand the problem, the more likely we are to get a better prediction.

I'll keep working on improvements to this algorithm, in the mean time, let me know your thoughts!.  My brain hurts, it's time for a Nog.

Smooth seas...

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