Difference between Reach RS base and NTRIP correction

[wittich (Valentin)]

I have a difference between my tracks when I do the post-processing with the base data and with the nearby NTRIP data. The base was set with connected to the same NTRIP stream and an average fix.

1. How can be the differences so “huge” > 2 m east/west and > 2 m south/north. I assumed when I have a fixed on the base, that difference should be much smaller…

2. The other part I don’t fully understand yet is, why I have differences in which parts of my track have fixes depending on the base/NTRIP source.

3. Well the most important question for me at this point is how do fix this difference?

You can see in the fig. that there are different parts of the track in float/fix

Download Logs + NTRIP data (54.3 MB)

For the collection these data I used ReachView version: v2.9.3-r0

[egor.fedorov]

Hello,

Some base stations provide their coordinates in a different format or datum. As the FIXed solution is relative to the base position, there must be something different about the base position in the caster and in your Reach. Please share the info on your caster.

[wittich (Valentin)]

Hi Egor,

I added the Renex File of the NTRIP station from the whole day into the ZIP File…

The caster is available over: http://www.igs-ip.net/

STR;WIND0;Windhoek;RTCM 3.2;1006(10),1007(10),1008(10),1019,1020,1033(10),1077(1),1087(1),1097(1);2;GPS+GLO+GAL;IGS;NAM;-22.57;17.09;0;0;euronet;none;B;N;10000;GFZ

I’ll search if there are more information public available…

EDIT: Found it, https://igs.bkg.bund.de/dataandproducts/showstationdetails/id/1000188

2.   Site Location Information
 City or Town             : Windhoek
 State or Province        : Khomas Region
 Country                  : Namibia
 Tectonic Plate           : AFRICAN
 Approximate Position (ITRF)
   X coordinate (m)       : 5633708.7802
   Y coordinate (m)       : 1732017.6960
   Z coordinate (m)       : -2433985.8026
   Latitude (N is +)      : -223429.71
   Longitude (E is +)     : +0170521.95
   Elevation (m,ellips.)  : 1734.7

PS: @egor.fedorov are you sure that it is an transformation issue?

[TB_RTK]

From what i could see, i would think long baseline with IGS is the cause of mismatch. BS ranges from 16-20km in PPK mode, that is 6-8km more then the recommende value. When compared to Reach base, BS is 0-4km and far better data to work with.
I would rather do static process with Reachbase and IGS, and then PPK Reach with rover,that would give you the most accurate measure i think.
Other then that you could maybe process the result a bit better from IGS and tweek it to line up more, but dont think it will line up perfectly.
Other then that, VRS is an option maybe ?

You could do a test. If you drove the same route, but stoped and did static measure for few minutes and repeated this few places around the track, and then processed those static points with Reach base vs IGS base, i am pretty sure the resulte would suprise you. Static handles long baseline better then kinematic.

[wittich (Valentin)]

@TB_RTK

I would rather do static process with Reachbase and IGS, and then PPK Reach with rover,that would give you the most accurate measure i think.

That’s what I thought I have to do, though I still don’t know exactly the processes… Let’s see if I can figure it out by my self.

@TB_RTK

Other then that you could maybe process the result a bit better from IGS and tweek it to line up more, but dont think it will line up perfectly.

But that only makes sense, if I can improve and verify the Reachbase position, right?

@TB_RTK

Other then that, VRS is an option maybe ?

I have to admit that I hat firs to read about it (by the way thx for the hints), before I know what you mean. For now it’s only about PPK as I’m back in Europe, also the there is not something like a good GNSS network there (s. fig).

@TB_RTK

You could do a test. If you drove the same route, but stoped and did static measure for few minutes and repeated this few places around the track, and then processed those static points with Reach base vs IGS base, i am pretty sure the resulte would suprise you. Static handles long baseline better then kinematic.

I have a track from another day where I measure some GCP that should work for a test. Can you give me some more hints about the procedure? I’ve never got that munch into the detail of PPK…

[TB_RTK]

@wittich

I have a track from another day where I measure some GCP that should work for a test. Can you give me some more hints about the procedure? I’ve never got that munch into the detail of PPK…

Be aware of the baseline and use static measure. Postprocess it in static mode and log few minutes at each point. This measure should be done two or three times with minimum 15min if three measures or 30min if two measures. If all two/three points line up, your are golden (most likely )

Edit: If you already made a run, from the processing point, do control measures between each GCP and use it as base-rover setup. I assume you have the .ubx file.

But i hear its challenging to do survey in Lukeland
.

[bide]

In your first post at the top, how did you establish a base coordinate for post-processing? Was it by RTK from the same NTRIP source? or some other way?

[wittich (Valentin)]

@bide

In your first post at the top, how did you establish a base coordinate for post-processing? Was it by RTK from the same NTRIP source? or some other way?

Yes, well I did it with RTK in the field from the same NTRIP stream. I had a 3g connection for the time until I got the average FIX.

With the PPK I just used the data output from Reachbase. Actually I still didn’t fully understand how to recalculate the base coordinates in the PPK step and how to use that output for the correction of the Reachrover.

[wittich (Valentin)]

Okay, so now I found a little time to process the files again. I’ll describe step by step what I did’t, let’s see if there is room for improvements:

1. Get the static coordinates of the Reachbase

% program   : RTKPOST ver.2.4.3 Emlid b27
% inp file  : C:\Users\wittich\Example\Base\out\raw_201711221559.obs
% inp file  : C:\Users\wittich\Example\IGS\obs\2017\326\WIND00NAM_R_20173260000_01D_30S_MO.rnx
% inp file  : C:\Users\wittich\Example\Base\out\raw_201711221559.nav
% obs start : 2017/11/22 15:59:51.8 GPST (week1976 316791.8s)
% obs end   : 2017/11/22 18:31:45.4 GPST (week1976 325905.4s)
% pos mode  : kinematic
% freqs     : L1
% solution  : forward
% elev mask : 15.0 deg
% dynamics  : off
% tidecorr  : off
% ionos opt : broadcast
% tropo opt : saastamoinen
% ephemeris : broadcast
% navi sys  : gps glonass galileo
% amb res   : continuous
% amb glo   : off
% val thres : 3.0
% antenna1  :                       ( 0.0000  0.0000  0.0000)
% antenna2  :                       ( 0.0000  0.0000  0.0000)
% ref pos   :-22.574920442   17.089431707  1734.6752

2. Then I got the static average (like described here). I got the following average Reachbase coordinate: -22.566062960, 17.260892157, 1993.3128

3. I processed the Reachrover data with the “new” Reachbase and the following settings:

% program   : RTKPOST ver.2.4.3 Emlid b27
% inp file  : C:\Users\wittich\Example\Rover\out\raw_201711221613.obs
% inp file  : C:\Users\wittich\Example\Base\out\raw_201711221559.obs
% inp file  : C:\Users\wittich\Example\Rover\out\raw_201711221613.nav
% obs start : 2017/11/22 16:14:20.2 GPST (week1976 317660.2s)
% obs end   : 2017/11/22 18:47:18.6 GPST (week1976 326838.6s)
% pos mode  : kinematic
% freqs     : L1
% solution  : forward
% elev mask : 15.0 deg
% dynamics  : off
% tidecorr  : off
% ionos opt : broadcast
% tropo opt : saastamoinen
% ephemeris : broadcast
% navi sys  : gps glonass galileo
% amb res   : fix and hold
% amb glo   : off
% val thres : 3.0
% antenna1  :                       ( 0.0000  0.0000  0.0000)
% antenna2  :                       ( 0.0000  0.0000  0.0000)
% ref pos   :-22.566062960   17.260892157  1993.3128

4. Now I compared again the data (I processed them with the same settings from above). The result is much better.

From what I can measure by hand the difference is much better:

• FIX < 10 cm
• min. 1 FLOAT ~ 30 cm

Will just running some statistics to see what are the “real” difference in numbers, but from what I can see like this its totally in an acceptable range.

So basically the problem was that I got the Reachbase coordinate in first place from the RINEX header position (which is the one from the field, right?). Locking into the Reachbase signal, I saw that it took over 40 minutes to get a steady FIX. And now I remember that I might have just FLOAT the average in the field 'cuz it took forever…

Anyhow, finally the map with details looks much better. Thanks for the help @TB_RTK and @bide

[bide]

I’m glad you figured it out! And yes, your map is looking quite good now!