Ground visibility time diverging for ISS

This code propagates the ISS visibility using the TLE propagator. When I match the visibility start and end times to the data from,

I see a divergence in both start and end times by a second to start with and as the propagation proceeds the divergence is more than 20 secs.

What is wrong in my approach?

Also, how do I use the GroundAtNightDetector class to restrict the list to night time only. Appreciate an example on how to populate the constructor.

Hello @hbagchi,

Welcome to Orekit forum !

Nothing really. You’re just not using the same TLE than the one on your reference website.
On your link to heavens-above website click on the “Orbite” menu on top. You’ll see they are using a more recent TLE (12:07) than yours (08:06).
With that TLE the results are much better. You don’t get the 20s divergence at the end. You still get some less-than-1s difference that is due to rounding off the date.
However there are still some differences that are above 1s. These I cannot really explain since I don’t know what’s under the hood of the heavens-above engine.

An example:
EventDetector groundAtNightEvt = new GroundAtNightDetector.ASTRONOMICAL_DAWN_DUSK_ELEVATION, new EarthStandardAtmosphereRefraction());

This is for the GroundAtNightDetector.
Now you want to have both ISS visibility AND local night so you’ll replace a line of your code with:
propagator.addEventDetector(BooleanDetector.andCombine(kolOgrVisiEvt, groundAtNightEvt).withHandler(new VisibilityHandler(kolFrame.getName())));

You’ll have to adapt your VisibilityHandler. Here I made it take the location name in argument since the BooleanDetector does not have a getTopocentricFrame method.

With this you’ll definitely see some discrepancies with your reference website.
From the different configurations I tried they do not seem to use atmospheric refraction (replace it by null in the constructor to do so) and the dawn dusk elevation they use is quite high, in fact even higher than the civil dawn dusk elevation (which is -6deg).

You’ll have to play around with the values to get the same results as them. I’m not even sure that you can get them since they may not use such a complex scheme and simply cross their visibilities calculation at culmination with dawn/dusk ephemerides of the Sun.

Hope this helps,

Hi @MaximeJ:

Thanks for your help. Its working as expected. I used EarthITU453AtmosphereRefraction() instead of EarthStandardAtmosphereRefraction() as suggested in the documentation. The divergence is nearly gone other than due to rounding errors.

As for finding the ‘night only’ passes using GroundAtNightDetector, while some of my data are matching that of heavens above, not all are. Any suggestions?

Also, heavens above has a pass type called night (unlit). does it mean ISS will not be visible even though it is in the line of sight at night. What does this mean?

Hi @hbagchi,

It’s hard to go further since we don’t know how heavens-above calculate the “night” parameter. You can play on the dawn/dusk elevation angle and the tropospheric model to change your values.
I you take the August 25th visible pass you have the 2 following data line:

Date Brightness Start Highest point End Pass type
(mag) Time Alt. Az. Time Alt. Az. Time Alt. Az.
25-août - 21:19:14 10° S 21:21:38 19° SE 21:24:03 10° ENE visible (full)
25-août -0,2 21:24:02 10° ENE 21:24:02 10° ENE 21:24:03 10° ENE visible (reduced)

First line is the pass with no restriction. Second one is with “night” restriction. You see that the starting date is later when the night restriction is on. It means the beginning of the pass is not at night but the end is.
So it depends on how you define “night” (civil, nautical, astronomical, custom) and what refraction model you use.

I’d say that it is when the ISS is in eclipse. The ISS does not produce enough light of its own to be seen from the ground. What you see is the reflection of sunlight on the ISS. So if the ISS is in eclipse it is “unlit” and it is indeed not visible.

Hi @MaximeJ:

Thanks yet again. I see an EclipseDetector that I plan to combine with the rest for removing the unlit conditions.

How do I calculate azimuth?

You’re very welcome.
Eclipse detector should work fine for removing the unlit condition.

See TopocentricFrame.getAzimuth. Everything is explained there.

Thanks. It worked perfectly.

Btw, is there a utility to translate the azimuth degrees to direction, e,g, E,W, ENE, SW, etc.

Not that I know of. This is a piece of code you’ll have to write by yourself.

Sure. Thanks.