We are using a pair of RS2 receivers (base and rover in RTK mode) and the base position is fixed over a known location. After about an hour, we’ve noticed that the rover location will drift (up to 0.55’) when left in a static position and then we’re unable to locate points with any accuracy.
We are losing a lot of field time due to these interference and drifting issues and they are happening each day we’re in the field. The field team has been collecting logs and taking pictures of the data, but I’m hoping that there is something I can do in the meantime, before the data is sent to support, costing us more time. Any advice or recommendations are appreciated!
We have a ticket in with support, but I’m looking at all other options.
Yes, we are usually connected with only one device, but as I mentioned, they were attempting to troubleshoot. Turns out that they had the wrong base entered, so the multiple devices showing different locations is not an issue, but the drifting and unrepeatable measurements is still an issue. I will strike that from the original post.
Are your units in clear sky areas ? The Reach devices are good receivers, however any kind of multipath (trees, buildings, cars, etc) will give bad results.
Just make sure you or your field guys are not trying to obtain positions near any of the above.
Also, make sure your base has a stable mounting. Although it’s only happened to me once, the wind blew over my base. I could tell my positions were off by checking into known points and my radio signal went to nothing. Just an example. I use sand bags on windy days from that episode !
Hi Bryan,
Thanks for the reply. Yes, we’re in open fields, with a clear view of the sky, no buildings for several hundred feet, and we’re using a stable tripod on a windless morning.
I’m having the team check the settings again, but we’re at a loss of what’s going on. We’ve been using Emlids for several years and we’ve never experienced this level of interuption.
Would be unlikely to be EMI, that spreads as an inverse square so would dissipate relatively quickly over distances like we can see. And the issue is apparently not electrically random e.g. no other quirky issues, just drift and in different locations.
I would also have initially guessed it sounds symptomatic of multipath but otherwise then sounds more systemic.
Jason, are there any recent changes that may have been made that could be coincident and backed out? E.g. Procedural, staff, specific assigned devices, possibly firmware or software updates, whatever. Just stepping back out and looking at options for a quick fix as you stated this is new so something has changed and I would be looking to revert to a previous known good state if possible.
Nope, no welders, power lines, or UFOs in the area. Again, this has happened at multiple sites (hundreds of miles from each other) in ideal conditions and proper setups. Thanks for checking though! We’re going back to Trimble R10s and we’ll see if there’s any problems with those.
I asked the field team to check all settings and make sure they didn’t change anything that was vital to normal operations and nothing has changed. They’re using all of the available constellations, logging at normal rates, masking is normal, etc. All units are using the newest firmware and software and we can’t seem to find anything abnormal.
We can measure a point, leave, then come back and get over 6" of difference to what the original shot was. That’s if we can get a fixed position. We might work for several hours with “good shots” and then come back and try to reshoot and have errors of several tenths. The team will set up the rover and just watch the position and see almost a foot of drift while sitting in one spot and observing a static shot, etc.
Apologies for the dumb question but I’ve got to ask, are the base receiver coordinates actually configured Manual to the known point coordinates e.g. fixed?
Or set to Average in which case your rover position could be moving relative to wherever the base averaging is up to at that time?
Assuming correct procedures suggested by @Wombo are correct, the only other issues are maybe
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 do the same with my M2/RS2. Lower observation times are hit and miss as far as accuracy is concerned. PP with commercial software will require at least that for a reliable solution.
Low pdop values overall is imperative in obtaining a good solution also. I always try and see what the overall constellations conditions will be throughout the day. There are several free mission planning sites online, Trimble 's is a great example.
The only other issue other than those mentioned I can think of might be software issues.
I usually have two base receivers, one as a rtk radio broadcast and the other simply as a static receiver. I’m logging data at both static receivers as well at the rover. Usually if I’m using the Emlid’s, I’ve got two receivers as a static baseline approximately 500 meters apart depending on the survey site. Using my rover collecting positions, I can PP the baselines for each point. This method I know for sure I have adequate accuracy values for each collected point as I have a closed polygon loop. For short baselines in the open (<2km) , 3 minutes occupation time for rover points is adequate. This is the only way to know for sure if your rtk “fixed” positions are truly fixed to a sufficient required accuracy.
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.
I want to mention that @jrolfe is also in contact with us. I’ll post the summary and findings here once we finish troubleshooting.
If anyone encounters the same issue or has any questions, please feel free to create a new thread in the forum or email us at support@emlid.com. Thank you!
I know this kind of unlikely, but are you anywhere near Israel or Ukraine? Or possibly any other war-torn part of the world. I’ve read some many article about intentional GPS / GNSS interference / spoofing lately…
You would need to supply Internet connections to your base and rover, of course. You can use cell phones or I believe that the RS2 has a built in cell modem and can accept a cell phone SIM card to provide the connection. I’m not suggesting that youdo that all the time, just to eliminate one of the possible causes of problems.
One other thing occurs to me. Have you checked that your base is still configured to send out position messages? If you’re using RTCM that’s type 1005 or 1006. If the configuration had got scrambled and those messages are unconfigured, the rover could be receiving other messages but it would effectively be uncorrected and you would get something like the behaviour that you report.
I know from experience that investigating problems like this is very frustrating because you can’t see what’s going in under the covers. I also distribute a piece of free software that sits between the base and the caster and captures and displays the messages so that you can see what’s going on. go-ntrip/apps/proxy at master · goblimey/go-ntrip · GitHub
Can’t wait to see what the issue was. Cannot find much here searching the forum in the past with this subject… so must be an isolated case? Operator error? We’ll see.
i’ve occur such same issue with RS3 with NTRIP correction (baseline 4km). I’ve done multiple surveying in different areas, where i have also known points. I’ve done some check over that multiple points, and i had even 10cm difference in heights, in few cases, with elevation mask set to default 15 degrees.
On a known point, i’ve done 3 measurement in 3 different days: once +5cm, once -5cm, last +3cm.
Tried to add more elevation mask, i’m now at 20 degrees and i can observe 5cm error on heights at same points.
