2-line elements in Year 2000.

Ian Galpin (g1smd@amsat.org)
Tue, 09 Sep 1997 22:05:37 +0100

[1997-Sep-09]

I don't regularly subscribe to this Mailing List, but several friends do, so
I will get to see any replies.

I was recently alerted by one of them to a discussion about the SGP4 model
not being Year 2000 proof.

I am working on a number of Year 2000 projects. I am also trying to raise
awareness of the ISO 8601 date format that writes dates in the order
Year-Month-Day with a 4-digit year and so solves that UK / US date format
ambiguity at the same time as solving the Year 2000 Problem.

1/12/96 means 1st December in UK and January 12th in US.
1996-01-12 always means 1996-January 12th.

See <http://ourworld.compuserve.com/homepages/dstrange/y2k.htm>
and <http://www.aegis1.demon.co.uk/y2k.htm> for more information.

I wrote to T.S. Kelso in the USA about 11 months ago about the ISO 8601 date
standard and also about various perceived deficiencies in the 2-line Kepler
elements that we all use. I did not receive a reply. I have recently re-sent
that letter, and the second half of it (about 2-line Elements) is reproduced
below. It may be of use in the discussion:


.begin


........ 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.

Perhaps a new 3-line format will emerge around (preferably before) the year
2000. The format needs to be sufficiently different, such that it is
immediately obvious whether the 'old' or 'new' format is being used. I don't
think that it would be a good idea to just extend the 2-line format by
making the lines longer and/or change the order. What is needed is a new
3-line format, with the whole structure altered, but without changing the
order too much.

My suggestions are as follows:

Object number is only 5-digits and currently up to 60 000 for some objects,
going to run out (roll-over) in less than 20 - 30 years (needs at least
another digit, maybe two, in this field).

The IAU designator allows only 2-digits for year. Needs to be changed to
4-digits, otherwise confusion in Year 2057! (there may also be confusion in
year 2000 when 99 rolls over to 00).

The Elements' Date (year) epoch is only 2-digits at present; (starting in
1957 I presume). Also needs to be changed to 4-digits. Some software will
get confused with year '99' (1999) Keps, and using them to try to work out
year '00' (2000) pass predictions. Also there will be a repeat in the year
2057 for any object that was launched in 1957 and that is still in orbit.

Orbit numbers are now wrapping around on some early high-rev objects. Need
another two (maybe 3) digits at least, to allow for a 15 Revs per day object
staying in space for 500 years.

Bulletin numbers are wrapping around for some objects. Allow another 2 or 3
digits.

The number of decimal places (after the decimal point) allowed in the data
elements seems sufficient for most objects. I don't propose any change
there. But, if someone better qualified at the maths has a good reason to
add more digits then it should be considered (though in my 'proposal' below
I have added 2 decimal places to the MM & First Derivative to neaten it).

I would like to see the data elements all positioned such that there is a
blank space between each element, so that the elements do not run together
(to avoid problems like where the MM and Rev number and checksum are all run
together on 'line 2' for some objects at present).


If a file becomes corrupted (especially lines missing), then it is possible
for line '1' and line '2' to become separated; or for a pair of line 1 and 2
that are not from the same bulletin to come together. If they are for
different objects this will be spotted by most (but not all programs!). If
they are for the same object (but from different dates) then these will be
accepted as OK by the program (because each line is check-summed separately,
and each line only includes the 'object number' as common information. The
bulletin number, epoch date/time etc presently only appear once in the
2-lines, not once per line). To overcome this, consider the following:

As well as the object number on line '2', there also needs to be either the
Epoch Date OR the Bulletin number included on both lines. Whatever is
included, it should appear in the same character positions on the line (i.e.
directly below the corresponding data on line '1'). I believe that it should
also appear directly after the object number information.

There needs to be a proper system for issuing pre-launch Keplers. Proper
numbering. Proper object Identification. Or an agreement that the Object
number is left blank, and a 'P' is added somehere in the Data to signify
'Pre-Launch Prediction', and that the Object Key is transferred to the
'Object Name', or some other pre-defined method.

Perhaps there should also be an optional comments line after the Kepler
information, for extra data, such as: 'Based on Launch 1996-Jun-03 :
04:25:30 UT', or 'Decay expected 1996-Jul-25/26' etc. This line being
numbered as '4', and programs can optionally ignore it.

Most of the progams I use accept 2-line Kepler element files with the
extension '.2LN'. I like this. It reminds you of '2-line'.

I don't like '.TLE' because I find that a lot of people call '.TLE' files
'TELEMETRY FILES' when they are actually talking about NASA / NORAD 2-line
Kepler Elements Files. This really winds me up!  I would be very happy if
'.TLE' was replaced by '.2LN' in general usage. One program I use accepts
Kepler files with the extension '.2-' which makes them really stand out in a
directory listing. .KEP is also popular on some European software.

If a new 3-line format were to appear, I guess the extension .3LN would be
appropriate.



Present NORAD 2-line Kepler Element Data Format:

   nnnnnnnnnnn
   1 nnnnnU yynnnaaa yyddd.dddddddd +.ffffffff +sssss-s +bbbbb-b t eeeec
   2 nnnnn iii.iiii rrr.rrrr eeeeeee ppp.pppp aaa.aaaa mm.mmmmmmmmrrrrrc
   123456789012345678901234567890123456789012345678901234567890123456789   [69]

   Mir
   1 16609U 86017A   96276.19408002  .00000915  00000-0  16289-4 0  6923
   2 16609  51.6519 304.8165 0012480 224.8931 251.6678 15.62085522606724


nnnnnnnnnnn    [11]    = Object Name (11 characters).
nnnnn          [5]     = NORAD Number.
yynnnaaa       [2 3 3] = International Designator.
yyddd.dddddddd [2 3.8] = Epoch.
+.ffffffff     [+.8]   = First Time Derivative of the Mean Motion or
                         Ballistic Coefficient (Depending on ephemeris type).
+sssss-s       [+5-1]  = Second Time Derivative of Mean Motion (d.p. assumed).
+bbbbb-b       [+5-1]  = BSTAR drag term (GP4 general perturbation theory).
                         Otherwise, radiation pressure coefficient (d.p.
assumed).
t              [1]     = Ephemeris type  - - - What does this mean ?
eeee           [4]     = Element Set number.
c              [1]     = Check Sum (Modulo 10)
                         Letters, blanks, periods, plus signs: 0 ; minus
sign: 1.
iii.iiii       [3.4]   = Inclination [Degrees].
rrr.rrrr       [3.4]   = Right Ascension of the Ascending Node [Degrees].
eeeeeee        [7]     = Eccentricity (decimal point assumed).
ppp.pppp       [3.4]   = Argument of Perigee [Degrees].
aaa.aaaa       [3.4]   = Mean Anomaly [Degrees].
mm.mmmmmmmm    [2.8]   = Mean Motion [Revs per day].
rrrrr          [5]     = Revolution number at epoch [Revs].

What is the 'U' for [on Line '1', at Position '08'] ?



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.


nnnnnnnnnnn        [11]     = Object Name (11 characters).
nnnnnnn            [7]      = NORAD Number.
ccyynnnnaaa        [4 4 3]  = International Designator.
ccyyddd.dddddddddd [4 3.10] = Epoch.
+.ffffffffff       [+.10]   = First Time Derivative of the Mean Motion or
                              Ballistic Coefficient (Depending on ephemeris
type).
+.sssss-s          [+.5-1]  = Second Time Derivative of Mean Motion.
+.bbbbb-b          [+.5-1]  = BSTAR drag term (GP4 general perturbation theory)
                              Otherwise, radiation pressure coefficient.
t                  [1]      = Ephemeris type.
eeeeee             [6]      = Element Set number.
c                  [1]      = Check Sum (Modulo 10)
                              Letters, blanks, periods, plus sign: 0 ; minus
sign: 1.
iii.iiii           [3.4]    = Inclination [Degrees].
rrr.rrrr           [3.4]    = Right Ascension of the Ascending Node [Degrees].
.eeeeeee           [.7]     = Eccentricity.
ppp.pppp           [3.4]    = Argument of Perigee [Degrees].
aaa.aaaa           [3.4]    = Mean Anomaly [Degrees].
mm.mmmmmmmmmm      [2.10]   = Mean Motion [Revs per day].
rrrrrrrr           [8]      = Revolution number at epoch [Revs].
p                  [1]      = A Letter P in this position indicates
'pre-launch'.
x                  [1]      = A letter X here forces line 4 data to be used.



There may be other pieces of information that other people may want
included, either for professional or for amateur purposes; e.g. an
indication as to whether the object is manned, the object type (amateur, TV,
comms, navigation, recon, weather, astronomy, debris, booster, nose-cone,
etc), physical size and/or brightness etc. Some people may want a short (say
five or six character) shorthand name embedded in the data (the name that is
used when plotting the object on a computer map). I believe that the 2-line
format is in need of a good overhaul. Lets choose a format that is going to
last the distance this time!



We need these standards (ISO 8601 in programs definitely, and also possibly
a replacement for the 2-line format). We need them soon. The year 2000 is
the breaking point. There is going to be a small amount of chaos (certainly
in the Amateur Radio world - I don't know about 'Professionally') when
programs start mis-behaving in the year 2000. In solving these problems, it
would be appropriate to analyse the data layout thoroughly and choose a long
term solution - one that will last hundreds of years rather than solve the
year 2000 problem only to find that the solution adopted itself only has a
useful lifetime measured only tens of years before some other problem is hit.

The short-term problem is:
- the wrap-around of the year at the end of 1999, when '99' becomes '00'.
This affects both the Epoch Date, and the International Designator.

The most serious long-term problems that I see are:
- Object Number will run out in a few tens of years time.
- Date wraparound on International Designator in 2057.
- Date wraparound on Epoch in 2057.
- Orbit Number truncation (already happening I believe).
- Element Set number truncation (already happening ?).
There may be other problems that I have not thought of. I welcome your comments.

My 'proposal' is just a basis to start some discussion on this topic. It
would need refining by someone more qualified before being implemented, but
I hope you can see roughly what I am trying to get across from it.

The year 2000 is going to bring a lot of computer related problems. Now is
the time to start thinking about averting some of them. There are now less
than 700 working days until the day that 1999-12-31 becomes 2000-01-01.

There is a document available for download, that you may care to read. It is at:
            http://www.s390.ibm.com/stories/tran2000.html
It covers many of the aspects of computer problems in the year 2000
especially where only a 2-digit year representation is used. There are
document versions suitable for reading on an IBM-compatible PC as well as
versions especially for those who may use the document in a mainframe
environment.

It would be very easy to write programs to convert both ways between the
2-line and the proposed 3-line formats, until such time as all tracking
software was able to handle the 3-line format.

Such conversion software would assume that years 50 - 99 are 1950 - 1999
respectively and that 00 - 49 are therefore years 2000 - 2049. The software
would need to warn of these assumptions, and that Orbit (Rev) numbers and
Element Set numbers have been truncated in the conversion from 3-line to
2-line format (or were already truncated in the 2-line data used to generate
the 3-line file) etc.

I throw this letter, written nearly a year ago, open to wider debate.



Ian Galpin, G1SMD.

<mail:g1smd@amsat.org>


.end