Problem with "most recent" elsets option from OIG

Mike McCants (mikem@fc.net)
Sat, 29 Nov 1997 10:22:04 -0600 (CST)

There is a problem with the option to get "most recent" elsets
from OIG.  If Spacecom "revises" an elset and the revised
elset happens to have an epoch that is slightly smaller
in time that the elset being superseded, then the option
to get the most recent elset will get the "old" elset
(that has a larger epoch date) instead of the "new" elset
that has a smaller epoch date.

For example, the following elset is (still) retrieved as "most recent"
from OIG for the 97 74D object:

1 25066U 97074D   97332.51699590 -.03049481  00000-0 -35676-1 0    28
2 25066  34.9948  45.4125 0013062 290.1196  69.8151 15.64018060    88

The elset has a negative "drag" term and one should always be
suspicious of such an elset (unless it's for an Iridium gradually
going higher and higher :-).

The use of the "get the most recent 5" elsets option obtains:

1 25066U 97074D   97332.32561562 -.00000061  00000-0  00000+0 0    11
2 25066  35.0047  46.6892 0012091 284.5790  75.3598 15.63636339    50
1 25066U 97074D   97332.51699590 -.03049481  00000-0 -35676-1 0    28
2 25066  34.9948  45.4125 0013062 290.1196  69.8151 15.64018060    88
1 25066U 97074D   97332.51699546  .00099460  00000-0  10000-2 0    32
2 25066  34.9960  45.4125 0013394 290.2516  69.6772 15.64042889    80

Now it is obvious that elset #2 has been superseded by elset #3
which has a (not completely unreasonable) positive drag term, but
a slightly smaller epoch.

Of course this positive drag term will place this D object ahead
of the A object, which reverses Craig Cholar's identification
of the two and explains his surprise that they were so close
together.

Mike McCants