Settings for VRS RTK using Trimble R12 and Access
Quote from Eddie on August 15, 2024, 2:42 pmI work for a County roads department in upstate South Carolina. We recently purchased a Trimble R12 rover and have it set up to obtain corrections from the SCRTN (South Carolina Real Time Network). I'm running Access on a TDC600 containing a SIMM card supplied by Data Activation Center. The hardware is running fine, I have no trouble connecting to the SCRTN correction service and collecting data. My problem has to do with the coordinates of the points I collect using this VRS RTK rover setup. The points are consistently shifted roughly 4 feet versus checkpoints determined from observations obtained with my TOPCON Hiper Plus and OPUS. Oddly enough, the point elevations are pretty close. I've specified US NAD 83 for the coordinate system, South Carolina 3900 for the zone and GEIOD 18 for the geoid model. But I'm obviously missing something major in my Access settings to account for the 4' point shift. I need guidance from someone that understands this better than me. Thanks for your help. -Ed
I work for a County roads department in upstate South Carolina. We recently purchased a Trimble R12 rover and have it set up to obtain corrections from the SCRTN (South Carolina Real Time Network). I'm running Access on a TDC600 containing a SIMM card supplied by Data Activation Center. The hardware is running fine, I have no trouble connecting to the SCRTN correction service and collecting data. My problem has to do with the coordinates of the points I collect using this VRS RTK rover setup. The points are consistently shifted roughly 4 feet versus checkpoints determined from observations obtained with my TOPCON Hiper Plus and OPUS. Oddly enough, the point elevations are pretty close. I've specified US NAD 83 for the coordinate system, South Carolina 3900 for the zone and GEIOD 18 for the geoid model. But I'm obviously missing something major in my Access settings to account for the 4' point shift. I need guidance from someone that understands this better than me. Thanks for your help. -Ed
Quote from jimcox on August 15, 2024, 5:09 pmPretty much certain to be a coordinate system issue
What coordinate system are you using?
What coordinate system is the VRS running on?
You can probably get around the problem using a site calibration on known points
-- later
I've had a quick dig
I see SCRTN uses Trimble receivers - this suggests it is also using the Trimble standard definition for SC 3900 - which turns out to be NAD83(2011) - a time dependant transformation with a 2010 reference epoch .
I've had a look at Opus, but could not confirm if its numbers are straight NAD83 or NAD83(2011)
The size of the shift you are seeing suggests it might be the former...
Pretty much certain to be a coordinate system issue
What coordinate system are you using?
What coordinate system is the VRS running on?
You can probably get around the problem using a site calibration on known points
-- later
I've had a quick dig
I see SCRTN uses Trimble receivers - this suggests it is also using the Trimble standard definition for SC 3900 - which turns out to be NAD83(2011) - a time dependant transformation with a 2010 reference epoch .
I've had a look at Opus, but could not confirm if its numbers are straight NAD83 or NAD83(2011)
The size of the shift you are seeing suggests it might be the former...
Quote from davidgstoll on August 16, 2024, 3:28 amHi Eddie,
In Greenville, South Carolina, State Plane coords, the difference between US Survey Feet and International Feet is just under 4'.
The shift will be to either the Southwest or Northeast.
Dave
Hi Eddie,
In Greenville, South Carolina, State Plane coords, the difference between US Survey Feet and International Feet is just under 4'.
The shift will be to either the Southwest or Northeast.
Dave
Quote from Eddie on August 16, 2024, 4:30 amDave,
Thanks for that information. Do you suggest that I set up my Access job using International Feet in lieu of US Survey Feet?
Below, are the settings for SELECT COORDINATE SYSTEM in my Access job:
System: US NAD 83, Zone: South Carolina 3900, Local Datum: NAD 83 (2011) (Mol), Global Reference Datum: NAD 83 (2011), Global Reference Epoch: 2010.00, Displacement Model: HTDP V3.4.0, Use Geoid Model: YES, Geoid Model: GEOID18 (Conus) (g18us.ggf), Use Datum Grid: NO, Coordinates: Grid, Project Height: 900sft
Dave,
Thanks for that information. Do you suggest that I set up my Access job using International Feet in lieu of US Survey Feet?
Below, are the settings for SELECT COORDINATE SYSTEM in my Access job:
System: US NAD 83, Zone: South Carolina 3900, Local Datum: NAD 83 (2011) (Mol), Global Reference Datum: NAD 83 (2011), Global Reference Epoch: 2010.00, Displacement Model: HTDP V3.4.0, Use Geoid Model: YES, Geoid Model: GEOID18 (Conus) (g18us.ggf), Use Datum Grid: NO, Coordinates: Grid, Project Height: 900sft
Quote from OleManRiver on August 16, 2024, 6:07 amSounds like international feet bs is survey foot for South Carolina to me. Make sure in Trimble access in units are set to feet not us foot. To truly check just use the meters at first and see if you still have the shift. If not then that’s the issue. If you still see the shift. I remember a long time ago that topcon has a setting called wgs84 no trans. That not being set caused issues when topcon recovers ran on a non topcon network.
Sounds like international feet bs is survey foot for South Carolina to me. Make sure in Trimble access in units are set to feet not us foot. To truly check just use the meters at first and see if you still have the shift. If not then that’s the issue. If you still see the shift. I remember a long time ago that topcon has a setting called wgs84 no trans. That not being set caused issues when topcon recovers ran on a non topcon network.
Quote from davidgstoll on August 16, 2024, 6:54 amEddie,
It's been a decade since I last used Access, so I don't know what coordinate systems are available these days.
I'd go with EPSG:6570 NAD83(2011)/South Carolina(ft) if it's available in your data collector. All the cool kids are going to International Foot units.
Dave
Eddie,
It's been a decade since I last used Access, so I don't know what coordinate systems are available these days.
I'd go with EPSG:6570 NAD83(2011)/South Carolina(ft) if it's available in your data collector. All the cool kids are going to International Foot units.
Dave
Quote from lurker on August 16, 2024, 9:20 amEddie as others have said, you are using US feet in your data collector while South Carolina operates on international feet.
For the purposes of the South Carolina Coordinate System, the foot is the International Foot with one inch being exactly equal to 2.54 centimeters.
Eddie as others have said, you are using US feet in your data collector while South Carolina operates on international feet.
For the purposes of the South Carolina Coordinate System, the foot is the International Foot with one inch being exactly equal to 2.54 centimeters.
Quote from Eddie on August 16, 2024, 10:45 amYes, that certainly explains the cause of my X-Y coordinate shift issue, so I'll make the change to IFT. Do I also need to set up Access to use IFT for ELEVATIONS? Thanks for your help, -Ed
Yes, that certainly explains the cause of my X-Y coordinate shift issue, so I'll make the change to IFT. Do I also need to set up Access to use IFT for ELEVATIONS? Thanks for your help, -Ed
Quote from davidgstoll on August 17, 2024, 12:19 amSassafras Mountain, in the Blue Ridge Mountains, is the highest point in the state of South Carolina. Elevation 3554'.
The difference in elevation there between the 2 foot units, 2ppm(*0.000002) is only 0.007'.
I might be wrong, but I think elevation units are always going to be same as the horizontal units when you select a coordinate system.
Dave
Sassafras Mountain, in the Blue Ridge Mountains, is the highest point in the state of South Carolina. Elevation 3554'.
The difference in elevation there between the 2 foot units, 2ppm(*0.000002) is only 0.007'.
I might be wrong, but I think elevation units are always going to be same as the horizontal units when you select a coordinate system.
Dave