I’m using ES (v. 1.3) and RTKlib (v. 2.4.3 b34) for the post-processing correction of some field points collected in a forested montane area. For each point the position has been taken as mean of 3 minutes.
Points are corrected first (in ES and RTKlib) with the same parameters and then, together with the CSV coming from ReachView3, I use Stop&Go.
Emlid Studio and RTKLib are different software products. So it’s ok if the processing results from them are different. But, of course, the difference of about 10 meters is too big. Are all the processing results in Fix? Did you use the same coordinates for the base position?
To analyze the quality of the results, you can check parameters such as solution status, RMS, and the number of satellites used in calculations. Can you please share the logs with me? I want to check their quality and process them myself.
hey, thanks for replying!
Due to the site morphology I have to use fix (usually <2%) and float values, otherwise I risk to lose some points during the correction process. Here you can find some of the files…thanks for taking the time.
We’re not that experts but we’re trying to catch up
PS
I don’t know if the average quality derives also from the fact that the field collectors switched off the antenna after each data collection to save some power, giving few minutes to the antenna to “wake up” at each new sampling plot + 3 minutes of recording.
As you can see, there are plenty of cycle slips, which means the signal was disrupted. Also, the SNR is low and unstable.
You’ve mentioned that conditions on your work site are harsh. And the logs from the rover confirm that. But when signals from the satellites are noisy or don’t reach the receiver because of the obstacles, it leads to position accuracy degradation or losing the solution. Thus, we recommend following these tips for the receiver’s placement.
We also recommend collecting the points with Fix solution status only. Float means that not all ambiguities in positional calculations are resolved. So the position in Float is usually sub-meter accurate.
And one more thing. I’ve noticed in your folder the .22N navigation file only. It contains just the data for the GPS constellation. But there should be a .22P file from your Reach RS2 rover as well. This file is mixed. So if you have it, I recommend you use it in processing instead of .22N. It contains more data.
Let’s return to your initial question. I’ve processed the CSV you shared in Stop & Go mode with the POS files from Emlid Studio and RTKLib. The difference between the results is up to 2 meters. But both results are in Float, so it’s within the accuracy range.
The RTK point in CSV differs from the PPK solutions for about 5–6 meters. But I think it’s because of the several-meter-accurate Single solution status. Also, the base position in RTK and PPK calculations was different. So the mismatch in it affects the results as well.
Turning the device off and on should be fine. And you just need to give the receiver some time to load and get corrections from the base.
But as I see in the logs, your survey took about 1 hour on the first day and the same on the second. Reach RS2 can provide up to 16 hours of working as a rover without additional charging. So it should work without turning it off to save power. Does it? Or do you need it because of some specific project?
may I ask you the settings that you used? If I can agree on some plots, others (e.g. number 22) get pretty far away…
what do you mean with RTK point/base position? we collected the data only for PPK, using corrections from the nearest reference station.
It’s not required but we didn’t have the chance/time to test it for a whole day in harsh conditions: we always work in remote forested mountain areas (with signal coming and going) and we used a cautelative approach just not to find out in the field that battery won’t last enough for a full day of data collection. We’ll try one of the next surveys
I used the default ones from the Emlid Studio but with the Combined filter type. The files I processed as an example were 22_10_11 base and 221011_plot_22 rover.
Oh, yes. Sorry, I got confused a bit. You collected points in Single, so there was no base unit, right.