I saw a bug in Trimble access this week that I have seen before, but since it is not possible to directly contact Trimble, I am posting it here hoping that it will be brought to their attention. When I saw it previously, I send a message to my dealer about it, but obviously it didn??t go anywhere. I have been using Trimble now for 36 years, and my biggest complaint about them is the lack of a direct method for reporting bugs and other issues.
A lot of our monitoring projects have sets of colinear points. I was on one this week that has a monument at each end and 18 alignment pins in between, nominally on the line. The distance between the monuments is 607 meters. I set up on the two endpoints and also on a point about halfway and observe each alignment pin using a total station, as well as three reference monuments off of the line. When I setup on the middle point, I backsight one monument at the end of the line and turn rounds to the monument at the other end. I always use grads, where 200g=180?ø. When doing these rounds, some readings to the far monument are slightly under 200g and others are slightly over. After each round, Access shows a results page with differences, which are usually around 0.1 to 0.3 milligrads. After the second or third round, I noticed the angle to the far monument came up on the summary as being many degrees off. I was doing 4 rounds, so I added another round, total 5. Here are the values observed (grads):
|
Standpoint |
Backsight |
Forepoint |
HI |
HT |
Angle Right |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
200.001494 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
199.999845 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
199.999726 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
199.998699 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
200.000516 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
199.999590 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
200.002180 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
200.000502 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
199.999331 |
|
A05 |
M1 |
M2 |
1.758 |
1.841 |
200.001686 |
The mean is 200.000357g (180?ø00 ¨«01.16??), ? is 0.001129g (3.66??). The data is a bit noisy because the lines of sight are parallel to the ground (concrete one direction and asphalt the other direction) about 1.5 m above ground, so lots of heat waves. This was done with autolock on a 1? high accuracy S6. ?ÿ
The values for the mean angle stored in the access file are 280.000357028, which is exactly 80g off (1/5 of a circle, maybe because there were 5 rounds?), and a ? of 160.99674g. To get that as an average, I would have to add 800g (two full circles) to the sum of the individual readings.
Looking at the .jxl file, each individual pointing (10 total, 5 D and 5R) shows the correct value, these are listed in the table above. ?ÿ
To summarize, the function in access that is keeping track of the directions observed in rounds got one or more pointings wrong by integer values of a full circle) in the mean turned angle computation, but actually stored the correct values for each individual sighting.
Software which reads the mean turned angle value and associated standard deviation will use the wrong value, while software which reads every individual pointing and then computes a standard deviation will have the correct data.
I know the explanation is somewhat convoluted and maybe hard to understand if you aren??t familiar with trimble access files. Hopefully someone from Trimble will contact me and I can send them the .job file. As I said, this isn??t the first time this has happened, and the other times I have seen it was always when the angles were close to and on either side of 200g (180?ø).
Don't think it was convoluted or hard to understand at all. What a failure on Trimble's part not to have a pathway for receiving bug reports.
After the second or third round, I noticed the angle to the far monument came up on the summary as being many degrees off
Is this only happening when working in grads? Sounds like a conversion issue buried in the mean angle code. Not sure about native JOB files, but JXLs are always stored in decimal degrees.
I have always found the mean angle data code in JXL files (meaning the raw XML format) to be funky. Dealing with mean angles when writing custom XSL reports can be a real pain...
?ÿ
What a failure on Trimble's part not to have a pathway for receiving bug reports.
This is something that needs to go through the local dealer. They can and should send your data and explanation directly to the Trimble troubleshooting techs. There is a standard process that they can use to transmit this stuff.
Trimble, like other big names, uses dealers as a sort of "filter" for bug reporting. After working tech support for one of the larger dealers, I could see why. The ratio of true bugs to "user does not understand the gear or software" is pretty low. 98% of the time I was able to fix the "problem" right away, without involving the support team at Trimble.
Regardless, if I couldn't figure out what was going on I would send it to the support team, and - at least during the time I worked with them - they would usually implement a resolution if they could get a fix on (replicate) the problem, and it would show up in the next version of Access.
?ÿ
This seems like something that should be easy to check and replicate, though.
Hijack warning.?ÿ I have often reported bugs while in the field to Carlson, and received a patch before I could get back to the office.?ÿ I first made sure I could replicate the problem, and describe it step-by-step before calling tech support....?ÿ I practice operator error (;)), and can usually identify it by "trying to explain the bug" before actually calling tech support.?ÿ Carlson rocks!
I'll try to help after I stop laughing at the thread title.
Try hand entering a scale from 0,0 in local site settings. It hasn't worked reliably in the history of access....
I am so glad I will be retired by the time Carlson sells out to corporate America. I am a capitalist but many monopolies are just plain bad.?ÿ Worst yet about Trimble, is the last time I tried I could not use a dealer outside of our Geographic sales region.?ÿ No Country for Old men, Jp
Try hand entering a scale from 0,0 in local site settings. It hasn't worked reliably in the history of access....
Really? We do it all the time. Walked a crew through it just the other day, and I don't recall having problems in the past.?ÿ
But if I really need to run with ground coordinates in the field, it's easier to just pick an observed point and compute from that. Result is the same unless we're trying to match a pre-existing survey that both has a CSF plus local coordinates published.
That's super rare for me but maybe not for others? 99% of the time I have it already calculated and a JXL set up in the office before fieldwork starts.
@rover83 I do it a lot when following legacy work. Be sure to go back in and look at tge scaling base point. It nearly always starts about 40 feet wrong and gets a little better with every iteration..
Rover83: yes, you are right, the jxl (and .dc file) is degrees. I was wrong, all of the field work is done using degrees as the unit, stored in the files as degrees. When I wrote my software, I convert to grads because it is easier to deal with grads and decimal grads than DMS in my software. The only time it is converted to grads is when I process it. For some reason I was thinking we had the data collector set to grads, but we don't. It is always set to meters, though.
It was doing this during the rounds, so it isn't a conversion error when making the .dc file or .jxl file. And the data collector was running in degrees, so not a grad to degrees conversion problem.?ÿ
To correct myself, the angle was stored as 252.000321325?ø, which I had converted to 280.000357028. that is 0.7 of a circle.?ÿ
I have had other major issues with Trimble software over the years. Way back I could call or email people I know there, but they are long gone. I have sent detailed explanations of bugs that I have found to my dealer, I don't know if any of it was ever sent to Trimble. I am not your average user, I have a very good understanding of both the GNSS ( I have written programs to create/read/edit .dat files and convert those to Rinex)?ÿ and total station sides, and I write a lot of my own software so I do understand that part of it as well. But, since I am not a huge buyer of equipment (just me and one employee at my company, but we do have 12 Trimble receivers), so I have never been a beta tester or anything like that. I do get it that they probably get a lot of stupid questions and issues that are pretty much operator error.?ÿ?ÿ
?ÿ
Bug reports and suggestions go to Trimble vendors. They prioritize fixes and enhancements. Just because you don??t see your input acted upon in the next software update, doesn??t mean that they didn??t get it.?ÿ
An apparent bug that I've seen at 2 different companies now is when using a job template in Access.?ÿ If you create a project using a template and the template has a coordinate system, if you then open the coordinate system properties in the job after it's created-- the coordinate system box is empty.
The first company where I saw this instructed everyone to go into the properties and pick the coordinate system again just in case this wasn't merely a visual bug.?ÿ This was months ago though and I'm surprised to see it hasn't been addressed.
@bstrand?ÿ
It's because that's not really a bug, it's more of a disconnect between TBC and Access in the way each program rounds numbers out to the 10th or 12th decimal place - specifically the ellipsoid flattening. The last digit or two often is very slightly different in TBC. Also, I believe TBC runs things out to 12 decimal places and Access keeps it at ten.
Even if the naming conventions might be the same, the disconnect in that very last digit will keep it from being recognized as a default library system, which is why "select from library" prompts you for a selection and it looks like a system might not be applied already.
?ÿ
But backing out and selecting "Key in Parameters" will show the correct projection parameters that came out of TBC, and if there's a site calibration the H/V adjustments will be found there too.
If I cared enough about it, I'd go and manually modify Coordinate System Manager to exactly match Access. But the program is working as intended and isn't going to throw incorrect values since the difference between the two is infinitesimal.
Yeah, it's a little confusing, but on the other hand I don't want the crews (or myself) screwing with template coordinate system settings unless there's a major problem in the field. I'd rather the collector hold to the values coming from the template than try and match things up using naming conventions.
@john-hamilton, I'm the Trimble Access PM, I'm a bit late finding this info on this forum, but if you still have this job, and you want the Trimble Access engineers to investigate it, please send it to me and we'll take a look and try and figure it out.
One small question, it's not clear from your post if you are seeing the problem directly in Trimble Access, or in one of the stylesheets used for generating reports. I ask this because there was a similar type of problem reported with our ISO Rounds Report we have recently fixed. But I'm assuming you are actually seeing this issue with the Trimble Access software itself?
Note that your Distributor really should be listening to your feedback, especially bugs like this, and then passing it back to Trimble when required. Some distributors are better at this than others unfortunately. If they aren't, then I would try pestering them until they do (but I appreciate this takes time and energy).
Cheers
Rob
