[Kstars-devel] SatLIb verification

Bernard GODARD bernard.godard at gmail.com
Sun May 6 15:01:38 CEST 2007


Hi,

I have re-compiled the kstar code changing
data->geo()->lng()->Degrees() in line 65 of
satellitecomposite.cpp by  -(data->geo()->lng()->Degrees()) and it now
seems the predictions are not far from those from Heavens Above
(tested with Envisat and locations : Toulouse/Fance +
Lancaster/Pennsylvania).

On another note, the DST rules are not working for EU and US (I had to
manually change
the UT offset in the Geographic Settings Window for Summer Time).

Clear Skies,

               Bernard

On 5/1/07, Bernard GODARD <bernard.godard at gmail.com> wrote:
> On 5/1/07, Bernard GODARD <bernard.godard at gmail.com> wrote:
> > I've just modified my test program to find all the HST passes on a ten
> > day period using SatFindPosition and keeping only the data where
> > elevation is above 10 degrees and I found all the passes predicted by
> > heavens above but some of them were flagged as being in Sun light
> > (visibility = '*') but not being on the night side (visibility = '+')
> > whereas Heavens above gave a sun altitude at maximum elevation
> > negative. It seems the sun sets later in SatLib.
> >
> > Heavens above seems to report only passes with altitude > 10 degrees.
> > That's why SatNexPass in SatLib reports much more passes (elevation >
> > 0)
> >
> >
> > On 5/1/07, Bernard GODARD <bernard.godard at gmail.com> wrote:
> > > Hi,
> > >
> > >
> > > On 5/1/07, Jason Harris <kstars at 30doradus.org> wrote:
> > > > Hi,
> > > >
> > > > So do I have an old version of SatLib or something?  Because when I
> > > > run the demo, I am seeing some problems.
> > >
> > > I did my test with the SatLib.h and SatLib.c code I found in the
> > > satlib directory of kstars svn. I didn't use the demo code. I made a
> > > custom C test program.
> > >
> > > > First of all, It reports a
> > > > Julian Day number that is off by about a month (and calendar dates
> > > > reported in the output tables also reflect this month-old date).  I
> > > > have to hack the code like this if I want the correct JD:
> > > >
> > > > jd=Julian_Date(cdate) + 30.0;
> > > Just tested. same problem here!
> > >
> > > >
> > > > There are some ambiguities in the meanings of some parameters:
> > > > + What time is reported by the demo?  I assume it's UT, and looking at
> > > > the code I'm pretty sure that is correct.
> > >
> > > That's what I did too.
> > >
> > > > + What convention is used for geographic longitude?  Are west
> > > > longitudes positive or negative?  From the longitude you gave for
> > > > Toulouse, I guess west longitudes are negative.
> > > >
> > > I was wrong about that but the difference is not so important for
> > > Toulouse because it's almost zero longitude. I just did the test with
> > > west longitude positive and I have now a better match of the Heavens
> > > Above results.
> > >
> > > > Assuming my guesses are correct, as I said before, I can't find any
> > > > correlation between SatLib predictions and those of
> > > > NASA/Heavens-above/calsky.
> > > >
> > > > For example, for JD=2454221.5 from Tucson, AZ (lat=32.222,
> > > > long=-110.926), SatLib gives the following pass prediction for HST:
> > > >
> > > > % ./demo HST
> > > > JD=2454221.516105
> > > > 90037B HST 2007-05-01 12:15:10   0.03 185.72  38   9  251   2727  73294 +
> > >
> > > I have tried to re-do your test and it seems SatLib's demo finds many
> > > more passes than Heavens Above.
> > >
> > > But I did another test with my test program which doesn't use
> > > SatNextPass but SatFindPosition and I made it print the epheremeris
> > > for the 3 may 19h30 (local time = GMT-7) pass above Tucson (
> > > 32.2220°N, 110.9260°W, alt 751m) predicted by Heavens Above and I have
> > > a very close match.
> > > _________________________________________________________________________
> > >
> > > test program
> > > _________________________________________________________________________
> > >
> > > #include "SatLib.h"
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <math.h>
> > >
> > >
> > > #define NBPTS 3600
> > >
> > >
> > >
> > > int main(int argc, char *argv[]){
> > >
> > > char *sat1 = "HST";
> > > char *obsname = "Tucson";
> > > double latitude = 32.222;
> > > double longitude = 110.926;
> > > double altitude = 751.0;
> > > char *TLE_file = "hst.tle";
> > > int result = 0;
> > > double jd_start = 2454224.60417;
> > > double step = 1;
> > > int i=0;
> > > int h,m;
> > > double s,s1,s2;
> > > double t;
> > > SPositionSat * pPositionSat[NBPTS];
> > >
> > > for (i=0;i<NBPTS;i++)
> > >   pPositionSat[i] = (SPositionSat *) malloc(sizeof(SPositionSat));
> > >
> > > result = SatInit(obsname, latitude, longitude, altitude, TLE_file);
> > > result = SatFindPosition(sat1, jd_start, step, NBPTS, pPositionSat);
> > >
> > > for (i=0;i<NBPTS;i++){
> > >   t = (jd_start-0.5)+i*step/86400.0;
> > >   s1 = (t - floor(t))*86400;
> > >   h = floor(s1/3600.0);
> > >   s2 = s1 - h*3600.0;
> > >   m = floor(s2/60.0);
> > >   s = s2 - m * 60.0;
> > >
> > >   printf("UT TIME : H: %d, M: %d, S : %f, ALT : %f, AZIM : %f VISI:
> > > %c\n",h,m,s,pPositionSat[i]->sat_ele,pPositionSat[i]->sat_azi,pPositionSat[i]->visibility);
> > > }
> > >
> > >   return 0;
> > > }
> > >
> >
>


More information about the Kstars-devel mailing list