For those of you using receivers that can use this signal (R10, SP60, etc), does the data collection software that you use along with it include a routine to localize to a known point instead of waiting the 30 minutes +/- for convergence?
It's not a localization, it's initializing on a known point - those are two different things. But yes, you can initialize Centerpoint RTX with an R10 on a known.
Oops that's what I meant, but yes. Thanks for the input.
The coordinates must be known in ITRF
John Hamilton, post: 399761, member: 640 wrote: The coordinates must be known in ITRF
Trimble has that coordinate system "State Plane 1983 To ITRF" in Access; I don't know how good the transformation is but it definitely tightens WAAS up a good bit. I would think it's close enough for initializing on a known point in NAD83 SPCs.
Actually, that should be an "exact" transformation. I believe they use the same parameters that OPUS, etc uses to transform from ITRF (which is what OPUS does calculations in) to NAD83 (2011). But, I could be mistaken, I don't know exactly what Trimble does in their transformation, I just assume they do it rigorously.
I'm going to need to research that some more. I know Trimble GNSS uses ECEF and ITRF in the background for everything, so I'm not sure why which coordinate system you choose to represent your local coordinates in should matter. Any thoughts?
Trimble uses ECEF in the background, but when you select the basic State Plane 1983 coordinate system it's not performing any transformation; in other words, it's treating NAD83 and ITRF as if they were the same (it says Moledensky when you look at it, but it's a null three parameter).Obviously NAD83 and ITRF are not the same, but they're close enough that it doesn't affect the performance of the GPS to treat them as if they were. For every point, Trimble has a Global (ITRF) coordinate and a Local (in this case NAD83) Lat/Long/height; when you select the basic State Plane 83 system those Global and Local values are identical. When I receive corrections from our VRS, those corrections are likewise correlated with NAD83, so no transformation is required.
On the other hand, services like Centerpoint RTX, WAAS, and Omni Star are satellite based and transmit their corrections in ITRF, so in order to position in NAD83 you need a transformation between the two. As John said, I believe that Trimble uses the same transformation parameters in Access that OPUS uses, but I don't know this for sure. When I've tested WAAS solutions against VRS solutions using the Access transformation, the results have been excellent - generally better than a foot horizontally under good conditions. I had a sales rep make a vague reference to having been told not to use that coordinate system, but I'm pretty sure he was taking something he heard out of context. There's a time when it is not appropriate (with VRS in my case) and a time when it is (with Centerpoint RTX, for example).
Plumb Bill, post: 399834, member: 226 wrote: Trimble GNSS uses ECEF and ITRF in the background for everything, so I'm not sure why which coordinate system you choose to represent your local coordinates in should matter
To answer your specific question, Trimble always ASSUMES that the Global values are ITRF, but they are only truly ITRF if you either transform to ITRF from your local system or use a remote correction service that transmits it's corrections in ITRF. Does that make sense?
Ad I stated above, we do not normally transform our NAD83 coordinates to ITRF; that would only add an unnecessary layer of complexity and opportunity for blunders to creep in.
I don't know if it is still the case, but Trimble did have a coordinate system in the data collector called something like State Plane NAD83 (2011). Sound like the system one would want to use on NAD83 (2011) right? Wrong. That was to be used IF you were using ITRF and wanted to use NAD83 (2011). Since MOST users are using a VRS with NAD83 (2011), it was applying a correction that was resulting in a shift of about 1.5 meters away from NAD83 (2011) in the opposite direction from where ITRF is. Poor choice of name.
Yes, that coordinate system is the one that is now called United States/ITRF to NAD83 (per below). It's on at least its third name; as you mention, the first one was unfortunate, plenty of people made that mistake.
But at least they got it right this time...
Hi everyone,
Please contact your local Trimble reseller, or the Trimble Advanced Positioning Customer Care team and they can help with any confusion regarding Coordinate Systems to be used with CenterPoint RTX.
Is it using HTDP or 14 parameter only? OPUS uses HTDP. Probably not substantial over much of CONUS, but a difference nonetheless. Particularly with sub-decimeter positioning.
As far as I can tell it's just a seven parameter Helmert transformation; the parameters are shown in the attached.
My experience with high precision L-Band corrections is getting a bit dated, but it seems like the rules for getting sub-decimeter performance were similar to working with L1 only RTK/PPK. Convergence (in L-Band parlance) or fixed integer ambiguity (in RTK/PPK parlance) requires about 20 minutes (L1 could actually do better depending on base line length). If you lost the fix while passing under an overhead obstruction you had to reinitialize. The same is true for L-Band, although you shouldn't be much worse than meter level immediately, once back in the open again, but to get back to decimeter you have to wait for convergence again. L-Band provides great results in open conditions (excellent for agricultural applications and machine control in some settings). If I were surveying big land out west (with no canopy) I might even consider using L-band to survey from. (What's a decimeter on a 10,000 acre survey?) Might be tricky in many cadastral applications though, due to canopy limitations. Having said that, my most recent experience is probably three years ago or more. I keep hearing that PPP is making big strides in performance, but I haven't really heard anything specific.
