False FIX needs an Urgent Update

Hello everyone, I’m Alessio, and i’ve been using the RS3 for about a year. When my unit was brand new, i had a false fix errors, as detailed explained in this famous forum topic: https://community.emlid.com/t/big-issue-with-data-repeatability-position-error-over-10cm/37043

After that, it seemed it was a NTRIP problem, i’ve changed provider and the errors looks disappeared.
But that’s not.
This morning i had huge errors during a survey, where my RS3 was totally in FIX solution with RMS errors around 1cm XYZ, but every time i “rebooted” it (stopping NTRIP corrections and then reconnnect) i had different values on the same point. Almost of them in that 10cm range of error, specially in Z.

Then i tried to PPK that points in Emlid Studio, and i discovered almost all of them were in FLOAT, so the Rover was in false fix almost all the time.

Here’s some screenshot of me trying to check a point. As you can see we have 18cm in height difference this time


On the same point, FIX solution, after a reboot, METERS AWAY!

This is the PPK track of my GCPs, as you can see most of them are in float (i needed to apply a combined filter type to get some fix, if i use the default one, 99.5% of my track was in float.

The area where we had the survey isn’t the most comfortable one, inside of a valley, we used also a Riegl Laserscanner with builtin GNSS and even that one had FIX problem, but at least IT SAYS is in float solution. Not like the Emlid which tells you you’re in FIX and then you’re not.
This is a HUGE problem. I can’t rely on my instrument in the field.

If someone from Emlid wants to give a look on this data, i’ve uploaded datas in this gdrive folder.
https://drive.google.com/drive/folders/19prPIXyoTqSk1dHMt1NuD_PRZ9yWjmBB?usp=sharing
you find the points data in the CSV, the Reach LOG, and then RINEX files from 2 different provider and antennas: the TPOS (Trentino Positioning) which is a local NTRIP provider, and the HEXAGON national service.

As i said, i tried getting points with both TPOS and HEXAGON, and i had same errors in field. All of the time was in fix, but i get different coordinates every time i change ntrip correction.

1 Like

Keep an eye on Age of Corrections… below 3. Lower the better.

https://rpls.com/forums/gnss-geodesy/what-causes-gnss-blunders-when-you-have-fix/

2 Likes

What were your occupation times at each point ? I’ve found if you are in any kind of multipath areas, you need to use extreme caution in accepting any “fix” results. Short observation times in high multipath areas are a no-no. Even in clear sky conditions, I observe a minimum of 3 minutes at 10hz for important points.

In areas of multipath, long occupation times with logging for each observation and multiple observations per point are needed. Also, make sure you have a base receiver logging onsite even if you’re using radio or RTN RTK. With short baselines and adequate logging times, you’ll have confidence in verifying your “fixed” solutions via post processing.

4 Likes

Hi Alessio,

Thanks for sharing the details and data! I’ll take a look at your logs and get back to you with my thoughts. In the meantime, could you please try testing the latest firmware version 33 Beta 1? We’ve made some updates to the GNSS chip firmware and improved the position calculation algorithms.

Here’s the guide to help with the update, and make sure to enable Beta updates.

when i use it as base for my drone flights i usually take 3 minutes observation for base coordinate calculation. Then i register 2 points one after the 3 min base registration and one at the end of the flight (in this case 30 mins later).


after 3 min base confirmation

at the end of the drone flight, 30 mins later.

Then using another Ntrip provider (hexagon, imax), as you can see 11cm higher then the last one.

For other points i take as gcps, usually take few second observation. I stay on the point for few seconds “idling”, then i take a 5 seconds measuring with 10hz gnss update (50 measures).

Thank you. I’m updating right now, i’ll try in the next few days.

In the folder i’ve added 2 files: first one is the Emlid log for the drone flights (i use to log it separately) and the CSV (Autogrill adige est - file tpos hex) for another group of points (where i don’t have the log because i forgot to restart the recording).
Inside this CSV there’s same points taken with TPOS and HEXAGON. Suffix “hex” for points taken with hexagon.

in this group of points only the first 2 (ppk base inizio/fine) are inside the RS3 log.

Maybe you don’t need these data, but just to demonstrate i was totally in fix and with low pdop while measuing these points.

Hi @alessio.bonfante, I understand your frustration with the results, here is what immediately jumps out at me when looking at the data:

  • The base station is almost 30km away, which means that there is a ppm component in error, that results in additional 30mm error budget, leading to 44mm of expected RMS. Switching from an IMAX mountpoint to a VRS one could help eliminate it if that is available.
  • The tilt field in your export file shows different tilt angles between reboots, as well as your screenshots for the base station reinits. For long stationary shots it is not advisable to use tilt. Turing tilt compensation off for base station positioning would also improve your results.
  • When using different NTRIP providers at these baselines, there is no guarantee that the results are going to match perfectly between the two networks, this is again due to ppm and uncertainties inside the networks.
  • The fact that there is difference in fix percentage between RTK and PPK by itself is not an indicator that a fix in RTK is wrong. The algorithms used are different and the fix calculation process is stochastic, which means that it converges or not converges based not only on the input data, but also on the tuning of the filters and specific algorithms used.

Having said that, I am still unsure if I fully understand your test. Are all the points from boot1 to boot32 taken in the same spot? The difference in coordinates is up to 40 meters, so it doesn’t look like it is an RTK error. If indeed you saw fixes in the range of 40 meters of error than the only possible explanation could be either a problem with a base station or a spoofing attack. It is impossible for the receiver to produce such an error.

By the way, which firmware version are you running on your units?

2 Likes

Hi Igor, thank you for your reply. Answering your questions point per point:

  • ok the base station is 18km away for TPOS and 30km in Hexagon configuration. But 10cm in Z is not acceptable anyway, not in FIX and not with RMS error declared of 12-16mm. My colleague has a Sokkia rover that haven’t this kinda problem with same NTRIP provider (TPOS).
  • Yes, the tilt was on during GCP collection, but while using RS3 as base for drone operation i always turn it off. The log file i provided was the one from GCP collection, so with the Tilt turned on
  • Yes, different ntrip provider could give different results, i know. But even if i use only one of these, turn correction off and then on again, i have that 10cm specially in Z. During GCP collection i notice that because while measuring i lost FIX for a while, i came back on a point after a new Fix (with same ntrip provider), and i have 10cm difference in Z.

for the points name, “boot-number”, that is not the same point measured N times. These points are different GCPs taken while a “test” after the first campaign from the other CSV in my gdrive folder.

In fact, i started collecting points with TPOS, i noticed the differences when losing FIX, then i started collecting with Hexagon instead of TPOS (in the other file, i have “PPK BASE INIZIO/FINE” which is the first base points, then i have numbered points taken with tpos, then “hex-number” which is same points taken with hexagon).
After that i took a new file with LOG, which is the one you’re looking at, the “boot-number”.

Firmware: i was running the last non-beta firmware, was the 32.1 i guess. I’ve already update to beta 33 as asked

Seems even regular users, inexperienced or new users take FIX as gospel? Maybe something needs incorporated into FLOW distinguishing any misconception?

i.e. ADD PDOP and Age of Corrections right above the MEASURE button to see it quickly while measuring? I know you can click the precision area to go into the Status overview to see all of the details.

Also, add PDOP and Age of Corrections limit in the Survey settings Collector Rules also? Maybe a MULTI-PATH warning also?

Most survey software have these things.

I’m not a new user, but when i have a FIX and PDOP between 1.2 and 1.8, i can guess points should be quite reliable… :face_with_spiral_eyes:

2 Likes

:+1:

1 Like

Someone may have already asked but what was your baseline?

his baselines are in his screenshot above.

Just typing it would have been shorter, lol.

I see 18km in PPK but that doesn’t mean anything to the RTK capture because there could have been a different source of corrections used. You can see in the points list that it jumped from 18 to 28km which tells me it’s VRS. First thing is to get off VRS if that is the case. I have had similar issues with other brands and well.

2 Likes

Usually, my VRS point is only a few meters away from my rover using our state’s RTN. I’ve never used any other so things maybe different. However, I think the VRS is designed to have a short as a baseline as possible.

2 Likes

Hi Alessio,

Thanks for the detailed reply and for updating to the beta firmware.

I’ve reviewed the logs, and the quality of both looks good to me as well. The PDOP being under 2 suggests a good satellite geometry.



I converted your RTCM3 file to RINEX. It helped me see the shared satellites between the NTRIP base and the rover. There were about 24 in common, most of which remained stable.

Also, I tried processing the data using the parr base logs (TPOS) and RS3 data. With a 20-degree elevation mask, the Combined filter, and the GPS navigation data, I was able to get 97.4% FIX solutions.


Looking at your location on Google Maps, it appears pretty open. For now, the environmental conditions don’t seem to be the main cause of the mismatch issue. Still, you noted that your colleague’s receiver had trouble getting a FIX solution in the same area. So, we’ll keep that in mind as we continue investigating.

It’s great that you’ve tested both TPOS and Hexagon. From the data in the Autogrill Adige EST CSV, I can see a mismatch of up to 18 meters. This is most noticeable between point 5 and hex5, as well as between point 7 and hex7. We need to investigate further to understand what might be causing this. As Igor noted, it doesn’t seem to be an RTK processing error.

To help us track down the cause, could you please conduct some tests without tilt compensation? This could help us rule that out as a factor. Do you have any known points in your area? That would be perfect for comparison and help us determine if the issue is device-specific. Also, when you run the test, could you enable the following log options?

  • Raw data debug in UBX
  • Base correction log in RTCM3
  • Position log in LLH

Once we have the results from these tests, we can analyze them and see if there’s anything specific that stands out.

1 Like

Thank you for your detailed reply. I’m going to test the data in PPK with your setup, then check it in our photogrammetric model to test its absolute and relative precision, compared with our Riegl vz-600i with gnss. For this project i’ve used the laserscanner model to get GCP for my Mavic3E photogrammetric reconstruction.
With these PPK fix points, i’m going to re-check GPS positions.

I haven’t done a detailed survey with the beta firmware you told me to install, but 2 day ago i’ve tried it during a small work. I need to create a detailed post you with logs you can analize, but in summary, i haven’t had RTK issue during the survey, checking few points 2 or 3 times, and getting errors between 0 and 3cm XYZ (acceptable), but when at office, i tried to PPK the points i collected, and the results were quite different between the RTK points. Not meters but about 7-8cm differences between RTK and PPK points. I’ve used the RS3 as base for a P1 Matrice 300 flight and then PPK the P1 pictures with Emlid log, and the photogrammetric model are showing the RTK points are more accurate, with Pix4d model.
But as soon as i have time enough, i’m going to create a detailed post with data and picutres.

Regarding the CSVs file, if there’s points mismatches more than 2 meters, that’s my fault. They’re not the same points. I was in hurry for that work, i’ve noticed points mismatch and i’ve done the points collection 4 times, few points might not be the same points with same number. Don’t get mad. :frowning:

Close to my office i have 3 government known points, in the next days i’m going to create a detailed logs with my RS3. Then i’ll share for you analysis.

I’m start thinking it’s my unit the problem… I had this kinda problem since day 1 :confused:

Thank you

Thanks for the update and for sharing your plans! No worries about the mixed-up points :ok_hand: It’s totally understandable when working in the field. Testing on the known points near your office should give us a clearer picture. Once you’ve tested, please send the logs my way. Looking forward to your results!

If anything suggests an issue with the RS3 itself, we’ll definitely explore other options we may suggest.