What to trust - Commercial NTRIP or 24h GPS log? Or am I being "stupid"?

Hi,

I have now tried several NTRIP providers and done my own 24h log files with CSRS both Ultra Rapid and Rapid results over multiple days.

All (every single) NTRIP provider solution have offsets from each other on Lat/Long. Height not so much. But their measurements are “reasonably” repeatable as long as I stay on the same NTRIP provider.

With my own “soaking” for 24h + CSRS - my results are repeatable day after day (5 days of different logs, 4h to 24h logs) - all return results within 9-14mm total lat/long and total diff 25 mm in height. But as I said - offset from ANY of the NTRIP solutions.

The NTRIP providers are between 70-86 cm offset from my 24 hour soak - so it is a huge difference. And we are talking NTRIP from “some of the best” in the industry.

So which one should I trust? My own CSRS - or the NTRIP providers?

CSRS - Log files set to CSRS
Processing chosen : Static, ITRF
Logfiles - 10 log files processed from 4 to 24h “Ultra Rapid” - and some reprocessed using “Rapid” with no big difference in final outcome.

What datums are used by those services? When you output from PPP, can you select NAD83 CSRS and compare with the coordinates from those services?

The shift you mention is bang on in the range of offset between ITRF14 and NAD83 CSRS. I am wildly guessing that you’re in Canada, else disregard the output step above.

Anytime you want to use different services, having the datum specs is the most important part for repeatability.

Thanks Gabriel,

I’m in the UK and using OSGB 1936 with ODN height - so global datum = ETRS89

/k

Still, if you’re saying the services all give incompatible solutions but they are all repeatable against themselves, that most probably means they are not using the same datums. You need to find out what these are in order to make accurate transformations to a common one or your own static measurements.

3 Likes

Hi Kaz,

I agree with Gabriel: I’d also pay additional attention to the coordinate systems here. How do you compare CSRS results with NTRIP ones? I mean, how do you convert the coordinates to OSGB1936 if you do that?

And how much is the difference between different NTRIP services’ results?

1 Like

Thanks but everything is done standard settings:

  1. Reach RS2 - set to Base according to Base setup instructions.

  2. Enable NTRIP - Base reports “global” base position X (in Emlid Flow it then can translate between global and local OSGB1936) - Flow say “Make certain NTRIP corrections are in ETRS89 format” - which they are.

  3. Do 24 hour log - process via CSRS (Static - ITRF) - get averaged base position Y

  4. CSRS (Y) and received NTRIP (X) are offset - so is that due to CSRS reports coordinates in ITRF20 (2023.1)?? - do I need to convert “Y” to ETRS89 before I apply the coordinates as “base station” coordinates? I have checked the CSRS UTM (North) Zone 30 as well as delivered by CSRS and that matches “Y” - even when Emlid Flow converts “Y” from Global to a “Local” OSGB1936 coordinate.

/k

Without knowing all the details the answer is most likely both. Just re-visit the point, it does not have to be 24h. Even 1h should be enough. I would bet you get the same results, including the same offset.

CSRS gives you the ITRF coordinates which are, in crude terms speaking, tied to some global earth average. Often you can check this by downloading a RINEX file from your local NTRIP provider and processing this using CSRS. Then the ITRF coordinates will not match the published coordinates of the NTRIP base station but exhibit that offset.

1 Like

Yes, the results from PPP need to be transformed to ETRS89. They are not in the same reference frame. @Alexander’s second paragraph is spot on.

1 Like

Hi @Alexander ,

thanks - but is there anyway to get “rid” of the offset - without having to rely on the NTRIP offsets?

Apart from that all the different commercial NTRIP’s and free ones I have tried - each have their own offsets to eachother.

RTK2Go - > 62m from nearest mountpoint - so result is terrible
IGES Free - good fix 30km from base - reasonable repeatability.

IntelliRTK(local UK) - limited GPS channels - so hard to get a good/reliable fix

PremiumPosition - Good coverage - 5km to closest basestation - reasonable repeatable fix (not as good as my own multiple avg. fix) - in the UK they use the “official” network - so same as Leica Geo’s “SmartNet”

RTKFix - uses “virtual” bases - but are more “shaky” than PremiumPosition - and not as repeatable. Often won’t give a fix unless very clear view of the sky. Don’t know who is their “prime provider”

But as I said - each of them have their own “offsets” - so their fixes “cluster” together. But all are quite “offset” SW from my “average” CSRS fix. But my CSRS fixes are MUCH more repeatable with lower cone of uncertainty.

But NONE of the tutorials I have seen anywhere - does anything but say use CSRS result as your “base position” after 24h log or more. So I guess that means many of the RTK2Go will be publishing with “wrong” datum without a shift?

/k

RTK2GO don’t really have any documentation for each station and you can only trust that the station maintainer is actually competent at all to begin with. A station might be broadcasting WGS84 coordinates, for all we know.

But in order to compare them with your own data, you need to first transform everything to a common datum. You haven’t explicitly mentioned if you have the datums for each service. Without those, any analysis you try is meaningless and wasted time.

But as I said above, you should first use a tool like this to convert your PPP results to your local reference frame. This will give you what every other service should approach. If there are significant shifts, then the datums are not consistent.

3 Likes

ok - I think I’m getting somewhere.

So steps:

  1. Log and upload to CSRS
  2. Grab the Cartesian X, Y & Z
  3. Go to EUREF Permanent GNSS Network and enter X, Y & Z - set Frame to ITRF2020 - EPOC to (now) 2023.01 - and output to ETRF89 - EPOC 2023.01
  4. Grab output Cartesian X,Y & Z and convert to Lat/Long for Reach RS as base

Manually placing the converted base coordinates - landed it smack between RTKPremium and RTK Fix’s “clusters” but I guess that might work well enough.

More testing to do tomorrow…

Time for me an RS2 to Recharge …

Sounds good! Keep us posted.

But I’m still curious how much is the difference between different NTRIP services? They can differ a bit because of different baselines, but if it’s decimeters or more, that’s weird.

I’d only exclude RTK2Go from this comparison because of the things Gabriel named.

I’m not familiar with the UK CORS. If there are some local CORS, you can download their data and PP with your base station. That would be a good check and also a final position that is tied to the national network without possibly translating to different coordinate systems.

I PP all the time using local base and rover from our national CORS here in the US. using commercial multi base line processing software.

It’s a good check against RTK so-called “fix” solutions by post processing . Actually, it’s a lot of fun once you really understand the basics.

I don’t trust any single baseline RTK “fix” solution. Post processing always varifies your data.

3 Likes

@EBE111057 Hi Bryan:

What “commercial multi base line processing software” are you using?

I have spent some time with Trimble Business Center and learning to appreciate multiple baselines. I am wondering what other software is out there that support multiple static bases.

I notice OPUS solutions here in the States have three CORS stations listed in the processing report.

I appreciate this thread chasing centimeters.

Thank you for the conversation everyone.

Joe

Hi Joe, please see this post by Bryan using both Javad’s Justin 3 and CHC Geomatics Office 2 PP software for post processing. I believe they are both capable of using multiple baselines for processing.

More information on Javad Justin 3 here
https://www.javad.com/jgnss/products/software/justin3.html

And CHC Geomatics Office 2 PP software is available here:
https://iggps.com/cgo2/index.htm

There is also EzSurv, which has a rep here on the forum as well (@Effigis_OnPOZ )

2 Likes

I suggest you PPK your 24 hour observations with data from the nearest OS NRF and see where that gets you. The OS stations are ETRS89 so your position will transform to OSGB36 directly.

This is the difference I get from a static observation of six hours processed with RTKLib and AusPos:

RTKLib ETRS89 OS RINEX 2022/07/02
60.150999806 -1.143162572 71.6655
OSGB36: 447675.598 1141030.363 22.457

AusPos ETRF14 2022.05 FINAL
60.1510049658 -1.1431543943 71.968
—>
ETRF89 2022.05
3181925.9962 -63493.5549 5508932.2069
—>
OSGB36 447676.093 1141030.790 22.688

I have made several static observations processed with OS data and they are all within 50mm ENU, the same observations processed with AusPos have varied as much as 500mm when transformed to OSGB36.

I regularly use the OS processed base position for RTK surveys and the results are within 50mm of OS data in drawings.

FYI there is only one OS station here in Shetland, AusPos uses multiple reference stations but with some baselines over 600km away.

2 Likes

So just a follow up:

I have compared 3 NTRIP providers + “just average”

Procedure:

  1. Setup RS2 - set NTRIP provider (none for “just average”)
  2. Do a 2 min Avg. Base calculation (avg fix if possible)
  3. Do a 2 min avg. point collection (fix if possible)

The contenders:

  1. RTK2Go
  2. IGES provider - base 31km from me - so should be 7mm + 1mm / km uncertainty ? - so 38mm total
  3. RTK Premium (Same base network as Leica SmartNet - operated by UK Gov.) - base distance roughly 5km reported but I doubt it.
  4. Just averaging 2 min pos.
  5. Repeat above after 1 hour…

here is the image of how it went:

First capture with RTK2Go would not get a fix. So calc’s below are only based on the 2nd where I got fix. All other calculations are averaged

RTK2Go vs RTK Premium Easting : 0.575m
RTK2Go vs RTK Premium Northing 0.6705m
RTK2Go vs RTK Premium Height : 0.1055m

IGES vs RTK Premium Easting: 0.0845m
IGES vs RTK Premium Northing 0.1205m
IGES vs RTK Premium height: 0.0205m

I’ll update the 2m corrections after I have “transferred them” to current UK offset.

But it seems like RTK2Go does not have any corrections applied

I think AusPos is using satellite ephemeris data to compute a stations position. It doesn’t use any baseline processing. Long observation time is required to obtain a cm accuracy (+24hrs).

Here in the US , OPUS uses baseline data from various CORS to compute a position… OPUS also only uses GPS data and decimates all data submitted to a 30 sec interval.

NGS OPUS is supposed to be revised where other GNSS can be used. But I haven’t visited them lately to see.

2 Likes

For instance, about the 5 km baseline with RTK Premium → Note that if you are using a PRS-type mountpoint, the base is a virtual base, hence it is seen close to your rover wherever you will survey. The closest real base is probably further. It’s not something purely RTK Premium related, but any NTRIP provider using VRS or PRS corrections.

1 Like