Trimble Access-is this a feature or a bug?

I always start my base using Access so it automatically uses the coordinates from my VRS point. Wouldn't the offset that you describe result in all of the vectors and points being correct relative to your VRS point as if you'd just started the base with Access and told it to use the VRS point for the base?

If I am understanding this correctly, it seems like the intent was to use autonomous coordinates rather than VRS-derived coordinates?

I wouldn't say this is necessarily a feature or a bug - it just allows the user to choose. If I have a good base station position in my data collector, and the base is trying to broadcast an autonomous position, I will pick the job coordinates over the received coordinates.

However, if I am going to post-process the base station static data and update its position after the survey is done (which is not unusual), I can pick either one. As long as I'm not checking into a VRS-derived position, I can choose the autonomous broadcast position and survey all day long. Access will store all of those positions in the raw data file so the user can, if desired, extract whatever they need for processing.

I have been on projects where the client was operating a continuously broadcasting base station, and on occasion crews would accidentally store a point with the same name as the base position point. We would have to make sure to use the received coordinates when the discrepancy message popped up.

Like most of its other functions, Access gives the user a fair amount of control, which can be both a very good and very bad thing...

It should not matter which coordinate is used, the vector should be the same no matter which one is used. A coordinate has to be off about 5 or 6 meters to make a 1 ppm error in the results.

But what this is doing is actually applying the difference in coordinates to the measured vector, and then storing that value. So if the difference between the VRS and the HERE coordinate was 4 m vertically, it would store the measured difference in height PLUS 4 meters.?ÿ?ÿ

The place I found it was when the HERE coordinate was 6 meters different in height than the VRS coordinate. So, the vector from the base to the rover, which were both at the roughly the same elevation, showed an elevation difference (APC to APC) of 6 meters rather than the basically zero height difference that was actually there. The points were about 20 meters apart.

There is a reason why I start the base with the web interface, but when I select "use new coordinates" or whatever the choice is everything is fine. But the other eprson selected "USE JOB COORDINATES" and that is what got fouled up.?ÿ

Because the difference is stored in the job file I can fix this, but I am wondering WHY? Maybe there is a reason and I am just not seeing it.?ÿ

There's a setting for allowing points to be merged or averaged in the Access collection parameters.

Make sure that's never set to yes, because you will get a merged point you don't necessarily want, unless you actually do.

I figured out what is happening. The base is transmitting corrections computed using the new HERE position. However, when the operator said "use job coordinates" access did NOT store that HERE position. Then, the vector is computed by differencing the solved position at the rover (which is based on corrections from a HERE position) and the stored position of the base (which was from the VRS). In other words, the rover is not directly solving for the vector components, it is computing the vector components (DX, DY, DZ) by inversing the two positions, the one solved for at the rover and the one stored in the data collector database. Then it stores that vector.?ÿ

Because the differences in base positions were stored each time this happened, I was able to write a program to scan the jxl files (10 of them), extract the differences (azimuth, distance, and delta elev), convert them to ECEF differences (DX, DY, DZ), and then apply those short correction vectors in the least squares adjustment (Geolab) as additional observations. Not a simple task, in order to convert an azimuth, distance and Delta Up to DX, DY, DZ you need to have lat/long/height. To do that I read the adjusted ECEF XYZ coordinates out of a database, converted to lat/long/hgt, then converted the local horizon values (azimuth, distance, Delta H) to ECEF DX, DY, DZ.?ÿ

Took me about 5 hours to develop that program, but it beats having to drive 300+ miles back to the site to reobserve 46 points spread out over several counties. Most of the job was done using the VRS, but when we surveyed Lidar woods checkpoints, we set a temporary base using VRS, then survey in the woods using a R10-2 receiver with Trimble Propoint. Prior to Propoint we would set a pair of points in the open using VRS, then use a total station to survey the point in the woods. I did extensive testing and proved to myself that the new method works, so I was really distressed trying to figure out why all of our VRS points (300+) worked fine, but the woods checkpoints were all over the place, 0 to 6 meters off.?ÿ

Lesson learned...do not select "Use Job Coordinates" or whatever the option is.?ÿ

BTW, the reason I use the web interface to start the base after the VRS survey...for some reason Access does not turn on all of the signals in the receiver, so I manually turn them on (under receiver options...tracking) using the WUI. I discussed that issue here before, not sure if that makes a difference but I want as many satellites/constellations/signals available when doing shots in the woods.?ÿ

We do RTK over cell rather than radio.

I just tried to start a base using access, but it doesn't work. I can't see how to configure it.?ÿ

I use either an internal sim card on an R10 with a static IP, or an external modem with static IP on an Alloy, outputting the corrections through the ethernet port on the Alloy to the modem. I probably could do it with the alloy if I output the data through a serial port as a custom radio, because the external modem also has a serial port and I have used that with my R7.?ÿ

In order to start a base, I need to configure a GNSS contact, which doesn't make sense. It wants to route it through the controller to operate as a server, or if I turn off "Route through Controller" it wants to upload the data to a remote server.?ÿ

Is there any other way to start it using Access? I think I could start it using Access as if it were to output corrections over a radio, and then use the Web UI to turn on the NTrip caster.?ÿ

The steps I take to start a base are as follows:

1) go to receiver configuration

2) under reference station set the reference station position using HERE, and put in a station name

3) Under antenna Set the HI and antenna type

4) Under tracking enable all of the signal/constellations

5) go to I/O configuration then configure NTRIP Caster 1 by enabling the caster and turning on CMRx output

I can do this remotely as well since the modems have static IP.?ÿ

?ÿ

Explain your reason for using a web interface instead of Access. Without explanation, it sounds you are making things more difficult than necessary.?ÿ

I just did in the post above...I can't see how to start it otherwise when doing RTK (NTrip) over cell

I use this function as an alternative to localizations....for reasons that would require a different thread.

Setup my base in a known projection/datum using a "Here" point.

Then once I find the site control, I survey it in and translate my base position on to it.?ÿ If you restart the survey, it will ask you if you want to use the "broadcasted" coordinate for the base or the "job" coordinate.?ÿ If you use select "job" it will use the translated coordinate for your base corrections.?ÿ If you select broadcasted, it will give you corrections from the autonomous "here" point.

I always go back and restart the base with the new translated coordinate though.?ÿ Just to avoid any slip ups.

I tried to duplicate this issue today at the office. I keyed in to Access the known coordinates of the base, then measured a point using RTK. Then I put a position about 2.5 meters away into the reference coordinate screen of the base (Alloy), and restarted the base. When I went to measure, it told me the coordinates were different, and I picked "Use Job Coordinates". That is not exactly what was happening in the field, because I don't have a VRS subscription here to do that first.?ÿ

But the before and after coordinates/vector are the same (I gave each observation at the rover a different point ID). And the "difference" note is in the jxl file, but it didn't "warp" the data.?ÿ

?ÿ

So I can't duplicate the problem.?ÿNot sure if not doing it with VRS is the difference, or maybe this was actually a bug that was fixed. The work done last year was with Access 2020.11, and now it is version 2021.00.?ÿ

?ÿ

I am 100% positive it was happening last year, my client sent me a list of 48 points with their misclosures, which closely matched the vertical differences listed in the jxl files. Their misclosures varied up to ?ñ6.5 m in height (versus lidar), and once I applied the differences in the jxl file they were in the decimeter range for these forest checkpoints.

?ÿ

@john-hamilton I havenƒ??t used RTK sourced from mobile data to a local base, but it sounds right that you have to define a GNSS contact to start base because in this instance thereƒ??s little difference between mobile data to local base and government /large system VRS/RTN. Both use mobile data.

but you should be able to use your VRS to store a point to setup your base on and use as RTK-cell data base. I do the same thing with the VRS in my state. Iƒ??m not sure if the ƒ??store asƒ? fir points in settings being positions or vectors would matter. I store points as vectors. That setting might only see a difference when brought into TBC.

@john-hamilton Hi John, maybe I'm misunderstanding what is going on, but that message pops up for me when I start my base using a point number (100) but then open a new job and point 100 in that job has a different coordinate associated with it.?ÿ So the controller is asking if you want to use the 100 coordinate broadcasted from the base??ÿ Or do you want to use the coordinate for 100 associated with the job you're surveying in.

Access will calculate the difference between the 2 coordinates if you choose "job" instead of broadcasted.

?ÿ

I've also had it pop up if I set my base up on a point I have stored "check shots" on.?ÿ So I believe the problem lies with having multiple coordinates in the job associated with the same point number.

Definitely a bug...NOT a feature

?ÿ

We did two projects where this was a problem. So, I "fixed" all of the affected points.?ÿ

On the second job, we actually made three trips there. The second trip was cut short in December due to a snow storm. We went back two weeks later, and points done on the third trip were unaffected, although they did have the note about the base shift.?ÿ

Turns out I installed a new version (2020.20) of access on the data collector (T7 running windows 10). Version 2020.10 was the problem. Since it seems to have been resolved in the later version, I can only assume they discovered the problem and fixed it. There was no mention of this at all in the release notes.?ÿ

I asked my dealer rep to inquire about this to Trimble, but got no response at all. This, to me, was a serious problem that I had to figure out with no help at all from Trimble. The alternative was to go back and resurvey 100 checkpoints in a very large area. As it is it cost me quite a few hours in the office figuring out what happened and fixing it.?ÿ?ÿ

The controller is just calc'ing a translation base on where you tell it the base is broadcasting from.?ÿ Save yourself the stress and rename your "Here" point something unique.

Why you would start your base broadcasting autonomously after you've set a corrected point before hand is puzzling though.