Big issue with data repeatability - position error over 10cm

alessio.bonfante · January 31, 2024, 2:29pm

Hi everyone, i’m having big big issues with measuring points with my unit, a new RS3.
I’ve done multiple tests with my unit, and i’ve discovered i have big error over known coordinate points, once even 10cm in heights. I tried to raise the elevation mask from 15 to 20 degree, in order to reduce errors, things were a bit better, with errors about 5cm over known points. Every time i was in FIX solution, Ntrip correction (topnet live RTK), with low PDOP value and about 30 satellites (normal for my area, i live in a valley surrounded by mountains)

So i’ve tried to do multiple survey over same points, even with this GNSS Settings, but thing didn’t go well, i have my “manhole cover corner” for testing, and now i had big errors from 4 multiple survey:

This was today’s measure over past days survey over same points. How is it possible to have more than 10cm considering distance and height over same point?

This was the status of the rover in that moment. Every survey i’ve done i was in FIX, with that sigma errors, about 2cm horizontally and 2.5cm vertically. PDOP is ok. Tried also with IMU OFF with no improvement. Baseline from NTRIP correction is about 4km, not so far.

The manhole is outside my house, in an urban area, but as you can see from the pictures, i have a clear sky view in every direction and no near obstruction.

These are my GNSS settings

Should i try to raise the SNR Mask?
Could this issue be cause by interference?

I had same results in another area where i’ve done 2 survey in 2 different days.

alessio.bonfante · January 31, 2024, 3:45pm

Came out for other measurements, same manholes…

sara.aguiar · January 31, 2024, 4:05pm

Hi, this is a false FIX. I have been warning about the need for Emlid to urgently implement rules for point collection, such as defining a minimum number of satellites, a minimum pdop, the minimum horizontal StdDev, the minimum vertical StdDev, and the minimum age of corrections for the user to be able to collect the point with confidence. It is very important that points without significant errors are collected. See the image below of this functionality in the FieldGenius software.

tolerancia

alessio.bonfante · January 31, 2024, 4:12pm

Great, false fix…
in your opinion could be a false fix even if rover status parameters were good? i had 1.4-1.5 PDOP, and the standard deviation was low. Are these parameters fake? or these parameters doesn’t count masked satellites?
In this case, more i try to mask to increase quality, less absolute precision i shoud have?

igor.vereninov · January 31, 2024, 5:31pm

Hi Alessio,

This is a highly unusual situation to see such an error. You have really good conditions and it sounds like the base station is not too far away.

There could be three potential sources of these errors:

A coordinate system mismatch. How is the benchmark position determined?
An issue with antenna height configuration. When using tilt compensation, if the antenna height is not set correctly, the lateral position will be affected and not just the height. I can see that you are using a prism pole, often times they are marked for a particular prism offset and the marks do not match the actual height of the pole. This could be deceptive sometimes.
An issue on the base station. Sometimes it happens. I have seen malfunctions that cause position errors on the rover. After all, the RTK is only as good as the base station data.

The best course of action to find the root cause of the issue is to collect raw data logs and corrections logs and send them to our support at support@emlid.com.
After we look at the data, we will be able to pinpoint which of the factors is causing the issue.

The equipment is more than capable of achieving much higher accuracy in this environment, I am sure that there is simple explanation to the errors you are observing.

EBE111057 · January 31, 2024, 6:38pm

Hi Alessio

I agree with @igor.vereninov statements. What is your occupation time for each point ?

Adequate time on station for rover observations, even with our scientific Javad receivers (Triumph LS +) in the open with rtk radio or rtk ntrip we observe a minimum of 3 minutes.

I know this may seem like overkill, but in my profession I can’t afford or accept the time required to chase down inaccurate observations.

alessio.bonfante · January 31, 2024, 7:52pm

Hi Igor, thank you for your reply.
answering your questions:

coordinate system is the same, ellipsoid height so there’s no conversion. I have some benchmark position determined by our local administration, is our known points network for local survey. It’s our “bible”. Over these known points i’m observing same issue, every time i try to measure, i get different positions, not big mismatch horizontally, but in 4 measurements, +5-5cm in heights from reference point.
But the screenshot i’ve taken this afternoon was about a manhole cover outside my house, so these coordinates mismatch was from 3 observation taken days before, no known coordinates but mismatch from measurements of same corner.
antenna height is ok. Yes, that was a prism pole, it has 100mm shift from the numbers on the pole. I know it and i’ve consider it when set pole height.
that’s what i was thinking too. I’m using the TOPCON’S Topnet live RTK NTRIP service (national), quite reliable on the paper. I’ve been using it for 2 years, but i have to admit in last months we had some iusse with it.
I’m gonna check with our local NTRIP service.

Answering to Brian, in these case for checking accuracy the observation time has been quite long, i’ve stayed there a couple of minutes per measurement, after being still for that time, 5 seconds average marking the point. I can understand that more observation time means more precise points, but 12 or 15cm in heights like last shots, means there’s something wrong.

I’ve opened a ticket, linking this post for detailed info about the issue.
I’ll keep you update, tomorrow i’ll try with other NTRIP service.

In your opinion my GNSS settings are ok? shoud i set the elevation mask back to 15?

igor.vereninov · January 31, 2024, 8:33pm

The default setting at 15 degrees is really optimal, I wouldn’t recommend to change it. Still, the mask shouldn’t have such a significant impact.

jake_g · January 31, 2024, 8:58pm

Just to jump onto this…
I’m running a Reach RX currently and use it for a variety of things… Measuring base stations for machine control, drone surveying and general Topo surveying.

I have the exact same issue as above.

For example…
I measure a base station position using Trimble VRSNow using my ReachRX and also another point locally to cross check later. Once measured I then key those co ordinates into our Leica iCG60 base station and broadcast over ntrip.

I then disconnect from VRSNow and connect to the base station. I then stake out the point I measured earlier and we are usually 20mm out in height (not a big deal)

All seems well and everything seems to tie in until I switch RTK sources back to VRSNow for example.

When I switch, I almost always get an error between 100-150mm in height from the point measured earlier.

I have found that I always, if switching rtk profiles, the RX always needs to be restarted to obtain the same XYZ as previous.

sara.aguiar · January 31, 2024, 9:23pm

Hello, try to collect the point away from the house. I have noticed on my emlid rx that false positives are very common near buildings, where the rms presented is not real, even in apparently optimal conditions, such as many satellites in sight, low pdop and low correction age. For commercial reasons, brands have been developing very optimistic fix algorithms, which constitutes a major problem for the accuracy of the points.

timd1971 · January 31, 2024, 9:26pm

Using FieldGenius and the tolerance settings, do you get totally different results than using Flow on the SAME KNOWN POINT? I.e. FIX vs FALSE FIX?

sara.aguiar · January 31, 2024, 9:37pm

Excellent question. This is the test I want to do soon. I hope that with optimized and demanding tolerances I will be able to control false fixes. I’d rather not be able to collect the point than collect with a significant error.

timd1971 · January 31, 2024, 10:06pm

Is your assigned COORDINATE SYSTEM the SAME as the CORS / NTRIP COORDINATE SYSTEM?

What is the NTRIP using? What are you using?

sara.aguiar · February 1, 2024, 8:31am

Hello @igor.vereninov, I want to congratulate you as the co-founder of Emlid. You’ve created truly revolutionary products with above-average design and quality at a very competitive price. The user-friendly software, beautiful design, and excellent cloud synchronization contribute to a positive experience. The user forum for questions and idea exchange is another great aspect. Emlid’s constant software updates and user-autonomous firmware upgrades are valuable. However, lately, I’ve noticed that my RX device is highly susceptible to false fixes near buildings. In these situations, the presented RMS seems false, as after collecting and locating a point, turning off the device results in a significantly higher error than the RMS, even in seemingly good conditions (20 satellites in view, PDOP 1.6, correction age at 2 seconds, and a 6km distance from the base). How can I resolve this issue to have confidence in the precision and accuracy of Emlid’s GNSS?

MDS · February 2, 2024, 12:40pm

Something that would be VERY helpful is to update Emlid Flow so that we can easily stakeout the point that was just shot. Moving forward I will stake out every gcp point immediately after shooting it. If I take a series of topo shots I will stake out the last one on a slope to make sure it matches. This will at least help catch bad shots. So it would be nice to have a “Stake out last point” button on the survey screen so that after collecting the point, I can easily stake it out without leaving the add point screen.

alessio.bonfante · February 2, 2024, 3:33pm

Hi everyone, thank you for your reply.

I’ve already done the field test emlid’s support asked me, and maybe the problem could be the NTRIP provider. I have the subscription with TOPCON NTRIP Service, and as you can see from the data, that points have problem, the TPOS NTRIP (local ntrip provider) points doesn’t.

Emlid support requested me a 15 minutes observation with TOPCON NTRIP, then 4 survey: 2 with TOPCON and 2 with TPOS, after every survey I’ve done a complete reboot of the device.

I’ve collected 10 points per survey, point name is: “NTRIP USED”-RTK-“SURVEY NUMBER”-“POINT NUMBER”

Here you can download all the data:

https://drive.google.com/drive/folders/1Ck8n9v1P5ozeeS2RYvJOamkSBEsELwOP?usp=sharing

inside you can find:

Test emlid support (raw CSV file from flow project)
data_alldata_excel (same as csv but imported in excel)
Data_dividedPer-NTRIP-network (excel divided per survey, and divided by ntrip used. Then the table with elevation divided per survey)
Logs from all things done, except per TPOS survey 1, log corrupted.

From the survey data, I can for sure say I have the 10cm offset in height with TOPCON ntrip, also the XY coordinates have a non irrelevant shift. The TPOS points instead looks good, with 1-2cm shift in heigts, all normal.

In that points, i have a know point, the number 1. in my survey, coordinate system was ETRF-2000 and ellipsoidial heights. This is the point coordinates:

Tomorrow I’m going to make other 2 surveys, 1 Topcon and 1 tpos.

Yesterday i was in another region for a survey, about 250km from home, i’ve used TOPCON NTRIP again (but of course connected to another base), and i’ve experienced same thing: after half survey the emlid RS3 stuck, so i needed to reboot. After the reboot, all the previous point were 10cm lower than the points collected after the reboot.

vgo195 · February 2, 2024, 4:41pm

Some NTRIP providers send messages that some receivers can’t read.
I had the same situation with Topcon ntrip service in Greece.
When I used the VRS mountpoint all the points had 10cm offset vertically.
The rover was a Hemisphere brand but the same situation happened with DJI Mavic 3 Enterprise RTK.
So it is crucial to use your own base station to avoid such problems.
I use my Emlid M2 as base station and send corrections via Emlid Caster or in Local Ntrip if there is no cell coverage.
The other day I had a bad fix on the base station and it was 30cm off. The Hemisphere had good repeatability but the Emlid struggled to have a good fix in the same point. The base station was 18km away, not that far.
Anyway after some attempts the base station fixed closer to the Hemisphere point XYZ but again it had 6cm horizontal error.
I don’t know why this happened but in the past I had similar situations mainly in remote areas away from the ntrip base station.
I guess we can’t have it all in a affordable product.

mensurageospatial · February 3, 2024, 3:15pm

You are using single base as your correction system? I used it at the beginning with my RS2 and had similar solutions and errors. I changed to the VRS correction system and I get way better number over ngs and city points. Also they say the imax is the best correction system for gnss system.

alessio.bonfante · February 3, 2024, 3:30pm

I’m trying to figure out the problem, but I can be almost sure it’s an NTRIP Provider problem.

I was using the NET mountpoint, which I read it took the 9 closest base, create an average virtual base close to the rover.
I thought the problem was that, I so switched to nearest base mountpoint, 20km baseline, and thing gone worse, with 2 other dataset, one with 18cm error in Z.

I’ve opened a ticket also with Topnet live. Waiting for their answer on Monday.

I was using the NET_MSM5 mountpoint, for multi constellation solution.

adrian.levy99 · February 3, 2024, 4:04pm

I notice your pole has 3 telescoping segments.
Multiple segments lead to greater centering errors.
I suggest using a pole with a single telescoping segment and a checked/calibrated bubble.
Try this and tell me if your precision improves.