Technorati Tags: SEM Almanac,YUMA Almanac,GPS Ephemeris,AEP,Navigation,Ephemeris

Something happened.

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.

Read more

Technorati Tags: Navigation accuracy,mashup,ionosphere,GPS errors,NOAA

I’ve started creating a nav mashup that takes several technologies and data from different sources to determine the near real time navigation error across CONUS. We left off just before I showed you how to create a custom error model to model the receiver noise. Let’s get busy.

First, we need to derive a new noise model class from the GPSReceiverNoiseModel. Here’s the code, I’ll explain what it does below.

public class IonosphericNoiseModel : GpsReceiverNoiseModel
    {
        public IonosphericNoiseModel(StreamReader IonoTecFile)
        {
            m_tecFile = NoaaVerticalSlantTecFile.ReadFrom(IonoTecFile);
            m_GpsL1Frequency = 1575.5e6;
        }
	NoaaVerticalSlantTecFile m_tecFile;
    }

The IonosphericNoiseModel constructor takes a StreamReader that reads in a text file containing the Total Electron Count (TEC) data for a given time, and sets the GPS L1 frequency.

Once I have a TEC file, I need to override the GetTotalNoiseScalar method defined in the GPSReceiverNoiseModel class, to provide my own noise values. This is the meat of the functionality.

Read more

So, it’s the beginning of the month, that means a new AGI components release is here! You can get the release from the ADN here: http://adn.agi.com/detailedView.cfm?resourceId=210. I’ve profiled the performance of navigation accuracy calculations over a grid - usually the entire Earth - at different levels of granularity. I’ve started plotting the run times for these tests and wanted to show off the improvements in calculation speed. Kevin’s DGL blog shows the how of evaluators and the changes that you need to be aware of, I’m going to cover the results from a nav point of view.

Here’s the performance chart:

The first two releases of AGI Components are show in red and blue. Release 3 is shown in the magenta line - the one with the really small slope. Release 3 shows about a 4400% improvement in calculation speed over R1 and R2.

Read more

Mashups are great - even if that word is getting kind of old now.  It’s the idea that’s really cool.  Like the tinkers who grab bits and pieces from junkyards and make something really cool, today’s programmer’s search the Internet and find gold nuggets that can be pieced together and brought to life in a new way.  So, I wanted to tinker a little bit.  I decided to combine the navigation accuracy component library (that I’m so fond of) with the STK 4DX embedded technology and some near real time data I found at the National Oceanic and Atmospheric (NOAA) web site.  This NOAA data consists of slant range total electron count (TEC) data for GPS satellites - and this is important is your a civilian GPS user.  The largest error for civilian users is caused by the ionosphere, so it pays to watch what it’s doing.  I also found a graphing package called Zedgraph that will help with plotting any necessary data.

Ok, so what can you do with slant range TEC data, NavAccLib, DGL,  4DX and Zedgraph?  Well grab a Nog and let’s take a look.

First, I created a Windows Application from Visual Studio and started designing the GUI - nothing too difficult, just enough to get the job done.

ok, maybe I added a few extra things that aren’t absolutely necessary, but I get carried away.

Read more

InsideGNSS:

On Wednesday (April 16), a U.S. Air Force team successfully launched the Communication/Navigation Outage Forecasting System (C/NOFS), an experimental satellite designed to monitor the ionosphere and predict conditions that would disturb radio communications, including GNSS signals.

This satellite carries a GPS receiver specifically designed for this mission:

The C/NOFS Occultation Receiver for Ionospheric Sensing and Specification (CORISS) is a dual-frequency GPS receiver that measures line-of-sight total electron count (TEC), on-board scintillation indices and spectra, stratospheric temperature profiles, and high rate scintillation products.

The ionosphere is the biggest cause of errors for single-frequency GPS users - if you have to ask if you are one - you probably are.  But ionospheric effects also affect dual-frequency users, typically the military.  Even though a dual frequency measurement can eliminate the ionospheric delay caused by ionized electrons, it can’t get away from scintillation - the scattering of the GPS signals through a turbulent ionosphere.  

I talked with Joe Kunches, the Chief  of Operations at the Space Weather Prediction Center, and he explained scintillation to me this way:

Imagine you’re shining a flashlight through a tub of still water onto a dark rock.  You can see how the light bends a little as it enters the water, but the beam is still clear and visible on the rock.  Now imagine the water sloshing around.  The beam on the rock is now just small specks and moving patches of light - that is scintillation - the bouncing of the GPS signal through a turbulent ionosphere.  So turbulent that your receiver can’t lock up on the signal.

As we get closer to Solar Max, ionospheric errors and scintillation will increase, because the sun becomes more active and sloshes the ionosphere around more.

Again from InsideGNSS:

As the Earth enters a period of increasing solar activity, the effects of phenomena such as sunspots on L-band GNSS user equipment is drawing an increasing amount of attention. An article by Joe Kunches in the November/December 2007 issue of Inside GNSS highlighted the effects of space weather on GNSS and the efforts of the National Oceanic and Atmospheric Administration (NOAA) Space Weather Prediction Center (SWPC) to aid the GNSS community in dealing with these effects.

Joe has invited me to speak at the upcoming Space Weather Workshop in Boulder on May 2nd.  I’ll be presenting some of the work I’ve done integrating their near real time total electron count data into our tools.  I’ll be showing a sample application I built that shows the near real time navigation error over the continental United States.  The navigation error at each grid point includes satellite ephemeris and clock errors as well as ionospheric errors calculated from the data available from NOAA.  The data NOAA provides is very useful, but it’s derived from one perspective only: that of looking from the ground to space.  This new C/NOFS satellite  will help us measure from a different perspective - from outside of the tub - opening a whole new category of analysis and extending our ionospheric prediction capabilities.

Technorati Tags: agi,navigation accuracy,terrain,3D globe,fabric,cloud computing,space symposium,ice cream,monte carlo,basketball

Next week (April 7-10, 2008) the National Space Symposium is being held at the Broadmoor in Colorado Springs. As always, AGI will be there with all of our traditions - ice cream, Monte Carlo night (!) and basketballs! We’ll also have something that you may have thought didn’t exist - navigation accuracy analysis on terrain.

Yes!

By now, I’m sure you’re aware that navigation analysis is not that easy - it takes a lot of data, thousands of calculations and there are many variables that need to be taken into account - including your surrounding terrain. Terrain affects your visibility to satellites, reducing the number of satellites you can track and decreasing your receiver’s position accuracy.

Using a combination of our 4DX technology our Navigation Accuracy Library, our Terrain Analysis Library and our Dynamic Geometry Library, I’ve created an application that not only calculates your navigation error over terrain, but also displays it on a 3D globe.

The majority of engineers and analysts have known that terrain is very important to getting reliable navigation accuracy - but now the less geeky crowd is starting to become aware of it as well. And this group is big. So it’s important to reiterate what has been done in the past, lest the newcomers start to re-invent the wheel. There’s no sense in paying to create a technology that already exists, when you can get a validated and verified solution now and start working on the real problem! By the way, this application also calculates global accuracy and runs on a fabric of 20 computers in the cloud.

This application will be running at our booth (#402), alongside many other applications representing areas such as

• Space Superiority
• Space Exploration
• Space Mission Design and Operations
• Missile Defense

and many others. Stop by if your in the area. Contact me if you need a guest pass - I’d be happy to meet and show you around!

-Ted

The GPS error budget is a lot like your home monthly budget.  At home you have to pay for gas, electricity, cable, phones, food, Internet, garbage … - sheesh! I could go on and on.  You add up how much you spend each month then see how painful the final total is.

GPS on the other hand is a somewhat less taxing provider; at least in the number of items that must be paid.  The GPS error budget lists the errors that you have to account for when calculating your receiver’s position.  Some of these errors can be estimated, thereby reducing their affect (like coupons for your food budget), and others must just be paid outright (like the phones, cable, gas, etc)

For GPS the different errors are usually binned into different categories, such as Signal-In-Space (SIS), Atmosphere, Receiver, etc.  As you might expect, there are some differences of opinion as to which error goes into which category.  That doesn’t matter for what we’re discussing here though.  So, here’s a typical error budget for GPS:

Note that the Ionospheric error results from mis-modeling by the receiver.  Also, some receiver’s model tropospheric errors, others do not.  Caveat emptor.

Read more

The new GPS Block IIR-M satellite (PRN 7, SVN 48) was set healthy in record time on Monday March 24, 2008. According to GPS World:

That is apparently a record timeframe for a satellite being set to usable after launch. The previous satellite launched, SVN57, which went into orbit December 20, 2007, and was set to usable January 2 — a matter of 13 days — had also set a record at that time. After the successful launch of SVN48, the Air Force originally said that it anticipated it would set the satellite to usable sometime next month.

The standard timeframe for setting a satellite healthy after a launch is a month, but if all goes well, it will usually be set healthy when it’s ready.

So, why the delay once it’s on orbit? 

Once the GPS satellite gets into the correct orbital slot, turn on procedures are followed to activate the payload, upload programs and navigation data.  The rubidium atomic clock is also turned on.  The atomic clock plays an important role for navigation users, you wouldn’t know where you are without it.  Once the clock is turned on, it has to be set to the correct time.  This isn’t as easy as turning the dial on your watch - these clocks are accurate to nanoseconds.  The GPS satellite operators go through processes with arcane names such as baseband reset and PRN sync to get the timing set correctly.  Then they have to watch the clock.  The control segment Kalman filters process the clock states continuously, watching and waiting for the initial start-up clock errors to settle down.  Once all the payloads are on and functioning correctly, all the data is uploaded and current and all of the clock and ephemeris Kalman filter states have settled down, the satellite can be set healthy for all to use.

The fact that this process takes so little time now, is a testament to the manufacturers of the satellite and the clocks and to the operators in the GPS Control segment. Well done!

Now if only I could get a dentist appointment that fast…

Ok, you’ve had some time to digest the first two parts of this series on assessed navigation accuracy.  First I discussed what ephemeris and clock errors were, then I went over how those errors are created.  Now, in this final installment, I’ll show how these errors are are turned into accuracy measurements for your GPS receiver.  For now, let’s assume that our only errors are those we’ve discussed - ephemeris and clock errors.  There are other errors that affect your receiver and those are covered in the GPS Error Budget nog.

Now that we know what our typical ranging errors are, we need to understand how those are translated into a receiver error. The other piece of the error puzzle (and there are only two pieces) is Dilution of Precision (DOP).  DOP is the effect that arises from measuring signals from spatially separated sources - be they lighthouses, GPS satellites, semaphore technicians or pulsars.  DOP typically has the affect of diluting the accuracy of your ranging measurements.  I’ll cover DOP much more thoroughly in a future nog as well - because we want to get to the good stuff now!

Notionally, your receiver’s accuracy can be modeled as:

receiver error ~ DOP x URE

This is not a mathematically robust description, but it does show the general behavior of your errors.   The higher your DOP or URE, the higher your receiver’s error.  Lower either, and you’re likely to find that geocache quicker.  The mathematically correct construct for DOP is a matrix, and the UREs are a vector.  The elements of the URE vector are the total root sum square (RSS) errors along the line-of-sight from your receiver’s antenna to each GPS satellite.  So far we’ve only discussed the ephemeris and clock errors, but any error can be RSS’d into the URE and be used in the receiver error calculation.  We’ll see this when we look at the GPS error budget.

So, there it is, on the table - now you know how accurate your receiver’s position estimates are.  As long as you know all of the satellites ephemeris and clock errors at a given time (and all the other errors we glossed over) and you can do the matrix multiplications on the fly.  Piece a cake!  Right - we don’t think so either.  That’s why we automated all the data collection and math for you in our tools.

Read more