Archive for July, 2008

Utilities and tools

July 28th, 2008 | Category: Utilities and Tools

Technorati Tags: ,,,,,

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.


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.

Read more

No comments