International Surveyors Week 2018

A week long celebration of Land Surveyors, Worldwide

Africa Asia North America Europe South America Middle East Oceania +Add a Story

Survey Earth in a Day 7

Remeasuring the entire planet in a single day as a community of Land Surveyors

Visit Post

How to use the new Surveying Jobs Board

Find and Post Available Surveying Jobs

Learn about Jobs Board

Land Surveyor Submitted Photos

See through the eyes of other surveyors, worldwide.

Featured Photos

Surveying Videos

Learn Something New Everyday

Surveying Tutorials

If you are a land surveyor who would like to contribute to the community's collective knowledge, here is where you get started.

Sign me up!

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!

This Content Originally Published by a land surveyor to Land Surveyors United Network

Views: 748

See Your Saved Posts Timeline

☇ Reply to this

Replies to This Discussion

(Add  Set the pair of points with RTK, then setup on the pair and shoot in the various points with the Robot or conventional total station)

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

Before going into anything deeper. When your guys are shooting points, don't have then just sit on the point and collect. Have them rotate as they average shots. This may help.
Rotate the rod I mean

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.

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. 

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.

RTK solutions are typically only good to about 0.1' vertically, thats why you're seeing so much of a difference. A rapid static solution at least 16m long (for OPUS processing) or conventional methods are your best bet

RSS

Where Thousands of Professional Land Surveyors, Students of Surveying and Educators are United through Collaborative Knowledge and Purpose.

Tools,Apps and Quick Guides

Surveyor Community Hubs For World Regions

Surveying Hubs For US States

Social Support For Equipment

Surveying Photos by Tag

Surveying Videos by Tag

+LandSurveyorsUnitedon Google+

Survey Earth in a Day 7

Surveyor Birthdays

© 2018   © Created by Land Surveyors United   Powered by

Badges  |  Contact LSU  |  Privacy Policy  |  Terms of Service