Re: Element Manager for Windows in work

Björn Gimle (b_gimle@algonet.se)
Tue, 17 Nov 1998 22:18:10 +0100

>Rick von Glahn is working on a new version of Eleman and asked me to =
forward
>some questions.  I'll forward all replies or you can write to him =
directly.
>
>> It's working pretty good but I'm running into one BIG problem. =
Although the
>> program can now manipulate the entire NORAD satellite catalog (per =
Allen
>> Thompson's list) or 10,000 element sets, it takes absolutely FOREVER =
to
>> clear memory and either shut down or load another element file. How =
long is
>> "Forever", try 10 minutes on my 200 MHz Pentium with an 8000+ element =
set
...
>
>> I've got several alerts built into the program. One points out an =
element
>> set is aging, another when the perigee starts getting too low.
>>=20
>> I'm using RED to indicate real problems. Elements older than 7 days =
for
>> instance. Yellow for older than 3 days. No consideration of MM =
(altitude) is taken.
>>=20
>> Here's my question. At what altitude should a perigee be highlighted =
with
>> yellow to indicate mild problems with drag? And at what altitude =
should
>> perigee be highlighted red indicating severe atmospheric drag leading =
to
>> imminent splash or dramatic reductions in apogee?
>>=20
I agree with Rick von Glahn that an elset manager with a practical
limit of 1000-2000 elsets would still be useful to some satellite
amateurs, but that the problem could and should be solved.

But I disagree with using a 'best before' from a fixed age of elsets!

The inaccuracies in old elsets are mainly caused by incorrect values
of ndot2 (B* in SGP4, but they are usually properly related). ndot2
can vary because of solar activity and daylight and weather below
perigee, and can be incorrectly estimated from measurements.

An element manager can often compare the current elset to a previous.
If the epochs, ndot2 and MM are E1, n1, MM1 and E2, n2 and MM2,
n1 and n2 should be close to (MM2-MM1)/(E2-E1)/2.
If not, a warning flag should be raised, and the numerically larger
value used for 'best before' estimate.

The effect on predicted time on date E3 is about n2*(E3-E2)^2 orbits
or 1440/MM2*n2*(E3-E2)^2 minutes. The error can be assumed to be
20% of this, either from initial error or average of a varying drag.

A warning should be raised if this (similar to QuickSat's TIM) is
'too' high at the time of running the elset manager, and (another?)
if it will be a week from now.

For a near-circular orbit, remaining lifetime is roughly 0.1/n2 days.
An eccentric orbit decays less rapidly, but for high eccentricities
the resulting warning may still be adequate, since perigee is often
very much affected by lunisolar perturbations.
Likewise, near-circular decay causes ndot2 to increase with the
inverse of remaining days, which could be used to improve error
estimate, but this is probably high enough to raise the warning
flags anyway !

Regarding unmentioned features, I would like to see that the
destination of elsets is controlled by a 'quicksat.mag'-type file,
with flag charecter(s) per USSPACECOM numbers, and desired/
unwanted/unmentioned objects can be directed to three different
files (including NULL?). Older elsets should be appended to
history files (ignoring duplicates, at least in the same run)
- one per object, or per month, or per year - if desired.

Bj=F6rn Gimle
=20