I have a 6.5 hour OPUS-S solution on a base point, and some ~15 minute sessions on rover points taken during the base session. All are within 300 yards of each other.
I processed the rover points with OPUS-RS, and also with Topcon Tools holding the OPUS base solution as fixed control.
The data was recorded with 5-second epoch rate, which OPUS decimates to 30 seconds but TT does not.
I see differences between TT and OPUS-RS of a tenth foot or more.?ÿ Would you use one solution, or the other, or an average?
My approach would be to hold the OPUS-S base position and the TT vectors.?ÿ That will certainly give you the best local relative reproducibility.?ÿ ?ÿ
You are seeing they variability of elevation calculations, and it??s not just that some were 15 minute static. 8 years ago, knowing much less about GNSS, I observed 2 hour static on 3 points spaced 1000 feet apart. Sent to OPUS static. ?ÿRunning a level through them, between 2 points differed by 0.15?? compared to OPUS.
I recommend using one static base point and have everything be relative to that. If you have 4 constellation RTK, your RTK observations can often have total station quality observed elevations.?ÿ
Which one is correct? That's the solution to use.
I would typically expect the PP vector solutions to be much more accurate with respect to the OPUS-S base.?ÿ
@mightymoe ???? correct? Again, it??s elevation calculation variability of GNSS from long baselines , and very short 15 minute static recording. They could all be ??correct? based on how much was recorded, just different sessions are of different quality.
They are only 900 feet apart, figuring out which is correct should be fairly simple to accomplish.
GPS surveyors seem to tend to want to look at statistics and run analysis. By the time all that's done setting up the robot or TS and running a few checks could answer the question. 15 minutes on a point is forever unless the CORS station is a 100 miles away or something.
A tenth shouldn't show up. Heck, I recently ran the same process and everything was within a couple of hundredths and those were 2 minute and 15 second files and the CORS point tied to was over 30 miles distance.?ÿ
Also, is this a tenth vertically, a tenth horizontally, a tenth globally, a tenth between point locations?
If Topcon calculates NAD83 the way Trimble does it you will pick up some differences between OPUS and Topcon for the NAD83 number. So that could have something to do with it.?ÿ
First: Break your 6.5 hour OPUS into 4 or more segments of less than 2 hours and submit to OPUS-RS. Take note of which CORS are used, should be up to 9. An OPUS-RS elevation is meaned from these 9. It is reasonable to have only 7 common CORS on 4 typical solutions, because no set of CORS data is perfect. Your OPUS elevation is only meaned from 3 CORS and possibly from CORS not used in the OPUS-RS solution. if so, resubmit your OPUS 3 times using 3 of the 9 each time. Having done that you can begin to compare apples to apples.
Having done that I may mean my OPUS-RS solutions for my project elevation or judging the tolerances, just stay with the OPUS elevation. I have no qualms in using only 3 out of 4 OPUS-RS elevations, especially if the OPUS elevation is not an outlier to that range of values.
It has been a long time since I have been finickly enough worried about OPUS-RS to request extended CORS data and weed out the loose values.
Paul in PA
It seems to me to not even present a choice.?ÿ
The long obs opus control, and radials from control.?ÿ
