As mentioned, I’m struggling to get a fix after correcting my base station via NRCAN and then using the Stop & Go in Emlid Studio to generate the corrected points we measured.
In Reachview 3 all points were “fix” but I’m only getting 2 in Emlid Studio after PPK (I can get slight changes by adjusting mask).
I’m sure its my mistake, but I’d like to understand what mistake I made so we can avoid it in the future. Even better if we can get our points to fix (and get them to accord with local known points).
I’d upload the data here but the logs are a tiny bit too big for the forum, can post via any Dropbox if needed.
Thanks for your patience! I’ve checked your data, and the observation data quality is poor. Usually, it depends on environmental conditions, so let’s look at the issue closer.
This is your rover’s log. It has many cycle slips - red marks, which means the signal was delayed or disrupted. Also, the Signal to Noise Ratio (SNR) is not higher than 35 for L1 and 30 for L2 signals. You can check SNR by the color of each line. Color changes depending on the satellite SNR value. Usually, it happens when the sky view is partially blocked by obstacles such as trees or buildings or when the device is affected by RF noise. These factors lead to poorer processing results, and that’s why you have points in the Float solution. To avoid this in the future, you can follow our recommendations for the receiver placement from this guide.
I’ve also checked your base station log, and it looks strange. There are identical pauses in the log when the data didn’t record. How did you connect your base and rover?
There were times between the GCP collection when we were driving around the site which is likely when there were these disconnects. What puzzles me is the actual acquisition point itself, as almost all collection points had clear sky.
Remember that for Stop & Go, you process the entirety of the dataset. If you only provide a 30 seconds of good data while observing a point, with the intermediate data being sub-par, it isn’t long enough to recapture a good fix.
Keep the GNSS unit outside of the car while driving, pointed at the sky. There are vehicle-mounts for that even
Oh, now it’s clearer to me! I see the whole picture. The issue isn’t related to the sky view, it’s in the base log. It looks like you used a base corrections log, which contains data received by a rover. So, there are gaps, and it’s ok, but it doesn’t work for PPK. There will be not enough data. If you want to do PPK as a backup for RTK, I’d suggest using RINEX log directly from the base.
And you’re right, Emlid Studio Stop & Go mode uses data only from time periods when points were collected. So, if you’re moving from site to site, rover log collected in a car can have low quality, and that’s fine because the program omits it.
Also, I see important to say that of course, clear sky view is ideal for GNSS receivers. But Reach RS2 can handle trees or buildings nearby. We still recommend providing a base with a clear sky view, but rover can work in a more challenging environment.
Also, if it happens that you recorded the base raw log, you can share it along with a CSV file with points, and I’ll try to play with settings and improve the results.
This is only true if you collect points for so long that a good initialization can be obtained while on observing the point in question.
If you want to make sure you can obtain a fix for Post-Processing (under good conditions) you would have to collect data for 2-5 minutes.
So, if you only collect for 30 seconds, and your previous and subsequent data is sub-optimal, you will likely not get a fix, or at least not a completely trustworthy one.
Bear in mind that the 2-5 minutes also counts walking to the point, leveling etc, as long as you hold the antenna towards the sky, and have good sky-view.
