It would help if you included the datasheet of the base that the RTN service used for the corrections that you received along with the .pos file from Emlid Studio where you observed any differences.
After looking at that information, the answer may become clearer.
In Emlid Studio the RINEX Header Position is used by default. If you placed your base over the point with known coordinates you need to enter them manually, including the antenna height.
The default coordinates you see in Emlid Studio coming automatically from RINEX header are not FIX coordinates, they’re only averaged during your RINEX log. This is why they’re different to the one you collected using NTRIP corrections with FIX.
The other thing that will be of interest and is of vital importance, is understanding the reference frame, and its particular realization that’s used by the originating streamed source. This link is a good place to start if you haven’t already studied it:
I’m not sure of much, but went looking for your western base. It appears to be in strip of woods between an off ramp and the main highway.
You can almost make it out using the little Google guy and Street View.
Used MAFA and TELL to work out the position of the “localhost” base, and then referenced that from the Rover, using the CSV files.
It seems that the Rinex embedded positions from MAFA and TELL are in the same system and reasonably aligned. 1 cm difference in XY and 0 cm in Z.
One question though, why not use your RS2 as base instead of the RS+?
I don’t have time right now to reprocess this for you as I have to prepare to leave for a testing session over in Hancock, Maine, and it looks like @wizprod has got you very well covered using EZsurv; however, here are some things that might still be of interest:
The RINEX files that you shared for TELL & MAFA contain spot on x,y,z header values.
While your [localhost_raw_20230522103048.23O] may have collected for 5 hours and 25 minutes, its time common with the CORS data was 1 hour and 40 minutes.
Just to affirm, and to confess I sadly don’t read/ speak French, but it appears the reference frame is ETRS89 and you’re using the Belgian Lambert 2008 projection (epsg:3812)
I attempted to set up an account at http://184.108.40.206/sbc/ looking to see if they offer RINEX downloads for a VRS close to your project which could then be used for your post processing in Emlid Studio, but it’s probably best for you to look into yourself.
The 3D distance between these two points is 4.4 cm. But you can’t determine which one is more accurate until you check the rover coordinates on a known benchmark using different base coordinates. And this requires getting back to the base and reconfiguring it.
I had a fixed really quickly and very stable, so I thought it was enough to have an accurate measure of the base. I let it recording because I had to measure some GCP who were not in a good situation (house, trees, lower altitude…)
I thought it was better to work with the RS2+ to measure them, that’s why I needed to work in PPK because I had no fix at all for these points.
Here we did the field survey starting the base with Ntrip correction. However, sometimes the baseline is met, so we always process the UBX/RINEX of the base in the IBGE PPP service to check if the initial position obtained through Ntrip is ok.
In fact, over long distances there is a significant difference, mainly using Ntrip from IBGE. I believe that because of the limitation of traffic and access to data.
Another important issue is to analyze the accuracy of the equipment in terms of ppm. In M2 we have: Horizontal static 4 mm + 0.5 ppm, that is, we will have 4 mm of precision + 0.5 mm per km of baseline.
In one case, the difference between the base coordinate obtained in real time by Ntrip and that obtained by PPP was 9cm (horizontal).
We adopt the following practice here: if the coordinate obtained by Ntrip is close to the PPP (<5cm for example) we keep the Ntrip coordinate, otherwise we adjust the entire survey based on the PPP coordinate. This is for surveys of rural properties.