All
I’ve been going through the measurements package, and when I was running the OneWayGNSSRangeTest I noticed something odd. It looks like the clock parameters for the local satellite are added to the AbstractMeasurement parameter list twice.
Class is initialized:
public class OneWayGNSSRange extends AbstractOneWayGNSSMeasurement<OneWayGNSSRange> {
public OneWayGNSSRange(final PVCoordinatesProvider remote,
final QuadraticClockModel remoteClock,
final AbsoluteDate date,
final double range, final double sigma,
final double baseWeight, final ObservableSatellite local) {
// Call super constructor
super(remote, remoteClock, date, range, sigma, baseWeight, local);
Local clock parameters are added to parent class AbstractMeasurement:
public abstract class AbstractOneWayGNSSMeasurement<T extends ObservedMeasurement<T>>
extends AbstractOnBoardMeasurement<T> {
public AbstractOneWayGNSSMeasurement(final PVCoordinatesProvider remotePV,
final QuadraticClockModel remoteClock,
final AbsoluteDate date,
final double range, final double sigma,
final double baseWeight, final ObservableSatellite local) {
// Call super constructor
super(date, range, sigma, baseWeight, Collections.singletonList(local));
// The local satellite clock offset affects the measurement
addParameterDriver(local.getClockOffsetDriver()); <----------ADDS the local clock parameter drivers
addParameterDriver(local.getClockDriftDriver());
addParameterDriver(local.getClockAccelerationDriver());
// Initialise fields
this.remotePV = remotePV;
this.remoteClock = remoteClock;
Local clock parameters are added again:
public abstract class AbstractOnBoardMeasurement<T extends ObservedMeasurement<T>> extends AbstractMeasurement<T> {
public AbstractOnBoardMeasurement(final AbsoluteDate date, final double observed,
final double sigma, final double baseWeight,
final List<ObservableSatellite> satellites) {
// Call to super constructor
super(date, observed, sigma, baseWeight, satellites);
// Add parameter drivers
satellites.forEach(s -> { <----------- Adds both local and remote clock paramter drivers
addParameterDriver(s.getClockOffsetDriver());
addParameterDriver(s.getClockDriftDriver());
addParameterDriver(s.getClockAccelerationDriver());
});
AbstractMeasurement master class:
public abstract class AbstractMeasurement<T extends ObservedMeasurement<T>> implements ObservedMeasurement<T> {
.
.
.
protected void addParameterDriver(final ParameterDriver driver) {
supportedParameters.add(driver);
}
And then when you go through the list of paramters, the debugger output is:
>>> measurementDriver
ParameterDriver@30 "clock-offset-sat-0 = 1.37E-7"
>>> measurementDriver.isSelected()
true
>>> measurementDriver
ParameterDriver@86 "clock-drift-sat-0 = 0.0"
>>> measurementDriver.isSelected()
false
>>> measurementDriver
ParameterDriver@88 "clock-acceleration-sat-0 = 0.0"
>>> measurementDriver.isSelected()
false
>>> measurementDriver
ParameterDriver@30 "clock-offset-sat-0 = 1.37E-7"
>>> measurementDriver.isSelected()
true
>>> measurementDriver
ParameterDriver@86 "clock-drift-sat-0 = 0.0"
>>> measurementDriver.isSelected()
false
>>> measurementDriver
ParameterDriver@88 "clock-acceleration-sat-0 = 0.0"
>>> measurementDriver.isSelected()
false
Can someone please confirm that this is not expected behavior? Also, is there a clock associated with the source of the receiver satellite (the PVCoordinatesProvider remote value in OneWayGNSSRange and if so do the clock paramters for the receiver clock matter to the solver?
Thank you.