I am currently implementing precise orbit determination for LEO satellites using GNSS carrier phase measurements.
And then calculated two types of linear combinations using GeometryFreeCombination and MelbourneWubbenaCombination classes for cycle-slip detection. I checked the results and found that the shapes of the two graphs were almost same (although at different scales), and also, the values seemed too large.
For the geometry-free combination of phase measurements, the two frequency data are differenced in cycle unit (φGF = φ2[cycle] - φ1[cycle]), but I think the geometric distance term wouldn’t cancel unless the difference is taken after converting to meter unit.
And for the Melbourne-Wubbena combination, the difference between WL phase (cycle) and NL range (meter) is taken, but is there any problem with taking the difference between different units? This problem also applies to PhaseMinusCodeCombination and GRAPHICCombination.
The following is the result of the calculation after correcting the above problem.
Welcome to the forum!
I’m not a GNSS expert at all but it does look like you found one or several bug and fixed them !
If this is the case, would you care to contribute your fixes ?
Maybe @bcazabonne and @luc who are far more knowledgeable than I am in navigation can answer you properly though.
For the geometry-free, it looks like an ugly bug…
I’m surprise we never tested combination of measurements based on simulated measurements. That’s my fault…
For the MW combination, I’m not familiar with this method.
For Graphic and Phase minus Code, I also suspect they are bugs due to the fact the combinations are not performed in the same measurement units.
As you said, the fix is simple (multiplication by the wavelength). But we shall validate the measurements using simulated measurements.