Archive for February, 2009
GPS gets its due
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.
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... .
2 commentsNavigation Error Predictions – Part 2
In the last Nog, we left off trying to figure out how to predict GPS behavior from the data I showed you. Our GPS error prediction problem involves predicting the Signal-In-Space User Range Error (SISURE), to the extent possible. From this picture, we came to the conclusion that trying to fit some type of periodic function to this data was going to be difficult. So, where do we go from here? In situations like these, I'll always recommend that more data analysis can help, and this case is a perfect example. The picture linked above shows only one day's worth of SISURE values - the next question we should ask ourselves is; is their a long term behavior to this data? Let's find out.
GPS Satellite Error Trends
I gathered over 800 days of SISURE data, and looked at the maximum clock error, ephemeris error and the combined user range error for that period. The following plots show what the maximum errors look like. To keep the plots readable, I've only plotted two satellite's worth of data in each.
These plots show something good. The errors in both clock and ephemeris (and hence the SISURE) are clamped. This means that they do not grow past a certain value - a value we can estimate and use to our advantage. Even when the errors oscillate over the day, we can say that on average, the errors will not go above some value. This clamping behavior is not a result of GPS system mathematics or design stability. It's the direct result of active participation and monitoring by the 2nd Space Operations group (2SOPs) - the Air Force squadron that runs the GPS Control Segment.
This may be old information to some, but I want to be clear on why these errors do not grow. The GPS system continually broadcasts its position and clock state information to users world wide. The information the satellites broadcast was predicted by 2SOPs and uploaded to the satellite roughly 24 hours earlier. When this predicted data is sent to a GPS satellite by 2SOPs it's called a nav upload. Nav uploads only occur when they are necessary - that is - when a satellite's predicted position differs from it's actual position (For the ringers in the audience - that's the Kalman Filter's estimated position). So the maximum error a satellite will broadcast is determined by 2SOPs - they do the clamping. Without this clamping, we would see errors that increase roughly quadratically over time. Thanks 2SOPs!
Using the Clamped Errors
Looking at the above graphs, we can see that using an average of the errors will give us a good number to use in our predictions. There are long term trending issues, especially with PRN 1's ephemeris error in this case, so we'll have to take our averages over shorter periods. These average values will help us predict our GPS accuracy statistically, over longer periods of time. Obviously, we can't use these numbers to predict the short term behavior of the SISUREs, but we can identify how each satellite performs and get statistical estimates of GPS accuracy for longer periods. This is exactly how the Prediction Support Files (PSF) are used. If you've used AGI's Navigation ToolKit or the AGI Navigation Accuracy Library Component at all, you'll be familiar with PSF files. A PSF file contains the root mean square values (RMS) of the ephemeris components and the clock for each satellite over the last seven days. A graph of this data is available here: http://adn.agi.com/GNSSWeb/PAFPSFViewer.aspx (second graph on the page). Here's the graph from today:
You can see that some satellites perform much better than others, and it's this type of differentiation we want to take into account when predicting GPS accuracy.
Predicting Long Term GPS Accuracy
Warning: Statistics Ahead
Using this PSF data, we can predict GPS accuracy. We cannot predict specific errors in a given direction (East, North, etc.) but we can predict a statistical GPS error for any location given a confidence level we want to use. Recall the Assessed Navigation Accuracy Nogs from several months ago. In these, I outlined how to generate GPS errors from a previous time using PAF data. Using that same method, we can use PSF data to generate future GPS errors - but only the RMS value of the error - not the actual error. The RMS values produced from the GPS navigation accuracy algorithms have probability distributions associated with them, depending on what type of prediction we are using. One-dimensional predictions, like east error, vertical error or time error will have the standard one-dimensional Gaussian probability distribution. This means that the RMS prediction of these values will have a 68% probability of likelihood, 1 sigma. Multi-dimensional statistics are required for predicted values of horizontal error and position error. For the two dimensional horizontal error, the predicted RMS value has a 39.4% likelihood 1 sigma. Three dimensional position errors have a 19.9% likelihood 1 sigma. These 1 sigma values are not constant for the different dimensions, making comparisons difficult. These predicted values can all be scaled to a specific 1 sigma level, or confidence level, using scaling factors derived from past GPS error data. For example, to compare the East, Vertical and Position errors, we would use different scale factors to convert the predicted RMS values for each of those metrics to a 95% confidence level. Theoretical scale factors are listed on the internet, but the theoretical values don't accurately model the behavior of GPS. The AGI Component Navigation Accuracy Library provides a scaling interface using scaling factors derived from empirical data, more accurately representing the GPS constellation behavior.
The graph below shows the empirically derived scale multipliers, using over 600 days worth of data.
The tables below show the actual scale factors to use for the different metrics, with their associated errors.
50% Confidence Level multipliers
Dimensions |
Empirical Value / |
Theoretical |
1- Vertical |
0.6323 / 0.0223 |
0.6745 |
1- Time |
0.6084 / 0.0220 |
0.6745 |
2 - Horizontal |
0.7824 / 0.0236 |
0.8326 |
3 - Position |
0.7551 / 0.0236 |
0.8880 |
95% Confidence Level multipliers
Dimensions |
Empirical Value / |
Theoretical |
1- Vertical |
2.0096 / 0.0316 |
1.960 |
1- Time |
2.0230 / 0.0281 |
1.960 |
2 - Horizontal |
1.8109 / 0.0431 |
1.731 |
3 - Position |
1.8433 / 0.0380 |
1.614 |
So, using this scale data and the PSF data, what do my predictions look like? The graph below has the actual error in red. The 95% confidence predicted GPS accuracy is in blue and the 50% confidence predicted GPS accuracy is in green. Notice that roughly only 5% of the actual errors are above the blue line, and roughly 50% of the actual errors are above the green line. Notice also that the shape of the 50% line and the 95% line are identical. This is because they are the same prediction - just scaled differently.
There's one more thing you should be aware of when predicting navigation accuracy. The confidence levels you pick won't always be adhered to. Because of the day-to-day variability of the GPS system, the multiplier values are not constant for a given confidence level. This is evident from the Confidence Interval Multiplier Analysis graph above. In the Actual and Predicted Position Errors graph, the true percentage of actual errors above the 95% prediction line is 6.8%, not 5%. This makes me wonder, how long can I use a PSF file to predict my GPS accuracy before the PSF data, or the multipliers become too old to use?
How long can a PSF file be used?
To see if I could find out, I plotted the excursions (the percent of actual GPS errors greater than the predicted GPS errors) for 155 days, using the same PSF file. The PSF is brand new for day 1, but as we head towards day 155, the PSF file becomes increasingly older. If there is any correlation between older PSF data and GPS accuracy prediction, we'll be able to see it.
The graph says it all - there is no difference in the number of excursions based on PSF age. If there were, we'd see an increasing trend from left to right, meaning more actual errors were breaking the 95% confidence threshold. This implies that a PSF file is good to use for longer periods of time, but in using one, you must expect that sometimes the GPS errors will be worse that you expected.
If you've made it this far, congratulations! The topic is not an easy one and you have to be a die-hard stats fan to keep at it. Enjoy your Nog and tell everyone at your next party that you know GPS prediction excursions aren't constant, but can they tell you why?
Next time, I'll cover the art of short-term GPS error prediction. We'll move away from stats for awhile, but we may ask Taylor for a little help...
Until then, smooth sailing.
No comments