                     ALM2POS.EXE

Is a program that uses a Yuma GPS almanac file to calculate the
positions of the GPS satellites relative to a user location. It
can also compare the almanac calculated position with "precise"
position info from IGS (+/- 50 cm accuracy). This shows how
accurate an almanac predicts position, if an almanac has any
problems, and allows experiments on how the almanac accuracy
changes with time etc.

It is a DOS program, but runs well under Windows 9x. It does not
change registry, load drivers or do anything to upset your
system.

Some very quick notes to get a person going.  More detail is
given later in NOTES:

SITE.TXT
--------

This file allows you to customise the program to your own location.

The file has comments to guide you, enter your longitude,
latitude, altitude, local time to UTC, and seconds GPS is ahead
of UTC.

This data is only used to calculate the satellite positions
above your location (option 1), it is not used when comparing
the IGS precise position data with the almanac.

ALMANAC.TXT
-----------

This is the name of the YUMA Almanac file the program uses.  If
you download a YUMA almanac from the Internet or your receiver,
you will need to change the name to "almanac.txt"

The almanac distributed with this program has its epoch on
Sunday 11th March 2001, this may be getting quite old by the
time you read this, so you can get an up to date YUMA almanac
from one of these sources:

If you have a Motorola or Magellan or a Rx that can output the
NMEA almanac, you may like to download my "alm2tle" program, it
has a number of utilities that will create a YUMA file from the
aformentioned devices:

http://www.geocities.com/kiwi_36_nz/alm2tle/alm2tle.htm

Otherwise you can download a recent YUMA almanac from the
Internet:

http://www.nis-mirror.com/systems/gps/Yuma.txt

or

http://www.schriever.af.mil/GPS/Current/current.alm

The following site has the most up to date service, however at
the time of writing (circa March 2001) the TRIMBLE TANS receiver
used at the site has problems with week numbers during weekends,
see later NOTES for more info about this site. Use with Caution:

ftp://sirius.chinalake.navy.mil/pub/nawc/local_almanac/almanac.yuma

SP3.TXT
-------

This is the RINEX precision position file from the IGS. With 
this file, ALM2POS ascertains the accuracy of the almanac file
that you are currently experimenting with.

The "SP3" data can be obtained from:

http://igscb.jpl.nasa.gov/components/prods_cb.html

You will need to UNZIP then rename the file you get to "sp3.txt"

What the Program does.
----------------------

I wrote the program to do many ALMANAC tests, these are the
ones I have "enabled" in this version.

Program OPTION:

1. Uses the location data in "site.txt" plus "almanac.txt" to
show (using the PC time (I assume its accurate!)) the GPS
satellites above the horizon. The Azimuth and Elevation, the XYZ
distance, and the range to each satellite from your location is
given.  Enough precision is displayed so you can see how fast
the satellites are moving relative to your location.

7. Shows the raw Almanac data SV by SV.

8. This function writes a summary of the difference between
satellite position data in the IGS SP3 file and position as
determined from the almanac. Because the error of the SP3 file
is of the order of 50cm or better, we take the SP3 as the
"correct" satellite position. The IGS file is read to get the
date and time of its position coordinates, alm2pos then uses the
almanac supplied to calculate where the satellite is at this
time, the SP3 and almanac XYZ ECEF is converted to a more
familiar LLA (the earth latitude and longitude directly beneath
the satellite) and the difference written to the file
SUMM_LLA.CSV

Because the SP3 file has a minimum of 92 x 15 minute positions
for each satellite, the output file from ALM2POS gives an
accurate account of how the almanac can predict satellite
positions over a 24 hour period..

The CSV file uses the "append" mode, if the file already exists,
the data will be appended to it, you may want to delete or
rename the file if you are going to experiment with different
almanacs etc.

To help quickly decide if an almanac is okay, I apply a test
that indicates if the almanac determined position is different
by more than a normal 7 day diff between almanac and SP3.

If there are SV's that exceed this threshold, the number that
do is displayed at the end of actioning function 8 . Useful for
doing a "quick test" of almanac accuracy without having to look
at the CSV file.

The file is in CSV (Comma Separated Value) format, so that it
can be imported directly into EXCEL (or other spreadsheet) to
make graphs or analyse in whatever way you wish.

9. This function is similar to "8", except it only applies to
one satellite at a time giving the difference between the SP3
file and almanac position tabulated at 15 minute intervals in
ECEF XYZ in Km units. This gives a precise picture of how the
almanac varies over a day, and how the time difference between
SP3 and the almanac tracks.

The DIFF_XYZ.CSV file is in CSV (Comma separated Value) format,
so that it can be imported directly into EXCEL (or other
spreadsheet) to make graphs or analyse in whatever way you wish.

The CSV file uses the "append" mode, if the file already exists,
the data will be appended to it, you may want to delete or
rename the file if you are going to experiment with different
almanacs etc.

A rule of thumb I have observed (to help you understand the
numbers) is that if the SP3 and almanac are for the same day,
the almanac can predict the position to +/- 1KM. With each day
difference between the SP3 and the almanac the position accuracy
increases by roughly 1KM / day. For example after 7 days, the
almanac has about +/- 7 Km error. This allows one to quickly
spot a "normal" almanac from one that is "out of spec".

First Experiment:
-----------------

The default "almanac.txt" and the "sp3.txt" files are for the
same day.  So if you try function "8", it will give a full days
summary of how the sub satellite LLA (Latitude,Longitude,Altitude)
predicted by the almanac compares with the "actual" LLA of the
satellite. Looking at the SUMM_LLA.CSV file you can see (for say
PRN 1) that the almanac does a pretty good job of predicting the
satellite positions. The lat and lon "width" is about 1/4 of an
arc minute, which is what is to be expected with a "same day"
orbit.

Just a few comments about the field names in the LLA file.
"Min,AVG,Max,Width"

Min is the smallest arithmetic number of the LLA differences.

AVG is the arithmetic average of the absolute value (ignoring
the sign) of the differences. I did this to give me a quicker
way of deciding the errors. For example if a reading was +1 and
another was -1 then the AVG is 0, whereas taking the absolute
value gives an average of 1, which is more descriptive of the
orbit error.

Max is the largest arithmetic number of the LLA differences.

Width is abs(MAX-MIN), which descriptively is the width of say a 
silk ribbon that would encompass the entire almanac positions
for the comparison. Of course the narrower the width of the
"ribbon" the more accurate is the prediction of the orbit.

Using these values you can see how symmetric the almanac
prediction is.

Running ones eye further down the LLA file, you can see that all
the SV's have similar position errors until you get to PRN 18
when the error takes a large jump. Alarmed by this (because in
my experience this is rare) I checked the health status in the
almanac file, it was 0 so it means the SV could be used. I then
checked  the current status to see if there was a forecast
outage.

http://www.nis-mirror.com/systems/gps/Status.txt

However there was nothing there, I then checked almanacs from 
the Coast Guard and Schriever, they had the same identical 
almanac Keplerian data except (because they were a little older) 
they had PRN 18 now set as "unhealthy". The following day, PRN 
18 was healthy and the almanac gave correct position data. So 
this is an example of how the almanac can occasionally have
errors.  It would seem that they are picked up by the GPS MCS
after a while, but it reinforces that users of the almanac data
need to be vigilant and use an error checking scheme on Almanac
data if they are going to be used for "serious" prediction
purposes.

Second experiment:
------------------
At the following address:

http://www.peterson.af.mil/usspace/gps_support/frequently_asked_questions.htm

They have a FAQ, here is question number 3.

3.  How do satellite (SV) positions vary with the age of an
almanac?  Will my receiver still be able to lock up on SVs with
an old almanac?

After their answer, they give this table.

---------------------------------
Age of Almanac Angular Error
 7 Days  0.23 Degrees
14 Days  0.48 Degrees
21 Days  0.95 Degrees
28 Days  1.45 Degrees
---------------------------------

Using ALM2POS, and four files from the IGS the above table can
be "tested" in a few minutes work.

I think they are being a little "hard" on the poor almanac.
Doing a quick test, I would give values about 1/10th of the
above table, see whether you agree with me ! I suspect they used
TLE's to do their comparison.

NOTES:
------

A new Almanac is transmitted from the satellites in the early 
UTC hours and remains the same for a day , it is usually posted 
such that the Toa (Time of Almanac or in the YUMA files it is 
Time of Applicability) is 2-3 days in advance. It appears that
the MCS has settled on a standard of 7 Toa's (one for each day
of the week).

Day*  Toa (secs)  Almanac Epoch (GPS Time)
0     61440           Sun 17:04:00
1    147456           Mon 16:57:36
2    233472           Tue 16:51:12
3    319488           Wed 16:44:48
4    405504           Thu 16:38:24
5    503808           Fri 19:56:48
6    589824           Sat 19:50:24

* Day refers to the day in the IGS filenames. For example

IGS11050.sp3.Z is the 24 Hr file, week 1105 day 0 which is Sunday.

If a satellite position is reported by an almanac to be quite
different from the "reference" SP3 file (especially if there is
a large time difference between the almanac and SP3) this may
be quite natural. About once a year the satellites are boosted
in their orbit, so a satellite can change from its "predicted"
orbit once a year or so. So care must be taken interpreting the
results.

One of the first important "discoveries" alm2pos made, was that
it found the Almanac data put out by a TRIMBLE TANS receiver at
Chinalake NAWC facility has major errors for 2.5 days out of 7.
The Trimble receiver does not increment the week number at the
beginning of the new almanac week. This increases the normal
almanac error by about 6,000 times. You can see if TRIMBLE or
the Military have fixed this problem by downloading an almanac
with a TOA of 61,440 secs or 147,456 secs (available Friday and
Saturday UTC) from:

http://sirius.chinalake.navy.mil/almanacs.html

If you would like to know more about this problem, rather than
make this file any bigger you can see my discussion of the
problem on the GPS newsgroup. You can look this up by going to:

http://groups.google.com/

and search with the following string

Military - Trimble Almanac Error

then click on "view thread"

I have noticed that a similar problem exists with the TRIMBLE
Planning software (version 2.35) as found at:

http://www.trimble.com/satview/index.htm

Using their own almanacs (they call it ephemeris file) I have 
found that the "Show Report" function sometimes puts the 
satellites a 1/2 hr ahead and sometimes 1/2 hr behind the real
satellite position. So someone with some spare time may like to
fathom what's going on with the Trimble Mission Planning
Software. By the way, to those who may think, ah maybe its
"alm2pos" that is wrong, I have been careful to check the
satellite positions with 2 other independent means to eliminate
"alm2pos" leading me to wrong conclusions.

If one does want to do "Mission Planning", predict DOP's,
tabulate satellite position, one program that I have found to be
reliable in its position accuracy is Charles Wagner's freeware
program at:

http://sd.znet.com/~dclapp/GPS/GPS_VIS/

Also if you have a GPS receiver with NMEA ability, you can use
the following freeware W9x program to show the satellite
positions as determined from your receivers almanac.

http://www.apollocom.com/VisualGPS/default.htm

In the "site.txt" file, there is a field to set the difference
between GPS and the UTC timescale. To find out what the current
value is use:

ftp://sirius.chinalake.navy.mil/pub/nawc/local_almanac/utc.dat

look for the value in the field   DELTA_T_LS (s):

That is the number of seconds GPS is ahead of UTC, changes about
every 18 months.

If you have any questions about something that puzzles you with
the software you can drop me an email at:

geoff_nz@my-deja.com

Hope you have fun

Regards, Kiwi Geoff...

Oh to keep things tidy

DISCLAIMER
----------

GEOFF HITCHCOX DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO, ANY IMPLIED WARRANTY OF
MERCHANTABILITY OR SUITABILITY FOR A PARTICULAR PURPOSE.

Specifically, the author makes no representation or warranty
that the software is suitable for any particular purpose.

No claim for or right to recover any other damages, including
but not limited to, loss of profit, data, or use of the
software, or special, incidental, or consequential damages or
other similar claims can be made. In no event will the author's
liability for any damages to you or any other party ever exceed
the registration fee paid (US ZERO DOLLARS) to use the software,
regardless of any form of the claim.

Kind Regards,

Geoff Hitchcox

geoff36@i4free.co.nz
http://www.geocities.com/kiwi_36_nz/

36 Tomrich Street
Christchurch
New Zealand
South Pacific.

 Latitude:  43.5197 degrees SOUTH
Longitude: 172.7022 degrees EAST

Some references for those that would like to know more about GPS
----------------------------------------------------------------

http://www.navcen.uscg.mil/gps/geninfo/gpsdocuments/gpsuser/gpsuser.pdf
http://www.navcen.uscg.mil/gps/geninfo/gpsdocuments/sigspec/gpssps1.pdf
http://www.navcen.uscg.mil/gps/geninfo/gpsdocuments/sigspec/gpsspsa.pdf
