Hi everyone ! I am facing issues with the PhaseMinusCodeCycleSlipDetector, I have noticed that whatever the minimal number of measurement points n is I am always getting several cycle slips in a row separated by n/2 seconds (my rinex obs data is sampled at 1 second). And when trying to understand the functions, I found that the cycleSlipDetection function does not compare the predicted value through the polynomial fit to the actual phaseMinusCode but instead it does :
// Check if there is a cycle_slip
if (FastMath.abs(fitting.fit(xy)[0] - phaseMinusCode) > threshold)
which compares the order 0 coefficient with the phaseMinusCode value 
.
Is it normal ? it does not seem to correspond to the algorithm from Navipedia.
Thank you for your help.
I get it : it is because the dates are taken compared to currentDate so the x=0 is at currentDate.
Hi @HanaeLab
Thank you for the analysis. Could you open an issue in our Gitlab repository?
Also, any contribution is welcome 
Best regards,
Bryan
Actually the part where the predicted value is compared to the measured one is correct : since the polynomial is fitted on data where the times are referred to the currentDate, the 0-order coefficient then gives directly the predicted value of the fitted polynomial at currentDate.
For my other issue about getting cycle-slips every N/2 (which should not occur since at each cycle-slip the slidding window is reset and it should wait at least N more measurements to get to test if a measurement is a cycle-slip), I suspect that this is due to the presence of 2 pseudo-ranges (C1C and C1W) in my data, and when combining phase and code the combine function called from AbstractSingleFrequencyCombination does not perform a test to check if both phase and pseudo-range have the same signal code (there is 2 combine functions one does the test and the second does seem to). When checking manually some combinations of C1C-L1C and C1W-L1C I see that they sometimes differ a lot. If you confirm it is indeed the problem here, I can open an issue for that.