Static rover but FIX positions show drift of ca. 1m in 20 minutes

I am seeing drift in fix positions when my rover is static. This is processed in RTKLib against a Leica base station RINEX. The Reach was static for about 20 minutes and the XY positions show a drift in the order of a metre with fix solutions. The Z is (almost) acceptable in terms of stability). See attached plot.

I am using a new Reach M+ which wasfired up for the first time and updated a couple of weeks ago (sorry, I don’t have it to hand to post the reachview version but I assume it is the latest).

The antenna (shipped with M+) is on a 100mm aluminium base plane on a mast on a quadrotor drone (all switched off during test - see photo). Interestingly I didn’t see drift when I tried last week in almost the same location with the antenna not attached to the drone (or base plane).

I’ve tried fiddling with config parameters and get varying proportions Q1, but whenever I get fix solutions I see the drift. Interestingly, when the values only achieve float the drift is less pronounced/non-existent but, as expected, there is more ‘noise’.

I attach the log files and the config I’m using in RTKLib.

Any suggestions or help would be greatly appreciated, since 1m drift over 20 minutes might not be noticeable in a moving survey but would definitely ruin the results.

raw_201810011519.nav (21.6 KB)
raw_201810011519.pos (581.7 KB)
raw_201810011519.obs (6.6 MB)

Config_921_WithXYdrift.zip (1.6 KB)
1407274p18.zip (4.5 MB)

SystemReport.zip (105.5 KB)

Sorry, using Reacview 2.14.0

Hi @Ben_Evans,

Firstly, thank you for the detailed report and all attached logs :slightly_smiling_face:

After processing them, I’d like to share the result.

Here’re screenshots with the satellite view of rover (first pic) and base (second pic).


The second strange thing is that you’re saying that the rover is static but on the screenshot below I can see that it’s moving slowly as you mentioned.

So, can you, please, answer on following questions?

  • What’s the environmental conditions around your test base and rover area? Can you share a photo?
  • Can you show your base setup photo?
  • Have you got base .NAV file?
  • Can you share RAW base and rover log?

Thanks for your response.

When you say “the second strange thing”, what is the first? IS there something odd about the satellite visibility plots you nposted? If so, my untrained eye can’t see it.

Attached are the bas NAV and all raw logs.

Also attached is a phot showing where I set up, although without the equipment. Basically the base receiver was on top of the nearest corner of the building and the drone on the one slightly further away. Sorry for the poor quality photo. The sky visibility is, as you see, far from perfect, but I would have assumed that that would result in no FIX, rather than a fix, but with drift if visibility is the problem. There were sufficient satellites to get good RTK positions with the base using an NTRIP service.

1407274p18_raw.zip (6.6 MB)
raw_201810011519_UBX.zip (2.0 MB)

Best to get the BASE as far up out of the way of adjacent buildings, trees etc. They are clipping your clear sky view of the satellites. Put the base on the highest building if your area is highly urban with many buildings, trees, etc. Just the nature of what works best using GNSS.

Thanks. Most of my work is well away from trees and buildings, so not usually an issue, but I’m obliged to do what I can for testing here.

Surely I still shouldn’t get position drift in apparently ‘good’ data as observed?

Your DOP will suffer quite a bit in the environment you show here, and the DOP will change over time, as different sats come in and out of view of the antenna.
Try run a simulation with http://gnssmissionplanning.com/App/Settings and input your obstructions etc. It’s a real eyeopener.

1 Like

Hi @Ben_Evans

Green bars show satellites with good signal, as you can see you’ve only a few on base and rover screenshot.
It’s a normal situation if you place your base and rover as on your photo.

I’d recommend you to put UAV and base on the open space without any obstacles around and make one more test.

OK, I’m running a moving test in the field this week, so will include a static test too, see how it fares, and report back.

If it is satellite visibility, is there a way to stop the processing from reporting fix even though the data quality is clearly not adequate, to prevent false confidence?

For us, the “false result” is not the same as for device. If it can get fix solution with such sky view it will do this. During future logs post-processing, you can try different values for Elevation mask and SNR mask to get a suitable result for your environmental conditions.

Keep us updated, @Ben_Evans!

Thanks.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.