I’m running some tests on the RS2+ and finding that when connected to an NTRIP caster my RTK fix keeps dropping back to regular GPS fix. On inspection of the GGA strings being output, I found that these dropouts correspond to the Age of Differential/Correction value hitting 10 seconds. I see from a previous post on the forum that this is by design (dropping RTK if the corrections are more than 10s old), but I’d like to better understand what a normal AOD value should be, and what is causing my values to go so high.
I am using a free public NTRIP caster (via rtk2go.com)
I am connecting to the Reach via a hotspot WiFi connection on my iphone
is there any way to increase this cutoff value? I am using the Reach on a moving platform to recover the path travelled, and a sudden jump in position is generally worse than a slowly degrading correction quality.
Is there a way to tell from the data whether the increasing AOD is due to issues at the base, my rover, or somewhere in between?
Usually, it’s hard to say the reason behind the increase in AOD value right away, so it’s better to double-check all the possible factors. First, ensure that Reach has a stable internet connection to continuously receive corrections from the base and has a clear sky view.
Also, it’s worth trying to connect to different mount points. Maybe some mount points send corrections with a lower frequency that can cause a higher AOD value.
It’s more recommended to survey with low AOD values, so it’s better to avoid it increasing than to have a higher cutoff value. Let’s check if the high values persist, and if so, we can continue troubleshooting with other steps.
I switched NTRIP mount points, and the behaviour changed, but still got some problems with this - the new NTRIP was a single mount point that would automatically select the closest/best base on the network, but for some reason for a while I was only getting a correction from that base every ~30 seconds or so, causing it to continually switch from the nearest base (~8km away) to the next closest (~85km)
I realize that for static readings, there’s a benefit to ensuring low AOD values, but on a moving platform such as the one I’m using, I would prefer a slow degradation due to an older correction rather than switching between corrected and uncorrected. I realize increasing this cutoff would not be best for everyone, which is why having it as an optional parameter would be nice
There is a very good reason GNSS applications protect you from stale correction data, it’s going to skew your results regardless of whether you are mobile or static. I hope Emlid don’t offer this as an option, it would be extra clutter that experienced users won’t use and only cause problems for the unwary.
In your case the problem is likely upstream and the correction source poor. Further delaying and skewing your data is not going to solve anything, you need to solve the root cause issue.
Your data sources are suspect, RTKTOGO is the GNSS worlds version of social media, everybody is an expert, and anybody can post anything. Don’t blindly trust it, you have no idea how bad it actually is. There are no standards or even rigor in the contributed position accuracy, datum or bandwidth. Anyone can pump in rubbery positions, an incorrect datum out by meters horizontally & vertically, or via a haphazard slow feed connection. You could be taking in as gospel something dribbling out of a 10-year-old kids Raspberry Pi. Any mountpoint could be less accurate than simply recording autonomous (single) positions, and some may be excellent. You just don’t know.
Assume they are all suspect until proven otherwise. Do a proper test before you use one to make sure it is good, and this should be a rigorous static test on a known good control point. If it meets your criteria then enjoy the moment because tomorrow it’s feed coordinates could change and again you wouldn’t know.
Emlid gear is good, do it a favor and feed it the quality correction data it deserves. You have a number of potential alternative solutions:
Find a more robust source or provider, some regions have free government streams and otherwise be prepared to pay. You may be able to get a trial.
Set up your own base and validate the position to your own requirements. You will need access to additional equipment. Emlid Caster is free and works well, but also needs internet for the base.
Post process the data to fill in the holes. Cheaper, but more work. However, this would also normally give you more accurate results across the board including for the RTK corrected (or as the case may be, for RTK “corrupted”) positions.
If the issues is really only aesthetics and you simply don’t want to see jagged jumps visible in the track, then forget the RTK and just run a smoothing algorithm over your data. Many applications have this functionality.
A difference in the age of correction values can significantly affect the result in RTK. We recommend collecting data with a value of 1-2 seconds only. Surveying with high values usually isn’t enough to get accurate coordinates.
I can also agree with Wombo that either using a more reliable NTRIP service or setting up your own base is a good option for getting proper corrections. These may more probably help you to keep the age of corrections value low.
