Mark Mayer, post: 340253, member: 424 wrote: Any system that provides positions in real time would have to use ultra-rapid orbits.
My own base doesn't. Why would an RTN have to?
Jim Frame, post: 340251, member: 10 wrote: I guess I should find out whether CRTN uses the ultra-rapid or not...
Found a probable answer: the CRTN 5.0 proposal document (October 2008) states that the network uses ultra-rapid orbits.
RCliffWilkie, post: 340168, member: 10285 wrote: It all depends on how "repeatable" you need the control to be. Static and RTK are fundamentally the same thing. RTK just normally consist of very short sessions. Repeat RTK positions can work very well, again, depending on what your project needs are. And I say this after many years of doing static geodetic networks. I have never confirmed this, but strongly suspect that several RTK positions spread out in time give pretty much the same results as a continuous static session throughout the same time interval. Of course network geometry has to also be considered and five RTK sessions from the same base point can be rather weak geometrically. If using an onsite base station, a very good approach is to jump a base station around to perhaps three points spread throughout a project area then collect 5 second RTK positions on all other points from each of the three base setups. With an RTN the geometry will probably be quite strong since the rover position will be determined relative to several base stations anyway, regardless of whether it is a VRS or a Leica style network using RTCM 3.1.
Ultimately one needs to consider maximizing changing satellite geometry and overall baseline geometry effected by using various base stations spread out in a manner that is considered "well conditioned". Whether it is static or kinematic is secondary to those considerations. RTN's pretty much take care of the baseline geometry by using multiple base stations. And of course you gotta have redundancy (repeat positions) or you ain't got nothng at all. In the late 80's Trevor Greeening established second order control points in Colorado Springs using repeat post-processed kinematic positions on all points. It was done in response to a contract for providing second order control, and met the contract specs. Not many of us around anymore who have done post-processed kinematic, but it worked quite well too.
I would rephrase that to 'RTK and Static can produce nominally equivalent results in SOME situations'.
I've been developing and testing procedures for both for well over 15 years. There are way too many variables to make a blanket statement equating the two. Add to that the increased flexibility of static data and it's an easy choice. That may change when we have access to a better RTN, but even then it's just too easy to get dependable static solutions. I'm with Mo. It's a can / should decision...
Let me qualify: Static and RTK results are derived from the same mathematical process. In that sense they are the same. They are both double difference phase processing. RTK is a shorter time span involving usually 3 - 5 one second epochs. Static usually involves time intervals of from one half-hour up to 24 hours depending on the purpose. Static processing usually uses fifteen second epoch intervals. Of course "Rapid-Static" is somewhere in between in terms of the time span of the observations. Otherwise it too uses the same mathematical processes. All produce results that are a function of double difference processing of the phase observables of all the epochs with ambiguity parameters fixed to integer values. So in that sense RTK is the same as static. Error propagates in all these processes in the same way as well. It just has more time and a much bigger sample size to propagate through with static. I like to think of the processing error as "internal" error or precision rather than accuracy. It says nothing about what I like to call "external error" from sources such as overall network vector geometry, setup error, multipath environment, point naming mistakes, or error inherent in the coordinate values of the control points which the double differenced baselines (or simply coordinate values) are tied to. internal error is largely a function of satellite geometry and its changes, clock errors of both satellites and receivers, and tropospheric and ionospheric errors. Satellite geometry and its changes as well as multipath are controlled by the surveyor end user. Clock errors cancel in the processing and atmospheric modeling is the big deal of real time networks. They model the atmosphere in a way that makes it possible to successfully fix ambiguities to integers in much longer baselines.
My data collector can resolve ambiguities and initialize with under a minute of satellite data. Why can't my office software do the same with a minute of 1 second epochs?
Or can it? I've never really tried.
RCliffWilkie, post: 340478, member: 10285 wrote: Let me qualify: Static and RTK results are derived from the same mathematical process. In that sense they are the same. They are both double difference phase processing. RTK is a shorter time span involving usually 3 - 5 one second epochs. Static usually involves time intervals of from one half-hour up to 24 hours depending on the purpose. Static processing usually uses fifteen second epoch intervals. Of course "Rapid-Static" is somewhere in between in terms of the time span of the observations. Otherwise it too uses the same mathematical processes. All produce results that are a function of double difference processing of the phase observables of all the epochs with ambiguity parameters fixed to integer values. So in that sense RTK is the same as static. Error propagates in all these processes in the same way as well. It just has more time and a much bigger sample size to propagate through with static. I like to think of the processing error as "internal" error or precision rather than accuracy. It says nothing about what I like to call "external error" from sources such as overall network vector geometry, setup error, multipath environment, point naming mistakes, or error inherent in the coordinate values of the control points which the double differenced baselines (or simply coordinate values) are tied to. internal error is largely a function of satellite geometry and its changes, clock errors of both satellites and receivers, and tropospheric and ionospheric errors. Satellite geometry and its changes as well as multipath are controlled by the surveyor end user. Clock errors cancel in the processing and atmospheric modeling is the big deal of real time networks. They model the atmosphere in a way that makes it possible to successfully fix ambiguities to integers in much longer baselines.
While your statements are true, they omit a few important details.
My RTK data is stored as a vector. For the most part all decisions have been made and what you see is what you get. You won't be changing much during post processing. With Static I can run multiple iterations changing a large selection of variables.
Another consideration is the number of things that can go wrong. With RTK I may be fighting radio, isolating bad initializations or dealing with improper decisions limiting my data quality. With static I can take out specific birds, change mask or use any number of strategies to deal with conditions that can't be known in the field.
All that being said, the results can be nominally the same in some cases. The procedures required to obtain reliable equivalency make static a slam dunk choice most of the time.
I've had consistently good results with RTK. We do multiple sets of observations at different times during the day. Checking into established control such as ngs or town points has us always sub tenth.
-V
Norman Oklahoma, post: 340136, member: 9981 wrote: Depends on the RTN I suppose.
Truth.
Sounds like a great opportunity to do it both ways on this project and compare your results? Going forward the choice for similar projects will be easier.
Just consider the RTN shots a check on the static work and just work it into the QA/QC portion of your estimate.
An experiment is the only way to see if it really is good enough.
I am a post processed static fan since 1990. Much more control over the result and confidence in the solution. That said, I am using RTN's some and even running my own RTK base with some of the field procedures that build confidence in the solution.
ODOT here in oregon runs the ORGN, there was some testing done using the following procedure:
"Using the ORGN MAX or iMAX corrector observe four - 8 minute (480 seconds each) RTK sessions at one-second epoch each separated by 30 minutes"
That procedure has shown the RTN values to be equivalent to long (two hour plus) static observations during their testing and I am starting to incorporate it where the travel time is long between points. Your total elapsed time is 122 minutes (2 hours and 2 minutes) once reaching the location which makes sense if it takes more than an hour to reach the point (not uncommon in remote areas of the western USA). Even if I don't have radio link, I still have been collecting this way the last few months for post processing. I do break the setup between the 2nd and 3rd occupations and rotate the pole or tripod 180 degrees. I ALWAYS collect raw data on the rover and my base, if all else fails you can do PPK after the fact, if you don't have raw observables collected you are pretty well hosed if something undected goes wrong in the field.
I recently bought an Inticom RTK Bridge-X and that device allows you to host your own base station over an IP address, so essentially I can run any survey in the field as RTK within limitations of single baseline RTK as long as I have cellular coverage. I will be using this with the ORGN procedures in areas where there is no RTN coverage so am updating my tools somewhat to keep up with available technology.
SHG
Shelby H. Griggs PLS, post: 340941, member: 335 wrote: That procedure has shown the RTN values to be equivalent to long (two hour plus) static observations during their testing and I am starting to incorporate it where the travel time is long between points. Your total elapsed time is 122 minutes (2 hours and 2 minutes)
If 2 hours of RTK is as good as 2 hours of static, why not just collect static for 2 hours and not mess with the RTK?
Jim, I think it is because there is redundancy in four measurements over the two hours plus four initializations, not stated, but I think what they were alluding to is a network of 2 hour static observations, ie: the old school way of building static networks. The RTN solution is still a single physical tie to a CORS or your own base station, ie: a sideshot. RTN's take away the single baseline limits on distance, BUT you are still only tied to one base station, be it your "virtual base" in Trimble speak or the "real base" in Leica MAX networks.
I have modified the ORGN procedure where the travel time is short, and do two groups of two observations, or even just a single observation and come back after two hours, statistically LSQ of course shows smaller error ellipses for the four measurements than two. I am still evaluating different techniques and I have been using GPS for 25 years, sometimes it is hard to change from the way it has always been done, even though the tools change 🙂
I had one project this field season that required about a six hour RT into a remote area on the OR-NV border, you bet I was looking for a way to add redundancy and ensure I NEVER had to return!
SHG
I believe Shelby is saying that each 8 minute session is equivalent to a 2 hr OPUS, so 4 sessions over 2 hrs would be like 4 OPUSs. Or one 8 minute session and out. I'm not sure what testing was done, but it is very possible that a still shorter session (3 minutes?) would reliably match OPUS.
Shelby's comments are very interesting to me. (I don' t know how to copy a previous post as a reference). Nice confirmation that several RTK sessions can equate to a static session over the same time interval, yet leave time in between the RTK sessions for surveying something else. The various setups of the RTK antenna along with rotating the antenna provide a great "external" check that you don't have with a long static session. And even though the RTN baseline is still perhaps repeatedly from the same base station, it seems to me there is enough QC for it to qualify as more than a stand alone sideshot. First there are the repeat antenna setups. Second, since it is in a network, it is virtually impossible for the base station coordinates or its antenna height to be wrong. And finally, even though the phase-differenciing is from a specific base station, the atmospheric modeling (tropospheric and ionospheric) is from all the surrounding base stations of the neighboring subnet of bases. The atmospheric modeling is what makes the long baselines work or, in the case of a VRS, make the nearby VRS phase data work with the rover data. It's pretty hard to imagine how a mistake could creep into it. So, all in all, it seems pretty safe and quite accurate to me. One can force a change to another base station but I doubt the final positions would be much different and more "accurate". Interesting thread. It's difficult to get to this kind of input and information from proprietary network manufacturers.
Shelby H. Griggs PLS, post: 340945, member: 335 wrote: Jim, I think it is because there is redundancy in four measurements over the two hours plus four initializations, not stated, but I think what they were alluding to is a network of 2 hour static observations, ie: the old school way of building static networks. The RTN solution is still a single physical tie to a CORS or your own base station, ie: a sideshot. RTN's take away the single baseline limits on distance, BUT you are still only tied to one base station, be it your "virtual base" in Trimble speak or the "real base" in Leica MAX networks.
I have modified the ORGN procedure where the travel time is short, and do two groups of two observations, or even just a single observation and come back after two hours, statistically LSQ of course shows smaller error ellipses for the four measurements than two. I am still evaluating different techniques and I have been using GPS for 25 years, sometimes it is hard to change from the way it has always been done, even though the tools change 🙂
I had one project this field season that required about a six hour RT into a remote area on the OR-NV border, you bet I was looking for a way to add redundancy and ensure I NEVER had to return!
SHG
Thank you for weighing in. I was hoping to see you here...
I've been running two sets of 30 second occupations (rotating 180 between each 30) for RTK based control. For inaccessible points I separate the two sets with a little over 20 minutes of static data. This of course assumes my base or bases are nearby.
I would love to see a southwest Idaho vendor marry up with the Oregon system. The local network simply isn't robust enough to get the results our brothers to the west are getting. It is great to grab base data to augment local networks. We haven't logged in RTK in forever...
Norman Oklahoma, post: 340989, member: 9981 wrote: I'm not sure what testing was done
Mark, on the ORGN site there is a form outlining the "test" procedure. The results aren't stated there, BUT I have had a personal conversation over dinner with the person who did the testing and that is where the information came from that this was inline with long static observations. I need to get clarification on the accuracy achieved, but basicly I believe the goal was to find a field procedure using the ORGN that would provide a high degree of confidence in the solution that matched old school long static sessions, in other words a way to take advantage of the technology to improve field production without sacrificing accuracy. I believe if less than 480 seconds would of reliably worked that would be the recommendation, I am sure you can get away with less time, BUT I think that time might be the bulletproof minimum that works 95% of the time?
SHG
Shelby, Mark Armstrong told me that they ran checks following the recommended ODOT procedures on marks that had previous OPUS-S solutions. I was also told the positional differences were sub-centimeter. Sounds repeatable to me. I don't believe every network out there can deliver results like that.
