Hello guys!
I am doing my static the old way with longer observation time. With the expanded GNSS constellation now in service, how did it affect the static observation time in your experience? Any time-trajectory guide that you use? Any suggested data collection settings?
Thank you.
10 minutes, plus one minuter per mile. I would collect at 15 seconds, but that's pretty old school, trying to save computer space, 30 seconds is what OPUS uses, I think.
Keep very good records, start times, stop times, HI's-measure in feet and meters. use two different tapes.
Occupy every point at least twice
GPS only or GLONASS too.
L1 only, Or, L1 and L2? And, as Shawn above said, GLONASS too?
I know another surveyor, who used to observe at a 1" rate, (makes huge base files) and would use an ATV, and get around the Section as fast as he could. He would observe for 10 minutes, on everything, run home, post process, and come back, and finish his retracement. He offered his services to other surveyors, so that THEY could use his control, and work off of it, also.
Fact is, POST PROCESSED data, is MORE robust, than RTK. At, least it was at 10 yrs ago.
It has me THINKING about the new Javad deal, of being able to do BOTH together, on the same Job. It has my poor brain wheels turnin...... an turnin....
It is an idea, that was bounced around some 20 yrs ago... with TDS, but it never reached fruition. Then, Trimble bought them.
I want to see how this all pans out.
Lets see, I'd like a nice new drone... to get my own aerial photography... and a LS, and a nice fast mechanism to do cogo while the LS works..... O yeah!
N
I don't know for me, if it is important enough to static, then it gets at least 30 minutes, often an hour out in the open. And in the woods 3-4 hours is common. That is with GPS+GLONASS, at 5 sec record rate, and I have quite a few receivers to use, so it isn't imperative that I move them quickly.
In the open, I've found five minute occupation times are suitable for anything within about 7km (5 miles). A couple of weeks ago, I got a great solution from a 6 minute observation on a baseline of 15km (9.5 miles). I don't know if I could do that every time or not. This was with dual frequency GPS+GLONASS.
In adverse environments all bets are off. More the better.
Shawn Billings, post: 362216, member: 6521 wrote: In the open, I've found five minute occupation times are suitable for anything within about 7km (5 miles). A couple of weeks ago, I got a great solution from a 6 minute observation on a baseline of 15km (9.5 miles). I don't know if I could do that every time or not. This was with dual frequency GPS+GLONASS.
In adverse environments all bets are off. More the better.
I am always hesitant to do shorter than I am used to. The first GPS I got was the Leica 500 series way back in 2003. Based on my experience, I got good results with 45min observation time. I am used to data rate at 1s. Just two to three years ago, I got one bad result for a 30min occupation time (GPS+GLONASS) though all others were successful.
6min observation time is simply amazing. Of course, logistical considerations would come into play considering all business factors. I wish there are new guidelines (theoretical and practical) for best practices in static surveying.
I prefer to do 15 min. I'll go longer if I feel like it, and of course longer for longer baselines.... I do a lot of these for monitoring wells and for engineering control. Used to do dual 45min occupations for high accuracy control, but the results vs the cost just don't justify it very often.
Jon Collins, post: 362276, member: 11135 wrote: I prefer to do 15 min. I'll go longer if I feel like it, and of course longer for longer baselines.... I do a lot of these for monitoring wells and for engineering control. Used to do dual 45min occupations for high accuracy control, but the results vs the cost just don't justify it very often.
I'll try your way. Thanks for the tip!
Regards.
amdomag, post: 362081, member: 1683 wrote: Hello guys!
I am doing my static the old way with longer observation time. With the expanded GNSS constellation now in service, how did it affect the static observation time in your experience? Any time-trajectory guide that you use? Any suggested data collection settings?
Thank you.
Still the same with NAVSTAR. For baselines under 10 km, 10 minutes period. For baselines 10 km or more, it's 1min/km for the entire observation time.
This is the same and preferred method that TxDOT recommends and I can't see a fault with it unless you happen to be on a short baseline with terrible geometry, in which case, log more data and trim the crap at the end of the day in the office.
I love static processing. Static gathering, not so much.
Yesterday I was doing an RTK survey on a 25 acre tract. I collected each boundary point for 2 minutes. This was retracing a survey we did in '08. I also recorded raw data at each point. I sent the data to a new experimental Javad DPOS server that processes base rover data. All of the rover points were in marginal environments at best. DPOS processed every single vector. One point was under pine with a thick wall of pine to my east. Deciduous trees to the west. I observed 500 seconds. RTK struggled here. DPOS nailed it.
I think post processing is much more robust than we believe mostly due to outdated rules of thumb. In theory post processing should be able to provide a fixed solution with no more time required than for rtk.I can get a fixed solution on a 3 mile vector in just a few seconds with rtk. Post processing should be no different.
I recently sent some files to the experimental DPOS site that had six common epochs between base and rover (a mistake in recording intervals on my part) at 2.5 miles. They processed perfectly.
Logistically, we look at occupation time with a little added redundancy to avoid the necessity of a return trip on the outside chance that the data doesn't process well. That's one advantage of rtk. You know before you leave that you have enough data to determine the position of the point accurately.
Shawn Billings, post: 362418, member: 6521 wrote: Yesterday I was doing an RTK survey on a 25 acre tract. I collected each boundary point for 2 minutes. This was retracing a survey we did in '08. I also recorded raw data at each point. I sent the data to a new experimental Javad DPOS server that processes base rover data. All of the rover points were in marginal environments at best. DPOS processed every single vector. One point was under pine with a thick wall of pine to my east. Deciduous trees to the west. I observed 500 seconds. RTK struggled here. DPOS nailed it.
I think post processing is much more robust than we believe mostly due to outdated rules of thumb. In theory post processing should be able to provide a fixed solution with no more time required than for rtk.I can get a fixed solution on a 3 mile vector in just a few seconds with rtk. Post processing should be no different.
I recently sent some files to the experimental DPOS site that had six common epochs between base and rover (a mistake in recording intervals on my part) at 2.5 miles. They processed perfectly.
Logistically, we look at occupation time with a little added redundancy to avoid the necessity of a return trip on the outside chance that the data doesn't process well. That's one advantage of rtk. You know before you leave that you have enough data to determine the position of the point accurately.
Shawn, not all that much has changed, we were doing the same things almost twenty years ago with short static times on points.
I think OPUS has corrupted ideas about static times.
Of course the big change are all the satellites up and units that can fix under canopy, no matter how long you observed under canopy it was almost always faster and just safer to break out the instrument.
The 10 minute plus 1 minute per mile is probably overly robust, but it's still valid. Can you push it?,,,,,,,,,,,,,sure, I do all the time.
a 2-1/2 minute static observation giving a fixed solution to a CORS station 30 miles away won't surprise me at all.
A 10 minute static session with my base 70 miles from me isn't at all unusual. We were doing that in the 1990's.
What's kinda amusing is that people want rules to follow for these situations and want them rigid and inflexible, when that will never be the case.
What is certain is that 4 hours for OPUS on every point you do is not even remotely realistic, and it's good that trimble and javad are offering options to OPUS.
As far as fixing for points over great distances and short times, that also has been available, PPK will do that and always has.
There have been several rules of thumb discussed, without stating what accuracy and confidence was needed for the work, so comparing session times without comparing results is not terribly meaningful.
All the rules of thumb aren't as good as a test with your equipment under your working conditions. If you think X minutes is good, then someday when you can let it sit while you do other work take a 3X or 5X or 9X minute file and process as separate X-minute sessions, and then do it on another day (different iono) to see how well they all agree.
Bill93, post: 362481, member: 87 wrote: All the rules of thumb aren't as good as a test with your equipment under your working conditions.
I absolutely agree. Bill is spot on. It's pretty easy these days to test for yourself what your equipment can do in your work environment. Not only does this sort of testing give you an idea of what you can expect from your equipment, the process also improves your skills at operating the equipment.
Be aware that some software will process all the way through the file, even if it is trimmed. It just doesn't use those epochs for the position (sort of like post processed kinematic). I would recommend spending a Saturday and collecting data on a few points with varying conditions. Collect a session for 1 minute, another for 2 minutes, another for 3 minutes, 5 minutes, 10 minutes and fifteen minutes. You should be able to do a point like this in 30 minutes. Then go to the next point and do the same for this point. Use points far from the base and close to the base. Under a tree and one in the open. Process them. Then compare results. Was the processor able to get a fixed solution? Was there an improvement in accuracy with more time on site?
amdomag, post: 362081, member: 1683 wrote:
I am doing my static the old way with longer observation time. With the expanded GNSS constellation now in service, how did it affect the static observation time in your experience? Any time-trajectory guide that you use? Any suggested data collection settings?
Thank you.
I still preach "15 minutes + 2 minutes per km" as a rule of thumb, even with L1/L2 + GLONASS.
Why? Well, your static solution is still based on common satellites and and having a good sampling of their celestial movement.
I recommend a 1 second logging rate (since most receivers nowadays have larger internal storage) or at most a 5 second logging rate.
My $0.02.
15 MINUTES IS A GOOD RULE, EXCEPT WHEN IT IS NOT.
I just did planning for today at Easton, PA. Using just the GPS the average PDOP was 2 with a minimum of 7 satellites. However from 8-9 AM UTC there was a drop to 6 satellites and PDOP spiked to 6.5. 5 of those 6 were bunched in an East West band with only 1 to the South. During that time frame observation quality will definitely drop, but preplanning would allow you to compensate during that time period. Just because there are so many GPS satellites up there does no guarantee that they are always in the right place.
Having multiple constellations available does fill in the sky but with some preplanning that extra expense is not fait accompli.
L1/L2 GPS receivers are now so inexpensive that they can be left to run on certain points while conventionally surveying or RTKing the project without affecting the project time or budget.
Paul in PA.
My rule is 15 minutes plus 1 minute per km over 15 km (minimum)
PM3s have a window that gives a Range value.
It is ready when that value is 1.5 times the distance to my control points.
When it is recording from 8 or more sats 5min will do.
