         ALM2TLE converts a GPS YUMA almanac file to a TLE file.

The YUMA file can be obtained from your GPS RCVR or the Internet
(see _README_.TXT)
------------------------------------------------------
To cut to the chase, here are the short form instructions.

Software compiled as a 16 bit DOS application - should run
fine under the various Windows platforms.

You need to obtain the latest GPS almanac file, if you cannot
use your GPS RCVR, it can be obtained from the following site:
(another site is mentioned later in this file)

ftp://ftp.navcen.uscg.mil/GPS/almanacs/yuma/

Download the file (which has the form) YUMAx.TXT where x
is the week number. You can see from the "date stamp" in the ftp
directory what the latest file is.

Copy this file to the directory you have alm2tle.EXE located in,
simply run "alm2tle" and when it asks for the week number just type
in the appropriate "x".

Note: The input "yuma" file, must have the same name format as
on the ftp site.

The output file is called GPS.TLE, which you can then use with
your favourite orbital tracking software.

--------------------------------------------------------
Background info for those that are interested.

Alm2tle reads the ASCII formatted YUMA file that is kindly made
for us by the US Coast Guard, or by your GPS receiver.  This
file contains information that allows a GPS receiver to
calculate when a GPS satellite is above the local horizon and
therefore when to start searching for its PRN code in a digital
correlator. The information is "nearly" in the form required for
a TLE (Two Line Element) file. I was curious how to convert from
one format to the other - so, as a hobby project I wrote
alm2tle.

The US GPS "NAVSTAR" system consists of about 28 satellites in
6 orbital planes. This gives world wide coverage and a spread
that most of the time gives a receiver a good "trig" solution. I
have written some software to monitor 24 hours a day, the HDOP
(Horizontal Dilution of Precision - a quality parameter) and to
log when it increases beyond a certain point. Using the TLE from
alm2tle I am then able to go back in time, and see why the HDOP
was not good. It shows up some interesting information -
satellites that are clumped together in the sky, and a profile
of my property ( I am surrounded by large beautiful trees that
soak up the GPS microwaves ).

Another use I have of alm2tle's data, is to predict when a GPS
satellite should rise above the local horizon. This helps in
determining how "omni directional" ones GPS antenna location is,
and that the large trees are still alive !

A few notes on Accuracy:
------------------------

The NGS and IGS publish on the net the position of each 
satellite to an accuracy of a few cm's (DOD insist orbits be 2 
weeks old though). I have written some software to convert the 
IGS SP3 ECEF data to a LLA format reference file, this can be
directly compared to the TLE LLA output of Dr TS Kelsos
Trakstar.  Using this technique allows post processing of the
accuracy of "home made" and USSPACECOM and other TLE's.  Using
the GPS almanac to create a TLE (using alm2tle) produces an
orbit that is within 6 minutes of arc (1/10th degree) for 3 days
duration before the Toa (Time Epoch).  Because the almanac is
updated every day, it means one can always maintain that
accuracy, and keep up with any station keeping changes. One day
before Toa is the best orbit fit, where the maximum error for a
24 hour period is 2 minutes of arc.

These errors are maximum, the mathematical average orbit
deviations are 3 and 1 arc minutes (per 24 hour period) (3 days
prior, and 1 day prior to Toa).

To keep up with any satellite repositioning it is always best to
get the "latest" almanac.

Another "NET" source of YUMA almanac files is:

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

You will need to convert the file name "almanac.yuma" to the
form "YUMAx.TXT" where x is the week number found in the file
in the line starting

week:

If you don't need to keep old YUMA files, you could always rename
"almanac.yuma" to YUMA1.TXT" and call "alm2tle 1" (do this with
a batch file - remember those ;-).

The "sirius.chinalake" file is updated hourly, the USCG which is 
updated less often (and not at all over the US weekend it 
seems). A NEW almanac is updated to the GPS satellites about 
once a day, so there is no need to get one with greater 
frequency than that!

To allow for "automatic" running of alm2tle, the "week number"
can be passed in the command line:

alm2tle 36

Will run alm2tle, using file YUMA36.TXT for input. The purpose
of this is to allow the program to be linked by other programs.
For example nmea2alm.exe will automatically invoke alm2tle with
the correct YUMAx.TXT file - if it has decoded a valid NMEA
almanac file.

Likewise MOT2ALM will invoke alm2tle if used with a (suitable)
Motorola receiver, downloading the latest almanac available
direct from the NAVSTAR satellites.

If you compare the TLE (running on suitable orbital tracking
software) with what your GPS unit can display, you may see up to
a degree of difference in Altitude and Azimuth. This is because
the GPS unit does not calculate the (almanac) SV (Space Vehicle)
position all the time, and usually rounds off to the nearest
degree.

Also the TLE derived display may indicate a satellite where your
GPS unit does not show one. This can be caused by a SV with a
poor health status, so the GPS unit will not bother tracking it,
but the TLE indicates it is high in your sky.

The Almanac is updated to the satellites about once a day (in
the early UTC hours), and is usually posted such that the Toa
(Time of Applicability) is 3.5 days in advance. It appears that
the MCS has settled on a standard of 7 Toa's (one for each day
of the week).

   Toa (secs)   Units  GPS Time
1.   61440       15     Sun 17:04:00
2.  147456       36     Mon 16:57:36
3.  233472       57     Tue 16:51:12
4.  319488       78     Wed 16:44:48
5.  405504       99     Thu 16:38:24
6.  503808      123     Fri 19:56:48
7.  589824      144     Sat 19:50:24

If an email robot is used to obtain the YUMA file from the
INTERNET, the robot will add text data in front of the YUMA
file. Alm2tle is not affected by extra lines and text as it
decodes the numeric information.

NORAD - PRN Numbering
---------------------

The default setting now is that the PRN numbers are placed where
the NORAD numbers go, the TLE output looks like this:

GPS PRN=01
1 00001U xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2 00001  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This has the advantage of only needing to use a 2 digit number
rather than 5, when calling up data in your TLE application
software, it is also the same number your GPS unit calls the
satellite. The PRN (Pseudo Random Noise Number) is the digital
ID of a GPS satellite.  As satellites fly and die - the PRN's
get re-allocated!

If you require the NORAD numbers to be displayed in the TLE,
then make sure that "alm2tle.xrf" is in the same directory. In
the distribution ZIP the file is saved as "alm2tle.xrx" so you
will need to rename the extension to make it operative. It will
also be out of date, so you may need to edit it using the
following information. Probably the best place to get PRN to
NORAD numbers is to use the USSPACECOM derived TLE at:

http://celestrak.com/NORAD/elements/gps-ops.txt

The format for the XRF file is:

nn 12345U 98037A

where "nn" is the PRN, "12345U" is the NORAD Number and "98037A"
is the International Designation (year-of-launch + launch number
+ piece of launch). The order of the file is unimportant but the
number of characters per line has to be the same.

If you use "alm2tle.xrf" then the output TLE will be like this:

GPS PRN=01
1 22231U 92079A   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2 22231  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

TLE Epoch Time:
---------------

The time in the almanac is in GPS Time. To make a TLE this has
to be converted to UTC which becomes a problem for alm2tle
because the conversion cannot be accurately forecast. The
following notes show why and how you can overcome this.

The reason GPS and UTC are not the same is caused be the earth 
not rotating at a constant speed. Tidal braking, molten rock 
sloshing around differentially and other seasonal factors cause 
the slight change in rotation rate. Because the earth rotation 
rate is not constant it is not reliably predictable.  Atomic
time (which GPS is aligned to) is constant and predictable.
Because UTC is tied to the earth's rotation it needs leap seconds
added to keep the "earth time" within 1 second of time as
determined by the stars. This keeps our watches in synch with
the sun, so that NOON remains in the middle of the mean solar
day. It's really a small effect, a leap second in a year is a
change in

 1 / (60*60*24*365.25) = 3.1688087E-08

When leap seconds are inserted in UTC, first preference is given
to opportunities at the end of June and December, and second
preference to those at the end of March and September.  Since
the system was introduced in 1972 only dates in June and
December have been used.

To enable you to manually control the offset I have created a 
file called "gps-utc.off" which is an ASCII file that you can 
edit. If the number of seconds GPS is relative to UTC is placed 
in the first line of this file and the value is > -100 and < 100 
seconds, it will use the figure you provide. For example in
1999, the figure would be +13.  The default value is +999 which
causes alm2tle to derive an offset based on the "average" change
from 1980-1999. The internally calculated value is correct
during 1999, but will deteriorate progressively after that time,
which is why I allowed the manual feature, so you can maintain
the offset yourself.

You can see the offset the program is using in the output screen
on the line showing "GPS Epoch", the number of secs relative to
UTC is shown in parenthesis.

To find out what the "present" offset is, obtain one of the
following two Internet files.
----------------------------------------------------------------
ftp://tycho.usno.navy.mil/pub/gps/ser42.dat

In the 3rd line of this file is how GPS relates to UTC.
The rest of the file deals with the nanosecond offsets of
individual satellites - which is not relevant to our issue.
----------------------------------------------------------------
The GPS-UTC offset is also in the 3rd paragraph in:

ftp://tycho.usno.navy.mil/pub/gps/gpstt.txt
----------------------------------------------------------------
To find out more about our wobbly home planet try Earth Rotation
Service, Sub-bureau for Rapid Service & Predictions.

http://maia.usno.navy.mil/

The above address will also "advise" when the next "leap" leaps.

     ------------------###----------------

Hey and don't forget about the wee reminder (and address) on the
programs screen. If you find the program useful, all I ask is
you send me a postcard to say "thanks" and show me a nice
picture postcard of where you live - and I will be grateful and
toggle your conscience into "registered" mode.

Also if there is a "bug", I could email you a "fixed" version.

Oh to ruin the chat, here is my disclaimer...

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.

Back to happy smiley faces ;-)

Thanks go to David Ransom for his help and comments.

I hope you enjoy alm2tle, and it brings you good times...

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


Sample YUMA Almanac from The US Coast Guard, followed by the output of
alm2tle

******** Week 989 almanac for PRN-01 ********
ID:                         01
Health:                     000
Eccentricity:               4.2324066162E-003
Time of Applicability(s):   319488.0000
Orbital Inclination(rad):   0.9568349719
Rate of Right Ascen(r/s):  -7.7831812106E-009
SQRT(A)  (m^1/2):           5153.707520
Right Ascen at TOA(rad):    7.7697551250E-001
Argument of Perigee(rad):  -1.710852265
Mean Anom(rad):            -1.6439139843E+000
Af0(s):                     6.9618225098E-005
Af1(s/s):                   0.0000000000E+000
week:                       989

******** Week 989 almanac for PRN-02 ********
ID:                         02
Health:                     000
Eccentricity:               1.8337249756E-002
Time of Applicability(s):   319488.0000
Orbital Inclination(rad):   0.9371808171
Rate of Right Ascen(r/s):  -8.2174853588E-009
SQRT(A)  (m^1/2):           5153.598145
Right Ascen at TOA(rad):    2.7928552628E+000
Argument of Perigee(rad):  -2.232335329
Mean Anom(rad):             1.2115077674E-001
Af0(s):                    -4.7683715820E-006
Af1(s/s):                  -3.6379788071E-012
week:                       989

Excerpt from GPS.TLE file (output file from alm2tle.exe)

NOTE - This TLE is dated Dec 23rd 1998, it will not be use-able
much after this time...

GPS PRN=01
1 22231U 92079A   98357.69763523  .00000000  00000-0  00000-0 0  0003
2 22231  54.8226 132.8448 0042324 261.9754 265.8107  2.00559616 00001
GPS PRN=02
1 20061U 89044A   98357.69763523  .00000000  00000-0  00000-0 0  0000
2 20061  53.6965 248.3462 0183372 232.0966   6.9414  2.00572386 00003

-----------------------End of File-----------------------------------
