Technorati Tags: GPS,almanacs,SEM Almanac,Yuma Almanac,orbital elements

You need a GPS almanac, but there are two types generally available, SEM and YUMA.  Which one should you choose?  In this article, I'll outline their similarities and differences and explain the data contained in them.  The two almanacs both contain ephemeris data that you can propagate to give a rough position of each GPS satellite.  The orbits generated are very close to one another.  For example, in the picture below, the orbits are 12.1 meters apart, the maximum over a 24-hour period on the first of July of this year.

Both SEM and YUMA almanacs contain orbital elements - data that is used to propagate orbits.  The orbital elements are defined in the Interface Standard document IS-GPS-200D, on page 107.  A more detailed explanation of the elements is listed on T.S. Kelso's Celestrak site for both SEM and YUMA almanacs.  There are a couple of differences in these two almanacs.  I'll highlight those next.

An excerpt of the current YUMA almanac below shows the parameters used for propagation, along with other information:

******** Week 481 almanac for PRN-02 ********
ID:                         02
Health:                     000
Eccentricity:               0.8813381195E-002
Time of Applicability(s):  405504.0000
Orbital Inclination(rad):   0.9428253174
Rate of Right Ascen(r/s):  -0.7723429007E-008
SQRT(A)  (m 1/2):           5153.531250
Right Ascen at Week(rad):   0.3100656748E+001
Argument of Perigee(rad):   2.673376799
Mean Anom(rad):             0.2047160983E+001
Af0(s):                     0.1735687256E-003
Af1(s/s):                  -0.3637978807E-011
week:                        481

******** Week 481 almanac for PRN-03 ********
ID:                         03
Health:                     000

...

Specifically, the ID, Health and Af0 and Af1 values are not needed for orbital propagation.  The ID value specifies the Pseudo-Random Noise (PRN) number of the GPS satellite, defining that portion of the 37 week gold code that this particular satellite is designated to transmit.  The Health value is 000 if the satellite is usable - other health values are defined in Table 20-VII of IS-GPS-200D on page 109.  Anything other than zero's is generally not a good thing.  The two remaining parameters are clock correction parameters for the GPS satellite's on-board atomic clock.  Page 119 of IS-GPS-200D, section 20.3.3.5.2.3, tells how to construct the correct time for this satellite using these parameters.  One benefit to the Yuma almanac is that it is quite readable.

A portion of the current SEM almanac shows a much less readable format (at least for human's):

31  CURRENT.ALM
 481 405504

2
61
0
 8.81338119506836E-03  1.10626220703125E-04 -2.45927367359400E-09
 5.15353125000000E+03  9.86969709396362E-01  8.50962281227112E-01
 6.51631593704224E-01  1.73568725585938E-04 -3.63797880709171E-12
0
9

3
33
0
 1.14517211914062E-02 -5.35774230957031E-03 -2.65572452917695E-09

...

Notice however that there is more information here.  The SEM almanac lists how many satellites are contained in the almanac file at the top, 31 in this case.  This file type also contains the Satellite Vehicle Number (SVN) that is associated with the PRN.  The SVN is designated prior to launch of the satellite and can't be changed.  The PRN a satellite transmits on the other hand can be changed, depending on the needs of the GPS Control Segment.  So, a SEM almanac is a good way to map which SVN is transmitting which PRN over time.  In this case, PRN 2 is being transmitted by SVN 61.  Below the value 61, is a '0'.  this is the Average URA (User Range Accuracy) value as defined by IS-GPS-200D on page 84, section 20.3.3.3.1.3.  This defines how accurate this satellite is generally.  The higher the number here, the less accurate the satellite's navigation signal.

The orbital elements are the same, with two exceptions.  First, there is more precision in each element in the SEM file.  Second, Orbital Inclination in the Yuma almanac is represented in the SEM as an inclination offset from the nominal 54 degrees.  This allows the inclination to be specified with greater precision as well.

The final two numbers, '0' and '9' in the first record, are the satellite health and the satellite configuration respectively.  The health value is the same as in the Yuma almanac, but the satellite configuration is new.  This value represents the Anti-spoof status of the satellite as well as the type or Block of satellite.  Page 111, section 20.3.3.5.1.4 of IS-GPS-200D explain the configurations.

So, the SEM almanac has a bit more data in it and has a little more precision for the orbital elements.  Deciding which almanac to use is more a choice of which one you prefer, or have access to.  There's something to be said for readability, but a little more precision is always good to!  One other point to note is that with the transition to the new ground system computers, Yuma almanacs are now even slightly less precise.  I commented on this here, but didn't know at the time that only Yuma almanacs were affected.  Given all this information, if I had to choose (and I always do!), I'd choose a SEM almanac - but that's just me.

One last point, when using the Navigation Accuracy Library, which almanac you choose is immaterial - the methods to create the GPS constellation are identical.  This makes comparisons between SEM, Yuma, precise ephemeris, or broadcast ephemeris trivial.

using (StringReader almReader = new StringReader(@"C:\MyAlmanacOrEphemeris.txt"))
{
	SemAlmanac Almanac = SemAlmanac.ReadFrom(almReader , 1);
        PlatformCollection GpsSvs = Almanac.CreateSatelliteCollection();
}

To use a Yuma almanac, simply change the SemAlmanac statement to:

YumaAlmanac Almanac = YumaAlmanac.ReadFrom(almReader , 1);

This same technique works for Precise GPS ephemeris (in SP3a or SP3c format) or broadcast ephemeris in RINEX 2.11 or lower format.

I'd like to hear from you - let me know what you would like to see an article on, and I'll see what I can come up with.

Until next time, Smooth sailing!

Technorati Tags: A-GPS,Assisted GPS,predicted ephemeris,iPhone,e911

What exactly is A-GPS?  A-GPS for your GPS device is like a set of training wheels for your bike.  When you need help learning to ride, the training wheels keep you from falling flat on your face.  A-GPS helps your receiver find its position.  Unlike with training wheels however, you may need A-GPS over and over again.  Why do you need it?  What's it good for?  Let me explain...(grab a comfy chair - easier to do if you're reading this on your GPS enabled wireless device!)

When you use a typical GPS receiver, out in the open with lots sky available, and you don't really care how long it takes to get a GPS position fix, your receiver downloads almanac data for all satellites in the GPS constellation, then determines which satellites are above the horizon at your approximate position.  Once it knows this, it then proceeds to download the precise ephemeris broadcast from those satellites you actually have a shot at tracking.  It doesn't bother spending the time to download the precise ephemeris from the satellites on the other side of the Earth, you won't need that for hours yet.  Once it has the precise ephemeris (and a bit of other information it downloads), it can calculate your position within a few meters.  This is close enough to find your car in a parking lot - or for that matter, for anyone to locate you easily (you're the one holding the GPS receiver - doing the GPS walk).  Ok got slightly off topic.  So when do you not have the luxuries described above?  Turns out - most of the time.

Hikers, hunters, treasure seekers and other outdoor folk usually don't have an open sky issue, but urban dwellers often find themselves in a urban canyon.  In this situation, your GPS receiver can't readily lock on to the satellites it needs, delaying your position fix.  Not good - how can you expect your friend finder application on your new iPhone to work if your iPhone can't figure out where you are?

Additionally, there is a mandate for enhanced 911 (e911) services, that allow emergency personnel to know your calling location - even if you call from a cell phone.  This smacks of GPS-enabled cell technology - as long as you can get a GPS fix before you choke to death!  Not a pleasant thought.

Finally, I can get to the point.  A-GPS lets your receiver bootstrap it's positioning fix by delivering the precise satellite ephemeris over the cell network rather than trying to download it from each satellite.  Getting this data takes time and having it delivered right to your device helps find you faster.  Be aware, your GPS device still needs to have at least 4 satellites in view for a small amount of time to get a precise position for you.  There are other methods that your cell device can use to help position you, such as using cell tower locations to approximate your position (and provide a good initial guess to your receiver as your approximate position), so the emergency personnel then only have to look for the crowd surrounding you.

Another improvement can be made by not just passing the precise ephemeris received at the cell tower on the GPS devices in the area, but to actually improve on the quality of the ephemeris.  Remember the 'precise' ephemeris still has several meters of error in it.  It's possible using AGI's Orbit Determination Tool Kit, to get these errors down using a predicted ephemeris technique.  Contact me if your interested in this and I'll put in touch with the right people.

So, using your GPS in harsh environments (like the umbrella covered patio at Starbuck's), is now easier, mostly hidden from view of the casual user and more efficient thanks to the engineers who thought up this stuff.

Until next time, happy shopping.

Technorati Tags: GPS,GPS Satellite Errors,PAF,PSF

Ok, I like puns.  You'll see how this one fits in a minute.  Soon, a new version of our desktop navigation accuracy tool - NavTK version 2.3.4 - will be released.  One major change coinciding with this release is that we now have a new process for generating our GPS accuracy data - better known as Performance Assessment Files (PAFs) and Prediction Support Files (PSFs).  Previously, these files contained accurate estimates of GPS performance.  Now, with our new process these files contain the actual GPS ephemeris and clock errors.  Why are these errors important?  Read these Nog's of the past. The newest release of NavTK, as well as the AGI Components Navigation Accuracy Library, read in these new files and in fact, NavTK will go and find the correct file for your analysis situation - no need to hunt through the myriad FTP sites or cryptic download sites any longer.

So, we now use a new 'generation' scheme for our PAF and PSF files for our users (available for free) that include a new 'generation' of data quality.  To help visualize how well GPS satellites are performing, I developed a web application that allows you to visualize PAF and PSF data.  This application will allow you to view any PAF or PSF we have on our FTP site.  Here's the explanation from the web application - defining how the data is produced:

The PAF data is created by gathering the truth ephemeris and clock information (in .SP3 format) for a given day and differencing that data from the propagated broadcast ephemeris and clock information provided in the RINEX navigation file for the same day.  Both the SP3 and the RINEX navigation files are produced by the National Geospatial-Intelligence Agency (NGA) and available here.  The antenna phase center SP3 file is used to calculate the ephemeris and clock truth data.

The plotted values in the PSF graph are seven-day RMS's of the user range error (URE). The UREs are calculated using the Signal-In-Space (SIS) GOSPAR global URE formula, utilizing the data from each PAF file.  The seven-day RMS UREs for a specific PRN are constant for a given day, so the RMS URE values are plotted in a bar graph showing a three-day history of these values for each PRN.

The GOSPAR formula for user range errors (UREs, the quantity that affects your positioning error in GNSS systems) was defined in the late 1990's during the GPS Operational Control Segment (OCS) Performance Analysis and Reporting (GOSPAR) project.  This formula for the URE, sometimes called the global URE, is generated by integrating the UREs over the surface of the Earth.  The integrated formula follows:

where S is the surface of the Earth being integrated over, delta r is the ephemeris error vector for the GPS satellite and delta s is the clock error of the satellite.  The vector L is the line of sight vector between the GPS receiver and the GPS satellite.

The PAFs and PSFs have a 3-day latency, because the truth data produced by the NGA takes that long to produce.  Each day, the NGA data files are automatically retrieved, the PAF and PSFs are built and placed on our FTP site.  So, when we have the latest data - you have the latest data.

Read more

I'm at the ION GNSS meeting here in balmy Savannah Georgia and I've now heard from several people regarding the RAIM issue.  Here's the issue.

Pilots flying with GPS as their main navigation system or as a secondary system on selected routes must submit a RAIM (Receiver Autonomous Integrity Monitoring) report for their destination before flying.  This report defines whether GPS will meet some fairly stringent requirements for satellite  and signal availability.  The Federal Aviation Administration (FAA) is mandating this requirement.  The pilots, concerned with how they will meet this requirement asked the FAA - "how do we meet this requirement?"  The FAA responded by tasking the VOLPE center to develop a RAIM assessment tool.  This tool technically calculates RAIM, but it turns out, is not very useful to any pilot.

One pilot I talked with at the ION GNSS show said that it was too difficult to plan a route with the VOLPE tool.  Look at the tool and you'll see why.  Well, it's a good thing he was talking to us!  AGI has long been in the business of calculating access and coverage along routes - for virtually any kind of metric you can think of (no jokes here Kevin).  Here's an example:  the blue line represents a route in a mountainous area (Breckenridge I think) where there's a threat (large colorful communications jammer).  The white potato chip shaped thing is the Azimuth-Elevation mask for the jammer.  Any place below the potato chip the jammer is unable to see - above the chip - watch out. 

This route can be edited in the 3-D window to reroute around threats (or, say RAIM outages?) and reports run easily to determine RAIM outage times, etc.

I bring this point up because AGI has the technology to solve this pilots problem today.  Using our STK Engine and our components, an application can be built to make the RAIM reporting requirement a breeze and we can add the benefit of being able to give the pilot some additional valuable information!  Here's how.

Our Navigation Accuracy Library calculates RAIM (Fault Detection) and can report three types of RAIM outages for any location and time.  (En Route, Terminal and Non-Precision Approach) Our Dynamic Geometry Library comes with a waypoint propagator, useful for propagating routes of aircraft, land vehicles, whatever.  Our STK Engine provides 3-D graphing capabilities that can display routes (colored if you like) as well as coverage (a RAIM outage contour map for example).  Put these together in a single application and add some features like the following:

• Upload your own route file
• Database of predefined routes the Airline flies
• Recalculate the 'wheels up' time based on RAIM outages
• Create a handheld mobile application the pilot can use to initially assess RAIM for standard flight routes - from anywhere prior to flight.

There are many different versions of this scheme that could be put together depending on how the particular pilot or airline wanted to use the system.

There's another stick in the mud I haven't touched on yet.  The VOLPE center calculates RAIM in a specific way, using predefined vertical and horizontal alert thresholds.  I say predefined, because there is nowhere on their tool to change these.  There is no standard RAIM algorithm to use when calculating RAIM outages.  There are accepted algorithms in the literature, but nothing mandated by and interface control document (ICD).  Each GPS receiver manufacturer is free to calculate RAIM any way they choose.  AGI uses the accepted algorithms in the literature, but we allow the user/developer to define any alert threshold they like.  This provides more flexibility in calculating different RAIM outage thresholds.  AGI components are also flexible enough to be able to incorporate receiver manufacturer algorithms - with our without source code.

So, there is a great opportunity here for pilots to have a better system and a way to grow when future GPS availability requirements are enacted.  For more information on our technologies in this area, please contact me.

Technorati Tags: navigation,accuracy,utility,web tools,web service,web application,AGI,Google Earth,Space,satellite

Recently, I posted a Nog on some utilities and tools I created to help with the day-to-day engineering tasks faced when working with GPS.  Well, I've added to the mix (with help!) and put the collection in a single, easy to access place.  the tools can be accessed from the Web Apps/Services tab on the AGI developer Network: http://adn.agi.com/webServices/.

Here's a list of the GPS related tools there.  Some are repeats from the previous Nog, but I wanted to give you a complete list:

• GPS Date Calendar

The GPS Date Calendar displays a standard calendar with dates specific to the GPS community. Dates included are: GPS Week (current and full), day of week, day of year and time of week.

• GPS Navigation Accuracy

This web application calculates GPS Navigation Accuracy for the specified time interval and location of the GPS receiver. Specifically, it calculates Total System Error and Signal In Space Error and generate the appropriate reports and graphs. This application has been built using the Navigation Accuracy Library, which is part of AGI Components.

• GPS Satellite Outage Calendar

This Calendar displays historical, current and predicted GPS satellite outages based on the latest satellite outage file (SOF) produced by the United Stated Air Force. Clicking on a specific calendar date provides more information about the outage. You can also view all historical outages in a table format.

• GPS Satellite Outage Web Service

This web service allows you to connect and retrieve outage information for specific GPS PRNs, or specific time intervals, or both. Using just the PRN, a list of strings will be returned of all times that PRN has been unhealthy, based on the latest satellite outage file (SOF). Providing a start and stop time will return a list of strings denoting all PRNs that were unhealthy during that interval, with their outage times. Another service allows you to specify both the PRN and the time interval to further thin the results. The dates returned can be either Gregorian (standard date format) or Julian date format.

This example application shows how this service could be used.

• GPS Satellite Performance

GPS satellite performance is at the heart of navigation accuracy. AGI Performance Assessment Files (PAFs) and Prediction Support Files (PSFs), contain GPS satellite errors which AGI uses to calculate receiver positioning errors. This utility helps to visualize and understand those GPS satellite errors.

The following tools aren't specifically for GPS, but are just as handy in their own right. 

• Google Earth Satellite Database (Awesome tool!)

This KML network link visualizes all earth orbiting objects tracked by the United States Strategic Command (USSTRATCOM) using the satellite database processed by Analytical Graphics, Inc. using the Dynamic Geometry Library in AGI Components. All satellites are tracked in real-time and updated every 30 seconds. Please open this link using Google Earth.

• Satellite Tracker

This web application generates ground tracks on an embedded Google map, as well as ephemeris tables, for a user-selected satellite viewed from a user-defined location during a user-specified time period.

• Space Data Reporting (Web Service)

The Space Data Reporter is an example implementation of AGI’s new Dynamic Geometry Library (DGL). This suite of Web Services powered by the DGL enables users to:
- Publish ground tracks
- Derive current locations of satellites
- Calculate inter-visibility between satellites and locations on the ground
- Compute GPS dilution of precision (DOP)
- Analyze STK generated conjunction analysis (CAT)

Technorati Tags: almanac,navigation accuracy,ttff,ephemeris,PDOP,correlation,GPS

When you turn on your GPS receiver - what happens? Well, lots of stuff.  But primarily, GPS receivers work in a two stage process:

1. Look for available satellites to track
2. Do everything else

In this article, I want to focus on step 1, we'll get to step 2 later.  This is probably common knowledge, but for the record I want to state it.  The GPS receiver uses an almanac downloaded from a single GPS satellite to help it determine what satellites are above the horizon as it searches for signals.  Makes sense to not look for satellite signals that aren't even visible - it decreases your time to first fix (TTFF).  Since the receiver is simply determining whether a satellite is above the horizon, the almanacs don't have to be very accurate.  They are typically a coarser version of the precise ephemeris broadcast by each individual satellite.  In a recent Nog I discussed how well an almanac compares to the precise ephemeris - so I won't discuss that here.

What I do want to discuss is how long you can use an almanac for analysis.  Your receiver will usually download a new almanac when it sees that a new one is available, so it always has the freshest data.  When you do analysis though, sometimes you may not have the latest almanac (or the one correct for the time of analysis - a related problem).  So, is it ok to use any old almanac for analysis?  Since they are not the most accurate ephemeris representations, should I be using them for analysis anyway?  I'll answer these questions and show some interesting graphics that bring the point home.

For analysis sake, let's say we're interested in Position Dilution of Precision (PDOP) prediction.  PDOP is calculated from standard formulas and requires a source of ephemeris for the satellites.  You can calculate PDOP from precise, actual ephemeris, or almanac generated ephemeris, or whatever quality ephemeris you have.  I'll compare the PDOP calculated using the almanac to 'true' PDOP - that calculated from the precise ephemeris.

For our first analysis, let's look at 24 hours of PDOP values - using a precise ephemeris for the actual PDOP and a three week old almanac to generate the ephemeris for the predicted PDOP.

The actual PDOP is in yellow, with the almanac predicted PDOP in pink.

Read more

Technorati Tags: ephemeris,SEM Almanac,navigation,software tool,utility,SP3

As an engineer and a developer, I tend to be pretty needy.  I need access to arcane bits of information that sometimes can be hard to find.  Usually when I find that information, I go on my merry way and continue my analysis.  Then I happen to need it again.  Frustrated that I didn't save a link to the info last time (and even if I did save a link my bookmarks get so unorganized that I can't find it), I go searching again.  That was then.  I've wised up a little bit, and started creating utilities that provide the information I use regularly in one (or more) handy place.  Let's look at a couple of examples.

First, before I can do any analysis with GPS, I need some type of ephemeris element set from which I can propagate the GPS satellites.  Usually I use an almanac, but we'll look at SP3 files as well.  So, first thing I need is a location for these types of files.  Luckily, AGI has an FTP repository that contains SEM almanacs.  So, I go to this year's directory and see about 200 files and they all have names with lots of numbers in them, like this: almanac_sem_week0465_589824.al3.  Which one do I pick for the analysis I want to do?  It's little things like this that frustrate us analysts and engineers.  Turns out that the almanacs are named according to the almanac element epoch, in the number of weeks since the latest GPS week rollover and the time of week in seconds since Sunday midnight - were you expecting something else?  Discerning which almanac file is the best for my analysis brought me to my knees over and over again.  At first, I created intricate spreadsheets that calculated these numbers, but they had to be updated regularly and then I lost the spreadsheet.

Take another example, the precise ephemeris for GPS satellites that the National Geospatial-Intelligence Agency (NGA) produces.  These files have equally cryptic names: nga14000.sp3.  The NGA description says that the file naming scheme is

ngawwwwd.[sp3], where wwww is the gps week and d is the day (Sunday being 0 through Saturday being 6)

The catch here is that the GPS week they are referencing is the GPS week since the beginning of GPS time on January 6, 1980.  So the file I found above is for Sunday (d=0) of GPS week 1400.  Is week 1400 what I'm looking for?  More back of the envelope calculation time.

I needed a better way.  I decided that if I could keep one set of data organized - my browser bookmarks - then maybe I had half a chance of finding what I needed when I needed it again.  So, I created a perpetual GPS Calendar that displays all the days and dates that were of interest to me, GPS weeks, days and dates of interest.  Here's the Calendar: GPS Calendar. This calendar lists Julian days and Julian dates as well (yes, they are different!) - you never know when you have to know what Julian day it is -

PAF Files: 2008_203_v02.paf

PSF files: 2008_203_234500_v01.psf

SOF files: 2008_205_204839_v01.sof

Oh right!  So take a look at this Calendar, especially if you are doing any type of navigation analysis.  You'll run across these files types eventually, and need to know how to relate them to 'real' dates.  I've put a link to it on the Nogroll on the right side of the page under the Utilities category.

Well, nothing monumental in this blog, but taking care of the details can be a big hassle when all you really want to do is finish the analysis - like trying to bail all of the water out of a sinking boat so you can get to the hole to fix it!  Whenever I run across or develop a new tool or utility, I'll post a blog on it - so you can keep things moving along too - without being brought to your knees.

Technorati Tags: Ionosphere,navigation accuracy,almanac,STK

This is the last installment of the Ionospheric Error Analyst blog.  I've written two previous blogs on this mashup application, describing how you can calculate near real time navigation accuracy, including ionospheric effects, and display them on a globe.  In this installment, I'll complete the project and provide a download of the entire application so you can build it on your own and use it.

When we left off, the last pieces we needed were the time and positions to calculate and then finally, the actual navigation accuracy calculation itself.  To provide the time to calculate, we need to look at the filename of the TEC file.  Remember the TEC file contains the total electron count data  we need to calculate the navigation error due to the ionosphere.  The filename contains the date the TEC data is valid for - and it's valid for 15 minutes after that date.  Parsing the name and generating a date from the name elements is straight forward:

// sample TEC filename
// 200706102130_TEC.txt
// 01234567890123456789
year = Int32.Parse(filename.Substring(0, 4));
month = Int32.Parse(filename.Substring(4, 2));
day = Int32.Parse(filename.Substring(6, 2));
hour = Int32.Parse(filename.Substring(8, 2));
minute = Int32.Parse(filename.Substring(10, 2));
// add 15 minutes to file timestamp - we want latest accuracy
return new JulianDate(new DateTime(year, month, day, hour,
  minute, 0)).AddSeconds(900);

What about the grid we need to calculate over?  That's easy too.  We start with the bottom left grid point defined by the user and simply increment that by 1 degree for the entire area specified in the GUI.  I'll use a 1 degree step because the TEC data is defined with this increment.  Each time the grid point location is calculated, it's stored in a List of ContourCells.  The ContourCell class simply stores the four vertices of the cell as well as the cell ID and a definition of which of the four vertices of the cell the accuracy calculation will occur on.  You could change this implementation calculate for the middle of the cell - or somewhere in between too if you like.  In the interest of saving space, I'll let you browse that code on your own.  Look for the CalculateCONUSGrid method.  Note that the TEC data from NOAA is defined only over the continental United States (CONUS).  There's no error checking in the application to ensure the user has entered the correct latitude/longitude boundaries however.  You'll even get results for areas outside of CONUS.  The point is, be sure to understand the limitations of the data you use - otherwise your analysis will be flawed.

Read more

Technorati Tags: GPS,station keeping,atomic clock,NANU,GPS anomaly,GPS outage

Do you SOF?  You should.

Your GPS receiver doesn't care - it doesn't have to - if it's made right.   When a GPS satellite should not be used by your receiver, an appropriately set 'health bit' is sent down by the satellite and your receiver will ignore it magically.  When the health bit is set back to 'healthy' you receiver will start using it again.

GPS satellites are set unhealthy for a variety of reasons:

• On-board atomic clock maintenance
• Satellite station keeping (keeping in the same relative spot it orbit)
• Satellite malfunctions

just to name a few.  Since the satellite is always transmitting it's pre-calculated position and precise timing information, if you are using that satellite as part of a navigation solution when the satellite deviates from that information, you'll get very large position errors.  Since most receivers operate in real-time, there's not much to consider.  When you do analysis though, you need to SOF.

The SOF (Satellite Outage File) is a file containing all the historical, current and predicted outages for the GPS satellite constellation back to 1998.  Whenever a satellite is out for some reason, a NANU (Notice Advisory To NAVSTAR Users) is sent out by the GPS Operations Center.  This NANU's information is also added to the SOF file maintained by the Air Force.  The SOF file is an XML-based file that can be read easily by machines - you don't have to write code to parse the text data in the NANU message to get the information.  Here's a sample:

<?xml version="1.0" standalone="no"?>
<GPSISFILE FILEID="SOF" SYSID="GPS">
<CREATION YEAR="2007" DOY="183" HR="17" MIN="12" SEC="14" />
 REFERENCE YEAR="2007" DOY="183" HR="17" MIN="12" SEC="14" />
<HISTORICAL SVID="8" SVN="38" NAME="NANU" TYPE="UNUSABLE"
 REFERENCE="1998006" START_YEAR="1998" START_DOY="009"
 START_HR="009" START_MIN="55" START_SEC="00" END_YEAR="1998"E
 END_DOY="009" END_HR="22" END_MIN="56" END_SEC="00" />
<HISTORICAL SVID="29" SVN="29" NAME="NANU" TYPE="FCSTSUMM"
 REFERENCE="1998007"START_YEAR="1998" START_DOY="012"
 START_HR="12" START_MIN="25" START_SEC="00" END_YEAR="1998"
 END_DOY="012" END_HR="18" END_MIN="55" END_SEC="00" />

Using a SOF file in the Navigation Accuracy Library is not required.  You don't have to take any satellites out when performing your analysis. What's so hazardous about this then?  The hazard lies in the predictions.

Suppose you're predicting GPS accuracy for your mission next week.  The GPS Operations Center has sent out a NANU telling users that satellite XX will be out that same day.  If you don't take the satellite outage into account, you may have predicted better GPS accuracy than you'll actually be receiving.  True, this will only be a DOP effect, but unaccounted for, it still presents misleading information.

Using a SOF file in your AGI Components navigation accuracy calculation is easy.  You may already have something like this to get your GPS constellation setup:

SemAlmanac almanac = SemAlmanac.ReadFrom("almanac.al3", 1);
PlatformCollection constellation = almanac.CreateSatelliteCollection();

Add the following lines:

SatelliteOutageFile sof = SatelliteOutageFile.ReadFrom("2007_227.sof");
sof.PopulateConstellationOutageData(constellation);

Now the constellation is aware of all the outages and the evaluator will take them into account when evaluating accuracy.

For a quick glance at the outages defined by the latest SOF File, check out our GPS Satellite Outage Calendar.  You can retrieve the latest SOF file there as well.

Everyone needs a vacation, so do yourself a favor and don't make the satellites work when they're off...  SOF it!