Cors vs. RTX-PP

I would think that Trimble RTX-PP may also be using CORS data, or equivalent private fixed stations, or perhaps a combination.

When you say CORS processing, what service are you using - perhaps OPUS-S or OPUS-RS? CORS are some of the fixed stations, not anyone's processing algorithm.

With a possible differences in the choice of stations and the algorithms used, that is indeed a comforting level of agreement.

I ran one of my RINEX files through Trimble RTX-PP and compared to what I got with OPUS-RS (rapid orbits), and don't fully understand what I'm seeing.

Can someone explain the difference between IGS08 (EPOCH:2017.24606) as reported by OPUS-RS, versus ITRF 2014 at Epoch 2017.25 as reported by RTX-PP ?

What I see is a horizontal difference of 0.098 ft between processing methods (IGS vs ITRF), which is pretty good, but the difference between reports for NAD83 (2011 epoch 2010.0) North American Plate is 0.182 ft, so there must be something different in the definitions.

The vertical difference between methods is the same to the millimeter for NAD83 vs IGS/ITRF.

Bill93, post: 422655, member: 87 wrote: I would think that Trimble RTX-PP may also be using CORS data, or equivalent private fixed stations, or perhaps a combination.

When you say CORS processing, what service are you using - perhaps OPUS-S or OPUS-RS? CORS are some of the fixed stations, not anyone's processing algorithm.

With a possible differences in the choice of stations and the algorithms used, that is indeed a comforting level of agreement.

I don't use OPUS, I pick the CORS stations I want to use and process the baselines myself, look at the numbers processed from each CORS point and if I like them I run an adjustment for the point, it's usually faster than OPUS.

Bill93, post: 422658, member: 87 wrote: I ran one of my RINEX files through Trimble RTX-PP and compared to what I got with OPUS-RS (rapid orbits), and don't fully understand what I'm seeing.

Can someone explain the difference between IGS08 (EPOCH:2017.24606) as reported by OPUS-RS, versus ITRF 2014 at Epoch 2017.25 as reported by RTX-PP ?

What I see is a horizontal difference of 0.098 ft between processing methods (IGS vs ITRF), which is pretty good, but the difference between reports for NAD83 (2011 epoch 2010.0) North American Plate is 0.182 ft, so there must be something different in the definitions.

The vertical difference between methods is the same to the millimeter for NAD83 vs IGS/ITRF.

Strange. The transformation parameters don't look like enough to produce the difference in positions that Bill93 saw. Must be some difference in the solutions at work as well.

gschrock, post: 422660, member: 556 wrote: Actually, precise point positioning is completely different than baseline processing. Tightly tracked clock and orbit products are applied, for most PPP services there are global arrays of tracking stations. The only time dense arrays of stations are applied is to develop better iono and tropo data to improve the convergence time and vertical. It is a whole new ballgame but PPP has been around for several decades (first developed by natural Resources Canada). there are numerous free services (AUSPOS, IGS PPP, NRCAN, and many more in science and academia, plus the commercial service like Veripos (now available via Leica), Atlas (Hemisphere) and RTX. Many offer post-processing and real-time (state-space data delivered by L-band sats) - that is how they can offer it where their is no cell. While the real-time PPP services were productive for agriculture and marine markets, steady development is seeing them as being suitable for some (repeat, some) surveying uses. PPP is predominant for a lot of plate tectonics studies and geodesy in places where little infrastructure exists. I use it quite a bit in places in our state where OPUS struggles, and as one of the monitoring systems for our RTN (it would be the one that could most rapidly reestablish geodetic coords post-quake). I also use RTX as it handles multiple constellations. A wonderful second check. But remember, PPP is a global solution with only one true (ECEF) reference point; the earth center. And that is why it is heavily utilized for geodetic purposes independent of the inequities in local/regional systems.
I should not have started a lengthy post this late on a Sunday.... more another day.
I wrote something about PPP many years ago - and things have improved greatly since then....

Thanks for the info, I'd imagine because of ease and simplicity RTX-PP and like services will be what's used in the future. Might as well get used to it, with TBC I have to take an active step NOT to use it. And because it does it as you download I imagine it's being utilized way more often than OPUS.
My concern has always been I didn't have any idea what was going on, there is little in the way of a report, although OPUS is also very hands off, listing some stats and projections isn't all that helpful when your elevation is .3' off.

Shawn Billings, post: 422668, member: 6521 wrote: Strange. The transformation parameters don't look like enough to produce the difference in positions that Bill93 saw. Must be some difference in the solutions at work as well.

I agree. The transformation parameters do not explain the magnitude. Further evidence is the definition.shown above.

BTW, check out the information at: http://itrf.ensg.ign.fr/ITRF_solutions/2014/
For details of the fundamental changes incorporated in the new frame see Zuheir Altamimi's JGR article linked from the site. It is "free access."

My limited knowledge of how the Trimble RTX processor works is that it does use CORS around the world, but not in the conventional sense of processing the data against the CORS in a differential mode. It uses the CORS to model the errors in the ephemerides and clocks and the ionespheric effects. The same data is used in real time to send RTX corrections over a satcom link.

I suppose shouldn't complain about free, but I notice some things they could easily improve about the RTX-PP service.
1) They could put your file name as part of the subject line (like OPUS does) and the name of the report file so you can find the right file later.
2) They could make the PDF so you could highlight and copy text out of it to paste coordinates elsewhere instead of retyping or hunting down the numbers in the XML. The PDF now seems to be an image rather than formatted text.
3) I notice there is a covariance matrix in the XML that isn't in the PDF, not sure why not.

Bill93, post: 422857, member: 87 wrote: I suppose shouldn't complain about free, but I notice some things they could easily improve about the RTX-PP service.
1) They could put your file name as part of the subject line (like OPUS does) and the name of the report file so you can find the right file later.
2) They could make the PDF so you could highlight and copy text out of it to paste coordinates elsewhere instead of retyping or hunting down the numbers in the XML. The PDF now seems to be an image rather than formatted text.
3) I notice there is a covariance matrix in the XML that isn't in the PDF, not sure why not.

The RTX coordinate will attach to the point in TBC, you can use it or not depending on what you are trying to do with it. In my case I just was curious so its only informational. I'm fixing the original position. It should show up as a RTX cÌ?rdinate attached to the point and viewable in project explorer.

I find for several of my RINEX files modest differences between NAD83(2011 ep2010.0) as reported by the two methods, as expected since they are different algorithms using some different reference stations.

When I compute the OPUS vs RTX-PP NAD83(2011) difference MINUS the OPUS IGS08(current epoch) vs RTX-PP ITRF(current epoch) difference, I get a consistent 27 mm (0.087 ft), which breaks down as X 11 mm, Y15 mm, Z 20 mm, or lat 24 mm, lon 11 mm, el ht 0 mm.

The values haven't changed with the RTX change last month from ITRF2008 to ITRF2014 as the default to be reported along with NAD83.

The difference must be somehow related to the translation between reference frame realizations, and in some way that doesn't affect height significantly. The direction of that double difference doesn't fit the local velocity, so I don't think the explanation is some misunderstanding of epoch.

I'm in 'way over my head on this. I note that this page
https://www.ngs.noaa.gov/CORS/coords.shtml
says IGS08 is not identical to ITRF2008. I wouldn't have expected 27 mm difference, though, because all the recent realizations seem to be shaving millimeters.

"Since April 17, 2011, the National Geodetic Survey (NGS) and the other Analysis Centers of the International GNSS Service (http://igscb.jpl.nasa.go v'">IGS) have been providing GPS satellite orbits (ephemerides) that are referred to a new terrestrial reference frame, called IGS08 and defined by the IGS. This new frame is based on GPS observations and was designed to be consistent with the International Terrestrial Reference Frame of 2008 (http://itrf.ensg.ign.fr/ITRF_solutions/200 8'">ITRF). ITRF2008 is the latest frame realization of the International Earth Rotation and Reference Systems Service (http://www.iers.or g'">IERS) ...

"Although, the best fitting Helmert transformation between IGS08 and ITRF2008 for a set of well-established, international GNSS satellite tracking sites is the identity function, the transformed ITRF2008 positions have a site specific "correction" applied to them to create IGS08 positions (for additional details on IGS08 consult the following IGSMAILs http://igscb.jpl.nasa.gov/pipermail/igsmail/2011/006346.htm l'">6354, http://igscb.jpl.nasa.gov/pipermail/igsmail/2011/006347.htm l'">6355, http://igscb.jpl.nasa.gov/pipermail/igsmail/2011/006348.htm l'">6356, http://igscb.jpl.nasa.gov/pipermail/igsmail/2011/006366.htm l'">6374). Thus the IGS08 position for a particular site may differ from its corresponding ITRF2008 position"

I didn't see any guide to how much they might differ.

Does 27 mm make sense to you who are more familiar with such details?

I ran some averages using the multiple sessions I had from my cable length tests, a total of 24 hours of data from multiple days. The average OPUS IGS08(2017.xxx) matched very well with the Trimble RTX-PP ITRF08(2017.xx), giving a latitude difference of 2 mm and longitude 4 mm.

The average NAD83(2011) points from each service missed each other by about 30 mm (diagonal).

So the discrepancy is in the conversion from IGS/ITRF to NAD83(2011 epoch 2010). I confirmed that HTDP gives the same conversion as the OPUS report (duh), and the HTDP conversion does not match the Trimble report conversion.

Try it on one of your files.

Maybe Trimble is using a 14 parameter transformation instead of HTDP?

Shawn Billings, post: 423030, member: 6521 wrote: Maybe Trimble is using a 14 parameter transformation instead of HTDP?

Shawn,

HTDP uses the published 14 parameter transformation (IGS/ITRF to NAD83).

I suspect a velocity issue (2017.xxxx to 2010.0000).

The OPUS Extended Output Report contains everything you need to trace each step of the process (and verify it you wish). I have no idea what kind of bread crumbs are supplied by RTX.

Loyal

HTDP uses 14 parameter transformation plus regional velocities. Maybe RTX isn't using regional velocities, only the 14 parameter transformation.

Shawn Billings, post: 423046, member: 6521 wrote: HTDP uses 14 parameter transformation plus regional velocities. Maybe RTX isn't using regional velocities, only the 14 parameter transformation.

Shawn,

IF we had a step-by-step trail of bread crumbs from the RTX-PP solution (like the OPUS Extended Output Report), we SHOULD be able to trace the VARIATION in final solution pretty easily.

Loyal

Loyal, post: 423058, member: 228 wrote: Shawn,

IF we had a step-by-step trail of bread crumbs from the RTX-PP solution (like the OPUS Extended Output Report), we SHOULD be able to trace the VARIATION in final solution pretty easily.

Loyal

not big yellow- you get your little happy post successful captcha email and like wall-e... Ta Dahhhhh! a very minimalistic 1page pdf. just accept it, believe it, be assimilated by it.... less stressful when you quit resisting.......

Rankin_File, post: 423063, member: 101 wrote: not big yellow- you get your little happy post successful captcha email and like wall-e... Ta Dahhhhh! a very minimalistic 1page pdf. just accept it, believe it, be assimilated by it.... less stressful when you quit resisting.......

Thanks Rankin,

In that case I wouldn't even bother to submit in the first place, let alone put any trust in the results.

Loyal

Loyal, post: 423067, member: 228 wrote: Thanks Rankin,

In that case I wouldn't even bother to submit in the first place, let alone put any trust in the results.

Loyal

I was a bit fictitious. You get a .pdf and an .xml - I didn't digest the .xml at all- i just wanted a quick result from a half -baked observation OPUS - RS aborted out on - so I did get my rough lat and Long. ( I recovered a Bench under a BIG Bull pine while I had a bunch of receivers out burning statics, so I put an Epoch50 on it for a few minutes while I was waiting. )