Hi everyone,
its always difficult to do precise measurements in the forrest - we all know that. But it would be good to know, how big the error can be!
When you are in the Forrest and you can’t get a FIXED signal, you need to measure with a FLOAT or even a SINGLE Status - is the RMS delta which is given in Emlid Flow App reliable?
In my tests with a very poor indoor FLOAT or SIGNAL Status, the RMS given in the App was much to good, by comparing the measured point just with the sattelite picture…
How are you dealing with measurements in the Forrest?
Depending on your tolerance level… you may need to look into receivers that also have L5, not just L1 and L2 bands only. Apparently much better in forest conditions.
I.e. Hemisphere, AlphaGeo, etc.
Or even a total station?
Few to several meters off in all directions SINGLE and FLOAT.
What’s your use purpose ? I wouldn’t depend on an accurate indicated “fix” solution in any kind of high multipath areas such as wooded forest or in/around buildings without some kind of verification.
I’ve used the RS2 in wooded areas for static observations locating boundary corners. I place both of my M2’s onsite (usually about 500m apart) as a static baseline and use the RS2 as a static rover. On my last project all the observation baselines were about 1 km, I then used a commercial PP software to determine the rover’s position. Usually the rover occupation times are 30 min at a minimum, sometimes longer if needed. Most times after PP, the rover closed loops accuracies are pretty good, usually around +/- 3-5 cm.
RTK in the woods is a hit and miss unless your logging data as above and have an onsite base. PP against a CORS usually won’t work as baselines are too long. If I had an onsite base using radio/RTN, I would revisit the points at least twice to verify your positions. Even then you really can’t have confidence in the rover positions unless you have a terrestrial traverse with closed loops or as above with GNSS closed loops.
If you are just locating low order accuracy (like large trees for inventory), then I would get several measurements per point (3 minimum) with at least 10 min occupations logging data with an onsite base. You can then PP using a single baseline processor like Emlid Studio to average the positions of each point. At a minimum, 80% of all the ambiguities should be solved for.
RTK in the woods is a big gamble without some kind of way to verify the resultant “fix” solution. Also short baselines and adequate time on station is imperative.
You could buy a Javad Triumph LS+ like we have (2) and you would be confident in your solutions. We usually also have a base onsite for radio RTK and RTN as backup. You can switch back and forth at the rover also. You can even use real time RTPK (real time PP) at the rover to verify the RTK solution. Cost for these receivers are high ($45k) for base and rover, BUT it’s well worth it to our firm as it saves us time and money.
I think L5 recievers are very expensive and even not produced by Emlid
It is totaly Ok if my RS2+ is not accurate in the forrest!
But the Emlid Flow App should honestly tell me that there is - lets say for example - a 15 Meters range in the measured point, and not for example as the RMS says a Range of 0,48m or sth. like this… if i honestly know that there are severel meters of range, it already helps me, because than i can honestly say, that i can’t measure an accurate Point at this place…
There is a way for Emlid or any other receiver to verify the TRUE accuracy of any point, as I stated in my post of above.
Any position obtained either by standalone, single, float, RTK/RTN “fix” or by post process is just a statistical average of a series of individual epochs of observation
You’ll have different degrees of accuracy for each method. If you’re trying to define a TRUE position by standalone, single or float methods you’ll have to realize that each has their own expected accuracy in CLEAR OPEN sky conditions. In high multi path areas such as forests, you can expect these accuracies to be degraded significantly.
The only true method to have an indicated TRUE “fix” is to perform either post processing by closed loops or buying Javad receivers.
Since the ambiguities are not fully solved in Float or Single, the coordinates shown in these solutions can be really unstable. We recommend performing RTK when Reach calculates a Fix solution.
In Emlid Flow, we show a real-time estimation of the solution quality. To determine the “true” measurement accuracy, you can find known benchmarks and compare the coordinates reported by Reach with the Fix solution.
During your survey, you can also pay attention to the PDOP and Age of differential values.
To some degree, the problem is that without other checks and workflows mentioned by @EBE111057 and the others, it is sort of a Catch 22 situation. Since the receiver does not know where it actually is with any certainty, it cannot tell you “how far off” the measurement is to the coordinate it thinks it is occupying. You see?
For example, if I put a blindfold on you and then drive around for awhile and then ask you “where are you, and with what certainty do you think you are there?” Your response would be somewhat of a guess, right? It is the same for the receiver when it is not receiving the required data for it to “take the blindfold off.” Kind of a strange explanation, but I hope it helps.
When the receiver has a good idea of where it is, then it can also tell you more accurately how far off it might be.
