From: Riley Williams (ltbaprd@tpc.cz)
Date: Tue Mar 05 2002 - 21:13:39 EET
Hi Chris.
>> I've to head out in a minute, so I'm just dealing with one aspect of
>> your email and will do a fuller reply later...
>>> With the discussion of TLE servers, one other thing I was thinking
>>> would be nice is the ability to have multiple keps for a satellite
>>> with a range of valid time for each.
>>> If you go to the NASA spaceflight page to get the keps for the ISS
>>> or the shuttle, they have multiple sets of keps with a range of time
>>> that they're valid. That way you can do predictions after maneuvers
>>> and such.
>> There is one obvious problem with that idea - those "future keplers"
>> are based on the INTENDED manoeuvres, and those aren't necessarily the
>> ACTUAL manoeuvres that took place. Another problem is that the TLE
>> format only specifies a start time from which the keplers can be used,
>> and not a finish time at which they should stop being used.
> I understand that they are based on intentions, but they are
> probably better for predictions then just using the current keps.
Unless the manoeuvre went exactly as planned, you could toss a coin as
to which is the better set of keplers. I can't remember the exact
details, but I remember hearing on the new around 1998 that one
satellite manoeuvre that should have shifted the orbit of a satellite
towards the poles by 7 degrees actually shifted the orbit towards the
equator by 9 degrees, and in that case, the old keplers would have
provided considerably better information on where the satellite was than
the advance ones.
> As an example, if I'm trying to predict passes for the ISS for a few
> days from now, it would be better to use keps that include their
> intended maneuvers.
If you're planning to track ANY spacecraft for which manoeuvres are
planned, and you have keplers both for the current orbit and that which
the manoeuvres intend to put it in, the best option is to produce
predictions for BOTH sets, and then assume the result will be somewhere
in between.
> When the time gets closer to the pass, it would be good idea to get
> updated keps that include any changes.
That's always the case.
> This is similar to coming up with predictions for a satellite for
> next week or next month. It's as close as we can get right now, but
> I wouldn't want to drive a set of rotators using these numbers. I'd
> try to get a new set of keps before then. (Otherwise it would be
> like using an old set of keps)
Very much so.
> The reason I mentioned this was because I saw the discussion about
> coming up with a TLE server, and I though I'd mention it so someone
> could think about it before coming up with a design.
It's actually irrelevant for the TLE server as the TLE's themselves are
issued by either NASA or NORAD in a format designed by them, and any
tweaks to that format other than by NASA are unacceptable. All the TLE
server can do is to obtain them from one source and then distribute them
to any client that wants them.
The only aspect related to this that might affect the TLE server would
be for it to be able to receive TLE's with a future epoch, but not to
forward those on until that epoch arrives, and I can see distinct
problems with such an approach, all concerned with the inevitable flood
that would occur the moment that epoch arrived, and all with "DENIAL OF
SERVICE ATTACK" stencilled all over them.
Incidentally, the TLE format as ucrrently designed has two limitations
built into it, namely:
1. The specification for the EPOCH date restricts it to holding
dates between 1955 and 2054 inclusive.
2. The specification is also limited to handling not more than
100,000 different satellites.
Neither limit is a problem at the moment, but both will need dealing
with in the not too distant future, with the latter one likely to cause
problems first. If you don't believe me, just look at the facts:
A. As of my writing, the latest satellite number for which keplers
have appeared on the Celestrak website is 27388. This is over
27% into the available satellite numbers.
B. According to the Celestrak website, the satellites with numbers
27,367 through 27,388 were all allocated numbers in the last
seven days. This is a total of 22 satellites in those 7 days.
C. For the year limit to fail first, simple arithmetic shows that
the rate of allocating keplers needs to remain below 26 in any
7 day period.
You may feel differently, but I find it hard to believe that over the
52 years between now and the year limit failing, the number of launches
won't rise from its current 22 to something rather higher than 26...
> As for the format, I haven't implemented anything and the only
> source I've found so far for predicted keps has been the NASA
> spaceflight website, I was thinking of just adding a begin time and
> an end time on a line or two after the normal TLE. Then writing
> something to go to NASA site and parse them out of the web page.
If you did that, what would make use of it? That extra line would be
unknown to all except your own software, so would be ignored by over
90% of the software making use of the TLE's.
>> PS: I use British English, you use American English, hence the
>> difference in spelling of "maneuvers" and "manoeuvres" above.
> You should have seen my spelling before I ran it through a spelling
> checker. :)
If you rely on a spell checker to validate your text, then be prepared
for some unearthly mistakes caused by your mis-spelling of one word
being a valid spelling of another. There's an old old poem on the
subject that makes for hilarious reading - basically, every word is
mis-spelt, but the entire poem as written will pass through ANY
spell-checker without comment, although a grammar-checker will soon
spew up problems. See how the following sentence gets on with your
spell-checker for an idea of the problems...
Tat's were there awl reel fayre ladles.
...for which the CORRECT spellings are...
That's where they're all real fair ladies.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to terhi.victor@logonet.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b30 : Tue Mar 05 2002 - 21:15:12 EET