OKAY, so we have two R10 setups that we have been using in VRS with TSC3's and Trimble access. We are finding that one setup (Lets say system B) is giving us incorrect data by 3-4 feet horizontal and vertical. We have a control loop at our office and system "A" provides accurate results. I paired the controller from system "A" with the rover head of system B and the results are correct. Therefore it is my assumption that the rover head of system "B" is good and something is awry somewhere in the depths of the system "B" controller. The first thing I checked was the zone and they are the same. The error was found at three separate survey locations in three separate zones. Unlikely that the zones were incorrect there also. Anybody have any suggestions?
Thanks in advance
Go through all the survey styles and unit settings, US feet and international feet is one place to look, although that could give you the 3-4 feet in XY but only a small number in Z.
3' - 4' Hz and V sure sounds like the difference between ITRF/WGS84 and NAD83.
If I understand you correctly you have two R10s and two TSC3s and everything you're testing is with VRS. Is your VRS broadcasting the corrections in NAD83? Are the corrections CMR (+ or x) or RTCM (version?)?
If the two are running the same version of Access, copy the file from the good DC to the erroneous DC and try it again.
My opinion, it is the wgs84/nad83 issue like Lee said.
James
Suggestion:
Set them both up. Swap controllers. I doubt that its in the gps.
I think it's a setting in the controller.
(which may be sent to the gps, or, it may handle the data from the gps differently.
My 2 centavos...
N
Sounds like Lee D is on it. Check your datum /tranaformation...
We are using NAD83 State plane, same zone for both. Using same VRS network for both. The controller from the good systems works with the rover of the bad system( ...so I am thinking that the problem in in the controller of the bad system)
The reason I was asking about the broadcast format is that it's possible to select Broadcast RTCM as the coordinate system rather than Select From Library, but I would think that would be easy to spot. Depending on the Access version(s) they also have coordinate systems that transform ITRF to NAD83, you don't want to use that if the VRS corrections are already in NAD83.
thebionicman, post: 412652, member: 8136 wrote: Sounds like Lee D is on it. Check your datum /tranaformation...
OK so maybe I'm missing something. Is there a separate setting somewhere other than the job "properties" location for the datum/transformation setting?
What version(s) of Access?
Lee D, post: 412659, member: 7971 wrote: What version(s) of Access?
2013-20-5264
As previously suggested, check job units on the controller. Then under settings, connect, gnss contacts, verify the contact information, ip address and port #. Also verify the mount point name if it is said to connect directly.
Then in the survey style, edit rover options, and verify the broadcast format matches for the port.
Good luck, and let us know if you find a solution.
I don't mean to demean you but are you positive that both coordinate systems are set on the null NAD83 system and not NAD83 (2011)?
If the Access versions are identical, try copying the job from the controller giving you bad results to the one giving you good results; open it and see if you get good or bad results.
Sounds similar to a Topcon error I was seeing a couple years ago. You have set that to NAD83 No transformation or it would correct the already corrected network data.
Sent from my iPhone using Tapatalk
Other things to check would the the ground scale factor if you have "Ground (keyed in... " selected on the second page and the false north and east on the last page.
Lee D, post: 412666, member: 7971 wrote: I don't mean to demean you but are you positive that both coordinate systems are set on the null NAD83 system and not NAD83 (2011)?
No insult taken. They are both US State Plane 83, and same state zone.
Like Lee said, make sure they do NOT say (2011)
Are these TSC3s new (to you)? Wondering if someone went in and changed the parameters of the coordinate system. Unlikely, but possible.
I'd say check your geoid model also, but it seems this would just cause a vertical problem.