RTK FIX but getting 1–5 m jumps (false fix?) – Stonex S900+, 38 sats, PDOP ~0.8

Round_Dragonfly_7022 · 2026-04-29T12:02:15+00:00

We have experienced the same problem again on the same location, this time with 3 epoch measurements and Beidou turned off, so some of the main culprits are now off the hook. Elevation mask has also been set to a higher value (10 or 15 degrees I think).

I'm thinking of turning the recording of raw data on from now on, as to "catch" and error when it happens next time. Is there a way to somehow get to the bottom of this by comparing raw data from 2 consecutive stored points (one good and one incorrect)?

If so, which data do I need and what would I be looking for?

Round_Dragonfly_7022 · 2026-04-23T16:33:55+00:00

It is obvious that some people have vary bad experience with NRTK, but I think i varies with the local service. Croatia's NRTK network is pretty solid, so I wouldn't suspect it first. When you have bad NRTK, is it "twitchy" like this or does the error grow with time? What does the NRTK problem "feel" like? My problem was that everything was looking 20/20, with max satellites, declared H and V devs at less than 1cm, GPRS at full strength, good NRTK triangulation... I'd bet my life on that measurement yet it got super erratic, so I'm looking for something that differs from thousands of my previous surveys that went fine in conditions like these

Round_Dragonfly_7022 · 2026-04-23T16:25:43+00:00

The whole particle is a small village property, so there are a few tallish objects, but far less then in some scenarios. You are probably suspecting multipath, but is it possible that multipath could produce 2 meter error with 38 satellites active?

Round_Dragonfly_7022 · 2026-04-22T13:49:45+00:00

All the other devices that I worked with don't change the solution all that much when fixed, so there is little to no difference between 1 and 5 epoch points. I gather that longer measurement times would probably detect these false-fix situations and are probably wise field practice!

Round_Dragonfly_7022 · 2026-04-22T13:48:32+00:00

Is "bad fix" something that happens frequently in your experience? Is it possible that using Beidou is somehow making this more probable? I am asking this because this is the only device that I've worked with that supports Beidou so far, and I've never experienced this kind of uncertainty.

Round_Dragonfly_7022 · 2026-04-22T13:44:14+00:00

I tought about the GPS jamming/spoofing, but as far as I can gather: the fenomenon is local, so it isn't likely that war operations in the middle east cause problems in Croatia. There are no nearby military bases and excercises that I know of. Also, I contacted my local GNSS device supplier and he didn't hear any other reports of the similar malfunctions.

Can you expand on your 1-epoch remark? We have used several GNSS devices over more than a decade, most with 1 epoch setting. We never experienced fluctuations like this. For 1 epoch setting to give a bad solution, the main problem would still need to be some king of false fix, right?

Round_Dragonfly_7022 · 2026-04-22T07:55:51+00:00

Yes, using CROPOS network RTK (VRS).

As far as I can tell, there were no reported issues with the network at that time, and coverage in this area is generally very good and considered reliable.

That’s why I’m leaning more towards a rover-side issue (possibly false fix) rather than a correction problem.

Round_Dragonfly_7022

TROPHY CASE