- 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.
1 Like
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.
There should be a way to downgrade to specific version of ReachView.
1 Like
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.
1 Like
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?
Did you use fix and hold or Continuous in your post processing?
1 Like
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.
1 Like
Already answered here:
Also, might I suggest this interesting report from @TB_RTK regarding fix-and-hold:
Fix-and-hold: As far as I can tell, that sentence was for RTK, and not for later PP?
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.
If you could give us a tool to compute correct distance of two points from Survey project, it will be very useful.
1 Like
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.
2 Likes
So this could all be much ado about nothing. Nevertheless:
I am not at my most alert right now, but here is a simple calculator function which I think will work in XYZ mode:
If X=1, Y=2, Z=1.5, then:
3D baseline = sqrt(X^2+Y^2+Z^2)
3D baseline = sqrt(1^2+2^2+1.5^2)
3D baseline = 2.693m
Of course, add any unaccounted-for antenna height into Z
2 Likes
Well, if that is the case, the workaround for us is to put the pole to about same eight of the Base.
1 Like
Yep! One trick that I have for quick demo is to bring rover so close to the base that two RS’s touch with their sides. This should show the width of the RS as baseline in the app!
4 Likes
You were right. I tested and it worked. By setting the Rover pole to about same height of Base, we could compare with tape meter accurately. Thank you so much for this. It is very useful for us.
3 Likes