Displayed distance in stakeout is about 15% less than actual

When carrying out any survey I always stake out between known benchmarks to check in the field that projection and scaling are correct. I am new to the Emlid Flow and I am puzzled why the stakeout by direction displays about 15% less than the actual. When I record these positions, and reduce them in the office software the coordinate distances are within survey accuracy. So it is just the displayed distance thats not right. Note that the stakeout is within Survey accuracy when at the mark.

I have the latest RS2 firmware and Emlid Flow software.

I have tested this with 2 different projections and the error is basically the same (allowing for the differences between the two projections). NZTM2000 and NZGD2000/Mt Eden Circuit.

Does anyone have any thoughts?

Thank you.

Could this be it?

Thanks for the reply. The difference between grid and ground is a good thought, but around here it is very small. I can now give a better example now where the difference was far greater than 15%. I set out a 1/4 mile for the local car club this weekend. They provided the start position and I walked down the road using a wheel measurer. I measured the start with the RS2 first and used the stakeout feature. At 402.3m (1/4 mile), the stake out distance to the start line displayed as 230m. Back in the office, I reduced the data and the distance between the observed coordinates was correct as per the measuring wheel. The stake out distance seems to be only a reducing numerical guide rather that an actual measurement. That seems peculiar to me. I have done this same set up in previous years using Sokkia and Leica GNSS units where the stake out displayed distance is the actual distance.

Hi Tony,

Thanks for sharing all the details! So the data is accurate, but the live stakeout display didn’t reflect the actual distance walked.

To help me look into this, could you please do the following test:

  1. Start a screencast video.

  2. Collect the first point in Emlid Flow.

  3. Stake out the intended distance from this point.

  4. Save this point.

  5. Share the full CSV export along with the video via [email protected] or PM.

This will give a clear view of what the device was showing in real time and help me see why the display behaves this way.

Just a thought,

The ‘wheeled’ distance will not be horizontal distance.

boston

Well, if the coordinates in another software lines up and correct then blunder is out the window.
Fwiw just tested 2 and 3D distance and it lined up as expected. The Distance was only 9m but an error of such art should be visible.
So its likely to think its tied to the specific datum (both of them) and how the distance is calculated.
I assume the latest firmware is installed?

Out of curiosity, why mix metric and imperial?

One more silly question :grimacing: . Did you select the point from the list or the map?

Hi Inkar,

I now realize that this Forum discussion title is misleading as the error varies, and is not constant.

Please find video and csv attached. I have reduced this in my survey and engineering software Liscad SEE and the measured Horizontal distance is 49.96m and the measured Slope distance is 49.98m. This is great and I am within survey expectations for the GNSS receiver. Please note I am using NTRIP castor on a 50km base line. Local performance is good if results are obtained before the satellite constellations have moved significantly. I.E. short time periods. However I can get up to 0.15m “error” in coordinates if there is bad atmospheric conditions over long periods of surveying. Generally 0.05m is the normal result.

I have sent the files through to Support.

I have done both select from list and select from map.

Tradition has cars racing over the Quarter Mile.

And absolutely remains a 1/4 mile and nothing else in its place of birth, and for consistency continues to be known and raced as a 1/4 mile in our metric regions. Some loosely refer to “400m” times but anything recorded over that would be cheating by that 2.3m. Good to see even Kiwis don’t do that. Been down the strip a few times myself.

Sorry for the dumb question as I haven’t been over for a while, but could there be remnant banana impacting in this or have you guys really gotten over it? Used to do my head in.

Just saw this, for starters that’s starting to get a bit longish to be splitting hairs. At 1ppm already 5cm off the bat and will compound any other issues.

If you are averaging a point over some time it can improve the position but if the stakeout distance is provided from instantaneous solutions you could be seeing a lot more variability over that length baseline.

And what’s the NTRIP source, can your trust it and are base coordinates validated?

If you can shorten the baseline…a lot…and retest would be good.

Hi Tony,

Thanks a lot for all the details and files! I checked out your screencast and saw you were staking out by Direction. We’ve just found a bug with this stakeout mode. On Android, Emlid Flow currently mirrors the Easting and Northing values that are shown in Distance mode.

Our team is already working on a fix to make sure the stakeout display is accurate, and I’ll let you know as soon as it’s rolled out.

Hi Inkar,

Thank you for your help. I look forward to the fix.

Thank you also to all the Forum members who reached out with great suggestions and efforts to help.

Hi Tony,

We’ve released a fix in version 14.2 of the Android app. When you get a chance, please update to the latest version and let me know if the stakeout works smoothly now.

Tested version 14.2. All good

Id check against two known NGS passive stations. Inversing between them will give grid distance but the data sheets also give the combined factor and also point factor for each station. Then you can learn how to compute ground / ellipsoidal distances !

Ja, that is actually a good idea. That would also verify the X,Y and Z too