## Archive for the 'AGI Products' Category

### Number of GPS satellites – does it matter?

August 07th, 2010 | Category: Navigation Accuracy,Navigation Accuracy Library

In a previous Nog I wrote, an interesting result showed up.  The Second Space Operations Squadron (2SOPs) is currently in the midst of rephasing several GPS satellites – to optimize the coverage the entire constellation provides.  I analyzed the coverage before and after the optimization and showed plots of the coverage in both instances.  In one of the plots, the sheer number of GPS satellites available for your GPS receiver goes down AFTER the optimization.  This is a little non-intuitive, especially for those of us who have been in the GPS business awhile.  We tend to equate Dilution of Precision (DOP), that value associated with the GPS satellites’ orientation, with navigation accuracy.  This is somewhat true, but not always.

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:

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

No comments

### GPS Accuracy Failing – Seriously?

May 23rd, 2009 | Category: Dynamic Geometry Library,Navigation Accuracy

The scare level regarding the General Accounting Office report on the risk of future GPS failures is rising precipitously.  Let me be one of the first to say - hold on, there's no reason to panic, or sell your Garmin (GRMN) stock.  Many consumers have purchased the now ubiquitous GPS handhelds that tell you where to go.  Providing accurate positioning maps and voice response, they are a tempting buy (but not for me yet, somehow...).  Most folks even regard their device as the GPS, not the system that provides the location signals to their device.  So, what's the truth behind the failure cry and how bad is it really?

The General Accounting Office report, available here: GAO GPS Report, states there is increased risk of future GPS coverage failures because of acquisition problems - basically the next generation of GPS satellites; the Block IIF satellites, are behind schedule.  Also, there are several GPS satellites that are "single-string" meaning they have lost redundancy on one or more components.  This means that if the current component fails, the satellite may not be able to perform its navigation mission.  The GAO report is reporting on increased risk, it is not reporting on GPS failure.  The conclusion in their report is essentially, let's keep a close eye on it - by recommending the appointing of a single GPS oversight authority.

Let's talk specifics - what if the risks the GAO reports were actually to occur?  What if 6 or more satellites were to fail, with no additional satellites being launched and no GPS satellites being moved in orbit to counter poor coverage?  How bad would it get - really?

With that problem statement, I made the following conservative assumptions in order to analyze the problem:

• A GPS user has a 12 channel receiver (able to track 12 GPS satellites at once)
• A GPS receiver won't use any GPS satellites within 5 degrees elevation from their horizon.
• The GPS Receiver will have a combined error of 2 meters (Signal-In-Space and receiver noise, multipath, etc)

Let's look at today's GPS coverage:

This picture shows the maximum navigation error, over 1 day, for the world.  The legend is:

where I've used 10 meters as the max because it's about the width of a typical neighborhood street.

So, everywhere in the US for example, the maximum error you'll see during the day is under 6 meters - roughly half the width of the street.

What about the dark areas?  How bad is the accuracy in those areas, and more importantly, how long is it bad?

The plot below shows that in the dark area in Canada, over the entire day, only a small amount of time is spent with the larger navigation error - roughly 10 minutes.  Even then, the error is only about a street width and a half.

Ok, now on to the fretful stuff.  The GAO is reporting that, because of acquisition issues, GPS accuracy may begin to suffer starting as early as 2010.  Let's look at the situation where GPS starts to lose 1, 2, 3 and more satellites and see how bad our accuracy suffers as a result.

This video shows, in each frame, one additional GPS satellite removed.  There are a total of 9 frames, corresponding to 9 satellites removed.  To decide which satellites to remove, I used data that shows which satellites are most likely to fail based on their loss of redundancy.  I did not use any reliability numbers for these satellites, simply the state of their on-orbit hardware as of March 2009.  The most likely to fail satellites are taken out first, and so on.

The video starts to show some scary colors as we begin to remove large numbers of satellites, but remember - this is the maximum error you will see over the day.  The video points out that instead of localized larger navigation errors like we have today, many more people experience these large errors - but again, for only a short time.  Here's a plot of the worst case scenario along the Eastern seaboard, where 9 GPS satellites have failed, none have been launched, and no movement of GPS satellites has taken place to optimize the coverage.

Throughout the entire day, the accuracy never exceeds 22 meters (about two street widths) and averages roughly 4 meters (less than half a street width).

To counter the scary picture the video paints, I created the plot below to show the average navigation error for the world over one day, with 9 GPS satellites missing.

This result shows that we will still have sufficient GPS coverage for most navigation needs even if the worst was to happen.  For those users in more constrained environments (like canyons, urban or natural) or that have more stringent navigation requirements than knowing which road they are on, there will be additional effects.  It is unlikely that any of this will happen however, given the Air Force's track record for management of the GPS constellation.

So, keep you GPS unit, which ever kind you have, and don't over react when we hear more stories about how GPS will fail - we're nowhere near that result.

Smooth sailing, with an eye toward the sky...

No comments

### GPS Daily Accuracy on Twitter

I was a little reluctant to open a Twitter account, not because I didn't think the tech was cool, but could I possibly have that much to say each day?  In such short sentences?  Well, I figured out that on a daily basis I may not have much to say, but GPS does.  I wanted to provide some useful information to GPS followers, something that could be said in a few words.

To that end, I created an account on Twitter with a user name GPSToday.  This account I figured, could send 'tweets' to followers about GPS events, like accuracy statistics, satellite outages, etc.  But this type of information would take a lot of my time to create and update on a regular basis.  Ahhh, but wait, the AGI Navigation component can be coded in any way, shape or form.  I could use this to create a program that automatically did what I needed and produce the results automatically.

The first application: GPS Accuracy Stats over the globe each day.  Whether you're aware or not, GPS accuracy varies each day - due to satellite outages, GPS signal quality and many other factors.  Getting a quick glance of GPS accuracy and status on Twitter can keep you informed with no work on your part.  So what's available?

Here's a picture of a sample GPSToday Daily Accuracy tweet:

I use the AGI Navigation Accuracy Library, Dynamic Geometry Library and the Spatial Analysis Library to calculate the global position error, at 5 degree grid increments and 60 sec time steps.  I then find the Maximum, Mean and Minimum statistics over the globe for the day.  Once I have this information, I construct a string that states what you see in the picture above and use Twitterizer post the tweet.  I can't believe how easy this was to do.

On the machine I use to calculate the global accuracy, I used Windows Scheduler to set up the run every day at midnight. When it completes, The code will send me an e-mail that it finished and update the GPSToday status with the message above.  Also, if there were any satellite outages, a tweet with that info would be posted as well.

Computing global accuracy is easy using the Spatial Library component.  A peek at the documentation here, then heading to the Programmer's Guide, Overview, Coverage section, show lots of examples of how to compute coverage.  Down towards the bottom are some navigation examples also.  The coverage algorithm first calculates access over the grid (not at specific times, but based on the assets and constraints you assigned to the grid).   Once Access is calculated, you can evaluate a Figure of Merit (FOM), such as Navigation Accuracy, on that calculated Access at given time steps.  Also built in are statistical functions to allow statistical calculations over the entire grid and time, or just across time at a specified grid point.  Nice.

The best part of all this is that the access and FOM calculations are multi-threaded and core aware - the library will take advantage of all the cores on your machine simply by setting the following:

CoverageDefinitionOnCentralBody m_CoverageDefinition;

m_CoverageDefinition.MultithreadCoverage = true;

So, with the components, a little time and the help of a couple of tools, getting a new requirement coded and out the door happened in very little time.

If you don't have a twitter account, consider getting one, if just to follow how well GPS is doing everyday.  Follow this Twitter user: GPSToday.  Oh, You can find me at TedDriver too.

Happy tweeting!

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

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 comments

### Navigation Error Predictions – Part 2

February 03rd, 2009 | Category: Navigation Accuracy,Navigation Accuracy Library

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 /Standard Deviation Theoretical Value 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 /Standard Deviation TheoreticalValue 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

### What’s the difference between SEM and YUMA almanacs?

November 11th, 2008 | Category: Navigation Accuracy,Navigation Accuracy Library

Technorati Tags: ,,,,

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!

4 comments

### Assisted GPS – How does it work?

October 14th, 2008 | Category: Navigation Accuracy,Orbit Determination Tool Kit

Technorati Tags: ,,,,

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

No comments

### ION GNSS – I’m hearing a lot about RAIM these days

September 19th, 2008 | Category: Dynamic Geometry Library,Navigation Accuracy Library,RAIM

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.

3 comments

### GPS Tool Collection

Technorati Tags: ,,,,,,,,,

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:

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.

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.

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.

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

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.

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.

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)

No comments

### Ionospheric Error Analyst – a nav mashup Part 3

Technorati Tags: ,,,

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.

No comments