Stop and Go - Fixed in field result are Float with PPK

I surveyed a mine pit today and some of the walls prevent a FIX (they arn’t terribly high, maybe 3m) but I’m about 4kms from the base station which is over a known point (using RS2s). I reducing my air data rate didn’t help.

I managed to get some fixed points in different areas with different lines of sight and some with only SINGLE.
I’ve run the Stop and Go with RV3 and some of my fixed points have come back as float! Eg point 14.
I know its using a different calculation methodology, but I’m on each spot for 40seconds, I can’t see how it wouldn’t come back as fixed.
Strangely, some of my SINGLEs came back fixed… point 11 for example.

I’ve put my files here
[Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.](https://Onedrive folder)

I’d like to be able to use this as a good backup if I can’t get a fix, but it doesn’t fill me with confidence. Am I make a rookie mistake? Why wouldnt every point come back FIX, no trees and not close to the walls - about 10m away at a minimum.

The pit walls may be blocking half of the sats. Have you tried placing your base at the pit ? It’s just a simple matter of setting a control point at the site… occupy the new point with the base and try locating your areas again

GNSS doesn’t work well in “holes” as the majority of the sky could be blocked preventing a good fix for each point. I would look at the full sky constellation for the site before starting the survey and compare what the conditions are in the pit.

Also, short baselines are your friends ! You will have a better and faster “fix” solution. But as mentioned, half of the sky blocked won’t help matters at all


Hi Joe,

Do you have a ubx file from your base station? I took a look at your base station rinex file and it was only recording the gps constellation every 30s, your rover was recording all constellations at 5hz. Because of this the PPK solution can only be calculated using the gps satellites and the number of valid satellites in the solution drops to 4 frequently.

If you have a ubx file from the base station try the PPK with it instead, It should have recorded all constellations at a higher rate and should provide a better solution.


Hi Joe,

Sorry for the delayed comments.

RTK and PPK algorithms are different, right. And PPK benefit is that the results don’t depend on the stability of the correction flow. However, satellite reception is still significant, no matter if it’s RTK or PPK, because it’s what the solution is based on.

Here are the logs from your rover:

Here are the logs from your base:

You can see that logs from the rover have several red marks - cycle slips. They occur when the satellite signal is delayed or disrupted. Also, the SNR of the signals is quite low and sometimes changes abruptly for both base and rover. It usually happens when the sky view is partially blocked. And it leads to poor results, as Bryan @EBE111057 mentioned.

So you need to provide the receivers with better satellite visibility. The ideal placement is when the sky view is clear 30 degrees above the horizon. Here you can check more recommendations for the Reach RS2 placement.

I can also second David’s @david.burlace thought that it’d be better if your base had data from other satellite constellations as well. The current PPK solution is based on GPS satellites only, which number is few. Besides, their quality is poor in both logs. So turning on other GNSS systems on the base can give more data for calculations and improve the results.