Network RTK vs. Post processed static observation times

Network RTK, or any RTK for that matter, is providing a solution based on the snapshot of that moment in time; you get a fixed ambiguity solution, you get a position. Static processing software is looking at the entire data set, and is able to consider the change in geometry of the constellation over time. Obviously your PC has a lot more processing horsepower than the receiver and data collector that you use in the field. The short answer is that static software is better able to model out atmospheric biases, multipath, etc. due to the change in geometry and the amount of redundancy in the session.

In theory network RTK has the same accuracy specs as short baseline RTK, but in reality there are other considerations with network RTK that can cause degraded or even outright bad solutions, such as latency in the data - this can be a real problem, especially if the station in question is the one nearest your location.

Services like CenterPoint are able to model atmospheric and clock biases in a similar manner to an RTK network. However, it has been my experience that CenterPoint needs a pretty long session in order to provide a reliable solution, especially vertically. I have gotten the best results by post processing in TBC; whether using data from CORS or running multiple receivers in a session, as long as I observe for at least 10 minutes plus one minute per kilometer of baseline length with good geometry, I get great results.

Actually, I have wondered the same. If I go out in a VRS coverage area, it will typically initialize in 10-20 seconds if I have both GPS and Glonass. Results are usually very good, 1-3 cm level.

So, if I have a similar situation (inside a box of CORS), why is OPUS-RS so flaky? It has access to the same data (a network of CORS) that it could use to do the same computations as the VRS solution is doing. In fact, it has one distinct advantage...it does it after the fact, so latency, etc is not an issue.

I don't like or trust OPUS-RS, I once submitted 24 1 hour files, only about 16 of them came back with the right answer. I know it uses data from 6 stations, so if the data isn't available and clean from the nearest 6 CORS you're going to have problems.

I like OPUS Static but I find that PAGES needs 4+ hours of good data to really drill down to a good solution. I just submitted one this morning that came back with peak-to-peaks of 15mm, 2mm, and 7mm vertical....

How many receivers does the VRS have monitoring and calculating corrections? Is one always closer to you than the CORS? Isn't being close the big advantage of base-rover (despite its other problems)?

The Louisiana Gulfnet network (www.c4g.lsu.edu) is a network of 72 stations in Louisiana and the bordering states. Although the spacing of the stations in an RTN is important, proximity to a station is not particularly important.

Traditional base - rover solutions begin to degrade as the distance increases because the atmospheric biases at the receivers begin to diverge - in other words, at some point the receivers are no longer seeing the exact same thing. In a VRS network, the network software models the atmospheric biases and generates corrections that are specific to the location of the rover.

Not all RTNs are VRS; many use the data from the nearest station. VRS (Virtual Reference Station) looks at your autonomous position and generates corrections at that location. If in the course of your survey you move a certain distance (I want to say it's a mile here), the network throws that "station" out and generates a new one for your new location.

I am not a VRS operator, but my understanding is that it uses the CORS (the ones in the system, not necessarily the same ones available to OPUS) surrounding your site to compute corrections at a virtual station nearby, emulating a nearby base. It then broadcasts the corrections, and the rover is solving a short baseline rather than a longer baseline to the nearest CORS. You can also go "single base", in which case it is using the nearest CORS and not creating a virtual station.

But why can't this same functionality (creating a virtual station nearby) be incorporated into post processing?

I have found OPUS-RS way too flaky to rely on. I do use it as a check, but you cannot depend on getting good results, even when there are seemingly plenty of reference stations nearby.

I have been using VRS more lately, out of necessity. We have had a bunch of projects for 3" resolution imagery (which means tighter control necessary) covering huge areas, entire states (although the imagery doesn't cover the entire state). Not practical to do static as the points are too far apart. So, I am learning a lot more about the VRS and how it works (and the problems it can have). However, I do not need real-time coordinates, just an indication of the accuracy (precision) attained in real time so that I know I have enough data. I have found that the real time precisions shown on the DC are quite realistic. If they are high (numerically), the data is probably crappy. If they are numerically small, the data is good. We did a bunch of small projects where we went back 4 hours later, the precisions were reflective of the repeatability.

One neat feature the VRS that I use the most has is the capability to create a virtual base after the fact at a location you enter. So, I could create a base near where I need it and post process the data. It will create either a rinex or dat file. Works pretty well, but not flawless. You are still dependent on the post processing software to get a good solution, which it does not always do. But that is another fallback that I have found very useful. Kind of like roll-your-own OPUS-RS. It will take advantage of all the stations around you when creating the virtual station.

One problem that I have found is if there is changing weather conditions, the modeling sometimes falls apart (as might be expected).

Edit: I see that Gavin Shrock addressed some of these same topics in a post on 3/22, and he IS a VRS operator.

The single base solution is not an option with Gulfnet, it's always a VRS solution.

I think you answered your own question about incorporating a VRS - type solution into post processing; as you said, the network can generate a virtual static session at the location of your choosing. Here in LA that's an add-on to the basic network RTK subscription. From my limited experience using it it seems to work pretty well.

As far as the stations being CORS, I would estimate that about half of the stations in the Gulfnet are also national CORS stations.

I recently did some work where there were 2 VRS system, one a Trimble and the other a Leica. On some points I used both, and the results were similar but not the same, up to a couple of cm. Since I was using Trimble equipment I could only use the Leica system as "RTCM3Net".

We sometimes use hotspot on cell phone (or a mifi), and other times use an RTK bridge (Intuicom). The bridge is much easier, and also it works where there is only a 1x coverage (like large parts of WV). It works under the RTK style rather than VRS style, but the data is the same. What I liked about using the VRS style was that all data was stored as vectors from the nearest physical reference station (PRS), whereas the bridge would store it as a vector from the nearby virtual station (VRS). This meant that if I revisited a station at a different time, it created a different VRS station, which makes it more difficult to compare repeat line. I recently (accidentally) found out how to make the bridge store it from the PRS, so now I have absolutely no complaints about the bridge.

I flew to a job yesterday with the RTK bridge, GPS unit, and data collector in a small carryon. Had to check the rover pole with tripod legs because those tips could be dangerous weapons. I actually have a collapsible pole that folds down to about 16" (still has the tips, but I guess I could put a topo foot on it), but have not yet found a smaller version of the tripod legs.

I haven't used the Intuicom RTK Bridge; I always wanted to get my hands on one. Seems like a great tool, especially in areas with sketchy cell service.

I saw a Trimble R8III run on VRS right next to a Leica Viva running on the Leica network - they were running single base but the results from each were within a cm or so. I don't think their coverage is quite as good here as Gulfnet's but in any case we run all Trimble GPS.

The one thing I don't like about it is that Verizon made me get a 5 GB stand alone plan at $50/month. I can not share the 10 GB I have otherwise. I think even if I left it running 24/7 I could never get close to using 5 GB.

> Actually, I have wondered the same. If I go out in a VRS coverage area, it will typically initialize in 10-20 seconds if I have both GPS and Glonass. Results are usually very good, 1-3 cm level.
>
> So, if I have a similar situation (inside a box of CORS), why is OPUS-RS so flaky? It has access to the same data (a network of CORS) that it could use to do the same computations as the VRS solution is doing. In fact, it has one distinct advantage...it does it after the fact, so latency, etc is not an issue.

yes this is exactly what I'm getting at. the reference stations are exactly the same for the vrs and for post-processing.

Why can I get an accurate reading within seconds/minutes with vrs and need 1 hour for static observations post-processed with the the same data?

I have tried shorter observations like 10 mins as suggested but the stated accuracy was not good.

I have tried shorter observations like 10 mins as suggested but the stated accuracy was not good.

Yes, but how was the actual accuracy?;-)

I'll bet it was pretty good.

Test some points with a short observation then longer ones, see what you get.

Static post-processing doesn't use the same algorithm as RTK. Static wants data spread over time, that's why 30 sec interval works. Rapid-static is more like RTK. It requires short interval data such as 5 sec or less and can fix quickly, but doesn't work as well over longer baselines.

> > Actually, I have wondered the same. If I go out in a VRS coverage area, it will typically initialize in 10-20 seconds if I have both GPS and Glonass. Results are usually very good, 1-3 cm level.
> >
> > So, if I have a similar situation (inside a box of CORS), why is OPUS-RS so flaky? It has access to the same data (a network of CORS) that it could use to do the same computations as the VRS solution is doing. In fact, it has one distinct advantage...it does it after the fact, so latency, etc is not an issue.
>
> yes this is exactly what I'm getting at. the reference stations are exactly the same for the vrs and for post-processing.
>
> Why can I get an accurate reading within seconds/minutes with vrs and need 1 hour for static observations post-processed with the the same data?
>
> I have tried shorter observations like 10 mins as suggested but the stated accuracy was not good.

Yes I;ve checked the survey style it's "fast static" actually. Is that the same as rapid static? The logging interval is set to 5 seconds.
The nearest reference station is often only about 10-20 miles away (depending on where I'm working)

should I give TBC another go post processing fast-static observations?
do you think I might get better results for 10 min observations than centerpoint RTX?
When I tried it before I seem to remember that the results were very similar as you might expect.

I occupied a new control point Friday. I had 1-1/2 hour of time on it to process before lunch for session 1, then broke the setup, turned the tribrach and collected the rest of the day. One cors point about 30 miles away, the next one 95 miles. I post processed session 1 and for session 2 I post processed and sent to Opus as a third check. The cors point 95 miles away would not process a fixed solution for session 1 and had red flags, but I made it calculate the solution anyway. The float solution was within. .05' hor and .03' vert of my fixed solution and Opus.

Plenty good!!!!

Just because it won't fix and just because there are warnings doesn't mean it's a bad solution.

The base needs to have 5 sec interval also, and you need a shorter baseline. I bet 20 miles is too far.

If you have a base within a few km and logging at 5 sec., you'll fix fast similar to RTK. The reason the manufacturer asks you to occupy longer for fast static compare to RTK is because the fixing time is unknown and they want to be sure it fixes.

> should I give TBC another go post processing fast-static observations?
> do you think I might get better results for 10 min observations than centerpoint RTX?
> When I tried it before I seem to remember that the results were very similar as you might expect.

At 20 miles you need about an hour of data, regardless of your logging rate, if you want to get a good solution. Logging at 5 seconds only helps if the CORS is also logging at 5 (or at 1). I log at 15 and, as I stated above, have never had a bad result logging for 10 minutes plus 1 minute/kilometer of baseline length. You can absolutely get fantastic results with occupations as short as 5 minutes, but only on short baselines.

There was a great article a few years back in POB about the correlation between baseline length and occupation times; unfortunately I have no idea when and can't locate it. But the gist of it was that the farther apart the receivers are, the more they are receiving the satellite data with different geometry and atmospheric biases, and therefore the more data it requires to model the solution. Static processing engines like PAGES (OPUS static) are looking at the change in satellite geometry over time, hence the need for 2 hours or more.

An hour would be plenty, half an hour will work also, rather have two half hour sessions than one hour session, longer is better, more is even better.