I cannot see a way to define the absolute date values of ground station observed measurements to be recorded at anything other than time of signal reception. Considering the two way observation case: This does not allow for observations to be used when the date is defined at “Bounce” (transit) time or the date is defined at date of signal transmission. Is there anything we’re missing here?
I suspect we would need to add functionality while maintaining the current behaviour as the default, perhaps by adding “time tag specification” enumeration to the observed measurement which can be set to bounce, transmit and receive (which would be the default), and to modify the observedMeasurement.theoreticalEvaluation() to adapt according to the timetag type.
You missed nothing. The user must convert the observation epoch to be at signal reception. As a result, in case of two ways measurements, you may have to take into account the time of flight in order to convert the measurement epoch to a reception epoch. You can look what is done for laser ranging measurements in the Orekit orbit determination tutorial, in the readCrd(...) method. There is a conversion if the measurement epoch corresponds to bounce time.
That’s an interesting point. I don’t like the current implementation of Range and RangeRate measurements in Orekit. I don’t like the fact that these classes are used for both one-way and two-ways measurement. Firstly, because this makes difficult the implementation and the maintainability of the class. Secondly, the twoWay flag can be ambiguous to initialize for some users.
I would prefer to have separated classes: Range and TwoWayRange || RangeRate and TwoWayRangeRate. With this distinction, it is interesting to think about an enumerate for TwoWayXxx classes in order to initialize an epoch different from the reception epoch.
I would like to have the opinion of other Orekit developers about this point. If they agree, this change will need a major release of Orekit to be implemented.
In the CCSDS TDM format, there is TIMETAG_REF key in the metadata, which can take values TRANSMIT or RECEIVE (but not BOUNCE).
This is an additional reason to add this feature.
Would it be beneficial for me to give an implementation of this a go? Just in the current Range/Range Rate class (rather than dedicated twoWayXxx classes)
I’ve got a few days available to look at it.
The approach would be to use a modified version of the abstractMeasurement.signalTimeOfFlight(variableEmitter, fixedReceiver, receptionDate) method which looks to vary the receiver time (ahead in time) for the transmit case to get the bounce + reception delay.
