After entering base coordinates from CSRS-PPP, results are worse

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.

What am I doing wrong?
default.pdf (520.4 KB)
withbetterbase.pdf (677.8 KB)

Hi Robert,
would you please share both sets of the base coordinates ?
Set 1 from the RINEX header
Set 2 from the PPP report

What is the quality of the PPP coordinates according to the report ? RMS values ?

From the RINEX header (as reported by Studio)
Lat 54.959405718
Long -114.039709661
Ellip. height 647.9592

From CSRS-PPP (ITRF20 which google says is close enough to WGS84)
Lat 54.95107917
Long -114.03970843
Ellip. Height 645.274

The log was 5 hours and CSRS-PPP is reporting sigmas 0.007 m for lat and long

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

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 :slight_smile:

1 Like

Hmm I am self taught and so your help here is very much appreciated! Here is the RINEX file:

Hi Robert,

You can also try to process your log with OPUS service. I’ve tried to upload it to OPUS, so find its solution below:

You can check how these base coordinates work for your dataset in Emlid Studio.


Thanks !

At first glance, before process, my comments:

  • 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

See log file (2.5 KB)

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 :sunglasses:

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.


Florian, thanks for your comments!

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.

1 Like

You’re welcome !

Oh ok, I did not know that. Well, everybody, contact me then if you want to do PPP with full GNSS :laughing: :innocent:

1 Like

Thank you @Florian, I will try again tomorrow.

@kirill.pavlyuchuk I was led to believe OPUS was optimized for the continental US, and hence my focus on CSRS-PPP. Am I mistaken?

@Florian what service are you using for PPP?

I use a module called WaPPP, developed by researchers.

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.


What went wrong? My guess is you just made a data entry mistake. This is common.

In DMS format you have the CSRS-PPP latitude as 54 57 03.8xxx (converting from DD)

When I submitted the file to CSRS-PPP I got 54 57 33.8xxx

There’s your 900+ meter difference. The quality of the orbits won’t make anywhere near that difference.

Now if you check your original CSRS-PPP report and the latitude is indeed
54 57 03.8xxx and not 54 57 33.8xxx I would contact CSRS-PPP.


+1 @Gabriel_C

Although it’s been a while… we might once again be looking at NRCAN by necessity.

Note that Mark Silver’s scoring in the linked article is circa 2013.

1 Like

@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.


Hi Robert,

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.