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.
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.
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?
Reach RS2 - set to Base according to Base setup instructions.
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.
Do 24 hour log - process via CSRS (Static - ITRF) - get averaged base position Y
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.
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.
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?
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.
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.
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.
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.
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:
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.
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.
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.
