I have referred to docs and can’t find an answer. Sorry! So this post.
I set my base, logging for 4+ hours, static. I then go out with the rover and collect points, kinematic. All looks good.
I return to the office and process using Stop & Go. Processing, the .pos looks pretty good. Rover is in the forest, base is in the open. Results are FIX 36.3% rest FLOAT.
Now, I run the base through CSRS-PPP to get better coordinates for the BASE. I repeat processing but replace the BASE coordinates with those from CSRS-PPP. This is what I’m told to do in the tutorial - " If you placed your base over the point with known coordinates, enter them manually, including the antenna height."
Repeat Process and the results is much worse. FIX is now 1.5% (was 36.3%) and there are SINGLE all over the place.
Testing, I generate the corrected CSV first using the BASE coordinate from the RINEX and second using BASE coordinates from CSRS-PPP and redoing the processing. The results are much worse. Again, many points that were corrected FIX are now FLOAT or worse.
Ok so when converting these sets into UTM zone 11, which is easier to read for humans, we get
RINEX header
x 689527.8591m
y 6094284.3306 m
z 647.9592 m
PPP
x 689567.1485 m
y 6093358.1919 m
z 645.2740 m
You can then see a pretty significant difference in location between both sets. dx = 39.2894 m dy = -926.1387 m dz = -2.6852 m
dz is not an issue as it is on the meter-level. dx, and moreover dy are big though. This is definitely something that can causes what you experienced. When the true location of the base is too far from the coordinates that are used in the PPK process, the baseline is harder to solve, until it is not solved at all.
Now we are here, the question is why there is that big of a gap. It should not be because of datum difference as ITRF and WGS84 are close to a meter-level.
CSRS-PPP is a fairly good tool to use and there is no reason to question the results. However, if you agree to share it, I can process your RINEX file with my PPP software to check, as a step towards the answer we are looking for here
The current observations are GPS and Glonass only. You should enable Galileo and Beidou logging in Emlid Flow, especially when doing PPK and PPP.
You processed the observations the same day as they were logged, ie. May 11th. When doing post-processed PPP, you want to wait one or two days so the orbits and clocks errors of the satellites are computed/modelized more precisely. PPP works in a way that such information has to be very precise to work well. When observations are processed the same day, there is high chance the satellites errors have not been computed yet. Then, CSRS-PPP has to use some predicted values, sometimes not accurate at all, resulting in inaccurate/unexpected coordinates.
After processing the file myself, I got
x 689527.9142m
y 6094285.0954m
z 645.2887m
which is very close to the RINEX header set. Here are the differences with it. dx = 0.0551m dy = 0.7648m dz = -2.6705m
I can say that CSRS-PPP are way off. Still weird to me, knowing the general quality of the service. But considering what I told you earlier, I invite you to retry to process the data tomorrow, or to use mine
EDIT : just saw @kirill.pavlyuchuk answered with OPUS coordinates. They are close to the centimeter with mine so @robertfroese you can go with one of these sets, or with the average of both.
I’d like to add that only GPS and Glonass are enabled because Robert most likely selected our CSRS preset in the Logging tab. These are the only constellations NRCan CSRS-PPP uses.
Don’t give up on CSRS-PPP just yet, it’s very, very robust. I use it all the time and it’s never let us down. There was a hitch for you this particular time, but it should normally work fine.
@jbonde002 I think you’re right. I double-checked, and there’s a typo. So that is the main explanation for the issue I had. Thank you for digging into the issue and finding this for me. Despite the stupid mistake, the solution is what really matters.
But at the same time, I want to thank @Florian and @kirill.pavlyuchuk for their help. I am very, very impressed with the support from the Emlid community and I learned very much from this interaction.
That’s true, but you can receive ITRF2014 coordinates from OPUS. They can be easily converted into NAD83 (CSRS) using the TRX tool of NRCan.
I see that the issue was related to the typo, so it was figured out. But it’s a good way to check the solution in different services if it’s possible, so OPUS might come in handy just in case.
