I’ve obtain the coordinate of the base by connecting it to an NTRIP services but when I import de rinex file one Emlid studio, the coordinates are different.
Regarding the altitude, I figure that’s the difference between the geoid and the ellipsoid.
Concerning the latitude and the longitude, which one is right?
Thanks for your help!
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.
I hope it helps
Thanks a lot it is really helpfull!
I’ve tried to determinate the coordinates of my base (even I have it already with the rtk) but I wanted to control these coordinates in ppk.
And here is the result :
It looks pretty close but which one is more accurate?
The upload button does not allow me to join such a file.
@stevennefabian Hello Fabian!
When you said:
I’ve obtain the coordinate of the base by connecting it to an NTRIP services
I understood this to mean that you had connected to a known CORS and if so, for you to provide the published datasheet for that CORS. This will contain information to help in answering your question.
In the screen capture that you provided, it shows two bases, one base in the Emlid Flow app (on the left) and the other base shown in the Emlid Studio app. These are about 10 km apart.
If the western station is the originating streamed NTRIP source for the establishment of your eastern base, and if that western base is part of the NTRIP broadcaster (http://www.euref-ip.be) operated by the GNSS team of the Royal Observatory of Belgium (ROB), please read the note concerning the streamed locations on this page: http://www.euref-ip.be/
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.
Thanks a lot for your help,
To be clearer, I put the link with all the files needed here :
@stevennefabian Hi Fabian
I just got back into the office and will look at your data in the next day or 2 - not tonight. Tomorrow have field tests in Hancock, Maine
I took a look at the data.
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+?
Here are the resulting points, trying to take into account all the different heights.
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 CORS Stations
TIME: GPS ~ UTC; not local, e.g., UTC +2
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.
Thanks for your help.
Because I’m new in the party
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.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.