Archive for the 'General Navigation' Category

The Nog –The End

October 08th, 2010 | Category: General Navigation

Eventually, we always come to the end of our Nog, and thus it is with this one as well.  As AGI moves to a more centralized blogging architecture here:, I will no longer be making Nog posts at this location.  AGI assures me that the blogs I have posted here will remain, so feel free to use these as a reference source and continue to comment.  I will repost well read items from here onto our new site:

From now on, I’ll be blogging on our new site:, as one of the regulars.  On The Nog, I’ve been restricted to topics relating to navigation, but on our new site, I can branch out and discuss other things as well.  I will still post navigation related posts at our new site,, 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 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,, stop by and see what else is happening in our world.

Here’s the address of our new blog site: ; ), 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

No comments

GPS Control Segment software “Glitch”

January 24th, 2010 | Category: General Navigation
Technorati Tags: ,,,

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

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

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

Navigation Potpourri

September 25th, 2009 | 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:


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:


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.


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

SVN 49 Navigation Data parameter changes

June 24th, 2009 | Category: General Navigation,Navigation Accuracy

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

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

June 19th, 2009 | Category: General Navigation,Navigation Accuracy

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.


SVN 49, PRN 1 URE too high

May 03rd, 2009 | Category: General Navigation,Launch

After the last Nog, someone pointed me to the following picture, published by the GPS Operations Center from this site:, (pick the Position Errors By Satellite value in the drop down box)


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.


SVN 49 – not healthy yet – what’s up?

April 29th, 2009 | Category: General Navigation,Launch

SVN 49, PRN 1 was launched Mar 24 and if previous experience is any guide, it should have been set healthy quite awhile ago.  The standard time frame for this activity is a month, but we're over that mark now.  This satellite is also broadcasting the new L5 signal.

The GPS Operations Center says that the Air Force is continuing testing on that satellite and will be releasing a statement regarding this issue.

So what are the possible issues?  Caution, speculation ahead!

The satellite is on-slot, it's been in the almanac since late March.  It started broadcasting L5 on April 10, but still remains unhealthy for navigation using L1-L2 C/A-P(Y).  The time between when it's on-orbit and it becomes healthy is usually spent characterizing the on-board clock - the heart of the navigation and timing function of the satellite.  Once the clock has "settled down" (a technical term), it can be set healthy for navigation.  So, one could speculate that there is a problem with one of the clocks (there are three Rubidium atomic clocks on-board each GPS IIR satellite), or possibly an issue with the addition of the L5 signal.  If you have a receiver that tracks through the unhealthy setting on the satellite, you could watch the how the signal changes over time and make some conclusions.  If you do, I'd love to hear from you!

Until we get an official word from the Air Force, we'll just have to be content with our 30 healthy satellites.

No comments

GPS SVN 35 decommissioned

March 26th, 2009 | Category: General Navigation

Just a quick note for all of you keeping score, today (Mar 26, 2009) at 2031 UTC, the US Air Force decommissioned SVN 35 (PRN 5) per NANU 2009023.  It was on it's last clock, and in fact had be turned off before.  It was brought back to keep the constellation coverage up.  With the launch of the new satellite, and PRN 5 's declining behavior (See GPS Satellite Performance), it has now been shut off for good.  PRN 5 is now available for reuse by a future GPS satellite.

No comments

Block IIR launch Imminent and Block IIF Woes

March 21st, 2009 | Category: General Navigation,Launch

InsideGNSS and Patrick AFB are reporting that the latest Block IIR satellite (IIR-20) is ready for launch.  The launch is scheduled for March 24, 2009 between 0434 and 0449 EDT.  The GPS Operations Center reports that IIR-20 also known as SVN 49, will take PRN 1 and be placed in slot B2.  This slot is currently occupied by PRN 30, so this new IIR is probably a replacement.

SVN 49 has an L5 payload aboard and is intended to secure the L5 spectrum GPS is planning to use for civil signals.  According to InsideGNSS:

Meanwhile, the U.S. Air Force is in a race against the clock to get the new L5 signal on the air by August 26, 2009, in order to meet an International Telecommunications Union (ITU) deadline for securing a preferential L5 frequency allocation for GPS operations.
Problems have pushed the GPS program much closer to the deadline that expected.

The first and probably only opportunity to meet the deadline: a modernized GPS Block IIR-M satellite — IIR-20(M) — with an experimental L5 signal demonstration payload scheduled for a March 24 launch.

But if there are problems with the launch or the vehicle - ?:

“Originally, the U.S. planned to meet the deadline with the first IIF satellite,” said the [GPS Wing] spokesman. “The IIR-20 demo payload was developed as the back-up plan.”

If GPS cannot secure the L5 spectrum before August 26, 2009, ITU regulations state that GPS risks losing unconditional use of that band - instead providing priority usage of that spectrum to which ever GNSS system begins broadcasting on it first - so hopes are high on this launch and success of this vehicle.

Block IIF problems

The Block IIF program has suffered a recent setback - a power anomaly affecting all signals on the L2 frequency discovered during testing.  According to InsideGNSS:

Discovery of a power anomaly in signal generator of the first GPS Block IIF space vehicle (SV) has thrown a new wrinkle into the long-delayed follow-on generation of spacecraft.

In the words of a GPS Wing spokesman at the Space and Missile Systems Center (SMC), Los Angeles Air Force Base, California, “In reviewing test data from the final phase of SV1 thermal vacuum test, [government and Boeing mission assurance teams] identified a new concern that a component in the L2 transmitter may not have sufficient design margin to operate at its highest required power throughout the satellite lifetime.”

“Boeing has identified multiple options for addressing the concern and is working parallel solutions to deliver redesigned transmitters this summer,” said the GPS Wing spokesman.

The launch of the first IIF satellite was expected in October of this year, but that has now been moved to "late 2009" with a second launch not to be scheduled for at least 6 months afterward.

No comments

GPS gets its due

February 28th, 2009 | Category: AGI Products,General Navigation,Satellite Tool Kit

We get no respect!  That's what the AGI Product Managers used to hear me say - no respect - just like Rodney Dangerfield.  That's the way it felt using STK for GPS analysis.  Use a TLE for the orbits?  What's a TLE?  How do I bring in an almanac?  Really, there's a separate tool to do that?

Well, GPS's time has arrived.  With the release of STK 9 coming soon, GPS gets the respect its due, and then some.  Those of us in the GPS world know there are other satellites in the sky - especially since they can't seem to stay away from one another.  But - we really only care about one very special set of satellites.  Prior to STK 9, GPS was just another wallflower at the satellite party - but now, everyone wants to talk to her.

I'll give you some examples - if you're familiar with STK already, you'll feel the love in the next set of pictures.  If not, now you have to try it, you'll see why - and it's not just about GPS either.

Here goes, after starting STK 9, and creating a new scenario for today (with one-click!), you get the brand-spanking new Insert STK Objects dialog:


For the Satellite scenario object, you can either select Load GPS Constellation or Select GPS Satellite From Catalog. 25% !! We have 25% of the options to load a satellite into STK!  25% is fine - we'll let the other dozen thousand or so satellites have the other 75%.  (Though technically we could add GPS from most of the other options as well).  When you select the Load GPS Constellation option and click the Insert... button, STK will go to the continuously updated AGI data servers and grab the latest GPS almanac, create a new GPS satellite object for each item in the almanac, naming them appropriately, and also create a GPS constellation object.  So far, after starting STK we've used three, count them, THREE clicks of the mouse to load the complete, up-to-date GPS constellation for today in a new scenario.  Now that's service.GPSConstellation

The picture at right shows the objects STK 9 created, note the SVN and PRN number in the satellite name.

Suppose you want to use your own almanac - or one from a different date?  Just select the Select GPS Satellite From Catalog Method and you'll get a new dialog that allows you to specify further details for your constellation:


Here, you get detailed information about the current almanac and the ability to load your own almanac.  The Catalog source options at the top allow three options:

  • Automatic - AGI Server: Allows STK to pull the the required almanacs from the AGI server. When you change the scenario time, STK will go to the server and update all the satellite's almanac data for you.  Respect!
  • Automatic - File: Will load the same file from your local storage anytime the satellites are told to propagate.  This is useful if you update the files automatically by some other method.  If you choose the GPSAlmanac.al3 file for example, then use the Data Update Utility in STK, the GPS almanac in your local storage will be updated regularly, and the GPS satellites in your scenario will propagate accordingly.
  • Specify Catalog: A specific almanac you choose, that will always remain with the satellite - no updating is done at all.

The table lists the PRN, SVN, SSC (NORAD Catalog identifier), Health and Average URA information contained in the almanac for each satellite.  The SSC number is not contained in the almanac, but read from a cross-reference list maintained by AGI. There is an additional column that specifies the Span: specifying when a given PRN was not available.  For example, currently PRN 1 is not assigned to a GPS satellite, in the past it was though.  If your scenario contains a long time span, there may be times when PRNs are unavailable because of PRN reassignment among satellites.  The Span column will tell you whether a PRN is early or late, meaning that it disappears earlier than the scenario end time, or appears later than the scenario start time.  In either case, the PRN is not available for the entire scenario interval.


Looking at the properties of a single GPS satellite above, you can see that there are a lot more details to drool over. Not only is the propagator the correct IS-GPS-200D GPS propagator, but you can change the almanac source for this single satellite - accepted types of ephemeris information are SEM and YUMA almanacs as well as SP3 precise ephemeris files.  I didn't mention it above, but you also load the entire constellation from a single SP3 file as well.  Additional information regarding the GPS week number, the epoch and PRN can be viewed and changed here.

In coming Nogs, I'll go further into what you can accomplish with STK for navigation analysis.  STK 9 has significant advances not only with respect to navigation analysis, but in usability and functionality over all of its feature sets.  We just happen to care more about one of these feature sets than the others... :) .


Next Page »