Hi y’all,
This topic isn’t new and yes, it is documented by EMLID here (Kinematic processing | Emlid Studio) but I’ve found it to be important enough - especially for noobs like us - to emphasize it with a thread (and post some improvement suggestions for EMLID).
We have a setup in which we are flying a drone with an M2 strapped on it and an RS2+ as a base. To eliminate all millisecond-shifts in the position-correction of the drone, we PPK both RINEX logs from drone and base.
So far so good. But then we visualized everything in 3D and realized we had massive shifts in the flight paths of our drone. The starting points were sometimes beneath the ground or high up in the air. So we were going crazy thinking we might have some GNSS-signal disturbance or something (lots of mirrors & steel where we fly).
But there is a simple reason WHY our paths were shifted all along: EMLID studio DOES NOT USE THE MANUALLY ENTERED COORDINATES OF YOUR KNOWN POINT from the base config interface. You will have to enter the coordinates MANUALLY AGAIN in Emlid Studio, or else it will use some “phantasy base coordinate” from the RINEX-log ().
The good news is, you can PPK your collected data with the correct base coordinates and get the correct position / flight paths of your drone in post.
However, as stated above, EMLID does explain this possible pitfall in their documentation (link above & pic below).
But it breaks my head, why they wouldn’t simply write the manually entered base coordinates into the RINEX-files so they can automatically pre-select it as an option in the drop down menu of the kinematic processing in Emlid Studio…
Yo Emlid, how about it?
I’m sure that would save many beginners some serious headaches
THANKS!!
But it breaks my head, why they wouldn’t simply write the manually entered base coordinates into the RINEX-files so they can automatically pre-select it as an option in the drop down menu of the kinematic processing in Emlid Studio
Fair point. I’ll add this to our feature request list. I believe no one has brought this up before.
It appears that the rinex header info is only meter accuracy and hasn’t been post processed. If you’re planning on doing PPK, You need to enter the base final computed processed coordinates in the header to process the field data.
In other words, post process the base first then post process all the collected data with the new cords of the base.
If the base is in a known point, enter that for the base, then post process all the data.
According to the Rinex standard, the position in the header is a single epoch reading at the beginning of the file creation. So, if the base is in Single mode at that time, you’ll get a meter-accurate position, and centimeter-accurate if the base is in fixed mode.
I scratched my head just like you did in the beginning, but now I think it is a good thing. You should never take your base position coordinate for granted, thus the only right way is to manually input it in the right place, so you are sure it is correct.
Mmh, I’m not sure that contradicts my point. I meant, that Emlid Studio should automatically use the one I have entered in the base web config. If I do that, why should I have to enter it again in Emlid Studio? I’m not saying “make it impossible to enter a manual address in post, If I have entered the wrong address during data acquisition”.
Also, I’m quite sure we got the (7-9!) meter “accuracy” in the “guesstimated” RINEX header base position, even though we were logging on NTRIP in FIX. I’m really to noobish to understand what was going on there. That was a big surprise to me.
Maybe the RINEX got confused, because we were trying out different configurations earlier, with and without NTRIP (but with a manual coordinate!).
Either way, using the correct base position in Emlid Studio works like a charm, so we’re all happy now with our results and the accuracy
@ruth, I meant to please also write the antenna height somewhere into the RINEX and have Emlid Studio also preselect the height from that file for me.
It might seem like a little thing, but when dragging, dropping o&p-files and correcting positions for a huge amount of separate logs, those small actions add up FAST and they do create room for a lot of user error.
Ok, nevermind. Must have been a glitch.
I checked on the RS2+ and it worked as described.
Then re-applied the settings on the M2 and now it works also…
Don’t ask me what happened here. It was enabled before 100%…
