Does anybody have advise to a way to weed through inconsistent shots? Our field crew goes out on Monday, shoots elevations on control stations set 10 years ago, (that have been checked-out to have good NAVD88 elevations. They take 50 shots on each station using RTK, come in with the info and one might be within a few hundredths, the other may be 0.10' high, the last one might be 0.26' high. A week later, go back to the same control stations, again, take 50 shots on each one and be a tenth on the first, 0.08' on the second, 0.28' on the last. Are we doomed to these errors or are we heading about it wrong? Any suggestion will be welcome!
You need to be a member of Land Surveyors United - Surveying Education Community to add thoughts!
Replies
Thank you for the reply, we have a Carlson program and are currently trying to figure out how to use the static collection mode in it. I used the old system we have for static collection and it does seem more accurate than the RTK collection. The answers are here in this thread, and I will take a look at them, one by one until we can be more confident.
The Carlson program you refer to, is it Carlson SurvCE?
If so, set one receiver to collect static data internally to a memory card as a Static Base. Set the Rover as for RTK but don't connect to the base with UHF..fudge the RTK connection....As long as you have a Bluetooth connection to the Rover you should go to Survey then select Store RAW Data, Create a file, if it won't create a file it indicated your receiver is not allowing RAW data output, if it does just follow the prompts and store 10-15 minutes RAW data at each site (Stop'N'Go).
Carlson SurveyGNSS software is the best to post process if you don't have an alternative one...but beware and make sure your receiver and SurvCE software are on the list of tried and proven products...otherwise you may not get a PP solution.
Hope this helps!
Thank you, I will look it over and try that out. I will post any progress.
Did you create a Geod for the project?
Which did you localize on? Or did you use the base point?
RTK is usually centimeter accuracy (horizontal)
vertical is usually considered 3 X horizontal error
I would cook static for 30 min and send to OPUS
Thank you for the reply, we have a Carlson program and are currently trying to figure out how to use the static collection mode in it. I used the old system we have for static collection and it does seem more accurate than the RTK collection. The answers are here in this thread, and I will take a look at them, one by one until we can be more confident.
From my days developing a new CORS software solution..I would like to point out a common misconception; VRS is the answer, if you are using VRS, check the distance to the virtual reference point each time you make these checks (this is why the MAC method used in Spider CORS software is superior for this application); the distance to the closest CORS base is consistent (but is limited in other applications; when you are a long distance from the nearest base), VRS shines for speed of acquisition!...if there is a variable in the distance that the RTK software produces as the Virtual Reference Station (VRS) point, you cannot expect consistency...as has been said in other replies the length of the vectors will vary considerably, changing the result of the computation? Try using a MAC option instead of VRS (most CORS networks provide a list of options to select) allowing you to choose the one best suited to your application and see if it improves consistency.
Dear Mr. CcCarthy,
The published misfit of the Geoid12B model is 1.71 cm StDev (1sigma) nationwide. (It may be worse locally.)
1.71 cm = 0.06ft.
You don't indicate if your RTK is local or an RTN. I would expect a good RTM to be more consistent than a local base RTK.
GNSS solutions are sensitive to the time on point and the immediate environment at the time. The environment includes obstructions, reflectors, satellite geometry and atmospheric conditions.
Post-processed solutions are far less sensitive for several reasons; one of the most obvious is that dats collected for many minutes (at least 8) gives the software enough information to recognize & mitigatte some multipath signals. RTK is very susepable to multipath.
A high-quality GNSS system under ideal conditions ought to be about 1.5 cm (RMS) 1 PPM. (For the moment let's assume your base is almost ajacent and becomes zero.)
RMS or (sigma) has a 68% confidence interval. Most surveying assumes a 95% onfidence or better.
2DRMS or (2sigma) has a 95% confidence interval. The estimated RMS interval needs to be doubled to be expresed with 95%confidence.
OK now with that out of the way we can get to the meat of your query. The GNSS gives one ellipsoid geometric results.
The ppublished (ideal) expectation are 1.5 cm at 68% or about 3 cm at 95% confiudence.
This translates to 0.1 ft. of expected inteval at the 95% confidence (surveying) level.
The Geoid model adds at least 2.42 cm additional doubt in expressing orthometric height or elevation. 3 + 2.42 = 5.42 cm = 0.18 ft.
Since the value of the geoid height should stay the same for any point we should be able to ignore its contribution to inconsistancy.
From the above, an inconsistancy of 0.1 ft. with RTK is not alarming. One may look at the samples, eliminate outliers, and use the mean value.
Nowhere above did we consider the PPM, but it is important to include. WE also didn't mention how badly multipath or atmospherics can affect results. I always recommend repeated shots should be no sooner than the greater part of an hour to give conditions time to change.
Best wishes,
JAC
-
1
-
2
-
3
of 3 Next