I’ve just carried out a topo survey using 2 x RS2’s with the base pinned to exact coordinates. As a check for my orthometric heights I carried out a levelling exercise from a BM to certain key points. I have checked these levelling results.
Whilst my horizontal positions are accurate my GNSS derived heights after transformation are 3.349m LOWER than those from the levelling exercise. This is a constant offset across all points. It does not equal either antenna height (entered into Reachview) or any obvious interaction of them. My transform is WGS84 to UK OSGB using OSTN15/OSGM15.
Is there anything obvious that I might have missed that would cause this?
Just to make sure, was your levelling done from ellipsoid height or geoid (MSL) height? If you know the geoid undulation for your general area, this is usually easy to spot as it will match the constant difference you’re getting.
What firmware are you running ?
V2.20.8 on the units, Reachview 1.6
Did you enter the antenna in Base Mode on the base as well?
Do you have the raw-logs, so they could post-processed and thus checked?
Please note that ReachView uses the ellipsoidal height. So, just as Gabriel has pointed out, the constant offset in the heights might be due to the difference between the ellipsoid and geoid height.
We completed some surveying today using LoRa and RS2’s.
We noticed that when staking out a few known permanent marks, our z values were lower than expected, and always within a few mm of our base height (ranging from 3.11 to 3.14m lower than expected. Our base height above the known mark we set up on was 3.123. We swapped out rovers, and tested again - same result.
We even went back to our base and deleted the pole height in Reachview, applied that change, then reentered the base height above mark, applied that change and went and checked again - same thing.
We then set up a rover on a tripod, coordinated it using average fix, turned off corrections input and activated Base Mode (LoRa corrections output - on a different frequency with 0.0m base pole height). Went back to the base, flipped it to a rover on the new frequency and voila - replicated the problem again…
Bases both using RV 2.21.2, Rovers using 2.21.1 and 2.21.2.
@tatiana.andreeva @andrew.yushkevich are you aware of any known issues that may trigger this behaviour?
@FJDT You said that “It does not equal either antenna height (entered into Reachview)” but what was your base height above your known mark, when you experienced your problem?
@FJDT And here I find the answer, confirmed. ReachView v2.21.2 Where it states that when using RS2’s in RTK mode, for both Reachview dev versions 2.21.1 and 2.21.2 there is indeed an issue where the base height above mark is being ignored.
There is no user feedback there to determine if this issue also impacts RS+ or RS.
I’m confident Emlid will address this in a future update.
Height error in Reachview.
Tested RS, RS+ and RS2 and it seems to only affect the RS2.
All running 2.21.2.
It must be an error in the rover end of RS2 as the RS and RS+ worked fine in rover mode with RS2 as base.
For personal reasons I’ve been away from this forum for a while. Let me get up to speed with everyone’s replies.
We’ve just pushed the new stable v2.22.0 firmware release that should resolve the issue with manual base position applying.
It’d be nice to get your feedback on it. Thanks!
I’ve updated 2 x RS2’s to 2.22 and I can confirm that this has resolved the issue with the pole height for the manual base position not being applied.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.