Perfect OD with ilrs simulated measurements

Hi,
I often compare my orbits solutions to ILRS ephemeris. As I never get an difference lower than tens of meters, I suspected my propagator to be in cause.

So I tried if i can get a perfect orbit with simulated measurements

  1. I parsed an ajisai SP3 file (from dgfi)
  2. I generated range measurements from 3 random locations from the SP3 ephemeris
  3. I set up an estimator with this measurements and estimated the orbit
  4. I displayed the residuals
  5. I propagate the solution and compare it with the SP3 ephemeris

The simulated measurements:

the residuals are around 10 meters:

and the comparison with ilrs ephemeris:

My guess is that my propagator is too different from the one of dgfi, so it’s impossible to get the exact same solution. Their force model seems more complex as described in their sinex files header:
dgfi_header.snx (11.0 KB)
Is 10s meters of error similar to what I should expect, or is there a mistake somewhere ?

What could I do to get a more similar propagator ? Is there a perturbation responsible for the main part of the difference ?

my code and the sp3 file:
propagation_validation.py (10.6 KB)
dgfi.orb.ajisai.240706.v00.sp3 (3.0 MB)

(with orekit 12.1.1)
Also: if I tried with more data (over a longer period) but the orbit does not converge

Hi Theophile,

I just ran your example script and I get range residuals of a few centimeters, and an error vs the ILRS ephemeris of 10 to 20 centimeters. The only explanation I can think of is your orekit data ZIP, maybe you are using older Orekit data? I recommend managing the Orekit data in a folder and regularly calling the update.sh script to update it.


Indeed the model used for operational orbit determination of Ajisai is more advanced than yours. A few ideas to improve the accuracy of your orbit estimation:

  • Where do the CR and CD values come from?
  • The .snx file mentions that the gravity field up to 120 degree and order is used for Ajisai, while you are using 60
  • The .snx file mentions the EIGEN-GRGS.RL04 gravity model, whereas by default Orekit uses Eigen-6S.
  • You should use different variables for the degree/order of the gravity field vs the degree/order of the ocean tides (the degree/order of the tides used for Ajisai is 30 according to the .snx file)
  • The .snx file mentions using the Knocke albedo model, you could try adding it to your force model, it is available in Orekit: KnockeRediffusedForceModel (OREKIT 12.1.3 API)
  • The .snx file mentions third-body perturbations from the Sun, the Moon, Mercury, Venus, Mars, Jupiter, Saturn, whereas you are only using the Sun and the Moon
  • You only have three ground stations, whereas geodetic satellites of the ILRS network casually get range tracking data from more than 10 different stations daily: Last 8 days | Normal Points (CRDv2) | Ajisai (8606101) | Satellites | EUROLAS Data Center (EDC)
  • You could try to reduce the propagator’s positionScale parameter (which you called ESTIMATOR_POSITION_SCALE)
  • You could try to reduce the convergence threshold (ESTIMATOR_CONVERGENCE_THRES)
4 Likes

Hi @theophile ,

I have look at your py code. I think that the Cd should be estimated. Or you can try to do the OD of lageos, for which the atmosphere force can be ignored.

Best,
Rowan

Thank you very much @yzokras !
After updating the Orekit data, I get the sames results as you.

After adding other planets and changing gravity and tides degrees/order, and also decreasing positionScale and convergence threshold ( 1e-2, 1e-4) . It changes but realy slightly.

The Cd and Cr values come from an old paper I found: https://ntrs.nasa.gov/api/citations/19900016127/downloads/19900016127.pdf (I took the mean value)

@lirw1984 I didn’t know I could evaluate Cd before
I tried It. The solution is different but not better.

The KnockeRediffusedForceModel seems realy heavy to compute with 1° précision. What angular precision would you recommend ?

I will try with real ilrs stations when i have time, but for now, i’m happy with a 10cm précision.

Hi!

1° is a small value. You can try using 30°. If you not happy with the accuracy, try to reduce to 15°.

Best regards,
Bryan