We always update our Reach RS units to the latest version, currently 2.11. However, we believe we saw some for of this problem going back several versions, but in earlier versions did not yet understand the problem.
The problem is that the Reach RS shows on the Status tab and in the NMEA log the last collection point even after moving the rover to a new location anywhere from 10m - 100m away. So if at location A the rover achieves a very good fix, then we move to point B the rover continues to produce point estimates at location A. We saw this repeatedly several times recently. And we think this explains why some of our test data collected last year were inaccurate by 16 meters at one location and 80 meters at another.
We use the Reach RS as a rover to log real time position estimates to a NMEA log file.
Our testing method;
Position the Reach RS over a known location
Start logging
Stop logging after 20 minutes
Position the Reach RS over the next known location
Start logging
6 Stop logging after 20 minites
We repeat this until we record data at all 18 of our test locations.
RTK Settings
Postion Mode: Static
GPS AR Mode: Fix-and-hold
GLONASS AR Mode: Off
Elevation Mask Angle: 10 degrees
SNR Mask Angle: 30 degrees
Max Acceleration V and H: 1 m/s2
GNSS Select: GPS, GNSS, Galileo
Update Rate: 1 Hz
The workaround we found was to toggle off the Base Correction button on the Correction Input tab and click apply and then toggle back on and click apply. We started doing this just before starting to log at each new location.
If i understand your usage of the RS right, you should be using Kinematic (or atleast turn static on After you set the survey pole on tripod and is standing still) and possibly continuous too.
Your error sounds very much like what i demonstrated here
Yes, you are not static any more once you move the rover! The software assumes you are not moving at all when in static mode.
I agree with @TB_RTK that you should probably use Kinematic and Continuous.
You could also stay with static mode, but you need to break the initialization and then let it regain the fix. Your workaround may work, but it might be better to simply switch the rover to single mode before leaving a point, and then switch it back to static mode when you are on the next point. It slower to work this way, but there may be some benefit to it for crucial points.
Otherwise Kinematic is the way to go for speed of point collection.
TB_RTK, bide and wizprod, thanks for the responses.
But I think this is a bug that should be looked into.
On the many other commercial RTK Rovers weāve used, we always set the RTK solution engine to STATIC rather than KINEMTIC, if the config option exists when doing any sort of stop-and-go field work. It has always worked on the other unitās RTK engines without the need to reset the device or RTK engine. Maybe these other RTK engines can reset a Static solution after the ranging data has changed beyond a certain threshold.
Also, after a lot of RTKLib experimentation and suggestions from posts on this form the Reach RSās recommended surveying configuration is for Static with Fix-and-hold on GPS only. The other modes produced problematic data solutions for survey or mapping quality. Unless things have improved with the Reach RS in this regard, Iām not sure the system is usable in the Kinematic/Continuous configuration as mapping grade GNSS unit. I guess it is something I can design a test around as time allows.
To our understanding . . .
STATIC limits or rejects possible FIX solutions which fall outside a certain threshold established from a recent chunk of data. I have a suspicion that this might take into account the āMax Accel.ā settings but not sure. I thought this was guarding against possible data ājitterā in the position solution resulting from errant AR solutions as they may change from epoch to epoch. I think this is why we have seen difficulty in getting a Static/Instantaneous Fix unless the correction data is super consistent from epoch to epoch.
KINEMATIC mode is used to achieve/allow RTK Fix solutions to be produced and collected while the rover is in motion. So KINEMATIC would be used for tracing out the path of a moving object such as a UAV or car. It would allow position solutions to be qualified as FIX rather than FLOAT which move a certain amount from the previous solution. In this case, I think the Kinematic/Fix-and-hold combo can be a problem as AR solution may need to be recalculated frequently and on-the-fly especially if the movement causes Sats to come in and out of visibility.
RTKLib Manual From Section 3.2 . By setting the positioning mode to Kinematic and configuring the rover
and the base station receiver data inputs, RTKāGPS/GNSS is enabled with OTF (onātheāfly) integer
ambiguity resolution.
Instantaneous AR recalcs the AR solution every epoch without regard to the solution of any previous epoch.
Continuous AR recalcs the AR solution every epoch but limits the change in the AR solution by paying attention to some of the data used to calculate the AR solution from a few previous epochs. But sometimes the previous data is dumped if deltas between the current epoch and old epoch are outside a threshold. In this case the RTK Engine starts a fresh calculation of the AR Solution.
Fix-and-hold AR recalcs the AR solution every epoch like Continuous but uses even more data from precious epoch and can be very āstickyā within the thresholds.
I think the AR modes are really about when and how the engine calcs a new AR solution, not necessarily about locking onto a position solution no matter what.
So even if STATIC mode prevented a FIX solution which resulted in too much movement as compared to some subset of previous solutions, then in my situation the Reach RS should have dropped to Float rather than repeat on old FIX solution based on an old AR and old set of rover observations. I just donāt think it is reasonable to assume that STATIC mode means an indefinite repetition of a Fix solution no matter what changes.
To me this is definitely a bug. Maybe the Static engine is paying attention to too much old data for too long? Maybe the ādata windowā should be short so that a short time after setting up at a new location the old data should time out and allowing a new position FIX.
In Reach RS static mode is only intended for use case when your rover is actually stationary, walking to a new point while in static can produce weird results. It should not be staying in fix though, this sounds strange. Do you have a log file example?
Reach RS is definitely suitable for kinematic work, this is what 99% of our users do.
Igor thanks for the reply. Sorry no log files. I assume you would need the RTCM log and not just the NMEA file. Unfortunately we were only recording NMEA at the time, as we did not predict the need for the raw data.
By the way the Emlid product is very good. Iām hoping to be part of the community that makes it even better. Any criticism is intended to be productive.
In asset mapping stop-and-go data collection is very very common. Itās like a hybrid static and kinematic model. Itās kinematic in that the rover is moved from spot to spot, but it is static in that we donāt care about collecting data or resolving AR while moving. We only care about collecting data while at rest over an asset of interest.
One of the evaluations we made of the Emlid Reach RS was an accuracy and precision analysis. The accuracies and precision values were very similar to high-end multi band systems weāve also evaluated. Perhaps not a consistent or fast, but with a little extra patience it works.
We did these tests in Static/Fix-and-Hold data collection for 20 minutes. Although Continuous can look consistent over short periods of time, it can actually allow a lot of drift over longer periods. Thatās also the case with Kinematic, can drift over time. Iām afraid that if I were to re-execute my testing in Kinematic/Continuous the Reach RS would falsely appear to be less accurate than it actually is in comparison to competitors.
Right now the stop-and-go work flow in static mode can be supported by manually resetting the RTK engine. It should be possible to get the better data consistency of Static/Fix-and-hold operating mode and support a user friendly stop-and-go mapping technique.
I completely agree. I had exactly the same workflow today, though I was loitering for 15 min on each site, as the spots were on the limit of what a L1 receiver is good for.
Would be nice with a threshold, or at least a unlock functionality.
I am no expert on other commercial hardware, and can understand that they may have different algorithms integrated into their static mode or options that are a subset of it. BUT, if the docs of the open source RTKLIB, by T. Takasu donāt say there is a stop-and-go mode, and the Emlid docs donāt say it, then there isnāt such a mode and it isnāt a bug. In the same breath though, it could be the next great new feature!
I can just imagine a programmer finishing his masterpiece of coding on the static mode algorithm, and then the sales guy telling him that the users love the static mode, but now heās promised them they can move the rover while in static mode and still keep all the functionality of static mode. The images that come to mind are anything from a confused-glazed look, to the keyboard and papers flying and him stomping out of the room while uttering profanities.
Again, I do support this kind of feature, but as a separate mode from static. Please put it on the to-do list!
