Re: 2-line elements in Year 2000.

Jim Varney (sat_watcher@rocketmail.com)
Wed, 10 Sep 1997 12:36:12 -0700 (PDT)

---Ian Galpin <g1smd@amsat.org> wrote:

> ........ the NASA / NORAD '2-line' Kepler Element format has a few
problems
> built-in. I believe the data format to be in need of a good overhaul.

> Proposed 3-line Kepler Element Data Format (3 lines of 64
characters):
> 
>    nnnnnnnnnnn
>    1 nnnnnnnU eeeeee ccyynnnnaaa ccyyddd.dddddddddd  +.ffffffffff c
>    2 nnnnnnnp eeeeee iii.iiii rrr.rrrr .eeeeeee ppp.pppp aaa.aaaa c
>    3 nnnnnnnx eeeeee mm.mmmmmmmmmm rrrrrrrr +.sssss-s +.bbbbb-b t c
>    4 nnnnnnn  optional free field text information
>    1234567890123456789012345678901234567890123456789012345678901234 
 [64]
> 
>    Mir
>    1 0016609U 000692 19860017A   1996276.1940800200  +.0000091500 9
>    2 0016609  000692 051.6519 304.8165 .0012480 224.8931 251.6678 9
>    3 0016609  000692 15.6208552200 00060672 +.00000-0 +.16289-4 0 9
>    4 0016609  000692 Orbit boost due 1996-10-08 approx.


My two cents:

The Year 2000 (Y2K) problem is a minor one in the TLE format and a
major one in the software that uses the elements.  Programs can easily
be patched to fix the problem.  For programs that aren't patched the
Y2K bug has a fatal bite.  So I see the TLE Y2K issue as really only
affecting orphaned programs that are no longer supported by their
author.  Not that I'm aware of any programs like that ;)

My irritation with the current epoch format is that it serves neither
easy readability by humans nor easy computing of the actual epoch. 
One possibility is to support full human readability
(yyyymmddhhmmss.sss) so one can easily see the year, month, day, hour,
minute and second of the epoch in UT time.  The other possibility is
to support the true epoch and to use astronomical Julian Day.  Julian
Day was invented precisely to avoid calendar issues.  I see advantages
and disadvantages to both.  I certainly don't see any advantage to the
current yyddd.dd-- system.

I would like to see TLEs made more space-efficient.  As it stands now
a file of 8,000 element sets consumes about a megabyte.  To that end
we can do away with the "1" and "2" card numbers, and we can also do
away with the checksums.  They are antiques from the card-keypunch
days.  I'm not sure we should propagate these holdovers into the next
century.

Also to save space, there's no need (IMHO) to repeat the catalog
number in every line.  I've always felt that the fragmented TLE thing
is a solution to a problem that hardly ever exists.

The line 4 comment line is a nice sentiment but I would be willing to
bet that USSPACECOM/NASA won't put anything into the fields.  This
would mean that 99% of the TLE's floating around out there would have
a line of wasted space.

I'd also like to see a flag to indicate 'mean' and 'osculating'
elements.  I've said this before, the time is approaching when the
computing power of the typical desktop will allow numerical
integration to displace general analytical techniques for
prediction-making.  The osculating-to-mean conversion makes TLEs less
accurate so I'd like to see provision made for osculating elements so
that future numerical integrators can take full advantage of them.

Lewis(fictitious)
0024909U 1997044A   19970911 051436.214 -.00799397  19006-3  -29853-2 
0   12 97.5683 131.7809 0016310 244.2791 115.6890 15.87684528    36 F

In this example you get the expanded catalog number; the Y2K-compliant
COSPAR number; and a human-readable epoch that's split to show
yyyymmdd and hhmmss.sss.  The ephemeris '0' code and the bulletin
number get moved down to the second line.  The 'F' at the end is the
mean vs. osculating flag. 

__________________________________________________
Jim Varney   121.398W  38.458N 8m   Sacramento, CA
jamesv@softcom.net, sat_watcher@rocketmail.com

A jury consists of twelve persons chosen to decide 
who has the better lawyer.
--Robert Frost

_____________________________________________________________________
Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com