I have some basics in surveying but I am looking for some advices on some discrepancies I came across while trying to georeference a station we set in the field. I am processing the result with RTKlib 2.4.2 in static mode to use a nearby base station and trying to acheive the best available accuracy (which would be centimetric I believe considering our configuration).
As I am not experienced with RTKlib, here is my configuration to rule out any beginner mistake (ambiguity resolution is continuous and I am not sure about the calibration files for antennae):
back to my problem, the results are quite different depending on wether I am using the forward/backward/combined mode. I found this article quite helpful PPK vs RTK: A look at RTKLIB for post-processing solutions – rtklibexplorer
Similarly, I thought “combined” would give the best result in most cases, but it turns out not as can be seen here. The position saved if I put the output in “single” is one of the points on the down left side, while the rest of fixed solutions seem more appropriate (and because I checked with another data source for the same obs)
Why is combined not performing well compared to backward and forward methods here ?
seeing the plots, I feel that there is quite a lot of incertitude/moving going on on the coordinates for an immobile station on the field, is that normal ?
Regarding acquisition,
using a known base station from an official station network (SGIL from RGP in my example), should i use the coordinates filled in the rinex header of the base station ? or overwrite them with exact coordinates from the official website for this station ?
There were some high trees nearby (like 50m high, 25m away from the gps station). While I know clear areas are better to survey in, is there a general advice on the distance one should keep with high trees ? 10,50, 100m ?
How much time is necessary to acheive a centimetric accuracy, in some cases, the base station was set up for an hour and a half, and I am concerned it could not be enough. I was thinking 3h would be a minimum, 5h good
The height of the gnss was not measured on the field, although the antenna height is filled (1m or 1m80 depending on acquisitions) in the RINEX header file. Is the only concern the height accuracy or can it negatively influence the convergence of computations too ?
And more regarding RTKlib / coordinates reference frames
The output coords are in WGS84, to which ITRF does it correspond ? From what I understand, the current WGS84 reference frame is the G2296 from the WGS84 G series, which is aligned to the ITRF2020. However, I can’t find the epoch at which it is aligned.
So I suppose the resulting coordinates (as well as most hardware/softwares working with WGS84) are aligned with ITRF2020 and not ITRF00 (current epoch). Am I right ?
Edit: How to correctly estimate the accuracy of the result ? It seems RTKlib gives the last fixed position as result if you ask for “single” output. Shouldn’t it be maybe a weighed mean or median of all the fix solutions found ? I though the standard deviation elements (which were around 1cm) would indicate the true position is clearly within this interval but it seems not
RTKLIB is a great tool capable of precise results, but requires a lot of knowledge and considerable work and care. It’s quirks and inconsistencies can trap the unwary and can easily produce worse results than other options.
If a primary objective is learning it’s a great option, otherwise Emlid’s own Emlid Studio built around RTKLIB makes things a whole lot easier. The accuracy will still be dependent on base integrity and distance. E.G. at 1ppm that means you will be accumulating an additional 1cm uncertainty for every 10km.
If you simply want to accurately coordinate the point, there are better and easier options. For example AUSPOS will provide a robust global ITRF2020 solution (yes even in France). To achieve the centimeter requirements aim for an observation of 6+ hours.
Better still, do all of the above, play around and learn from it.
But whichever way the trees are likely to be a problem.
While my goal here is indeed to accurately coordinate the point, I am still curious in case the explanation can fit in a post.
In all cases, thank you a lot for these solutions, Auspoc alone helped me tremendously to understand a problem I was struggling with for weeks as I could make a comparison with other results I had. I will have a look at emlid studio too
To summarize the current answers I got/understood
6h+ hours for centimetric accuracy. Noted
the output coords from rtklib in reality seem to be in the same frame coordinate than the base station, even if the output is indicated “WGS84”. So in my case it was in the same as the RGP, so RGF93
The first answer would have to be regarding the trees, ideally you want clear sky all around above an elevation mask of about 15 degrees. Sounds like you have at least some obstruction up to 63 degrees.
Best understand and deal with that first before potentially chasing your tail on their impact. Multipath from trees and buildings is the biggest contributor to erratic results and possibly relating to some of the other questions.
A good base would normally populate its calibrated position in the “approx position xyz” in the Rinex header but if you are not sure just enter the known coordinates manually.
The actual rover antenna height is not going to impact the ambiguity resolution calculations provided it’s steady during static.
And yes, your output coordinates will be in whatever system the base is configured for and its normally a plate fixed datum.
Indeed, you are right about the trees, unfortunately I wasn’t there for acquisition but will be careful about it next time. How did you arrive at an obstruction up to 63 degrees though ? A simple tangent gives me a distance to keep of 14 meters from 50m high trees for a 15° angle (although I would consider it as a bare theoretical minimum)
I had a try with Emlid studio software, and the results are extremely good with combined and continuous for GPS, as you can see (24k points fixed with barely more than 5mm outliers), to the point it’s suspicious. Either I messed up with a basic option, or emlid studio does something really specific behind the scene. Do we know if it makes use of precise ephemerides/clocks ?
The angle is above the horizon, not off vertical. Your original guesstimate of 50m high at 25m gave 63 degrees above the horizon. If they are only 15m away that’s much worse at 73 degrees above.
Mid’ish angles provide the strongest position geometry but you don’t want to go too low, partly due to more obstructions down here but mostly because it results in signals travelling for longer distance through the atmosphere at low elevations and that causes more significant havoc. Hence below 10-15 degrees is normally masked out in processing. You can see the negative impact on the signals in your plots outside the 15 degrees circles (and therefore below 15 degrees).
Compare your Studio result to an AUSPOS position and see how it stacks up. You will need to do your own transformation to the base datum once you confirm it.
The angle is above the horizon, not off vertical. Your original guesstimate of 50m high at 25m gave 63 degrees above the horizon. If they are only 15m away that’s much worse at 73 degrees above.
My bad, it was an error on my part in my computations indeed. I may have oversized them also, the local digital surface model gives me 10m high trees, which are situated (I’m sure of the distance) at 25m, so they block up to 20° if i’m right.
With respect to emlid studios (after datum transformation), results are indeed good and coherent with AUSPOS (1,4cm difference on this one and 3,3cm on another short acquisition of 3 hours).
I will clearly stick with emlid studio instead of rtklib for the rest, but I’m curious as to how they acheive such good precision
Very common and expected, manufacturers clearly have deep knowledge of their own equipment and how it performs so their software is optimized to suit and generally works best for their gear.
In this case the optimum RTKLIB settings for the RS2/3 devices and the particular circumstances are baked in where we can’t mess them up, and presumably also EMLID RS2/3 specific enhancements have been added into the Studio code.
There may be extreme circumstances where you may be able to tease out better results from RTKLIB yourself but you will need a lot of knowledge & experience.
Hi,
In bad conditions (narrow streets with tall buildings), I had worst result with combined than with forward/backward so I had to increase the elevation mask to limit multipath errors.
By the way why do yo use only the GPS constellation and not the other ones (GLONASS, Galileo, etc…) ?
Be cautious with global PPP calculation provider like AUSPOS or NRCan, which give a result in ITRF2020 which will be slightly different from local one. If you are in France you can use the PPP service from IGN which provide a result in local coordinates : Calculs GNSS PPP en ligne | RGP
Unless you use some kind of field verification or by using another post processing engine like NGS OPUS, AUSPOS or other methods like closed GNSS traverse loops, you’ll never truly know the accuracy of the point despite all the glorious statistics of the computed single baseline processor.
Unless you have some kind of verification, single baseline processors will bite you in the *ass
I saw that others have already addressed your questions. @wombo is correct. Emlid Studio can be especially helpful in your case. It’s great to hear you’ve achieved good results with it!
but I’m curious as to how they acheive such good precision
The Emlid Studio is optimized specifically for Reach devices, using tailored presets and algorithms that align with their hardware for more precise and efficient processing.
