NAD83 2011 survey controller tsc2

I am not sure about the cost, but what about this...

http://www.trimble.com/positioning-services/vrs-now.aspx

Unfortunately I work in remote areas all over the US and lots of times I have no cell service.

I am guessng it is not possible to add datums to the data collector?

You create a WAAS enabled at the rover survey style and it will apply the necessary transformation to the coordinate system as defined by your project.

The NAD83 (2011) coordinate systems in Trimble DCs were for when you were using VRS and the reference station coordinates were broadcasting their ITRF position. This coordinate system was 7 parameter (if I remember correctly), and broke down like this in TBC:

global - ITRF lat/lon/ht
local - NAD83 lat/lon/ht
grid - nad83 N,E,El

Trimble didn't do a great job of communicating the purpose for the nomenclature of this coordinate system at the DC end, and a lot of people thought "well now that my CORS and OPUS have went to 2011 realization this is what I should be using", wrongo because most RTN systems broadcast from the NAD83 lat/lon. Hopefully most people knew something was wrong when they went to check against existing and were busting by a meter+.

I don't know if the DC knows by default that WAAS is ITRF (disclaimer, I don't know much about WAAS and cannot verify if it is ITRF, it's probably more likely WGS84 (same difference pretty much)), but I would guess that it does. The problem is that it's hard to check in on the fly and be comfortable that you have it set correctly because WAAS accuracy varies greatly. I have been on a project where I could find old (NAD 83) control within a meter. This was all one time, and at one time of day, so I may have caught a lucky constellation. Other projects, because of poor sky-view, I've seen it as bad as autonomous float, +/- 30'.

I think that a NAD83(2011) datum on your data collector would open the door for a double correction.

NAD83 is the datum, the 2011 is the realization. If you are running autonomous positions to begin with the risk would outweigh the reward in my mind.

http://www.intuicom.com/gps-gnss-products/rtk-bridge-c

If you do have cellular coverage within radio distance of your site the rtk intuitcom bridge should work as a nice realy to get the necessary RT correctors to you. in lieu of that a control point in the vicinity of the project with an OPUS derived position is your best bet.

I would request that your client give you a little more notice of the potential staking locations so you can establish the proper control in advance. Also, if they are deriving coordinates for your staking, they are either derived from GIS grade data or they actually have project control they aren't sharing with you. If they are using GIS grade data I don't see the point to attempt to deliver survey grade accuracy for the staking.

Drilldo - It is possible to add datums to the data collector, and it will tighten up your WAAS accuracy by about a meter in the Hz if you do so. Trimble added the NAD83(2011) datum to Access because satellite based correction services - including Trimble's own - are in ITRF. When they first implemented it they didn't do a good job of documenting or explaining it and people did use it where they should not have, like with VRS systems that were already broadcasting 2011 corrections - that is the instance in which you end up double correcting.

Trimble has since changed the name of the datum to ITRF to NAD83(2011), and when you examine it in Coordinate System Manager it is quite clear what its purpose is.

There are a couple of ways to go about this... if you have TGO or TBC you can create it in Coordinate System Manager and upload it via a CSD file. If you don't have PC software you can key in the transformation when you set up the job.

:good:

Compute the difference between the 2 realizations for your area. You will likely find that it amounts to nothing you can see...

agreed.

The difference I'm seeing between NAD83(CORS96)2002.000) and NAD83(2011)(2010.000) is .03'-.06'. Heck, my rod can be out of level that far......... 😉

Do not use NAD 83 2011 in Trimble collector. It applies a double correction. Use only the NAD83. If you base is using NAD 83 2011 coordinates, then your rover will recieve them.

> I would request that your client give you a little more notice of the potential staking locations so you can establish the proper control in advance. Also, if they are deriving coordinates for your staking, they are either derived from GIS grade data or they actually have project control they aren't sharing with you. If they are using GIS grade data I don't see the point to attempt to deliver survey grade accuracy for the staking.

I design the staking locations. We typically have a 3D grid with points in a line say 100' apart and lines 500' apart. Their relative positions to each other (ie they fall exactly on the grid) and the elevations are important. If the entire grid is moved a few feet it isn't the end of the world in our application but I want to try and get as close as possible.

We very rarely have the opportunity to set control in advance. Many of these projects are hundreds of miles from home. We drive to the site and start surveying and doing our testing simultaneously. The 6 guys doing the drilling, etc can't be sitting around waiting on a OPUS solution. Some projects are a one or two day deal and a separate trip to survey is not feasible.

We do however always collect static data for OPUS and correct our data to the OPUS solution so that the positions we include in our report are correct and can be duplicated. We are just trying to minimize these corrections

> Drilldo - It is possible to add datums to the data collector, and it will tighten up your WAAS accuracy by about a meter in the Hz if you do so. Trimble added the NAD83(2011) datum to Access because satellite based correction services - including Trimble's own - are in ITRF. When they first implemented it they didn't do a good job of documenting or explaining it and people did use it where they should not have, like with VRS systems that were already broadcasting 2011 corrections - that is the instance in which you end up double correcting.
>
> Trimble has since changed the name of the datum to ITRF to NAD83(2011), and when you examine it in Coordinate System Manager it is quite clear what its purpose is.
>
> There are a couple of ways to go about this... if you have TGO or TBC you can create it in Coordinate System Manager and upload it via a CSD file. If you don't have PC software you can key in the transformation when you set up the job.

Thanks. This is what I am looking to do. I do have TBC but I am not very proficient with it. I will see if I can figure it out.

That makes sense.

> agreed.
>
> The difference I'm seeing between NAD83(CORS96)2002.000) and NAD83(2011)(2010.000) is .03'-.06'. Heck, my rod can be out of level that far......... 😉

I am not concerned about the differences between the realizations. From what I understand the Trimble NAD83 (2011) which has been renamed to ITRF to NAD83 is doing something different. I only want to do this to convert WAAS data which I believe is ITRF to NAD83 to improve the accuracy of setting up a base.

If you have TBC and it has the ITRF to NAD83 datum in the version you are running, open up the Coordinate System Manager, hide all the ones you don't care about, and save it as custom.csd. Put the custom.csd file in Trimble DataSystem Files on the controller and reboot it. When you restart SC and go to select your coordinate system it should only show the ones that you displayed in the custom.csd.

If your version of TBC is too old to contain the datum let me know, I'll send you the parameters and you can create it.

> Do not use NAD 83 2011 in Trimble collector. It applies a double correction. Use only the NAD83. If you base is using NAD 83 2011 coordinates, then your rover will recieve them.

I am not wanting to use it in that sense. I do all my projects in plain old NAD83.

I am thinking a new job called WAAS with the NAD83 (2011) or ITRF to NAD83 whatever Trimble calls it now. Set up the base and collect WAAS data and save a point.

Export the point as a CSV.

Create the job file you will use for the project in NAD83. Import the CSV and use these coordinates for the base.

It should be more accurate than simply doing a "here" or saving a WAAS point using regular NAD83.

I could be wrong though that is why I am asking.

Have you ever looked at the Seismic module for Trimble Access? It uses the GPSeismic files to create the grid and supports exclusion zones, offsets, etc.

> If you have TBC and it has the ITRF to NAD83 datum in the version you are running, open up the Coordinate System Manager, hide all the ones you don't care about, and save it as custom.csd. Put the custom.csd file in Trimble DataSystem Files on the controller and reboot it. When you restart SC and go to select your coordinate system it should only show the ones that you displayed in the custom.csd.
>
> If your version of TBC is too old to contain the datum let me know, I'll send you the parameters and you can create it.

I will check and see. My TBC surely has it I just bought the license this year.

I have not looked into the seismic module nor do I use GP seismic. While they have many nice features they are geared towards large projects and cost more than we can justify. We are a small operation. I do offsets just using azimuth and distance.

Use HTDP to compute the offset between the two.

https://www.ngs.noaa.gov/cgi-bin/HTDP/htdp.prl?f1=4&f2=1

Then, you have control over the transformation. I wouldn't trust the data collector transformation unless I was able to verify its results against something know.