And that’s what we like! ; )
1 Like
Reviving a bit of an old thread here that was never resolved.
I am all for Emlid, however the discussion regarding false fixes never really seems to be adequately addressed.
Increased assurance that a fix is genuine is imperative for Land Surveying.
Obviously there are a range of options that can be implemented, from simple to complex.
Some will provide a little assurance, others will provide a level of assurance that is comparable with other top receivers in the market.
Can you share with us some of the details about how the RS2 determines a fix eg.
- number of iterations performed
- quality determinant eg. fixed result is 3 standard deviations better than the next best result
- if the software assesses for linear trends in the coordinates of a point
I have asked these before and it was not answered.
Previous suggestions include:
- setting an average SNR tolerance
- minimum sats tolerance
- minmum PDOP tolerance
- blocking the ability to save a point if age of corrections are slow (this has been reported to be an issue with NTRIP in previous posts)
- “dist to last” function or indicator showing the distance (ideally broken down into XY and Ht) and azimuth to the last point
- a minimum length of time that corrections have been received without interruption?
- the use of a second algorithm (eg. rtklib?) to determine a fix and if both algorithms are fixed, calling it a, ‘double fix’ etc
See:
hemispheregnss_surefix_overviewpaper_20181119.pdf
Other suggestions? @EBE111057 @michaelL @TB_RTK @PotatoFarmer @wizprod
2 Likes
Just getting into finding specific points with accuracy, so I am super interested in this subject but not as knowledgeable.
I agree this would be super handy. Also if their was a magic way to plot two points and RV3 would make a straight chainage line between them at a chosen intervals. Or plot one point then enter a distance and a compass heading. For fancy planning I see the need for PC software, but just making a straight line seems basic enough. Just like doing an AB line on guidance. Sorry for getting off topic.
Currently I can only trust that fix means fix.
1 Like
Agreed.
Some fairly basic features will actually serve many of us very well for a large portion of what we do.
I’m trying to brainstorm a range of options that will directly relate to assurance of a fix and hopefully Emlid will job on board for some of them
1 Like
I think as my suggestion above is to have at least a 60 minutes selectable option of logging for the user instead of the current limitation of 6 minutes. Also some kind of “RTK reset”. Many times any receiver will get an instantaneous “fix”, but how well are the ambiguities determined for this type of fix ? Are they also included in the final fix ? Obviously, this kind of “fix” may well be several centimeters as outliers compared to “fix’s” of a 3 minute observation.
It would seem to me to also have a “standard deviation” fix. Measure 10 epochs, compute the standard deviation of the 10 epochs, reset RTK engine, measure 10 more epochs , compute the standard deviation of the 10 epochs, determine deviation of 1st set and 2nd set and store value. Reset RTK and perform verification of the mean deviation. If solution is within user accuracy settings, move on to next point. If not, continue with method above untill accuracy is obtained. This is a simplistic version of one level of Javad methodology for verification of a “fixed” point.
The existing error deltas shown also work well, but again a PDOP value next to the solution status would also help. “Click” the PDOP values and the solution page pops up.
2 Likes
To be honest, as i understand it, to rule most error into your favour and not rely to much on fancy algorithm. Is to reset between each session of iteration.
Eg. PPP. 3 sets of 4-5 hour log instead of one long 24 hour (24 hour is ok, but that is one large chunk of data to process).
And for PPK or static. 2-3 session spread over an hour for a min of 3-5 minutes log.
That is pretty much how the holy guide of accurate surveying is done around here.
Ordinary survey is 5-x amount of iteration in any conditions. 
4 Likes
What’s an epoch in layman’s terms? : / Sorry, my walnut sized brain is overloaded and smoking after reading that.
1 measurement or 1 instance of measurement, i.e 10hz = 10 epochs = 10 measurements/sec.
The issue at hand is a way of verifying a RTK “fixed” solution.
Time on station is important, as you are computing range measurements to the sats during a period of measurement. An on the fly, continuous, statistical analysis of a set of measurements (1 minute) would certainly give an overall accuracy of the solution, while continuing measurement and analysis of the next minute and so on until a six minutes observation is complete. 6 observations, 6 solutions to mean and determine overall accuracy for the 6 minutes “fix” or whatever length of time. The user has a confidence level of that set of measurements.
Again, this is a simplistic view of the Javad methodology of determining the accuracy of a measured point.
I believe there is no statistical analysis on the Emlid side of the point accuracy. The simple deltas shown appear to be a deviation from the first “fix” solution.
4 Likes
We have the practice we call backoff that once a point is collected for control that we pace off about 100ft then stake back to the point.
2 Likes
To keep this post about verifying RTK fixes, I started a new post which is related, but refers to times when you have the time/need to spend a longer time on a point, rather than just means of verifying an RTK fix is correct eg. for a quick shot in a challenging environment.
1 Like
We do the same.
Its also great using CAD drawing as an underlying map (E.g with survey master app). Then you have the written distances to the next point which is comparable with the distance to next point of stake out.
4 Likes
Hi guys,
We’ve got your point and will discuss all your requests with the team. Thanks for emphasizing this.
Still, if you ever have issues with Reach accuracy, please reach out to us. We want to examine each such case to prevent them in the future.
2 Likes
Hi Svetlana,
I appreciate Emlid’s support and was wondering if we could get an answer to the below questions:
3 Likes
Hi James,
I can hardly share such details. RTK is a complicated algorithm, which can hardly be unequivocally described in one post. It’s hard to give a simple explanation of how it works that will cover all possible cases.
We always try to be as transparent as possible regarding the processes and issues we have. However, it’s indeed not that easy.
As I said above, we took into account all your suggestions and concerns. We also have our own thoughts. A soon as we’re ready to share some results, we’ll go public.
4 Likes
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.