Archive for June, 2008
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!No comments
I get questions sometimes about which almanac format to use to propagate a GPS ephemeris, which one is better; SEM or YUMA? A SEM formatted almanac has almost the same parameters as a YUMA formatted almanac, except for the inclination parameter. SEM almanacs use an inclination offset from the nominal 0.3 semi-circles (54 degrees) whereas the YUMA almanacs provide the actual inclination angle. This isn't the issue I'm discussing here though. Before I get to the issue, let's look at how well SEM and YUMA almanac generated ephemerides agree. I generated an ephemeris for July 1, 2007 using both the current SEM and YUMA almanacs for the time. I took the difference in each position reported and plotted these differences here:
For this day, the biggest difference in positions was roughly 0.36 meters. Looking at the difference between the almanacs and truth data, we can find out which almanac is closer to truth. To see this, I'll use the SEM ephemeris (S), the YUMA ephemeris (Y) and the truth ephemeris (T), and create a second difference to see the effects, so:
T-S - (T-Y) = Y-S
or, the difference between how well the Yuma or SEM compare to truth. This difference is plotted here:
This plot is always positive, meaning the YUMA almanac is always slightly worse at predicting the actual ephemeris. One reason for this is the accuracy of the parameters in the file, including the inclination vs. inclination offset issue discussed above. I want to remind you though, that the almanacs are not intended to provide a very accurate ephemeris - only a rough estimate of position. The almanacs are created to allow receivers to quickly assess the visibility of satellites - whether they will be above or below the horizon based on the receiver's current position. Nevertheless, almanacs are useful for DOP and accuracy calculations and are widely used for this purpose.
OK, so we see similar results and SEM almanacs are a little more accurate than YUMA. So...?
So - something happened.2 comments