CORS vs PPP

With that kind of data sets, the PPP solution should be very good, I have obtained very good results using the CSRS-PPP and comparing to solutions from a baseline processing using CORS here in the states. I think you must have an issue with ITRF vs. your local datum there someplace and I would look at that first as I suspect the solution from PPP is going to be very tight with seven hours of data.

SHG

> The difference between TBC results and those from the websites is from ~50cm up to 2m
I'm not familiar with any of the specific softwares you are using , or with middle eastern datums, but the magnitude of the difference you are seeing suggests an ellipsoid definition issue. The datum setting and the ellipsoid setting are usually independent. Would you, perchance, be using GRS80 in TBC when you should be using WGS84, or vice versa, or some other ellipsoid?

Hi Simon,

I have a little bit of trouble understanding what exactly is the problem you are having. What do you mean when you say TBC differ from the websites between ~50 - 2m? I thought the three websites all agreed so should TBC differ the same with respect to all three?

I have done quite a bit of PPP processing on the CORS data and generally the agreement is very good with the published NGS coordinates, as Shelby mentioned. Usually when I have a problem it is related to:

1) Epoch of my coordinates CSRS-PPP will output in epoch of the collected GPS data while the coordinates from the NOAA site are usually epoch 2005 or 1997 and you must apply the velocities to get the correct epoch.

2) NAD83 vs ITRF (offset by about 1.5 meters depending where you are)

3) antenna offsets (mainly affect the height component, should be sub-cm in horizontal)

Hope this helps!

L

Howdy,

First of all, I am amazed with the close agreement between the point positioning services and the double-difference based tools. I did a comparison with a summary shown here: http://geodesyattamucc.pbworks.com/w/file/fetch/53012749/lab9_2012_summarySolutions.pdf

A listing of available "free" post-processing sites is provided here:
http://geodesyattamucc.pbworks.com/w/page/13931102/FrontPage#Lab5AutomatedGPSProcessingToolsbeyondOPUSdue27March2013nbsp

That said, when you state that you also got good agreement between AUSPOS and CSRS-PPP but poor agreement with your Trimble Business Center (?) software I assume that it is because these packages are not intended for the lengths of baselines you mention. Commercial packages do not generally(?) include many of the models used in the government and academic packages.

I also suspect, as others note, that there is a issue with velocities. I imagine you took the published coordinates for the CORS sites and entered them as shown on the source. In other words, the coordinates were at the reference epoch. IGS 08 coordinates are referenced to epoch 2005.0 which differs by over eight years from today.

What the academic and government packages do is calculate the mid-point of the session at the user's site. They then calculate the reference station coordinates at this date/time. Usually the results of the processing tools are expressed at the epoch of the observations.

I have not used commercial GPS processing packages in years and perhaps they have improved. Years ago we did a test of their suitability for hundreds and thousands of kilometer baselines; none yielded good results. As they are intended to support "normal" users, it would be difficult to justify adapting them for very atypical uses.

I would work everything in IGS. Determine the date/time appropriate coordinates for the reference stations and process. I would determine what reference frame and epoch my client wanted and do the appropriate transformations. IGS sites generally include site velocity information. I believe the NGS HTDP tool which includes the option to transform coordinates between frames and dates will not work outside the US unless the user specifies the velocities.

Hope this helps,

DMM

For all intents and purposes GRS80 and the WGS84 ellipsoid are equivalent, that is to say they are interchangeable. That is NOT to say that NAD83 (which uses GRS80) and WGS84 are interchangeable. The differences in the defining parameters between the GRS80 and WGS84 are negligible.

I would venture to say that your constraints in TBC need to be looked at. In other words, if you are comparing against an ITRF08 2013.35 position (i.e. today) from AUSPOS or SCOUT, or PPP, or whatever, you MUST transform whatever CORS you are using in TBC to that epoch before constraining.

Ahhh, I should've posted here earlier. You guys are brilliant :clap:

Silly mistake, CORS coords weren't adjusted to the correct epoch which is mentioned as 2005 so 8 years.. it adds up. I'm down to N 20mm and E 3mm difference with my TBC (single 7 hrs observation and 220km baseline) vs CSRS-PPP.

And that HDTP software - I was googling for it many hours without success. Cannot thank you enough!

Perfect way to start the weekend! 😀
simon

HTDP if you haven't found it yet.

SHG