I did a pretty basic and unscientific test today but the results were a bit perplexing.
Trimble R8 & Leica GS16, all QC settings identical, 325 observations @ 1sec.
Set the R8 on tripod ran a session on the NYSDOT NYSnet network (RTCMv3 NearSite) stopped survey and started a session on the KeyNet VRS without touching R8.
Gently popped off R8 and set on GS16 (quick release bayonets)
Ran GS16 on NYSnet (RTCMv3 NearSite) with same mount point as with the R8.
GS16 & R8 NYSNet results were within 0.03'H & 0.02'V which I didn't think so bad but this is where it made me think twice. When comparing the KeyNet VRS (R8) to NYSnet ( R8 & GS16) the difference was 0.02'H but 0.283'V.
Why would the elevation be so different on the different networks? I'm now second guessing the KeyNet in my area.
Why did you use mount point for nearest site in NYSNET? Why not use GGD Max RTCM to gain atmosphere correction?
How far are you from each base?
Did you use the same GEIOD?
Check the datum of each base. I would get 24 hour static from each base you used, send it to OPUS, compare the Ell HT from your DC raw data.
I used NearSite because the whole the GS16/Captivate can run MAX I don't believe it's an option on the R8/SurveyController so NearSite was just to keep it all constant. Both collectors have 12a.
I connected to the same base with R8 & GS16, about 5mi away. This was all done in about an hours tike this morning.
The above is not the issue so much as the R8 & GS16 gave me very similar results on NYSNet. The big variable is why the R8 gave such drastic vertical deviations with NYSNet compared toe KeyNet VRS.
leegreen, post: 416890, member: 2332 wrote: Why did you use mount point for nearest site in NYSNET? Why not use GGD Max RTCM to gain atmosphere correction?
How far are you from each base?
Did you use the same GEIOD?
Check the datum of each base. I would get 24 hour static from each base you used, send it to OPUS, compare the Ell HT from your DC raw data.
I use NYSNET with Sokkia, and Topcon equipment all over NY from Buffalo to Long Island and I never trust elevations. I often measure only one RTN location on a project. Then set my base on that, now RTK from there, while collecting static at the same point. I then will adjust to the static location, which is often 0.15' or more different in elevation. I also notice that OPUS-RS is just as bad as the RTN at elevations. With GNSS equipment, I only see good vertical redundancy with long static sessions and/or short RTK baselines.
Why not check to see what elevation number is correct?
MightyMoe, post: 416899, member: 700 wrote: Why not check to see what elevation number is correct?
That's what I'd like to do, not sure how in my yard though.
Luke J. Crawford, post: 416900, member: 11382 wrote: That's what I'd like to do, not sure how in my yard though.
The process I use for new Geoid models, new CORS, new epoch realizations is to set on elevation control and see the results. I have one leveled in the driveway at the office, which is a start to the process. If you have elevation control in the area, then it's important, I would say required, to know how it all works with GPS.
Checking both against an established BM is next. I was curious if there was a known issue with VRS vs a mount point.
MightyMoe, post: 416904, member: 700 wrote: The process I use for new Geoid models, new CORS, new epoch realizations is to set on elevation control and see the results. I have one leveled in the driveway at the office, which is a start to the process. If you have elevation control in the area, then it's important, I would say required, to know how it all works with GPS.
Luke J. Crawford, post: 416905, member: 11382 wrote: Checking both against an established BM is next. I was curious if there was a known issue with VRS vs a mount point.
I probably should stay out of this discussion since there are no VRS or RTNs here, but I can say that when I send in a dat file to OPUS and the same file to the Trimble service I get quite a difference in elevations and the Trimble one is always closer, so I use it instead of OPUS.
MightyMoe, post: 416907, member: 700 wrote: I probably should stay out of this discussion since there are no VRS or RTNs here, but I can say that when I send in a dat file to OPUS and the same file to the Trimble service I get quite a difference in elevations and the Trimble one is always closer, so I use it instead of OPUS.
I have found the same thing.
Javad has their own opus too. It's called DPOS.
I'm curious about differences too...
Run long static session, then post process yourself. Download static data from both the systems. Use interactions to constrain one system, to check the other.
For vertical I find it best to constrain the closest station. 60 miles baselines, not so good for heights.
Here is the datum statement from NYSNET:
Horizontal: Prior to November 4, 2012, NYSDOT CORS positions are based on the North American Datum of 1983, CORS adjustment, NAD83 (CORS96) (EPOCH 2002.0). After November 4, 2012, NYSDOT CORS positions are based on the North American Datum of 1983, NA2011 adjustment, NAD83 (2011) Epoch 2010.00. Users must take special note that CORS defined in NAD83 (2011) use absolute antenna calibrations. Absolute values should be used when processing data with CORS coordinates in NAD 83(2011) EPOCH 2010.0 When surveying on local coordinates systems, including prior adjustments of NAD83, the user must determine the appropriate connections to these coordinate systems.
Vertical: Heights produced from this network are related to the reference ellipsoid for NAD83, GRS80. NYSDOT CORS are not directly connected to the North American Vertical Datum of 1988 (NAVD88), an orthometric height system. NGS does produce GEOID models for transforming heights between ellipsoidal and orthometric heights. Users should be aware of the accuracy of these models. Depending upon required survey accuracy, the user must determine required connections to local vertical datum, including NAVD88. NA2011 yields ellipsoid heights that are inconsistent with GEOID09; therefore, GEOID12B should be used if transforming ellipsoidal heights to NAVD88 heights.
KEYNET does not have datum statement on their website. At more than $3000 per year subscription, one would certainly hope it is good.
KeyNetGPS offers 30 day subscriptions and yearly subscriptions. Our 30 day subscription rate is $375 per subscription. Our yearly subscriptions start at $3135 (net 30) and $3300 if paid in monthly increments of $275/month. Note for the monthly increments we require a credit card to be on file. To begin the process of purchasing a subscription you will need to register at http://vrs.keynetgps.com or click on the VRS Register link found at www.keynetgps.com
We've had KeyNet for 3+ years, no complaints thus far. We made a switch to Leica TPS & GPS and figured we'd try out the DOT because it's free.
leegreen, post: 416941, member: 2332 wrote: Here is the datum statement from NYSNET:
Horizontal: Prior to November 4, 2012, NYSDOT CORS positions are based on the North American Datum of 1983, CORS adjustment, NAD83 (CORS96) (EPOCH 2002.0). After November 4, 2012, NYSDOT CORS positions are based on the North American Datum of 1983, NA2011 adjustment, NAD83 (2011) Epoch 2010.00. Users must take special note that CORS defined in NAD83 (2011) use absolute antenna calibrations. Absolute values should be used when processing data with CORS coordinates in NAD 83(2011) EPOCH 2010.0 When surveying on local coordinates systems, including prior adjustments of NAD83, the user must determine the appropriate connections to these coordinate systems.
Vertical: Heights produced from this network are related to the reference ellipsoid for NAD83, GRS80. NYSDOT CORS are not directly connected to the North American Vertical Datum of 1988 (NAVD88), an orthometric height system. NGS does produce GEOID models for transforming heights between ellipsoidal and orthometric heights. Users should be aware of the accuracy of these models. Depending upon required survey accuracy, the user must determine required connections to local vertical datum, including NAVD88. NA2011 yields ellipsoid heights that are inconsistent with GEOID09; therefore, GEOID12B should be used if transforming ellipsoidal heights to NAVD88 heights.
KEYNET does not have datum statement on their website. At more than $3000 per year subscription, one would certainly hope it is good.
KeyNetGPS offers 30 day subscriptions and yearly subscriptions. Our 30 day subscription rate is $375 per subscription. Our yearly subscriptions start at $3135 (net 30) and $3300 if paid in monthly increments of $275/month. Note for the monthly increments we require a credit card to be on file. To begin the process of purchasing a subscription you will need to register at http://vrs.keynetgps.com or click on the VRS Register link found at www.keynetgps.com
leegreen, post: 416894, member: 2332 wrote: I use NYSNET with Sokkia, and Topcon equipment all over NY from Buffalo to Long Island and I never trust elevations. I often measure only one RTN location on a project. Then set my base on that, now RTK from there, while collecting static at the same point. I then will adjust to the static location, which is often 0.15' or more different in elevation. I also notice that OPUS-RS is just as bad as the RTN at elevations. With GNSS equipment, I only see good vertical redundancy with long static sessions and/or short RTK baselines.
Contact me about your troubles with OPUS-RS and elevation. I did all my beta testing of the OPUs-RS engine, RSGPS, using the NY DOT network plus one PA CORS. I still see no troubles with OPUS-RS elevations in my personal work area. I do note that some NYDOT sites are no longer publishing. Is this a general issue with NYDOT or do some county DOT offices just not care?
In general elevation issues could be with the antenna models and/or the Geoid models. Mixing absolute and relative antenna models can make differences that are hard to spot. One check is to reoccupy with your antenna/receivers swapped.
Paul in PA
Luke J. Crawford, post: 416944, member: 11382 wrote: We've had KeyNet for 3+ years, no complaints thus far. We made a switch to Leica TPS & GPS and figured we'd try out the DOT because it's free.
Paul in PA, post: 416961, member: 236 wrote: Contact me about your troubles with OPUS-RS and elevation. I did all my beta testing of the OPUs-RS engine, RSGPS, using the NY DOT network plus one PA CORS. I still see no troubles with OPUS-RS elevations in my personal work area. I do note that some NYDOT sites are no longer publishing. Is this a general issue with NYDOT or do some county DOT offices just not care?
In general elevation issues could be with the antenna models and/or the Geoid models. Mixing absolute and relative antenna models can make differences that are hard to spot. One check is to reoccupy with your antenna/receivers swapped.
Paul in PA
Most CORS in NY state are Lieca GNSS operated by NYSDOT, not county.
In my experience the expected vertical accuaracy derived with GNSS has been in this order best to worst.
1). Static GNSS posted processed my self with Magnet Office
2). OPUS w/ 2-4 hours Static
3). RTK using my own base less than 2 miles w/ 180 epochs and repeat 20 miniutes later
4). OPUS-RS with 1-2 hours Static
5). RTN or VRS
leegreen, post: 416966, member: 2332 wrote: Most CORS in NY state are Lieca GNSS operated by NYSDOT, not county.
In my experience the expected vertical accuaracy derived with GNSS has been in this order best to worst.
1). Static GNSS posted processed my self with Magnet Office
2). OPUS w/ 2-4 hours Static
3). RTK using my own base less than 2 miles w/ 180 epochs and repeat 20 miniutes later
4). OPUS-RS with 1-2 hours Static
5). RTN or VRS
Luke J. Crawford, post: 416967, member: 11382 wrote:
I just ran both networks on the R8 on NGS LX1309. NYSNet got me within .06', KeyNet was .12'. Those sessions were back to back without moving the receiver.
leegreen, post: 416941, member: 2332 wrote: Here is the datum statement from NYSNET:
Horizontal: Prior to November 4, 2012, NYSDOT CORS positions are based on the North American Datum of 1983, CORS adjustment, NAD83 (CORS96) (EPOCH 2002.0). After November 4, 2012, NYSDOT CORS positions are based on the North American Datum of 1983, NA2011 adjustment, NAD83 (2011) Epoch 2010.00. Users must take special note that CORS defined in NAD83 (2011) use absolute antenna calibrations. Absolute values should be used when processing data with CORS coordinates in NAD 83(2011) EPOCH 2010.0 When surveying on local coordinates systems, including prior adjustments of NAD83, the user must determine the appropriate connections to these coordinate systems.
Vertical: Heights produced from this network are related to the reference ellipsoid for NAD83, GRS80. NYSDOT CORS are not directly connected to the North American Vertical Datum of 1988 (NAVD88), an orthometric height system. NGS does produce GEOID models for transforming heights between ellipsoidal and orthometric heights. Users should be aware of the accuracy of these models. Depending upon required survey accuracy, the user must determine required connections to local vertical datum, including NAVD88. NA2011 yields ellipsoid heights that are inconsistent with GEOID09; therefore, GEOID12B should be used if transforming ellipsoidal heights to NAVD88 heights.
KEYNET does not have datum statement on their website. At more than $3000 per year subscription, one would certainly hope it is good.
KeyNetGPS offers 30 day subscriptions and yearly subscriptions. Our 30 day subscription rate is $375 per subscription. Our yearly subscriptions start at $3135 (net 30) and $3300 if paid in monthly increments of $275/month. Note for the monthly increments we require a credit card to be on file. To begin the process of purchasing a subscription you will need to register at http://vrs.keynetgps.com or click on the VRS Register link found at www.keynetgps.com
Both of my units have 12a loaded, don't niece 12b is yet avaliable for Captivate. Unsure about Survey Controller.
Luke J. Crawford, post: 416969, member: 11382 wrote: Both of my units have 12a loaded, don't niece 12b is yet avaliable for Captivate. Unsure about Survey Controller.
In your part of the world, 12, 12A and 12B are identical. If Captivate works like all the other Leica field software, you create a "field" geoid model from the NGS geoid models and upload it. I finally did that with 12B although 12A was the same where I work, it just gets less arguments from those saying you aren't using the current model. The field version just cuts it down to size, that is how the older SmartWorx is I have.
SHG