Inconsistent revolution number for successive TLE's

Hi there!

I have a block of code that uses Orekit to generate contact acquisition and loss of signal times given a specific satellite TLE and an observer latitude/longitude/altitude location. The TLE’s were obtained from Celestrak and I’m currently targetting the METOP-B satellite

The code uses a LatitudeCrossingDetector to increment the revolution number for each successive orbit as well as a ElevationDetector to detect when a satellite moves into and out of the station’s visibility circle.

I then also use the code to periodically refresh the expected contacts as new TLE’s become available and I use the revolution number to uniquely identify a specific contact.

In general, the block of code works correctly, but there are isolated instances where the TLE’s for certain satellites has inconsistent revolution numbers.

I’ve attached a small stand-alone example that shows how I’m going about the calculation (revolution-test.zip), and the following output is an example of how the revolution number changes when a new TLE is used.

Contacts via first TLE (with date 2019-11-26T03:27:28Z):
   Contact with revolution 37324 from 2019-11-27T22:45:35Z to 2019-11-27T22:58:04Z
   Contact with revolution 37325 from 2019-11-28T00:26:26Z to 2019-11-28T00:39:21Z
   Contact with revolution 37326 from 2019-11-28T02:07:05Z to 2019-11-28T02:20:10Z

Contacts via next TLE (with date 2019-11-26T22:43:15Z):
   Contact with revolution 37325 from 2019-11-27T22:45:35Z to 2019-11-27T22:58:04Z
   Contact with revolution 37326 from 2019-11-28T00:26:26Z to 2019-11-28T00:39:21Z
   Contact with revolution 37327 from 2019-11-28T02:07:05Z to 2019-11-28T02:20:10Z

Hence, the revolution number for contact 22:45:35 should have been 37324, and not 37325, etc.

I’m not sure whether I’m using the correct reference frames, or have some fundamental or obvious error in my code, or even whether the TLE’s being published by Celestrack actually supports consistent revolution numbers, but I would really appreciate any help in finding a solution.

Hi Eduan,

Welcome to the Orekit’s forum.

You initialized the GeodeticPoint object with the value 29.975995 for the latitude and 31.130753 for the longitude. I suppose that this values are in degrees ? However, Orekit uses SI units for angles. In that respect, latitude and longitude arguments shall be in radians.

Under this assumption, I performed three small modifications:

  1. Change the unit of the geodetic coordinates from degrees to radians using FastMath.toRadians()

     GeodeticPoint station = new GeodeticPoint(FastMath.toRadians(29.975995), FastMath.toRadians(31.130753), 210);
    
  2. Set the latitude argument of the LatitudeCrossingDetector to the latitude of your station

     EventDetector crossingDetector = new LatitudeCrossingDetector(MAX_CHECK, THRESHOLD, this.earth, FastMath.toRadians(29.975995))
    
  3. Increase the duration of the duration of the propagation by changing the end date; In order to have contacts.

     Date end = Date.from(Instant.ofEpochMilli(start.getTime()).plus(24, ChronoUnit.HOURS));
    

With these three modifications I have consistent revolution number

Contacts via first TLE (with date 2019-11-26T03:27:28Z):
   Contact with revolution 37330 from 2019-11-28T06:37:55Z to 2019-11-28T06:48:31Z
   Contact with revolution 37331 from 2019-11-28T08:17:19Z to 2019-11-28T08:29:20Z
   Contact with revolution 37336 from 2019-11-28T17:54:35Z to 2019-11-28T18:04:54Z
   Contact with revolution 37337 from 2019-11-28T19:33:21Z to 2019-11-28T19:45:36Z

Contacts via next TLE (with date 2019-11-26T22:43:15Z):
   Contact with revolution 37330 from 2019-11-28T06:37:55Z to 2019-11-28T06:48:31Z
   Contact with revolution 37331 from 2019-11-28T08:17:19Z to 2019-11-28T08:29:20Z
   Contact with revolution 37336 from 2019-11-28T17:54:35Z to 2019-11-28T18:04:54Z
   Contact with revolution 37337 from 2019-11-28T19:33:21Z to 2019-11-28T19:45:36Z

I hope this can help you.

Bryan

Hi Bryan, thanks for the help!

Apologies for the radians conversion bug, I must have had a copy and paste mishap while building the stand-alone app.

As you indicated, after I made the modifications you suggested, the revolution number were generated correctly.

Unfortunately though, I’ve tried another set of successive TLE’s I obtained from Celestrak which still exhibits the offset error in question. I’ve updated the test program with your suggested modifications as well as the two updated TLE’s, please refer to: revolution-test-v2.zip.

The output of the program is now as follows.

Contacts via first TLE (with date 2019-11-27T10:42:52Z):
   Contact with revolution 37329 from 2019-11-28T06:37:55Z to 2019-11-28T06:48:31Z
   Contact with revolution 37330 from 2019-11-28T08:17:19Z to 2019-11-28T08:29:20Z
   Contact with revolution 37335 from 2019-11-28T17:54:35Z to 2019-11-28T18:04:54Z
   Contact with revolution 37336 from 2019-11-28T19:33:21Z to 2019-11-28T19:45:36Z

Contacts via next TLE (with date 2019-11-27T21:30:31Z):
   Contact with revolution 37330 from 2019-11-28T06:37:55Z to 2019-11-28T06:48:31Z
   Contact with revolution 37331 from 2019-11-28T08:17:19Z to 2019-11-28T08:29:20Z
   Contact with revolution 37336 from 2019-11-28T17:54:35Z to 2019-11-28T18:04:54Z
   Contact with revolution 37337 from 2019-11-28T19:33:21Z to 2019-11-28T19:45:36Z

This seems to be the case regardless of whether I’m using 0 degrees latitude (equator) or the station’s latitude.

Could it be that the source TLE is broken?

Another thing I was wondering about is what the latitude boundary should be set to. I assumed the Celestrak TLE’s increment their revolution number while crossing the equator, while you suggested it should rather be that station’s latitude?

I do not see errors in your code. I tried to mix TLEs from your two examples and everything work except when I use tle0 of the second example. Computed values are 37330, 37331, 37336 and 37337.

    TLE tle0 = new TLE("1 38771U 12049A   19331.44643519  .00000016  00000-0  27590-4 0  9999", "2 38771  98.7226  28.5416 0000787 163.2861  45.2811 14.21479650373178");

In that respect, maybe there is an accuracy issue with this TLE. Because computed revolution numbers (37329, 37330, …) are not consistent with the other simulations. However, I am not sure at 100% with this assumption.

I suggested it because I am a little bit afraid of numerical errors during computations. In that sense, I really don’t have great confidence in performing event detection for a 0 value.

Understood, thanks Bryan!