RTK position inconsistency

[aespinalp (Angel Espinal)]

Hello, i am a land surveyor and have access to a paid network of reference stations emiting corrections in RTCM3 via Ntrip, and also own geodetic grade GNSS recievers.

Today i was comparing measurements between my reach and other high precision GNSS reciever, i was using a data collector with survCE to serve the corrections to the reach, i surveyed one point with reach using the folloing configuration:

30 observations.
correction input: bluetooth RTCM3
correction output: bluetooth RTCM3
RTK settings: GPS only @14 HZ
and all other settings by default

Then, surveyed the same point using reach with the following configuration:

30 observations
correction input: bluetooth RTCM3
correction output: bluetooth RTCM3
RTK settings: All constelations except Beidou @5 HZ
and all other settings by default.

There was a difference between the two points around 50 cm, so after that, i surveyed the same point using a Geomax Zenith 35 pro, conected to the same base station, the baseline was around 1.3 Km away.

In comparison to the Geomax, the first point had a difference of about 2 cm in X, and a few mm in Y, it is ok, considering that it was inside the Std of the rech when the point was surveyed.

The point surveyed using more constelations, had a bigger difference, around 50 cm, and considering the base reference station is only GPS+GLONASS, i asume the problem is with GLONASS.

I am thinking on make more comparison using both configurations to see if it is a concurrent event.

Is there any way you can help me to determine what is going on there? maybe sending some logs for be checked? i will apreciate your colaboration.

Thankyou.

,

[TB_RTK]

Screenshot of settings used or a simple system report might tell if you can post.

[aespinalp (Angel Espinal)]

This is the first setting used

and this is the second setting used

In both cases, those were the input and output settings:

[TB_RTK]

Thanks. I would recommend continuous, fix&hold might hold/throw your fix off.
Also, when you say “30 observations”, could elaborate?
I would use 2 or 3 observations @ x Hz with 20-40min between each group to be on the safer side.

[aespinalp (Angel Espinal)]

Ok. i will try using continuous.

When i say 30 observations, i mean, the reciever was showing fix solution, and i took 30 readings for each point.

[TB_RTK]

OK, 30 iterations at 14hz aint much time. And if thats the only sample done i would give it another run,at least give 2 run with 20 min between to rule out bad fix.
Also, log both rover and base correction .

[aespinalp (Angel Espinal)]

In both cases, i waited about few minutes with fix solution, without moving the reach, just to make sure it wasn’t a false fix, the sky was clear, relatively close to base, so 30 readings is more than enough (asumig it was a good fix).

In general, for getting survey grade precision (2.5 cm), 10 readings is enough with a fix solution, and if we see the comparison with another device which could be “the reference” to compare with, the first point can be considered as good.

I didn’t mention that after the comparison, i surveyed the point again with the reach using the first configuration, and had the first “good” result. That’s why i posted this topic.

Also though that might be a base station problem, but discarted knowing the Geomax Zenith 35 pro was using GPS+GLONNAS.

I’m gonna take some measurements in a few hours and will be back.

[TB_RTK]

@aespinalp

I didn’t mention that after the comparison, i surveyed the point again with the reach using the first configuration, and had the first “good” result. That’s why i posted this topic.

Ok, good. That rules out few things.
There has been few issue with refrence stations using a different system. Might wanna check this as well

If your CORS network uses NAD83, with rover readings be relative to NAD83?

If so, is there a reasonable way to translate the points to WGS84 in QGIS? I assume I could find a known point near me and measure the offset. thanks, steve

And i quote
Reach receives NTRIP caster’s coordinates and expects them to be in WGS84. Rover’s position is calculated relatively to the received base position, so you will have this error embedded in all the points you collect. I can not guarantee any good results in a situation where the base position comes in an unexpected format.

All the casters I’ve had a chance to work with have a mountpoint that provides base coordinates in WGS84.

[aespinalp (Angel Espinal)]

The base station is configured to WGS84 coordinates.

I haven’t read that topic, but i knew that. Positions are relative to the base station, as the correction is made to the vector between the base and rover.

This is not the case, as both points were surveyed using the same base (independently of it is NAD83 or WGS84) they should have the same result.

[TB_RTK]

Did you record log on reach with base correction?

[aespinalp (Angel Espinal)]

No, i’m gonna do it now.

Just wondering, as i have never done it before, is it possible to postproccess together different versions of rinex? the base stations are loggin rinex 2.1, and for postprocessing events, rinex 3.x is needed.

[bide]

@TB_RTK

Thanks. I would recommend continuous, fix&hold might hold/throw your fix off.

Fix and hold mode is anxious to get a fix and hold onto it, plus it allows for some risk in doing so. Continuous mode is skeptical and if a false fix does happen, it will correct itself sooner.

@TB_RTK

OK, 30 iterations at 14hz aint much time.

Once you are comfortable with the behaviour of Reach for longer observations, and noticing how long it typically takes to settle into a good stable fix by viewing the x y z plots in RTKPLOT, then you will be able to shorten your observations confidently.

[TB_RTK]

Yupp.
Just download RTKlib (Emlid version) and set RTKconv to the version you like

Kinematic processing | Emlid Studio