Trimble Access Site Calibration

WOW!!

That's terrible!!!

I do this all the time and expect to see differences <.04' in elevation checking 10 mile corridor control for DOT projects. That's using Geoid 18 vs. level control. Those checks are RTK and I might extend my checks up to 4-5 miles from control. Seeing .5' would throw the entire project into re-survey territory.

A couple of things I thought about, bearing in mind that while I interface with my colleagues in our CA offices fairly regularly, I'm not an expert on the area:

-is the CRTN broadcasting ARP vs publishing GRP heights? (not likely I know)

-did the crew maybe choose a mountpoint that is broadcasting a different epoch? That's what my money would be on

I'm not sure why PP vectors would be that far off from the the RTK vectors, unless there's an epoch issue and you're seeing the effect of the stations involved being adjusted in different directions. Are you comparing them after clearing the calibration? (Shouldn't make a difference, but still...)

In Access, there's no way to change a mountpoint when opening a connection and starting an RTN survey; whatever they are broadcasting is what you get, so it is almost certainly an CRTN issue. Running a calibration will modify the Local value (and then project to Grid), but not the Global that is transmitted by the RTN.

As far as the tilt + elevation issue....did they pick a single-base or true VRS/network mountpoint? If they were going 10+ miles away, I could see a single-base solution drifting off as they went further and further away. That being said, that distance isn't *that* far...

As a general rule, if the values being calibrated to are good vertically, and the geoid is good in the area, just a vertical shift + geoid solution should work.

And on that note, personally I am very wary when I see a tilted plane solution for a corridor project. Lots of potential for problems. But it might be fine for your project goals, and if the parameters are not unusually large, you're probably ok. I've done several when it was clear the local control we were working with had some systematic errors, and it was just not possible to change their values. Still I don't like it.

How much tilt are you seeing?

I have never like site calibration in a linear fashion. Any error in control plus error in measurements to tie compounds . I saw a 8 mile project that had a few hundreths in vertical on one end to the other get up to the .5 ft in vertical. At other end. I could hold one point vertically in the middle and let the geoid do the rest after the shift and i was under a tenth every where then.

That .35 process vs rtn. Could be just an ellipsoid error or ck the measure up. Quick connect vs bottom antenna mount va apc. If the original control was set with rtk rtn why do a calibration. Just re observe and find if it all matches or not.

You don't mention how the original control was established, maybe don't know?

The adjustment software in older versions of Trimble office software (going back to trimnet) had rotations turned on by default. This could produce pathological results on a linear project where benchmarks are nearly colinear. Any slight error in the benchmark elevations or the GNSS observations on the benchmarks, whether RTK or static, could produce large rotations in the direction perpendicular to the long dimension.

In the days before good geoid models it was always necessary to compute tilts (slope of the geoid surface i.e. deflections of the vertical). So it was good practice to spread out benchmarks in 3 or 4 directions, and to have some outside of the project area. I have seen a number of networks where they had BM's along a linear highway, and did not pay attention to the resulting rotations and got results similar to what you are describing, or worse

Now that we have a good geoid model, at least in the US, I would recommend to always turn off the rotations, as they are not necessary. I do projects outside of the US, where there are no good geoids available, and that is a different story.

When one does a calibration, it is doing something similar, computing rotations to fit the BMs. If the project is linear, it can result in what I describe above.

That is why I am against using calibrations in the field.

Just my opinion on what could be happening...

Nice catch. I didn’t think of that. Trimnet. GPSurvey. Color pencils and a map planning projects and who goes where when. The days of planning now i can draw pretty lines on google earth and plan and send a kml to the guys. Times have changed.

I get the linear-calibration concern, that's why calibrations always make me nervous. But the agency (Caltrans) has specified that their control values are to be used ("NAVD88 vertical values are provided based upon GNSS observations constrained to exiting Caltrans record elevations"), so we're working with that.

The rapid-static vectors (which all fixed nicely) from two different CORS using GEOID18 agree closely with the RTN vectors regarding the amount of control tilt along the corridor. Since all of the work will be inside the highway ROW, I'm thinking that any side-to-side tilt introduced by the linear calibration won't amount to much.

I learned this afternoon that I made a two bad assumptions:

1. I thought the field guy was using the CRTN caster, but he was actually using the UNAVCO/GAGE/NOTA/Whatever caster. Same mountpoint, but UNAVCO's ellipsoid heightis 0.434 m (1.424') lower than the CRTN value.

2. What I thought was a 0.444-foot vertical constant in the JXL calibration values is actually a 0.444 m (1.457') constant. So the calibration is adding back the difference (within 0.03') between the UNAVCO +GEOID18 ortho height and the CRTN+GEOID18 ortho height to get to the Caltrans ortho height once the tilted plane is accounted for.

I still haven't resolved the 0.35' difference between RTN vectors and post-processed vectors. But as long as the field guys can reliably hit the Caltrans control within spec I guess I'll live with it.

So do they have some type of shift or ldp or using a different ellipsoid than grs80. I am not familiar with what is being done on datum side out there. But I assume since caltrans has a different ellipsoid height something is different than straight up nad 83 2011. Probably why yall out there have a better understanding of datum’s velocity’s etc than where i am located. Sounds interesting. I might have to just look up this and read on it for fun.

UNAVCO operates in ITRF, or at least all of the static data I have ever downloaded contained an ITRF position in the RINEX header. Causes headaches for us when someone new or inexperienced grabs a UNAVCO download in TBC, rather than the corresponding NGS CORS download for the same station. Had a few projects that were inadvertently processed using ITRF values rather than NAD83.

Still doesn't explain why the LL would be the same but the height different...that makes me wonder if there actually is a ground mark.

Man, I love that I can find a couple monument cases using street views, grab their LL, transform, and hang my calculated plats/subdivisions/ROS off of it in C3D, and get the crews to within a foot or two (often less) of every other monument in that area.

I still see surveyors sending 5000/5000 calcs to crews (cogo points rather than lines, no less) and telling them to calibrate or translate/rotate in the field...but my crews seem to like being able to just walk up to a calculated position and find each mon without any fuss. Saves time and $$$.

Not to mention they can look at aerials or street views right on their controller, with the calc lines overlaid, and simply stake to the lines/vertices.

@rover83 ohhhh now i see. ITRF Now I see . So i guess yall have to open Rinex in note pad to ck headers often then. To edit etc. I am trying to remember now the tilt globally between wgs84 and itrf but that was many years ago now and it was a headache. Its where science and politics meet sorta issue. I reckon once the new datum comes out except for older on going projects might solve some of the issues. Yall have some interesting things to deal with. Here its not near the issues. Mostly grid ground and scaled coords vs non scaled which all look the same . LDP’s are not even discussed. Its pretty common practice that you just pick a point in center of project and scale to ground and break out the gun. I mostly keep crews on grid for everything. I work the magic at office side. So they can use gnss or robot for everything and don’t have to switch back In forth between a projection and scale 1.00”””” settings in dc. A few jobs like anchor bolt layout its ll just a project coordinate system so all total station and tape work so no gnss on those. Just tie to existing building and calc it and move on.

@rover83 Yeah on lines vs points and translate rotate I took some shape files not long ago from county gis. Brought them into tbc. Took deed comped it up moved it close to gis. Made a gut feeling on about how off the gis was. Just from doing the same county work. Told the guys to search and made sure they understood its a guess Showed them how to move the dxf in access as they found control if the wanted but like you said it was all under a foot. So close enough for them to wave the magic yellow wand to find corner’s. Much easier for sure. I just have to harp on them to look for other evidence besides just the corner pins like blazed trees fences etc.

If you have a long semi-straight corridor, it would be helpful to plot the Geoid Heights along the corridor on a graph. Once that's completed draw straight lines between points and find out if any combination of calibrated points will follow the graphed line. I suspect none of the points will accomplish a precise calibration. This is a technique I've used since the early days of calibrations. I never found a site locally that would work to an acceptable precision. Some longer ones produce errors in feet when pushed out miles.