when you test, you sure don’t do it halfway. You way exceeded my tests. One hour opus captures? The control point must be in your backyard; who would leave their emid set up, unattended, for so long. Impressive testing.
I’d very much like to know the elevation of your control point, so that I can see how close each of your results are to the control elevation. You list the results, but I don’t understand what those figures mean.
I think I understand what your figures mean now. Those figures show precision, not accuracy. IE they show consistency of the same measurements. My agency tasked me to measure accuracy- how close the emlid elevations are to a known, real world, elevation, the test control figure. I captured over a high order dept of transportation survey monument, with a published, real world, elevation. Your figures are the elevations compared to each other; highly precise, but, not necessarily, accurate to the real world. Your method is using an “assumed” elevation, which is a very viable method, but not what we need to know, since we want to measure real world elevations in our work. UAVs don;t work with assumed elevations; they attempt to capture real world elevations, based on their gps elevation taken at the home point. Do you have an actual elevation for your test point?
1 Like
Obtaining real world coordinates and an elevation for a point. We’ve determined the best balance of time and accuracy is doing 3-20 min captures, processing thru OPUS, and averaging the 3 opus solution elevations. Many believe that an opus capture should be many hours in length. I’ve earned access to the higher opus projects processing level, and so I’ve been able to try several opus processing methods and evaluate the results. FYI: optaining my level of opus projects access requires completing a 3-day online course, hosted by the opus staff. Unfortunately, we’ve found that, occasionally, opus won’t process a submitted rinex; I don’t know the reason. With that in mind, we feel it’s better to obtain multiple emlid captures for opus rather than one long capture. Don’t carry all your eggs in one basket approach. Imagine how you’d feel if you baby sat your emlid over a point for many hours and opus didn’t process the rinex file? I should mention, that in each case where opus wouldn’t return a solution, we were able to process the rinex thru the Canadian CSRS PPK website. I recommend that you submit your one hour rinex captures to opus and process for an average elevation. Then compare your non rinex captures to the opus elevation, as a control for your study.
Yeah lol it’s in my backyard on a survey pole jammed into the ground with no real control point under it.
Thanks for telling me that. I respect you went to a lot of effort; having, myself, done many such gps tests, over decades, I respect your effort. If you still have the rinex files, produced when you set off the emlid raw data logging, I strongly urge you to process each thru opus and calc a single average elevation for your yard point. That point could then be used, into the future, as a test control for other tests. The great thing about that point, is that you can leave the emlid there, unattended, without concern. I’ve been obliged to do such tests where I had to baby sit the gps reciever in a more public loc for many hours. I have such a control point, in my back yard, over which I’ve done many years of gps tests. Please tell me the average elevation you determine for your yard point. I want [I could really benefit from] to use your test results for a study I’m doing. The study goal is to calc a simple statistical adjustment factor [such as .95, a multiplier] to reduce the average error of reach app average single method captures, from the present result of 1.7’ down, hopefully, to a sub foot result. I expect many to scoff at what I’m attempting to do. The emlid ave single method is necessary to determine the real-world elevation of points, in remote areas, without the need for a second field trip there, after doing an opus capture [there is up to a 24-hr delay in opus processing]. Our staff wants to be able to establish points, to use as emlid bases from which to put out an RTK correction, to an autel evo, in a single field trip.
Yeah those result show precision and not so much accuracy.
You mention trying to find accuracy on a known control point. I have not done that much with my M+ receiver, but I did do a 5hr OPUS solution on an Army Corp of Engineers control disk last month. My setup isn’t exactly like your, as I am running a Sparkfun Top106 GNSS antenna connected to an Emlid M+. The ACOE control points does have a +5hr obersvation by a third party, two +5hr observations with a Leica GS16 done by me, and one 5hr session with my Emlid rig if you’re interested in that data.
I may have the RINEX File for my one hour observations, but the logging was the 17hr OPUS. I did one long recording of raw data and did 1hour logs in the survey app of ReachView3. I could split the 17hour rinex file into 1 hour sessions. I did learn a few thing - I do not lose data, if my battery dies on my M+ receiver while logging data, but if my phone’s screen times out while logging a survey point in the survey app, then it will lose the data.
Congrats on the OPUS class. I have been looking into it , but I always seems too busy. I just need to dedicate some time and actually do it. Did you feel like the additional OPUS features unlocked were worth the time it took to take the class?
I agree with your need to use Average Single to get up and running a mission with RTK, but I highly doubt you are going to find a formula or method to get your errors down by just using a Single Average Solution. Personally, I would use the Average Single to get my RTK up and running and run my mission and also log gps data such as RINEX or UBX. Then send the Rinex/UBX to OPUS to get a better solution on the base. Then process all my data with this corrected solution either by shifting the data xyz from average single base coordinates to the new OPUS coordinates or by using PPK. If I ever need to go back, then I set my base up over my control point again, but this time I manually input the OPUS values instead of doing another average single solution.
2 Likes
I didn’t feel the opus projects course was worth my time. Two other gov employees started it with me and they barely made it thru the first session. The opus staff goes way, way, “into the weeds” with the intent to make students into researchers. Most of us, in the real world, just want to use opus for results. I spent many hours, after the course, exchanging emails and phone calls with some of the opus staff, trying to, really pestering them, get them to answer questions of very basic opus details, like how to interpret or optimize the opus projects controls, that they didn’t cover in the course. A big investment by me for a small gain in accuracy: Not worth it. I rarely use my opus projects log in to get additional accuracy. At least I improved my geodetics knowledge. Adjusting rover point elevations, after the fact, post field trip, your suggestion, is a really viable method. Of course, our staff has used that method, in the past. We’re hoping to gain some elevation accuracy for the base point, since adjusting EVO UAV data is not possible, after the fact. Small sized, remote, areas should be mapped with two emlids, base - rover, which is what you understand, which rover pts can be adjusted later, but large, remote, areas are only time-feasible to map with a UAV, which does not allow post adjustment. If you could just report to me the elevation of your back yard point, that would be helpful in determining an adjustment factor, which, statically, only works if you have many test results, spread over a large area and the data is not too variable. The good news is we’ve noted that emlid ave single results are in error a consistent amount, both vertically and horizontaly [always to the north west]. Which vertical datum did you use? What’s the average elevation?
Thanks for the insight on the OPUS classes. I’ll probably eventually break down and do them.
I have posted everything I have so far regarding the elevation of the point in my backyard. I did, however, just edited my original post of elevation observations and added 2 more OPUS solutions I had observed on that point, a 6hr and a 20hr solution.
Its all in what you would like to hold. If you hold OPUS the elevation would be 10.749’ average. If you like the SmartNet Network and the ability to use more than just GPS satellites, then the elevation would be +/- 10.84’.
The post shows the precision for long OPUS Solutions, Long RTK observations, short RTK Observations, and short Single Average observations.
1 Like
Reading back through your post, I wouldn’t say I am using an ‘assumed’ elevation. The OPUS is corrected by the CORS station through a post processing, while the SmartNet Ntrip is real-time RTK subscription based commercial GNSS network supplying corrections via the internet.
The only ones slightly ‘assumed’ would be the uncorrected Average Single, as they have no ground based corrections. Just pure GPS signal being used to compute a 3D position.
2 Likes
verifying the precision of emlid doesn’t offer a practical solution for those of us trying to map the real world. Your data is useless, as is, without a control figure; which is basic to all testing procedure. You’re just trying to see the precision of the shotgun scatter, not how far off it’s off from the bullseye. Seems like you’ll fit right in with the opus staff- they’re only interested in endless research also.
For the past 27 years I have been surveying using conventional methods, gps, and hydrography to ‘map the real world’. I also completely understand precision and accuracy, as well as the need for both. I am completely versed in using and converting between vertical datums, especially since living and working in a coastal town where we have more datums than the normal NGVD or NAVD88. We have MSL, MLW,MLLW, MHW, & MHHW to name a few.
As far as my testing is concerned, actually checking into a control point is somewhat arbitrary, because the output of OPUS and the setup I have currently on SmartNet are producing elevations relative to NAVD88 by using the Geoid18 to get to NAVD88 from the RTK calculated ellipsoidal heights derived from a network of base stations. Knowing my measurements are precise is extremely important, as I can easily tie into a known benchmark and then do a straight vertical transformation to get to whatever the project datum happens to be.
You also missed the point of my testing. It was not to prove the precision of Emlid products, even though it was nice to see the precision of my $650 system. My goal was to show the precision gained when using a correction, whether it comes from a post processing service such as OPUS or a real-time RTK correction utilizing the SmartNet NTRIP, instead of only using an average Single solution. Even my 2 minute Fixed Solution data set produces a statistical confidence level of being within 0.10ft 95% of the time, while my Single Average data set has a 95% confidence level of being within 10 feet vertically. I do not know what your mapping is for, so this 10 foot could well be in your acceptable tolerance level, and if so that’s great.
I would much rather have a precise set of measurements with a constant error when I check into a known control point, so that I know with some relative confidence of what correction I need to apply to get to the working datum, than to do what you are planning on doing, which is to use a set of unprecise measurements and try to come up with an accurate solution.
All I meant to do was to help, but unless I have misconstrued your tone it appears something meant amiss
In the words of the great Willy Wonka, “Good DAY, Sir!”
4 Likes
Hi there,
I see the initial topic was already solved, but I want to post a short summary for anyone who asks the same question.
If you work in RTK, you need to work with the Base mode settings. If you do the Averaging method, everything is simple, you just average the position and go.
If you already have coordinates and use the Manual entry method, then you need to enter the tripod or survey pole height. If you’re using an extension pole, you also need to add 15cm to the tripod height. Still, the APC offset is taken into account automatically.
For PPK, always enter the tripod or survey pole height in the Logging tab. Also, no need to bother about the APC offset, it’s added automatically.
Still, some services, like OPUS, can’t read the antenna height and name from the RINEX header. So, when submitting files there, you need to enter it additionally. We described it here.
Also, we’ve recently written two posts about how to correct work with the antenna height:
You need to add this to the pole’s height.
2 Likes
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.