From: Chuck Hemker (terhi.victor@logonet.com)
Date: Sat Mar 02 2002 - 11:26:02 EET
On 01-Mar-02 Tomi Manninen wrote:
> I would like to see a predictd daemon completely without any UI
> whatsoever. It would handle unlimited amount of satellites and the TLE
> data could be updated without taking the daemon down (standard way would
> be to make the daemon re-read its config files upon receiving SIGHUP, I
> guess).
There is already a RELOAD_TLE in the client protocol to tell it to reload the
keps. I don't remember if there is a small program to send the message out
there already.
-
For handling keps, right now I have a script that gets several of the kep files
off of celestrak, and then runs a C program that has a file of which satellites
I want, and it reads the downloaded files grabbing the keps that I want and
writes them to a output file "current.tle". Then all my tracking have soft
links from where they keep their kep files to current.tle. One of these days I
was planning on finding or writing a small client that sends to RELOAD_TLE of
to the servers. It's not as clean as it could be, but if someone wants it, let
me know and I'll put it somewhere you can get it.
-
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
their valid. That way you can do predictions after maneuvers and such.
-
I've been working on my own mostly predict compatible server (see below) and
I've had a couple of things I was thinking of adding to the predict protocol:
1. An extended format that includes things from the single satellite tracking
screen and others such as ma, squint, solar angle, etc for clients that want
it.
2. Some way to handle multiple observers maybe?
3. Maybe even a sat only/no observer option for things like maps?
(It may not matter that much. Once you've figured out where the sat is, it's
not that much more calculations to figure out observer related stuff)
-
Now with the discussion. I'll mention what I've been working on. (It's getting
close to the point where it's useful, so soon I'll work on cleaning it up and
releasing it) It's sort of package of a several components (that if someone
doesn't like parts of it they can improve or replace it)
I set up a 2 servers:
current_server
A mostly predict compatible server for getting the current positions of
satellites. It wasn't necessarily planning on supporting future
prediction things such as GET_SAT_POS, and the AOS/LOS field of GET_SAT.
prediction_server
This server comes up with predictions of future AOS, LOS, Max elevation
during the pass (at least it tries right now). I'm planning on adding things
like AO-27 TEPR, AO-40 MA based mode changes, visibility predictions, two
observer predictions, AOS/LOS predictions with obstacles and things like that.
With this, uou could easily set up a caching server if you didn't want to run
this on your notebook or palmtop. Just connect it to network occasionally to
download recent predictions.
I have a client that connects to the two of these and lets me know what is
currently visible and what is coming up. I'm also working on a program that
does automatic radio doppler correction.
I broke it up this way thinking the prediction server would end up being tied
up doing predictions and wouldn't want to be bothered doing current
calculations which can be more time critical. However, currently it doesn't
take that long to do a days worth of predictions.
I was also thinking of writing a scheduling server that would get the
predictions from the prediction_server and figure out what automated processes
it could do. (pacsats, telemetry, ...) Since I live in an apartment and don't
have an automatic rotator controller, this is a bit lower on the priority
list.
-
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 : Sat Mar 02 2002 - 11:26:49 EET