🌐 Show Forums for All Locations
Show the latest social shares
USA Surveying Forums
United States Surveyors
- Arizona
- Alabama
- Alaska
- Arkansas
- California
- Connecticut
- Delaware
- Florida
- Georgia
- Hawaii
- Illinois
- Indiana
- Iowa
- Kansas
- Kentucky
- Maine
- Maryland
- Massachusetts
- Michigan
- Minnesota
- Missouri
- Montana
- Nebraska
- Nevada
- New Hampshire
- New York
- North Carolina
- North Dakota
- New Mexico
- Oklahoma
- Ohio
- Oregon
- Pennsylvania
- Rhode Island
- South Carolina
- South Dakota
- Texas
- Utah
- Vermont
- Virginia
- Washington
- Wyoming
- Wisconsin
- West Virginia
- USA Surveying Events
Asia Surveying Forums
Africa Surveying Forums
Middle East Surveying Forums
European Surveying Forums
South American Surveying Forums
Oceania Surveying Forums
Oceania Land Surveyors
Surveying Equipment Support Forums
Choose Your Equipment Type
Search Survey Photos
Search Surveying Photos by Tag
Add Posts, Surveying Photos, Videos and Articles to the Surveyor Community
Add Stuff to Community
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