Hi there,
I’m wondering how exactly the corrections from processing a base and rover file are applied to the csv survey output - mainly because the results don’t make any sense to me.
We ran a survey where we independently measured points with a Trimble R10 RTK base and rover and an Emlid RS2+ set of base and rover. In both cases, the base was set up over an unknown point and the position was then processed against local CORS stations and then the rover positions post-processed against the corrected base positions.
In the Emlid workflow, we first post-processed the base, then used the base file with the post-processed position and processed the rover trajectory file. This was then used to ‘generate a corrected CSV’ file. Sure enough, the positions in the csv file changed in comparison to the original csv file, but they did not, however, coincide with the post-processed Trimble positions (which, when compared against BM positions, were correct).
I then ran a separate check where I post-processed just the base in Emlid Studio and calculated the XYZ offset between uncorrected and post-processed base position. I then applied this static offset to the uncorrected rover positions and - tadaa - the points were now nearly identical to the Trimble (and BM) positions.
I assume I’m missing something here in the workflow. I expected the process of generating a corrected csv file to do something quite similar to just apply the offset between uncorrected and corrected base position to the surveyed points. I realise that longer baselines might cause issues with such a simplified approach, but since the radio in the RS2+ is fairly limited, that shouldn’t really be an issue for RTK surveys…
Ok, digging further into this issue, I can see a possible reason for the (to me) unexpected behaviour.
I used this workflow for an RTK survey where corrections were transmitted via LoRa to the rover. So, corrections are applied in the field directly.
I assume, when going through the stop & go survey workflow, this is purely for post-processed kinematic (PPK) surveys where the rover positions (and the resulting csv file) are not corrected in the field? My guess is, that the corrections are applied twice, leading to the wrong ‘corrections’ of the csv file in Emlid Studio.
If this is true, I’d suggest the implementation of a workflow in Emlid Studio which would be a regular RTK survey, but with a post-processed base position (which would end up being a simple shift in XYZ of all rover positions). Setting up the base over an unknown point and then post-processing the base position is a very common workflow for us and to retrospectively correct the rover points collected with the Emlid rover requires us to apply a shift (equal to the shift of the base position from post-processing) in Excel - a rather tedious workaround.
But maybe I got it all wrong and my workflow is flawed. I’m open to suggestions.
RTK and PPK are independent workflows. In Stop & Go, Emlid Studio processes the raw data from your base and rover and then averages solutions for the intervals of your point collection. This workflow doesn’t use coordinates from RTK and is different from simply shifting the data on the same value.
To understand why your results don’t match, I need to take a look at your data. Can you please share the logs from your base and rover, the logs from the CORS you used, the CSV file from your project, and the known coordinates of the benchmark for comparison? You can send them to support@emlid.com to keep the data private.
Also, data from different surveys need to be in the same datum to be compared. Do you know in what datum your CORS provide corrections?
I see how the automation for applying a new base position would come in handy for you. Thank you for the feature request! I’ve noted it and passed it on to our team for consideration.
