L Band Corrections ...
 
Notifications
Clear all

L Band Corrections (Centerpoint RTX, etc.)

16 Posts
5 Users
0 Reactions
21 Views
(@plumb-bill)
Posts: 1597
Member
Topic starter
 

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?

 
Posted : November 15, 2016 8:36 am
(@lee-d)
Posts: 2382
Member
 

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.

 
Posted : November 15, 2016 9:38 am
(@plumb-bill)
Posts: 1597
Member
Topic starter
 

Oops that's what I meant, but yes. Thanks for the input.

 
Posted : November 15, 2016 1:27 pm
(@john-hamilton)
Posts: 3349
Member
 

The coordinates must be known in ITRF

 
Posted : November 15, 2016 1:45 pm
(@lee-d)
Posts: 2382
Member
 

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.

 
Posted : November 16, 2016 6:38 am

(@john-hamilton)
Posts: 3349
Member
 

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.

 
Posted : November 16, 2016 6:53 am
(@plumb-bill)
Posts: 1597
Member
Topic starter
 

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?

 
Posted : November 16, 2016 7:31 am
(@lee-d)
Posts: 2382
Member
 

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).

 
Posted : November 16, 2016 12:47 pm
(@lee-d)
Posts: 2382
Member
 

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.

 
Posted : November 16, 2016 12:50 pm
(@john-hamilton)
Posts: 3349
Member
 

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.

 
Posted : November 16, 2016 1:15 pm

(@lee-d)
Posts: 2382
Member
 

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.

Attached files

 
Posted : November 16, 2016 2:10 pm
(@lee-d)
Posts: 2382
Member
 

But at least they got it right this time...

 
Posted : November 16, 2016 2:11 pm
(@towfique)
Posts: 1
Member
 

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.

 
Posted : November 16, 2016 2:46 pm
(@shawn-billings)
Posts: 2689
Member
 

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.

 
Posted : November 16, 2016 8:02 pm
(@lee-d)
Posts: 2382
Member
 

As far as I can tell it's just a seven parameter Helmert transformation; the parameters are shown in the attached.

Attached files

 
Posted : November 17, 2016 7:56 am

(@shawn-billings)
Posts: 2689
Member
 

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.

 
Posted : November 17, 2016 10:49 am