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.