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.
2 posts were merged into an existing topic: ReachView v2.14.0
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?
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.
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.
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.
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
Well, if that is the case, the workaround for us is to put the pole to about same eight of the Base.
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!
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.
So, with that comment, let us dispel with a myth that I remember contributing to in the past:
It said the rover should not be close to the base. Can we say that is false in all cases, or should we say to start the rover at minimum X distance from the base and after initialisation then it can be brought directly beside?
There is this cool oldtimer on yt showing something similar for a different purpose with an L1 i think.
Its called ‘Bar’ initialization and Stop and Go data collection. He is showing base/rover in a close setup.
Just about here https://youtu.be/rzYqBaUIqWU?t=4m10s
This is a classic case of looking too deeply for the problem in the processing and black box, rather than basic survey method. Glad itt is solved.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.