>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