Comparison between straight PPK from NTRIP RINEX and base-RINEX

Reach Module / M+ / M2 RTK / PPK configuration
1

I was going to process some results from our last expedition to Iceland and found one very strange thing.

Our workflow in the expedition was as following:

We were placing one Reach RS+ unit in the camp as a static base station in order to collect local satellite data. The data was used for processing our rover Reach RS+, which we took with us to the survey territory. The survey territory was about 7 km away from the camp. We were not using any RTK. Usage of local NTRIP casters in RTK mode was not possible due to poor GSM signal, that’s why we thought to do PPK afterwards with RINEX data. So, we were collecting raw log with base station and with rover, which afterwards we would combine in a following way: 1) correct base position with NTRIP caster RINEX files, 2) assign corrected coordinates to the base station and correct position of the rover against base station log file. Everything went fine and we got ~50% of all log in FIX status. Base station log was 98% FIX with average error of 5 mm. The NTRIP caster base was ~40-45 km away, so I assume, that total error might be around 5-7 cm, according to the formula of 7mm + 1mm/km.

Then, I tried to do the same correction to the rover, but against RINEX data straight forward, without using local base. And I got a track file, which in comparison to previous results was 1.5-3 (!!!) m off. I have no idea, what can be wrong. All the same processing parameters were used, so I prepared to see straight RINEX aproach track to be off some 10 cm, but not meters!

After finding this issue, I tried to do the same workflow here, in Latvia, and I see, that track is constantly off some 30-40 cm (RINEX base station is 1.5km away, Reach RS+ base station was ~300 m away). At some points, I see, that the shift is larger depending on the direction, which I was moving. This can be described with poor PDOP, but in Iceland data I don’t see the same clues.

Where the problem is hiding? What can be a solution to this problem?

Attached are files from the experiment in Latvia, if someone wants to check them. I would appreciate, if someone could.
dac_rover_base_experiment - Copy.zip (6.7 MB)

P.S.: I consider to trust Reach RS+ base station in Iceland, than local RINEX, because base station was only 7km away, in comparison to RINEX data.

3

Hi @jurijs.jeshkins,

Sorry for the late response.

You’ve such an interesting case :slightly_smiling_face:

I want to try to reproduce your steps and asking if you can share raw .UBX logs (from your rover + base) and raw RINEX station logs?

Thanks,
Andrew.

5

Hi @jurijs.jeshkins,

Can I ask once more to share your raw logs please?

Thanks.

6

Yes, sorry, I was out from computer. I will attach them tomorrow.

8

Here you can find log files from rover, base and local RINEX from LatPOS network.

9

The coordinate for the RS+ base, was that set manually in ReachView (and so stored in the log)?

10

Coordinates for base were calculated from RINEX in PPK. You can use included RINEX for calculating them.

11

Done a few processing-runs using your supplied files (and MGEX precise clocks/orbits). I too get an offset from using your own base and the CORS. Are you sure that the NTRIP provider are running WGS84 ? I tried looking up the station, but couldn’t find a info-page on the provider (didn’t look very hard though :smiley: )

Both the UBX files are a bit wierd though. They don’t display their SNR like I am used to from my own RS+ units. Instead displayed as grey in RTKPLOT?

Base processing

BaseJuri
BaseJuri.JPG1272Ă—1074 132 KB

Rover processing, both base and cors base used (First result is using Cors Base):

diff-track
diff-track.jpg863Ă—705 118 KB

Zoomed in:

diff-track-zoom
diff-track-zoom.jpg863Ă—705 139 KB

Alt view:

diff-POS
diff-POS.jpg863Ă—705 133 KB
base.pos (745.2 KB)
rover-CORS.pos (571.1 KB)
rover-ownBase.pos (570.4 KB)
base.pos (745.2 KB)

12

Thank you for trying out my data. So, for me it looks, that I did everything right, cause we have similar results. LatPOS network is working in local system LKS92, but as I get WGS84 coordinates from the RINEX header, I assume, that corrections are in WGS84. @wizprod, do you have any thoughts, why would they differ? Is the problem in units or in processing?

13

That is probably much better answered by the NTRIP supplier. They would know for sure, mine would just be guesswork.

14

It is just interesting, why I have similar difference in data based on 2 different NTRIP casters (as I was writing in my main post, the second experiment was in Iceland with Iceland NTRIP network). I will definitely ask NTRIP caster for their explanation.

15

Be sure to let us know their answer, once you have it!

16

I think most of the issue you have lays in the rover. Its full of noise… Base left, rover right

image
image.png1270Ă—534 45.3 KB

1 Like
17

Hi @jurijs.jeshkins,

Do you have any updates?

18

I was visiting local NTRIP caster, but they don’t have any explanation about what can cause trouble. We tried to measure points with different GPS systems (you can find results in this topic: Comparison between Emlid Reach RS+, Leica, Altus and Trimble receivers - #5 by michaelL), but results showed no shift from original coordinates. Now I don’t have too much time to experiment, but I still have to try to do the same approach, but for static points. Basically, the workflow should be as following:

  1. Measuring static point in RTK mode with logging turned on.
  2. PPKing collected log and comparing results with RTK measurement.

Measurements should be the same.

With our local NTRIP caster we have different correction techniques:

  1. SITE - corrections are received from nearest station
  2. NETW-MAX - corrections are being received from nearest station + 4 stations around the point
  3. NETW-iMAX - corrections from nearest station + 4 stations around, but modelled for the point, where the measurement is taking place
  4. VIRTUAL-RS - NTRIP caster is placing a virtual base station near the rover and modelling the corrections.

I had good results with VIRTUAL-RS, but with NETW-iMAX I had the issues, which were described in this topic. Maybe, it is the correction issue. It would be nice to compare the same results for all correction methods. I have 4 Reach units (2x Reach RTK kit and 2 Reach RS+). If I will connect them all to the one WiFi and place them on some kind of a rig, I could run simultaneously all 4 RTK correction methods.

19

Hi @jurijs.jeshkins,

Thank you for the update.
Hope, you’ll find time to make a test someday :slightly_smiling_face:

21

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.

22

Hi :slightly_smiling_face:

The topic was closed long ago. However, we have a great update for it.

Not a long time ago, we released the Emlid Studio. It’s an easy-to-use application for raw data converting and analysis, PPK, and geotagging. You can find helpful guides for each app feature on the Docs page.

Feel free to contact us with any questions or to share feedback!

1 Like