At the risk of “ganging up” on this issue, I will throw my 2-bits in with the above responses.
I UNDERSTAND that a LOT of modern survey work (GPS and otherwise) is performed and expressed in the ancient “5k/5k on yonder hill (or monument), and aligned with whatever basis of bearing is handy” paradigm.
Although this is changing (slowly), I don't really expect everybody (or every project) to move into a georeferenced spatial paradigm (aligned with the NSRS) anytime soon. In many cases, it might be more of a PITA than is warranted by the project.
That said however, too many folks, make too many excuses for not taking the next step forward.
If you RTK Base Station is setup for longer than 15 minutes, there's really no reason NOT to get on the NSRS (in some form or another).
If you are using a VRS/RTN, then you are ALREADY there (or could be if you push the right buttons)!
If the project ALREADY has a georeferenced coordinate system, then why not use it?
A “calibration/localization” CAN work just fine...it can also blow up in your face, mislead you, and at best is a step backwards.
Oh boy...this is a tricky question:
TRMR8 (Model 1?)
Trimble image (above) indicates 0.065 meters, NGS (relative) says 0.093 meters, NGS(absolute) says 0.0742 meters.
TRMR8_GNSS (Model 2)
Trimble image (above) shows no data (but your image indicates 0.1039), NGS (relative) says 0.1039 meters, NGS(absolute) says 0.0851 meters.
Trimble says 0.065 – 0.1039 = -0.0389 meters
NGS (relative) 0.093 – 0.1039 = -0.0109 meters
NGS (absolute) 0.0742 – 0.0851 = -0.0109 meters
NGS Absolute Calibration data can be found here:
Well BEFORE you do ANYTHING, make sure of what antenna that you are using (TRMR8 or TRMR8_GNSS)!
Which is right, and which is wrong?
I dunno... both Trimble and the NGS appear to agree on the TRMR8_GNSS, BUT NOT on the TRMR8.
But here's the kicker...IF you are using TRMR8s at both ends of the vector, it DOESN'T matter. IF you are mixing TRMR8s & TRMR8_GNSSs in the same vector, then it DOES matter. The same can be said for MOST antenna combinations.
I have “played” with this a LOT over the last year (Zephyr Base, TRMR8 rover), and the NGS (relative or absolute) values work the BEST! Of course I am comparing stations that have been post processed with either OPUS, or commercial software that also uses the NGS calibration data, with RTK [in-fill] data (using all three versions [combinations/estimates] of L1 phase center offsets).
Where this might get particularly TRICKY, is when you are using a Real-Time-Network (RTN). You may KNOW what antenna (and calibration data) that you are using, but what antenna (or antennas) is the RTN using...AND WHAT antenna calibration data is the RTN using. It probably doesn't matter IF the RTN data is based solely on the “actual” L1 phase center coordinate estimates (which I think it is), AND (BIG AND) your data collection software is using the RIGHT L1 phase center offset. I would submit that the NGS data will get you closer to “reality” than the vender data will in most all cases.
I just haven't played with RTN data enough to make a definite statement about just what goes on, but Bill Henning, Gavin Schrock, or Cliff Wilke (all of whom post here from time to time), will know the answers to the RTN question.
IF (maybe big if) RTN “vectors” work like “conventional” (single base) RTK (which I ASSUME they do), then the rubber meets the road in the Rover data collector, which computes the rover position based on the solved L1 Phase Center Coordinate, AND the Rod Height/L1 Phase Center data supplied by the user (or defaulted by the software in the case of the L1 PC offset).
Due to the inherent uncertainty in RTK [derived] heights, most folks (and some vendors) consider this issue to be trivial (and in some, if not many cases, it probably is). On the other hand, I HAVE satisfied myself that it is often NON-trivial, and is by definition, a systematic error (in MOST cases), which should be accounted for.
Now I'll put on my flak vest, and hide under my desk...
That is pretty much the ASSUMPTION that I have as well (see above concerning the L1 Phase Center). That does NOT however remove the ARP-L1_PC offset (at the Rover) from the equation. In the case of a “VRS” solution, there IS NO Antenna per se. BUT you still have to have an “accurate” L1_PC to GRP (monument) value (at the Rover) in the equation.
ALL GPS vectors (or positions...chicken or the egg) are INITIALLY derived from L1_PC to L1_PC. Static software (at least every package that I have seen) reduces the L1_PC to L1_PC vectors to GRP-GRP vectors (Mark to Mark), whereas RTK software/firmware (again in every case that I have seen) “returns the derived vector as L1_PC to L1_PC!
In a nut shell, here is [pretty much] what the data collector software does (behind the curtain) in the case of a “traditional” Single Base RTK solution.
First, the data collector software “solves” for the [geocentric] Cartesian X/Y/Z of the L1PC of the Antenna at the Base Station. This obviously INVOLVES using the Geodetic Coordinate of the Base Station Geodetic Reference Point (GRP) aka...monument, AND the “measured/input” HI + the ARP-L1PC “offset” unique to the Base Station Antenna. Regardless of what YOU entered into the Data Collector to define the Base Station Position (UTM, SPC, LDP, pushed the FUGARWE button, whatever), it all gets transformed to a [geocentric] Cartesian X/Y/Z coordinate in meters (or feet in some cases). Of course your selected coordinate projection and GEOID model factor in here as well.
Second, the geocentric Cartesian dX/dY/dZ vector that is solved by the receiver is added to this value. In the case of “conventional” single base RTK, this vector would be expressed in WGS84(G1150) because that's the “datum” of the broadcast orbits from the satellites. I think that most RTNs are using [ultra-rapid] IGS05 orbits, but for RTK purposes, there isn't much difference between WGS84(G1150), IGS05, or NAD83 vectors (due to relatively SHORT vectors). This returns the geocentric Cartesian X/Y/Z of the L1PC at the Rover Station Antenna.
Third, (last but not least) the data collector software “solves” for the [geocentric] Cartesian X/Y/Z Coordinate at the GRP of the Rover Station (based of course on the “measured” HI + the ARP-L1PC “offset” unique to the Rover station & Antenna).
Fourth, At this point...the Cartesian XYZ Coordinate is transformed to a [Datum specific] Latitude, Longitude, & Ellipsoid Height, the GEOID Model is applied, and whatever Coordinate Projection computations are performed. The result of this LAST computation (or series of computations) is what is burped out on the Data Collector Screen for you to look at.
So the “accuracy” of the height returned by this process, is highly dependent on the “accuracy” of the ARP-L1PC offsets used (and of course on whether or not you “measured” the HI [at both ends] accurately).
The only [real] difference (as near as I can tell) between the RTN/VRS Solution (in this discussion), and the Single Base Solution, is the omission of the First Step (because the L1_PC is the origin or the Coordinate Estimate to start with (and a geocentric Cartesian Coordinate), instead of the GRP of some point on yonder hill).
I may have over-simplified this a little, but [I think] the above is a reasonable accurate description of the goings on behind the curtain.
Note...I used “geocentric” above, even though NAD83 is not “geocentric” in the modern [ITRF] sense, it IS geocentric relative to the NAD83 Datum.
Scott Partridge:Hi Scott
Using Trimble tools, my solution is to build required custom projections in a coordinate system definition (CSD) file using Coordinate System Manager (CSM) in the office then upload the file to the data collector for the field crews. Much easier to build and check prior to the field work being done. You can define the projections anyway you like. It also makes them easier to track, distribute and share. The custom projections are available from the library on the data collector. With multiple field crews on a project it helps immensely. Only the specific projections you want the crew to use (custom or published) can be set to be available from the library.
Site calibrations work well with proper training and support of field and office staff, but building them ahead of time with CSM removes most of the headaches. It also helps to tie them to a known geodetic reference frame as Loyal suggests.
Trust me....it is well worth learning how to do.