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 
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.
Bryan