One of the issues I’ve come up against during the measurement class redesign is that in the CommonParameters values that are calculated, the OnBoardCommonParameters assumes that the GPS satellite is sending the signal to the ObservableSatellite, whereas the equivalent ground classes assume that the ObservableSatellite is the sender and GroundStation is the receiver. Basically this means that in the CommonParameters classes, the tau time delta value between sender and receiver is positive for the measurement classes that accept ground stations and negative for the ones that accept GPS satellites.
This applies to multiple measurement classes, but the one I’ll use as an example here is Range/OneWayGNSSRange, because they’re both range classes. These exist as two different classes for two reasons:
As the code stands now, we need separate classes because of the separation between ground and space observers
In OneWayGNSSRange the Observer is also the sender of the signal, whereas in Range the Observer is the receiver of the signal
Eliminating the distinction between ground and space observers would solve one of these problems, but we’d still have to deal with the other. Additionally, there’s the BistaticRange class.
So, here is the solution I propose:
The redesign of the code will make whether the Observer value is a satellite or ground station ambiguous already, so that’s not an issue in itself.
Instead of having OneWayGNSSRange and Range, we can have something like RangeSender, RangeReceiver, and the already existing BistaticRange. These classes will be able to accept ground OR space-based observer values.
BistaticRange will be able to accept two different Observer values, or the same Observer twice. Offhand I don’t think that will cause a problem. This will allow us to eliminate the isTwoWay switch in Range
The functions that calculate CommonParameters will have a trigger that will determine whether to calculate the delta time value tau to be forward or backward
I still have to think deeper about that, but you are most probably right.
The current design comes from historical reasons. It was initially set up for simple classical orbit determination (Range, RangeRate…). Then two different needs arose, and I don’t remember in which order:
multiple satellites
GNSS measurements
When dealing with GNSS (which are inherently one-way), and ground receiver, only the sender of the signal is a satellite and it is the one we want to estimate. In the GNSS measurement with multiple satellites case, we have multiple senders and we want to estimate all of them. If we also estimate the clocks (which is an very classical operational case and needed for accurate results), then we have an ODTS (Orbit Determination and Time Synchronisation).
I guess the mess appeared when dealing with inter-satellite measurements, for example a LEO satellite using MEO GNSS. There are several different use cases here:
we know the MEO orbits (from navigation messages or from SP3 files) and we only estimate the LEO, this is a regular orbit determination and the estimated satellite is the receiver
we want to perform a complete resolution and also estimate the MEO, then both endpoints should be estimated ; in fact this case is also the case when using inter-satellite measurements within the GNSS constellation itself
So at some point, I don’t remember when, we added the ObservableSatellite class, and I am pretty sure we did not think of all possible cases.
Your RangeSender and RangeReceiver proposal is appealing, but I am not sure it handles the case when both sender and receivers are estimated, and I think it is important to support this too.
“I am not sure it handles the case when both sender and receivers are estimated”
No it doesn’t, and this wouldn’t affect the cases where both sender and receiver are estimated. For now I think the best way to deal with that particular case is to essentially leave that section of the code as-is.