Orbit Determination and Time Synchonisation for a constellation

[bcazabonne]

@JordiS

Another workaround I was thinking is maybe use the clockdriftdriver in the range class so to modify the theoretical measurement with this parameter. I know it was not its intended purpose but it might solve my problem (also I have to try to use a shorter span and see if the metrics improve).

I’m not sure it will work because the clock drift driver is not use for the theoretical calculation of the range measurement in Range class. This parameter has been added for range rate measurement.
Therefore, if you want to use it for a range measurement, I think you will have to implement your own Range class (i.e. maybe by extending the existing class and overriding the theoreticalEvaluation method.

@JordiS

Additional in my script I’ve also implemented a Kalman filter in order to see if with an epoch by epoch estimator maybe things would improve since the measurement parameters are estimated at each time. Nevertheless I still haven’t been able to converge to a proper solution (errors seem to be around several hundreds of meters), so here there must be something wrong as well…

Are the evolution of the clock parameters stochastic? If not, maybe you can try to increase the noise values for these parameters.

@JordiS

In other words, if I am estimating the iono-free ambiguity, is there a way for me to recover the integer ambiguity of the uncombined original measurement using orekit classes ?

First, maybe you can look at this post on the forum. However, I don’t think that it is currently possible in Orekit to recover an ambiguity from a “combined” ambiguity. To be more precise, I was not aware that it is possible Do you have a paper or a document presenting a method?

Bryan