Correct, this is with a control system localized from control per the engineering plans which is shot in by a robotic total station and level-looped for elevations. Fairly typical construction process, at least in our company. Where my tolerance is and may be perceived differently is that anything more than 0.05’ deviation in the localization file is removed and my stakeouts can then be 0.05’, NEVER more than a tenth. If a control point checks in that bad then it was either mistakenly used or it has been disturbed. and is taken out of the localization after some checks. Usually 0.03-0.07’ is pretty typical for our primary control.
So 0.8-2.54 mm for us Europeans 
For the same 3 second obs time, what would you, with your experience of the system, expect of the reach ?
And for a 30 second obs time?
Good fix with the Reachview software 7cm and Magnet Software 5cm. RTK, no post-processing. The only place I really have trouble with the Reach, because of the single channel, is in our more hilly areas with medium vegetation.
so to standardise the test, would this flow be ok for a comparison:
- initiate base (average single fine, as the test is about relative accuracy)
- initate rover (note time when ready), kinematic RTK mode
- start new survey
- obtain fix (note time, note how long it took to fix AR > 3
- walk to first GCP
- place Rover rod and bipod on GCP
- level setup
- survey for 3 seconds
- stop and save collection
- survey for 40 seconds (Emlid recommended)
- stop and save collection
- survey for 3 mins
- stop and save collection
- place rover on next step and repeat the 3 individual measurements.
1 Like
Would it be best though to simulate a single collection, to move the rover then come pack to the GCP then do another collection? Isn’t the RTK running continuously so if you leveled the bipod (several seconds) made a 3 second collection, then after a few more seconds made a 40 second collection, wouldn’t the 40 second collection theoretically be more corrected than if you you made a 40 second collection as soon as you placed and leveled on the GCP since the rover would have been sitting on the GCP for longer if you are taking a succession of multiple collections at the same spot?
I was noticing with a good fix, that the RMSE numbers were the same (going to 3 decimal places) whether I collected 10 seconds or 1 minute. They didn’t go significantly up or down (I was working in pretty ideal conditions) so my thought was the 10 second collection (at least for my purpose not needing <3cm accuracy) was adequate and collecting any longer is following the law of diminishing returns on the accuracy over the extra time to survey multiple points.
Are you testing just the emlid or against another survey system? I think your outline looks pretty good. @jazee had a good point with walking away from it, but you’re test seems designed to prove that a longer collection time is more repeatable. That being said once you have collected your three points walk at least 10 meters away, sit for a second and then go back to the point and stake out each of the three points that you just collected. The longest point should be the most accurate, but if there is not a differentiation that exceeds your tolerance then you know on average what is safe to shoot. I would do this several times on different points.
I think for the accuracies that you are needing that with a good fix 60 seconds should be plenty.
@timmyd, have you shared the link to your video yet? Do you know the timestamp for the basic EZSurv run through?
If it is posted then I would encourage everyone to go look at the workflow for EZSurv. If your use-case is to make money then the bit that you spend on this program is a better choice than RTKLIB. Especially if you have more people than yourself that are going to be dealing with this data.
Hey Michael,
This is the link to the full “101” tutorial:
In the video there is an Index of the different sections and time stamps for each.
This is the basic video that I did which did not go into all the detail:
Let me know if this is not what you were looking for.
Tim
2 Likes
The post processing part starts at 41:45 in the full 101 tutorial video.
I know a lot of people here steer away from EZSurv as the price is almost the same as a Reach Unit and most of us buying these Reach units are doing so because it fits our budget RTKLib therefore is more popular due to the low cost (nothing). I think RTKLib is perfectly fine though for people that have a very good technical knowledge of how PPK works and the various workflows using RTKLib.
The fact EZSurv states “you can also access automatically 10,000 base stations.” That’s sounds really nice and convenient to me. But then again, there’s a reason they teach you Algebra/Calculus/Geometry/Physics in school instead of just handing you a scientific calculator and/or CAD program that does all the calcs for you. It’s good to have an understanding of what the software is doing for you. Still, surveying is just a side interest for me as it infrequently pertains to a drone job from time to time. I don’t expect to have time to become an expert but being able to easily and quickly do my own PPK when necessary would be nice, hence I may fork out the money for EZSurv if the learning curve is signficantly easier than RTKLib. I guess it really boils down to a matter of budget and patience/time.
Spinds like a good idea to walk away from the points for consistency.
So basically do 3 roundtrips, increasing the survey time each time.
It’ll take quite a bit longer, but if I am to do it, I’d rather just it properly the first time, removing as many potential errors the first time.
I don’t have any other RTK systems available, so it will just be 2xRS+.
If you can include a 10 second collection I’d be really interested to see results on that.
If you will be doing this workflow, can you, please, check also RTK vs PPK for the same points? I will try to make the same workflow as you tomorrow and we can compare our results.
Staying on the point emulates a longer capture time, but for true testing I think going off of the point is a good idea because it takes into account the recovery time of the receiver to catch up with you. I was under the assumption that this was just for testing purposes so you shouldn’t be concerned with your labor time. Otherwise I would just stick with a 60-second fix and occasionally back off and stake that point out to verify. For testing purposes though I think you can stay on the point for your shots, back off and then stake each point out to see if it progressively gets better. You want to choose your conditions as well because this could all be for not since GPS communications differ greatly from site to site unless you are in very similar conditions all the time. In my area I can go from flat farmland as far as you can see to 200ft elevation changes within an hour’s drive.
I agree that the cost of software can be a hard pill to swallow. If you are already comfortable with RTKLIB and are doing it yourself even better. 10000 anything is a marketing term to me.
I have trialed EZSurv after being reasonable proficient with RTKlib.
My background is technical from within the IT world, but also an avid semi-pro photographer and drone-operator. I’m used to reading documentation and technical documents.
Still, EZSurv is very confusing to me as a non-surveyor type. Most of that is about what they call things. In RTKlib things are called rover, base, etc. in EZSurv they are called different things, and you have to read the documentation more than once to figure out the workflow.
Simple things in RTKplot like seeing the resulting plot I couldn’t easily find in EZSurv, and sky view plots, number of sats used and so on. It looks and feels like something that haven’t been updated since the mid-90’s.
The only 2 real reasons for me to buy EZSurv would be for the auto download of CORS data (which could be done with RTKget potentially) and for the stop-and-go workflow, which sucks big time in RTKLib (very manual process), but with my current workload, I can’t defend spending the amount right now. Can only hope that Emlid produce something with RTKlib.
I made the experiments with the precision. You can read about them here, if you are interested: Reach RS+ experiments with local NTRIP caster
1 Like
I guess that would spare me a few km of walking!
Being in Denmark, our highest point being 172
meters ASL, it’s fairly flat in general, and hard to find Big variations in elevation.
Just to clarify, all of my data and opinions are based upon a traditional base and rover configuration.