I just want to know the ideal number of epochs I need when using RTK to take Topo shots. I used to do 3 epochs, is that OK in terms of accuracy, and what would happen if I reduce this number to 2 or one epoch?
Appreciate your help guys!
You need to talk to Kent
Kent McMillan is the resident RTK expert here. He should be back in from Uvalde any minute now. Give him a bit to rinse off and get a cup of coffee and I'm SURE he will answer your questions.
It depends on the topo you want to do, if it's rough dirt for a stock dam or well pad then I would put it on continuous topo and let it do it's thing, maybe use 3 epoch ties for a more intensive purpose say doing a topo for road construction.
If it's for concrete reconstruction like tieing into curb and gutter and finished floors of buildings then it's time for a total station/level survey.
Thanks for your posts Gents. We are using Trimble R10, and most of our survey projects are conducted using RTK such as as-built surveys, QC surveys, etc. Lately I noticed another field crew using a different number of measurements (epochs) than the number I use, and that's what raised this question.
You need to talk to Kent
> Kent McMillan is the resident RTK expert here.
No, I have never sold RTK equipment. I thought it was well known that however the salesman who did sell the RTK gear tackled the problem in the demo was the very best standard of practice in every possible respect.
Salesman insist that for topo you can accept the instantaneous solution. The thinking is that the processor is running multiple simultaneous initializations at all times. I'd say that you should test with redundant shots on fixed points under different conditions and see how your unit is working.
FWIW, I don't think that there is much to be gained in terms of productivity by going less than 3 seconds.
I've used auto topo twice. Burned me both times and I'm done with it. It simply doesn't save enough to make it worth it...
You need to talk to Kent
MattSur,
Might want to look some old threads concerning Kent and RTK. I saw the heading and Paden's introduction and I about fell out of my chair. Kent is very knowledgeable about GPS and the ACTUAL accuracy of an instrument. But there is a long RTK thread history you need to go through before you can truly grasp how funny this little bit really is.
...then again...it might just be me after a long day!!
Matt & Kent, my sincere apologies..
It was a crime of opportunity...I just couldn't help myself.
You should be able to test this for yourself.
If you are using base/rover, use your total station to set two points and determine the vertical difference between them. Set up the base on the first point and rover on second. If the rover has the capability of repeating RTK observations, set it to log continuous topo, logging once per second.
Export points to csv ASCII file and import into spreadsheet. Compile every third shot and average. Compute the difference between each three second average to Total station vertical offset. Compute RMS of elevations. Repeat the spreadsheet calculation using five second average, 20 second average, 30 second average, 60 second average, etc. How do the results change with increasing the number of epochs? This test will give you confidence in what your RTK is capable of in similar environments (baseline length, multipath, etc.) and what occupation time you should use for different accuracy needs. You ask how long should you occupy a topo point. Are all topo points the same? Plus or minus a what, foot, tenth, hundredth?
It takes time and mental effort, but the reward is knowing for yourself instead of trusting anonymous people on the internet to tell you how to survey.
I learned long ago that most of the time fast shots are just fine, but every now and then you will get a funny one. Since then my practice is to reach the point, hesitate two seconds, and take the shot. For more important elevations I hesitate longer, say four or five seconds, and it does make a difference. The rover needs a little time to catch up and be accurate.
I am using Survey Pro and a Sokkia GRX-2 base and rover.
Rough shots are taken as a "side shot" with only one epoch.
Not-so-rough shots are placed on the point, hesitate a few seconds, then take a side shot.
Important points get the bipod legs down, leveled up, and I go ahead and key in the point descriptor, giving myself several seconds before I hit the "point" button. I have mine set to keep measuring until I tell it to stop. I watch the HRMS and PDOP numbers, and the horizontal position numbers. I do boundary work, so verticals are not as important. When my horizontals get less than 0.05 feet, the unit will accept the position without giving me a warning message. I like to see my important points get down to less than 0.02 feet, so I let it cook until I am satisfied.
Shots near overhead canopy may take anywhere from a few seconds to a couple of minutes before I hear "RTK fixed" from my unit. I take my shot, then I lose lock by covering the top of the unit to lose RTK. I let it re-acquire and take another shot, then inverse between the two points as a check. Other check methods include taking shot nearby, then inversing between those two points to check with a steel roll-up tape. Take as many measurements as needed to verify the repeatability of the point coordinates. Others have suggested raising or lowering the GPS unit for additional shots and compare the vertical distances along with the horizontals.
When I need a base point, I will let my GNSS network rover cook long enough to get my horizontal position down to sometimes less than 0.01 feet. That is somewhere between 300 and 600 epochs, depending on how long it takes me to unload my ATV and load it up with my equipment. I then switch out and put the base on that point, let survey pro find the point, and start my base and rover work. I will also collect OPUS data while the base is running for comparison. The comparison it typically between 0.02 to 0.04 feet of difference between the two data sets, which is close enough for the type of work that I do. I primarily do rural Mississippi Class C and D work, and my equipment gives me numbers that are within those tolerance specifications. One good thing about getting a GNSS point is that I don't have to start with an autonomous point, which Survey Pro does not like when trying to do stakeout work. That frustrated me big-time until I figured out a work-around.
One important note: keep that little $35 level bubble on your GPS poles in good adjustment. That makes a $27,000 system work much better by obtaining closer numbers on your check shots.
I hope this helps somewhat. I am sure others have better methods and procedures. Mine works for me, and I am always looking for ways to improve my methods and techniques. RTK is just another field tool to use. If it doesn't give you the numbers you need or it just won't work in the conditions of the area, then get out the total station. Learn the limits of your equipment and the accuracies and precision you can obtain, and compare to what you need; then choose the right tool for the job.
I have used autotopo many times to trace a rapidly eroding barrier beach with the receiver on a backpack. [sarcasm]The results are perfect and you cannot prove they were anything but![/sarcasm]
So to the poster: I use Topcon & Topcon Tools. Every so often, I get a static point that the software thinks is a kinematic blob. Easy to fix, but the more important lesson is looking at the blob. Here's one from the internet (I started to grab one and chose an 8-hour file and it was taking too long, I have to stop procrastinating!)
I have no idea of the units or numbers or anything. I just know that the solution bounces.
Hey, setup your rover on a stable rod (bipod or better) and look at the status. Watch it dance. Do you want one of those epochs? Three?
I usually set 3 with a horizontal average of 0.05 and vertical of 0.05. Sometimes it will record one within 3 epochs.
Since everyone has danced around your question, here is a straight answer: 3 epochs for topo points in Trimble Access.
You'll get an average of the three epochs as your resulting position, and you'll get a warning for excess movement. There are some nice tricks and settings you can do in your survey style that should save you some time and button presses.
You can use the Rapid Point for quick 1 second topo, just change your QC for rapid points in the survey style from QC1 to QC1 & QC2.
Feel free to email me using the link in my profile for any other questions. I'm pretty knowledgeable with the R10 and Trimble gear in general.
> You should be able to test this for yourself.
[...]
> Export points to csv ASCII file and import into spreadsheet.
Or, better yet, export the actual vectors into an adjustment. Test the vector uncertainties by some unbiased method other than just logging s series of positions in rapid succession.
Focus on those occasions where the results turn out to be junk. What clues were present? If no junk results are being found, would it be prudent to improve the techniques employed?
Is there really a uniform answer when you have factors like
Number of satellites?
PDOP?
Wide open vs partially obstructed?
Honestly, I have had good results in the Auto Mode at times and bad results with 5 minute observations at others. How do you really know unless you build some redundant observations into your survey? The objective is good survey data and not how often you push the button. All survey equipment is a means to an end and not the end itself.
If the job allows walking or driving it twice and returning to resolve conflicts I may use it again. I don't consider it useless but I don't have any work where that model fits.
There is a uniform answer.
One needs to collect as many epochs as are necessary to obtain a reliable, repeatable solution for the intended purpose of the data. In some cases a reliable, repeatable solution for the intended purpose is not obtainable NO MATTER HOW MANY EPOCHS ARE COLLECTED.
Many, many thousands of square miles are topod using gsp mounted on a 4 wheeler, it's pretty easy to check the survey.
When I find significant portions of data outside my error budget I'm picking another tool. That doesn't mean it won't work for anything anybody does. It simply doesn't work for me with my current work...