We are running SRX3 with a Tesla, Topcon Magnet field. On most projects with this combination we are getting 0.06 difference between our foresight and backsight distances. We spent several hours testing yesterday. We identified one bad glass and one bad radio unit adapter, but nothing approaching 0.06 feet.
Looking through the data collector configuration and raw data revealed no setting errors. A manual calculation using the raw data shows there is indeed a 6 hundredths difference.
If the errors were random this could be chalked up to something broken or an operator needing glasses. It is very consistent. We only use one type of glass and the prism constant is correctly set.
Any ideas?
> Any ideas?
It's not clear to me whether or not you've tried shooting both BS and FS with the same prism. If not, that'd be the first thing I'd try.
I once had a gun that was consistently 0.04' off. It was an issue with the electronics, a new "board" was the fix.
But 0.06 also feels like a state plane/ground issue. Is you coordinate system set to state plane while you are doing these tests?
Have you taken it to a calibration baseline lately?
You state that the prism constant is correctly set. Have you checked in Magnet to be sure that the prism constant is set to the same value for both Foresight P.C. and Backsight P.C.? I use a Topcon A7-360° prism for most of my work but I will on occasion use a round prism for a fixed backsight. The A7 is a -2mm offset and the round prism is a -30mm. Sometimes I forget to change the backsight P.C., and sometimes I make the change but something goes wrong between the DC and the instrument and the change does not happen at the instrument. When I see a .10 backsight bust, I immediately know what the problem is. The right combination of foresight and backsight prism constants could easily give you a .06 bust.
We have used the same prism for and back with the same result.
This error is between distances within the same file. Shoot forward and get 500 feet. Move ahead and shoot back you get 500.06. It happens in State Plane, LDP and total station only projects.
All of our glass is -7 offset. We tested every one and got no variation except one badly damaged glass. The difference was still nothing close to what we have been experiencing.
In Magenta Office the offset for each observation is the same...
We use a Topcon DS robotic which is basically a sokkia gun . We had the same issue .06' and did a bunch of testing last week , we are using Carlson . All prism setting getting sent to gun correctly . I started reading through the DS manual and found that the edm in tracking mode is .10' /1/2" (this is out of the manual, not sure how .10' is equal to 1/2") tolerance, as soon as we went to Fine or Rapid edm setting the .06' went away .
If the only variable is that one shot is taken as a foresight and the other is taken as a backsight, then regardless of what the file says, something has to be messing with your prism constants.
Set two points, occupy one and backsight and store the second point, then without moving the instrument or backsight prism, shoot the backsight as a sideshot. If you're still seeing .06 between the backsight and sideshot then either the backsight prism constant is wrong or the software has a bug in it. For what it' worth, 30mm-7mm=23mm=.075'......awful close to the error you're seeing.
TBM,
Did you try the basic stuff first, like checking the plummet on both the instrument and backsight tribrachs?
Dave
Have you checked the optical plummets? If using a tribrach and target, is the optical plummet and level bubble adjusted properly? Is the gun level all the way around? Are you using a prism rod to set the control/back sighting? Is the rod plumb? Have you set a point 100' away and check it with a steel tape?
if you have eliminated all the basic hardware and human errors:
did you try this without the data collector?
are you reading raw slope distances and raw vertical angles?
so far I am wild guessing the is some software messing up your data...
Is it 0.06' in 50 feet as well as 0.06' off in 500'?
We performed the tests with and without a data collector. The error is the same at 15 feet as it is at longer distances. We have proven it is a constant rather than scale...
I love a good puzzle right up to the point it interferes with making money doing good work...
Let me get this straight:
You measure a distance to a foresight; take the instrument out of the tribrach; swap it out with the prism you used for the foresight; place the instrument into the tribrach you had at the foresight; measure the distance back to the same prism, in the tribrach you took the instrument out of and the distance is 0.06' different?
Sounds like it could be the instrument. Did you try measuring with a different instrument? Checking your instrument at a calibrated baseline?
0.06' is A LOT! I mean, it's half again as much as 0.04' lol
Doug
We had an SRX3 with similar problem.
The boss managed to speak with someone at Sokkia Singapore who told him the right button presses to get into the menu that is usually only accessible to the service people.
There was some scale setting in there that he adjusted and it was fine from then on.
I really feel that you have to be right about this.
I could swear we had this kind of problem with Topcon in the past.
If I remember correctly, the backsights were off by about that amount but if you then staked to the point it was hitting dead on.
So, it appeared that it was collecting the point correctly but just not providing correct backsight check information.
Sounds like you have this issue outside of the Topcon program also so you may not be experiencing the same problem we were.
The first thing I would do is make your own 2 point baseline with a known instrument. That way you know what the correct distance is. Use a chain if you have to. Then try just the instrument. Once you are sure that is correct do it with the data collector. At some point you will narrow it down to some piece of equipment or setting.
Thanks - we are not currently having that issue but I do remember that outside of the Topcon survey program (in regular old fashioned measure mode) we did not see this problem so it was a component of the software not behaving.