Iono and tropo delays modifiers for range measurements

While working on the merge request for the BistaticRange measurement, I noticed that the RangeIonosphericDelayModifier and RangeTroposphericDelayModifier modifiers, to be applied to Range measurements, do not take into account whether the Range is a one- or two-way measurement, while the same ones for RangeRate measurements do. Thus, I suspect that these modifiers are only valid for one-way Range measurements and therefore there would be a bug for two-way Range measurements. I also have a doubt on the same modifiers for the TurnAroundRange.
Could someone confirm my analysis?
It would be nice to have more realistic values for our tests than just unvalidated numerical thresholds :frowning:

I really think there is a bug for two-way range here, the delay should be applied for
both the upward and the downward paths, i.e. it should be applied twice.

Hi @pascal.parraud and @luc ,

For SLR data, in the method readCrd of AbstractOrbitDetermination, the range is convert to so-called one-way by multiply 0.5 if it is two-way.
And in the method theoreticalEvaluation of Range, if it is two-way, 0.5 is multiplied too. So the tropo modifier is should be applied once.

I am not sure about the TurnAroundRange.

I agree with @lirw1984, I don’t think there is a bug.

To be rigorous, it would be necessary for two-way measurements to compute the tropospheric delay like Tr = 0.5 * (Tr_uplink + Tr_downlink) and the ionospheric delay like I = 0.5 * (I_uplink + I_downlink). However, we can easily make the assumption that, given the duration of signal time of flight, neither the ionospheric delay nor the tropospheric delay have varied between the uplink and the downlink.