The Rinex header position and the a-priori position displayed by NRCAN are always approximate by definition. As such, they could derived from a Single-solution.
You should never count on these 2 positions as a source of truth.
In your case, the source of truth is the 1005 or 1006 RTCM message containing the position you see in the Survey CSV
So does that mean that if I wanted to apply an adjustment to the surveyed positions, I could add the difference between the base position in the CSV file and the corrected position from the PPP output, and ignore the a-priori coordinate?
Fully agree with Christian’s reply. And answering your latest question, I think yep. You can make such an adjustment.
Coordinates in CSV are calculated considering the base position from the RTCM3 message. So if the base has an offset from the actual position – collected points will have it as well. When the offset is known, CSV coordinates may be corrected.
You can do it manually, but why don’t you just work in Stop & Go mode with Emlid Studio?
The coordinates of the Rinex header .O (Raw Data) correspond to the one estimated in the last observation period. But they do not have any adjustment (as if it were the GPS of your cell phone), It should not be taken as a reference.
If you process that data in a PPP service, you should take that as a reference.
Thank you for the suggestion, Julia, I’ll keep it in mind. We’re establishing a simple surveying protocol for non-surveyors (scientists) that will work in extremely remote, rugged environments where we can’t rely on known positions or NTRIP, etc.
So far, everything is working well and the answers here have helped me get over this mental block!
Oh, yeah, I see. I just think that Stop & Go mode will allow you to do the work you’re doing manually. Using it, you can upload base and rover logs, points in CSV, set precise base coordinates from NRCAN, and voila – you have corrected position
