Quick question.
We have used a base-rover setup for many years and have been pleased with the accuracy when compared to total station measurements on the same points. We recently started using one of the networks for Georgia, and it doesn't seem like the compared distances are as consistent.?ÿ If the skies are wide open, no complaints. Otherwise, I'm talking as much as .09' between two set points. I have not tried the new equipment with a local base-rover setup.
Is that to be expected?
It's what gets complained about consistently here.
0.09' isn't very good for most tasks I do, rough topo maybe it's OK.?ÿ
Is that to be expected?
What you describe is pretty close to my experience. Local precision is better with a base/rover pairing - presuming that you have your base in a good open site, and nearby. Network accuracy depends on how well you determine your base position.?ÿ
It depends. I operated a network in Georgia and we had a very dense base stations so great results. ?ÿNow we at that time had tied to the Harn monuments as that was what was legislated at the time. So it sometimes caused conflict to certain county monument systems as they did not match the harn always and sometimes did not even fit themselves.
What I found from trial and erred was that base and rover was always relatively tighter at shorter lines. If on a network if you position the points at least twice with a 4 hour gap in time you could achieve just as good relative results. ?ÿNow also remember that you have about a .10 tenth of a foot per 1000 feet between grid and ground more if you get up in higher elevation and smaller on coast.?ÿ
base and rover have proven to be relatively better between two points. Where this fails is when the troposphere is not the same at base and rover . Example it rains on one side of your project like cats and dogs but sunshine and blue sky??s on the other. The network models this troposphere and ionosphere better. Base and rover assumes they are equal. If you are having discrepancies after doing good field procedures I would reach out to the network provider and discuss. They should be able to tell you the cause. Example solar flares, or a internet glitch caused one of the stations near you to go offline during your observations. Or another issue like a station was down and left a larger hole in. That area.
I have not tested a network that has full gnsss at the time we were gps and glonass only. ?ÿ
I have noticed more consistent results when the RTN uses all 4 constellations.?ÿ I am not a fan of the GPS + GLONASS RTN bases.?ÿ We have noticed some are rock solid and dependable (ie. usually the ones in large municipalities) while more rural ones are "looser."?ÿ We use the Topnet RTN in Ontario, for reference.
?ÿ
If vertical precision is a concern, a local base/rover becomes especially desirable IMO.
My observation is that the degradation of accuracy and precision of positions derived from network-corrected rovers versus a base/rover setup is principally the result of longer baseline lengths between the reference station being used as a correction source when compared with typical base-to-rover distances.?ÿ While I am certain that many pay close attention to the distance between their rover and the position of the network base they are running off, many do not.?ÿ While you can usually obtain a fixed solution under a reasonably good sky view even if the reference station you are running off is many miles away from your site, the absolute value of the parts-per-million factor grows proportionally with baseline length.?ÿ?ÿ
For illustration purposes, assume that factor is 1 ppm.?ÿ That amounts to a hundredth of a foot in 10,000 feet.?ÿ Therefore, if you are 20 miles from the reference station from which your RTK corrections are being provided, there is about 0.1 foot of positional uncertainty contributed from baseline length alone, disregarding other factors that may degrade accuracy and precision.
There is the case also of a "modeled network solution", the generic term for the Trimble trademarked VRS, in which the network creates a "virtual reference point" typically compiling it from the three nearest reference stations.?ÿ You would want to use such a correction source where your baseline length to the nearest reference station would be in excess of what you would want to use as a single baseline correction source.?ÿ The virtual point created for your mount point cannot eliminate the composite baseline length contributing to a lower precision than you would get from a short single baseline solution where you are near your local base or a specific reference station, even though it should be less than attempting to run from any of those individual reference stations.
These factors make it incumbent upon the network rover operator to understand the ins and outs of mount points.?ÿ To illustrate, I remember a customer complaining that he could not get a fixed solution.?ÿ When looking at the mount point he was connecting to, I discovered that he was still connecting to the same reference station he had been using on the previous site.?ÿ That reference station was some 50 miles distant from the site he was currently on.?ÿ Connecting to the nearest reference station allowed him to go to work.?ÿ?ÿ
Bottom line: using a network rover without understanding the properties of baseline length and its effects on your solution status and precision is a recipe for frustration and unsatisfactory results.
@jaccen?ÿ
This has been our experience as well. Even full-GNSS RTN tends to be worse (meaning much more variation) in the vertical than a base-rover setup. Cell signal strength and latency can cause issues too.
Horizontally, full-GNSS RTN even in canopy is still pretty darn good with the newer RTK engines.
Yes it??s to be expected unless the CORS you happen to be using when connected to nRTK is only a couple miles away. nRTK is cheaper and convenient, but is less accurate because often the base you get from it is far away from you. PPMs.
It should be clarified that a single-base solution and a networked (or virtual-base) solution are two different things. Both may be offered by a RTN, but the user has to understand which is when and when to use them.
True network solutions do not require one to be immediate adjacent to a reference station as long as you are within the service envelope.
@rover83 regardless of that your errors are to be from the closest CORS in the network per Trimble??s R10/12 spec sheet. And that can be 100,000 feet which makes PPM add up!
@rover83 regardless of that your errors are to be from the closest CORS in the network per Trimble??s R10/12 spec sheet. And that can be 100,000 feet which makes PPM add up!
Not with a network/VRS solution. The major benefit of such a solution is that a virtual base is generated in the vicinity of the rover, atmospheric corrections are modelled based upon multiple reference stations, and the resultant "observed" baseline is from the virtual station.
While the software may generate a vector to the nearest physical reference station (depending on how the RTN is set up and the rover operator's software settings), the NRTK solution - and scalar error - is relative to the virtual station, not the physical station.
http://www.wsrn3.org/CONTENT/Reference/Article_RTN101Part7-Approaches.pdf
Page 88 of this document supports Robert's claim:
https://trl.trimble.com/dscgi/ds.py/Get/File-956301/R12i_GNSSReceiver_UserGuide.pdf
?ÿ
And this point has troubled me for awhile.
Every instance of Network RTK needs an initial position to start computing the error estimates, whether VRS, MAX, iMax, etc.
Depending on whether the solution is Server Side or Rover Side RTK processing (Leica and/or Trimble both), I thought I've read that the initial position is (usually) a single baseline vector associated with a physical base station computed on the Server Side to begin the error modeling AND the initial position for corrections at the VRS for the rover.
Then the rover computes its position using really short single baseline solution vectors from the VRS (less than 1 meter in my experience).
So I've often wondered how Trimble VRS RTK solutions can claim certain low "network error ppm" when it's a combination of Network ppm (8mm + 0.5ppm*vector length RMS) + Single Base ppm (8mm + 1ppm*vector length RMS).
Physical Network RTK seems much more straight forward, and the literature about VRS seems wishy-washy, depending on the source material.
?ÿ
@michigan-left for vrs the position sent to the server where base stations are hosted are sent and do not have to be exact and do not need to be from a fixed rtk rover. ?ÿThe modeling that will take place for ionosphere and troposphere and to calculate a vrs base close to you. Can be a raw uncorrected position. Now depending how or who is operating the system is how often based on distance from the initial vrs position and your rover position at any given survey . When we first built ours we had it calculating a position within a few hundred feet the problem was it was not practical because the end user was constantly getting new base station message. I think we settled on about 3 miles maybe less. Now that was for a particular mount point. ?ÿGeo++ was another software we ran at same time as the Trimble vrs. Both had pros and cons from my experience and dealing with the end user. So not all networks will work the same even those who have identical software. ?ÿLike vrs. The network operator has to make decisions for the greater good off all users so like any thing in life there??s a pro and con to all the decisions made. On network side. Also the greater area covered the better the troposphere and ionosphere can be modeled. All stations play a role not just the stations around you the end user. I hope this makes sense in between flights with kidos at airport. You can literally calculate a base so PPM will not be an issue. So as i like the base and rover for relative accuracy where i am today. I had no issues with matching a base and rover when i was in ga off the vrs network at the time. ?ÿ
@michigan-left I am finally back home after vacation at grandmas house with kidos before school starts back. To maybe get a feel for how vrs and geo++ work we would take a airlink raven modem put in a lat long to send to the vrs nitrip and the lat long would just be a close autonomous position on a site for our customers that had older equipment that was not what they called wide area network compatible. ?ÿExample old ashtech z-12. And such. And especially contractors when all of this first got to really gaining momentum. ?ÿBut you could do single base via an internet protocol. So the customer could be dialed in a receiving rtk correction based on the gga message lat and long for simplicity on a site. And ?ÿthen they could dial into the air link raven modem and get those corrections and modeled vrs base station info at the rover . So a lot of the earhwork guys kept the airlink in the truck and just stayed close to the rover . Remember the base in single base has no idea where the rover is. So it was sort of an hybrid system. We are ven set up z-12 for USACE for hydro. Z-12 had a couple ports and it could send the gga out one and received corrections on the other in the boats. This way they didn??t have to have a base station physical rtk base and radio move every so often down the bank of navigable waterway. ?ÿ But they did have to correct or fake out the system every so often but it worked.?ÿ
not going to lie it was a lot of head scratching in a hotel room with antenna laying out the window and might have had a lot of frustration liquid stopper as well before we figured it all out. Beer beer lots of beer . Lol
Another factor in network rtk is the terrain difference within the network itself. If you took any network software and placed them in identical spacing and settings but two different locations. Say Georgia and Colorado they would not function identical thats why the network operators truly have to not just plug and play but really do ground truthing throughout. To get the right settings for elevation difference when drastically different because that changes troposphere so mountain vs flat land vs coast. ?ÿFlorida was a beast in itself because one side needed one type of approach and the other side needed another. Georgia mountain area vs Georgia macon or middle are vs the coast line. I called it redneck geodesy. Now a lot has changed since 2005-2008 timeframe. I never operated smartnet or the topnet but i tested vrs against geo++ at that time . Geo++ did a lot of things better and vrs Trimble did other things better. Some were measurement focused others business focused. We had a pair of IT guys that were awesome a licensed surveyor who was smart as a whip. And me i was the well just the guy who did whatever we needed but not the brains lol. Oh and a lady who kept us all on schedule and focused. I met myself in the road many times back then. On a network especially not knowing how or who set one up I would be testing it a lot before i just accepted a position on one shot. Two observations 4 hrs except maybe topo shots. But I would even spot ck those in different areas.?ÿ
Dovetailing into the initial Q--has anybody done any comparison between the satellite RTK services vs a traditional RTN/VRS setup?
?ÿ
ie. Hemisphere's Atlas
https://www.hemispheregnss.com/product/atlas-gnss-global-correction-service/
?ÿ
Trimble's XFill
https://positioningservices.trimble.com/services/xfill/
?ÿ
Leica SmartLink
