We noticed that the Baseline distance show on the Status page did not provide correct distance. It was off about 7cm from actual distance measured with tape meter. However, when we collected the point and do the calculate in GIS software, the distance was accurate with tape meter. Please look into this issue as it was troubling to demo for potential clients. Thanks
moderator edit: This was originally cross-posted in the ReachView 2.14 and 2.15 update threads, but because the behaviour is not version-specific, I have moved it into its own thread.
I am curious to know if you were you using fix-and-hold or continuous mode?
And the 7cm difference was out of a total of how much base baseline?
The distance calculation, was it translated from LLH, or were you using XYZ? Was is pure horizontal translation or did it include the vertical component?
We used fix-and-hold and Baseline was shown on Status page of the Rover. I did not know how the ReachView calcuated this baseline distance but before it was correct comparing to tape meter. The distance we tested was less 10m.
I collected the point with ReachView, convert it to XY in computer and computer this from to Base to Rover again and it was correct comparing to tape meter.
Let is assume that instead of a calculation error, that it is the fix-and-hold algorithm’s propensity to acquire a fix that resulted in the error. Given some movement or possibly some more time, it may have adjusted to the correct position, but for critical measurements the continuous mode would be a more reliable choice.
I have felt that before as well, but in the interest of not leaving anyone behind and stuck with their ‘favorite’ version, I think it is for the best that we only move forward. You can always reflash to stable if you can’t afford to live with the behaviour of the current development version.
We had trouble when showing customers because they always asked us to compare to tape meter and Baseline distance was a way to show them. Otherwise, we need to collect the points, and do the calculation in computer which takes times.
We reflash and updated to v.2.11.0 but the Baseline distance still displayed incorrectly. However, if surveyed the points and compute distances in computer, the distances were all correct compared to tape meter. Could this be issued with Projection or formula used by ReachView to compute Baseline distance?
I would say that displayed baseline on the status screen is an anecdotal length for your information purposes only, and that it should not be compared with a tape measure. It is information for you to use to help understand how accurate your point could potentially be (5-10mm+/-1-2ppm) or how much further you can go and still maintain radio reception, or how to get back and find your base, etc. Not for doing precise calculations.
I don’t know if the displayed baseline is the trigonometric distance between the two XYZ coordinates, if it is just calculated from the XY components, or if it is calculated along the surface of the WGS84 ellipsoid, etc., etc.
Also, a length difference of 7cm in a right-angle triangle with one length of 10m and a hypotenuse of 10.07m, yeilds a height difference of 1.185m. Could it be that there was this kind of differential height in the 10m distance between your tape and the line that Reach calcluated on? Perhaps not that much, but it is something else to consider.
Correct. @l3technologycambodia was doing a live demo for customers and they wanted him to compare the on-screen baseline with a measured distance on the ground by tape. The two measurements had a discrepancy of 7cm, and we are trying to help determine why and how to avoid that discrepancy in future.
Yep, that is a fact…
But as I read it, the difference is not there when doing PP, only RTK.
Hence when question on if the PP was using Fix-and-hold or Continuous.
As the Reach platform is based on RTKlib, I am guessing they should reach somewhat the same conclusions. The only exception I can think is if the rover was moved marginally, after Fix-and-hold had already locked on a point. That won’t be the same in PP, I would suspect.
However, haven read @TB_RTK ‘s report a few weeks ago, I never use Fix-and-Hold for static points. It is just too “sticky”.
Actually, I somewhat missed the point earlier that the difference was not about PPK or RTK. It was about the baseline figure on the status page. So we could also potentially assume the PPK and RTK distances both may have been correct.
i.e. fix-and-hold may not have been the problem after all. It could really be a change in how baseline has been calculated on the status screen.
I believe that the reason why you are seeing this difference is that baseline is measured between antennas of two receivers and does not take into account the pole height. When you measure a point pole height is added. to the measurement.
