RTKLIB static difference between combined/forward/backward

Hello

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)

Here are the plots of each coordinate :

So I have quite a lot of question :

  1. Why is combined not performing well compared to backward and forward methods here ?

  2. 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,

  1. 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 ?

  2. 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 ?

  3. 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

  4. 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

  1. 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 ?

  2. 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

Thanks for your help

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.

1 Like

Thanks Wombo for your feedback.

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

  1. 6h+ hours for centimetric accuracy. Noted
  2. 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.

1 Like