I have been working with Starnet and least squares and was wondering about the baseline data received from a Trimble data collector and an RTK CORS baseline.?ÿ I work around the twin cities in Minnesota and regularly use the state??s network and wanted to get my thinking straight regarding the following issues.?ÿ I found that I hit some roadblocks trying to explain this to people.
A number of years back I contacted an individual at the state to inquire about how the system worked.?ÿ He told me that the network generates a VRS which acts as the base station.?ÿ I was wondering why, in the Trimble software, a base point appears at a known mount point typically miles away from a survey.?ÿ Shouldn??t the software generate a point where the VRS is located, since that is the base??ÿ He did not have an answer for me other than that is just the way the Trimble software works.?ÿ Does other software do the same thing??ÿ
Also, when the system switches to a new base and has to reconnect, I assume that this means a new VRS is being generated.?ÿ Why then is another base point at a different mount point displayed??ÿ Technically these are mount points and not the actual base point(s), right??ÿ That would mean adjusting the baselines from the Trimble report would be meaningless, never mind the lousy network geometry.
When doing least squares baseline adjustments with a static operation or an RTK operation using your own base station and not CORS/VRS, the baselines are essentially point to point and roughly within the realm of the site that you are working on.?ÿ This does not seem to be the case with the CORS in my mind.?ÿ The base lines are all radiating from the mount point(s) miles away in most cases and not from the VRS, which should be the actual base point and somewhat close to the site you are working on, right?
Another thing I noticed is that if you apply the deltas (xyz) between a mount point and any measured point, there is a transformation error of some kind.?ÿ What causes that??ÿ It seems like I should be able to back calculate the GPS baselines from a Trimble report and find a location as I can with the total station data, but that does not seem to be the case.?ÿ This occurs when applying a least squares to the baselines as well, obviously it??s just using the report, but it seems that there is some missing data there.
Any clarification would be appreciated, Thanks.
I was wondering why, in the Trimble software, a base point appears at a known mount point typically miles away from a survey.?ÿ Shouldn??t the software generate a point where the VRS is located, since that is the base??ÿ He did not have an answer for me other than that is just the way the Trimble software works.?ÿ
That's the way VRS software, not necessarily Trimble, works. There's a good article, although a little dated, that delves into the various processing methods for network RTK, located here.
From that article: "Today, the most widely used server-centric approach is the Virtual Reference Station (VRS*) method. A common misconception of VRS technology is that it is not tied to anything physical. In reality, however, all data is tied with vectors back to the nearest physical reference station. As this method archives modeling information and raw data, the data can be easily re-created with post-processing methods."
Also, when the system switches to a new base and has to reconnect, I assume that this means a new VRS is being generated.?ÿ Why then is another base point at a different mount point displayed??ÿ Technically these are mount points and not the actual base point(s), right??ÿ
Most likely you have moved far enough from the previous VRS session that a new set of error corrections must be modelled by the network.
Mountpoints can be whatever the network operator chooses for them. Around here, we have single base mountpoints and network mountpoints. Either way, there is a vector tie to the physical base stations involved in the calculations, whether that comes from a modelled multistation solution, or a single base solution.
That would mean adjusting the baselines from the Trimble report would be meaningless, never mind the lousy network geometry.
I'm not sure what you mean by "lousy network geometry". If you are getting a VRS solution, presumably you are located at a point where the server can compute reliable error corrections based upon stations located all around your rover. That's good geometry. NRTK vectors flowing from base stations far away can still be adjusted without problems, as long as you have redundancy and field procedures are good.
This does not seem to be the case with the CORS in my mind.?ÿ The base lines are all radiating from the mount point(s) miles away in most cases and not from the VRS, which should be the actual base point and somewhat close to the site you are working on, right?
Well, you said above that you wanted to adjust your data. If the software generated a true "virtual" reference station from which vectors flow, how would you compare those observations to another day's observations where the VRS "base station" is in a totally different place? And since there's no existing physical point for either of those base stations, how can you prove out your solutions, or go back and tie into them again?
The fact that the vectors are longer than typical base/rover work don't invalidate them. The vector quality is determined by the network and your rover in tandem. Tying them to a physical base station makes quality control and adjustments far easier.
If a VRS station was generated at your immediate site location, your vectors would have the same raw positional quality as those flowing from one of the physical base stations (data from which were used to compute those statistics anyways).
Another thing I noticed is that if you apply the deltas (xyz) between a mount point and any measured point, there is a transformation error of some kind.?ÿ What causes that??ÿ It seems like I should be able to back calculate the GPS baselines from a Trimble report and find a location as I can with the total station data, but that does not seem to be the case.?ÿ This occurs when applying a least squares to the baselines as well, obviously it??s just using the report, but it seems that there is some missing data there.
If you are talking about the values in the "observed data" screen, those XYZ deltas are ECEF, not grid values. You would end up with ECEF values for the endpoint, which you would then have to convert to curvilinear geodetic coordinates (LLh) or projected grid coordinates.
I think what jessej is noting is that the VRS solution incorporates error modeling that isn't available to the single-base vector, and may not actually be recorded in the raw data.?ÿ (I've never tried to pick apart a Trimble raw data file to see if that data is there, but I wouldn't know how to make use of it if it is.)?ÿ I do know that when I've used Trimble single-base RTK vectors in adjustments I've found that the resulting positions differ from the VRS positions by insignificant amounts.
@jim-frame The network will reduce ionosphere uncertainty from 1 ppm to 0.5 ppm, but yes you are actually using one of the CORS in the system and a "virtual" base station is not created near you.?ÿ And "insignificant" amounts is always relative to what you are locating or mapping, e.g. property monument vs. ground elevation observation.
Thanks for the responses.?ÿ So the VRS point is NOT a base point and has more to do with modeling errors from multiple mount points. The corrections are sent to the rover and the nearest base/mountpoint as a way of locking the baseline onto something physical.?ÿ
As this method archives modeling information and raw data, the data can be easily re-created with post-processing methods.?ÿ
and
The vector quality is determined by the network and your rover in tandem. Tying them to a physical base station makes quality control and adjustments far easier.
...is saying that the quality control data stored in my Trimble report is the modeling information and raw data and the baseline from the nearest mount point to my rover point is legit, making the geometry usable?
As far as redundancy, that is still a little confusing since all the baselines are emanating from the same point, it is not like your looping through your control back to the beginning; there are no baselines between my individual rover obs.?ÿ Would tying these points together conventionally be the best way to go to ensure redundancy??ÿ I generally only use my GPS with the network and I am looking for a way to cross check my RTK points.
Jim was correct below about the transformation question.?ÿ I had 0.03' difference on my y coordinate when I did the math myself vs what the report said and was wondering if it was due to data that wasn't contained in the report or data from the CORS or Trimble software that I can't get access to, or maybe I missed a step.
Thanks
So the VRS point is NOT a base point and has more to do with modeling errors from multiple mount points.
I have very little experience with networks but am curious about them and have done a little googling... my understanding is that the network sticks the VRS in the ballpark of your rover to 'trick' (for lack of a better term) the rover into using the proper correction algorthims.?ÿ Since the baseline from the CORS to the rover is potentially much longer than the baseline from a physical base to the rover would be this would result in greater error in your measurements.?ÿ If the rover thinks your base is right down the road though then this problem is handled.
I haven't been able to figure out what a mount point is though.?ÿ Is it synonymous with VRS?
I haven't been able to figure out what a mount point is though.
A mount point is the remote base point that anchors your RTK vector.?ÿ Sometimes referred to as CORS or reference station.
my understanding is that the network sticks the VRS in the ballpark of your rover to 'trick' (for lack of a better term) the rover into using the proper correction algorthims.
That's essentially the case, although it's not really "tricking" the rover so much as using its position to more accurately model iono/atmospheric errors and generate appropriate corrections for its location. That location is what will show up as the virtual base station if your rover is configured to generate one.
The critical benefit, as @RobertUSA mentioned, is that the modelling tends to be more robust and can really get those atmospheric errors down to tighter specs because the server is crunching the numbers from every base station in the area.
As far as redundancy, that is still a little confusing since all the baselines are emanating from the same point, it is not like your looping through your control back to the beginning; there are no baselines between my individual rover obs.?ÿ Would tying these points together conventionally be the best way to go to ensure redundancy??ÿ I generally only use my GPS with the network and I am looking for a way to cross check my RTK points.
If all you are running is RTK, cross checks are best done using different satellite constellations. Waiting even just a short bit and re-observing will get you a good independent check.
I have all my crews hit every critical point with a 1-minute observation, rotate the pole 180 degrees, do another 1-minute observation, average and store. Move on to the next one, keep on going until you've hit all the critical points. Then go back to the beginning and do it again - enough time will have elapsed for the constellation to have changed and the subsequent measurements be independent enough for a good check. Especially with the newer receivers that do not rely upon fixed/float algorithms.?ÿ
And to be fair, network RTK has the same limitations as base/rover RTK in that you are not technically running the line between control points or monuments, and relying upon indirect measurement of the mark-to-mark vector. You could run static to do that, or use the total station.
Tying things together with the total station is always going to help. I mix static, RTK, NRTK and TS observations all the time. As long as your procedures are good and your standard errors are realistic, a least squares analysis will weight the GNSS vectors and TS observations appropriately and give you much better estimate of where the points lie.
?ÿ
@jim-frame this is not all the information about mount points. My state??s RTN has several mount point choices for different equipment, constellations, for farmers (instead of land surveying/positioning since more farmers use it than surveyors), coordinate system, etc.
Understood, I was simplifying.