[Kstars-devel] SatLib

Bernard GODARD bernard.godard at gmail.com
Sun Jul 16 21:00:19 CEST 2006


I am currently (very slowly) writing a TwoLineManager class (which for
the moment hasn't any kstars specific code, i.e. it could be a
separate library).

the interface will be something like this (from that we could develop
a dialog to add, remove satellites):

void TwoLineManager::load(std::string fileName)  // load the whole TLE file
void TwoLineManager::delete(ID id) // remove satellite from the list
and remove all related data
void TwoLineManager::select(ID id)   // set satellite as active,
initialize satellite SGP data
void TwoLineManager::unselect(ID id)  // set satellite as inactive
(and maybe delete SGP initialized structures, keeping only the two
lines data required for initialization ...)
void TwoLineManager::getPosVit(int id, double julianDay,double & posX,
double  & posY, double &  posZ, double &  vitX, double &  vitY, double
& vitZ); // computes position  and velocity of an active (initialized)
satellite
bool TwoLineManager::isActive(ID id)
std::string TwoLineManager::getSatName(ID id);
std::string TwoLineManager::getNoradId(ID id);
double TwoLineManager::getEpoch(ID id);
void TwoLineManager::getOrbitalParameters(double & semiMajorAxis, ...)
// for information

This would manage a list of satellite data identified by a unique identifier
identifiers (type ID) would be a combination of TLE epoch and
satellite NORAD ID (string concatenation), since there can be many TLE
for the same satellite for different epochs.

Then we will need something to compute satellites visibility (are they
in Earth shadow?). The code to do that is available on the web, but I
think it should'nt be included in a separate lib but rather inside
Kstars. Otherwise there would be duplicate code to compute the sun's
position.

Let me know what you think of this interface or how you think the
interface should be. Once we agree on the best interface, I could
(let's hope by end of august because I will be quite busy) implement
the class  (a basic implementation at first, that is without handling
syntax errors or unrealistic/out of range values in TLE files).

I think this interface would make it easier for interfacing with kstars.

I would be happy to see your code. You can send me a tar.gz of the new
code or commit it to SVN.

Thanks,


                         Bernard

















On 7/16/06, Jason Harris <kstars at 30doradus.org> wrote:
> Hi Bernard!
>
> Glad to hear this message.  It sounds like what you and I have done
> separately so far will fit together well.  I have written a
> SatelliteTrack class that stores the SkyPoints that make up a
> satellite's track in the sky.  I have also written a SatelliteComponent
> class to manage the currently-acive satellite tracks.
>
> I'd be very happy to give you what I have so far and let you adapt it to
> your C++ library (which sounds very nice, BTW), unless you'd prefer
> another way?  Maybe I can just commit what I have so far to SVN...let me
> know.
>
> Jason
>
> Bernard GODARD wrote:
> > Hi,
> >
> > Oops, I was working on that too...
> >
> > I guess, I should have written more often to the list (I just wrote
> > once), but I am quite busy at the moment I am quite slow to code
> > (always changing the interfaces to my libs..).
> >
> > I made a C++ library for SGP4 (and other models) from a GPL C lib.
> > It doesn't have global variables.
> > You can find it here:
> > http://godard.b.free.fr/dotclear/index.php?2006/05/26/4-sgp-cpp-library
> > there's a small documenting test program inside
> >
> > basically, it works like this :
> >
> > _____________
> > Sxpx * sat1;         // the Sxpx class is a pure virtual class that is used to
> >                             // compute the position and velocity of a satellite
> >                             // independantly of the model used (SGP,
> > SGP4, SDP4, SGP8
> >                             // or SDP8). The Sgp, Sdp4, Sgp4, Sgp8 and
> > Sdp8 classes all
> >                             // implement the Sxpx interface
> >
> > string fname("sat.tle");  // the name of the file containing the TLE
> > string id1("88888");      // a NORAD ID for a satellite
> >
> > t = new Tle(fname,id1);  // open the file whose name is fname. Look in this file
> >                                  // for the first TLE whose satellite
> > NORAD ID is id1
> > e = new SgpElements(*t); // convert the TLE from string to numerical data
> >
> > sat1 = new Sgp(*e);         // create an SGP model with the TLE PosVel
> >
> > pv=sat1->getPosVel(jd); // get satellite position and velocity at julian day jd
> > // in the TEME reference frame of TLE epoch
> > _______________________
> >
> > I have been thinking that we need a new SkyComponents class with all
> > the "active" satellites and I was working on a TleManager class that
> > can read TLE files, add and remove satellites.
> >
> > Well, I will be happy to help if I can.
> >
> >            Bernard
> >
> >
> >
> >
> > On 7/15/06, Jason Harris <kstars at 30doradus.org> wrote:
> >> Hi Jean-Baptiste,
> >>
> >> I have finally begun work on adding earth satellites to KStars using your
> >> SatLib framework.  If you don't mind, I'd like to give some feedback on the
> >> API to hopefully make a future version of the lib a little more usable for
> >> KStars.
> >>
> >> First, a brief introduction to your library for my fellow KStars devs:
> >>
> >> The two main functions for our purposes are:
> >>
> >>    int SatInit(char *ObsName, double ObsLat, double ObsLong, double ObsAlt,
> >> char *TLE_file);
> >>    int SatFindPosition(char *satname, double jd_start, double step, long
> >> number_pos, SPositionSat *pPositionSat[]);
> >>
> >> SatInit() reads in all of the satellites' orbital data from the TLE_file and
> >> creates the global sat array to hold these data.  It also sets up the
> >> geodetic position of the observing station.
> >>
> >> SatFindPosition() returns an array of SPositionSat structs, which basically
> >> encode the instantaneous Azimuth/Elevation coordinates for the named
> >> satellite, for a series of instants, starting at jd_start.
> >>
> >> So, the usage pattern is to first call SatInit() and then call
> >> SatFindPosition() on each satellite for which you want a track.
> >>
> >> Now, my comments:
> >>
> >> *) Is it possible to decouple the initialization of the satellite orbital data
> >> from the initialization of the geographic position?  Ideally, I'd like to
> >> call SatInit() once when KStars starts up, and then be able to react when the
> >> user changes their geographic position without reading the orbital data all
> >> over again.  Maybe the geographic position data would make more sense as
> >> arguments to SatFindPosition() than SatInit() ?
> >>
> >> *) Maybe this is just my prejudice as a C++ guy, but it seems kind of
> >> dangerous to have global variables with simple names like "sat".
> >>
> >> *) Can there be a version of SatFindPosition() that returns Equatorial
> >> coordinates rather than Horizontal?  This isn't a big deal; we have functions
> >> to do the conversion, of course.  Also, do you correct for atmospheric
> >> refraction in determining the elevation coordinate?
> >>
> >> *) What are the units for the ObsAlt parameter of SatInit()?  Is it the height
> >> above sea level, or the distance from Earth's center?
> >>
> >> thanks for your efforts!
> >>
> >> Jason
> >>
> >> On Sunday 25 September 2005 06:35, jb wrote:
> >>> Hi all :)
> >>>
> >>> On a previous mail, I've told developping a C library for position
> >>> satellites calculation.
> >>>
> >>> This job will be done on 8-9 October week end ;) (a good code week end)
> >>>
> >>> What's the aim ?
> >>> Having a strong, fast and light C library that gives Ra & Dec of a
> >>> satellites, by given TLE, position and time.
> >>>
> >>> To do what ?
> >>> search what satelites you've seen last night, predict ISS pass on Sun or
> >>> moon...
> >>>
> >>> Why not include this on Kstars code ?
> >>> We want to share it with all other ephemerids program (cartes du
> >>> ciel/Skycharts for example)
> >>>
> >>> A Little problem :
> >>> we aren't really good programmers ;) but we'll be helped by Patrick
> >>> Chevalley to do this.
> >>>
> >>> If you have any asks, hints, clue, code to do this, please send me a mail
> >>> to this adress.
> >>>
> >>> Mail you soon,
> >>>
> >>>                                       Jean-baptiste BUTET
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Kstars-devel mailing list
> >>> Kstars-devel at kde.org
> >>> https://mail.kde.org/mailman/listinfo/kstars-devel
> >> --
> >> -------------------------------
> >> KStars: http://edu.kde.org/kstars
> >> Forums: http://kstars.30doradus.org
> >> _______________________________________________
> >> Kstars-devel mailing list
> >> Kstars-devel at kde.org
> >> https://mail.kde.org/mailman/listinfo/kstars-devel
> >>
> > _______________________________________________
> > Kstars-devel mailing list
> > Kstars-devel at kde.org
> > https://mail.kde.org/mailman/listinfo/kstars-devel
> >
> >
>
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>


More information about the Kstars-devel mailing list