Getting agreement between RTKLIB and Emlid Studio

First, I would like to give thanks to the Emlid Studio team for a fine, easy-to-use product. Also, thanks to the developers of RTKLIB and Tim Everett’s extension’s to RTKLIB.

I am trying to get the same results in RTKLIB as I do in Emlid Studio. I am using Emlid Studio (ES) Version 1.7 and RTKLIB v Demo5 b34i. I am assuming that this is version of RTKLIB that has the most similar engine to ES.

The reason I want to do this is to see what additional gain in accuracy I can achieve in RTKLIB by providing precise ephemeris and clock data, which is something that I am unable to do in ES. But before I add that data I want to make sure that my results without precise Eph/clock data agree between ES and RTKLIB. My problem is that I am getting quite different answers between ES and RTKLIB, with a discrepancy of 1-3 m depending on the RTKPOST settings.

This is part of a trial in which I am trying to assess performance of different GNSS receivers under forest canopy and I have used a total station to get the coordinates of my peg (uncertainty ~20 cm).

For a static survey of 60 minutes the solution that ES gives (using differential corrections from a CORS station 83 km away plus the navigation file) has an accuracy of 42 cm and a precision (2DRMS) of 4cm.

For exactly the same data inputs, the solution that RTKLIB gives has an accuracy of 151 cm and a precision of 58cm.

These statistics are worked out on just the float solutions only - I am seeking decimeter rather than cm accuracy - and the fixed solutions seem to be unreliable due to the multipathing under forest canopy. However, if I choose all solutions (fixed and float) or just fixed, I get the same sort of descrepencies between ES and RTKLIB.

So, it seems that some of the settings in RTKLIB which are not accessible to the ES user are different. I have tried to work out what they are but have not succeeded.

My Emlid Studio Settings are:

My RTKPOST settings are



Are there any settings in RTKPOST shown here that would cause it to give a significantly different result than ES?

It would be great to know what the ES ‘hard-wired’ settings are for those parameters available in RTKPOST that are not accessible to the ES user.

For instance,

  • does ES use the “Broadcast” setting for the Ionosphere Correction?
  • What values does ES use for the ratio to fix ambiguity? (Min/Nom/Max)

I’d be very grateful for anyone’s help with this.


A few thoughts …

First you want to get at potential improvement with precise ephemeris and clocks? Obviously they are needed for PPP, but for differential they don’t do much at all. There is an old saying that if the baseline is less than 100 km don’t bother. Last century I did some testing with GrafNav which is now NovAtel software I believe and found no improvement in 500-1000km baselines. Later I found a white paper from NovAtel that said yes precise sp3/clk help, but the data in their paper didn’t show it. In theory it should help a little, but in practice it didn’t.

Fast forward to this century and RTKLIB. I thought I’d try it again, but had the same result with RTKLIB on 500-1000km baselines. No improvement. Actually slightly worse, but well within noise level. My guess would be minor bugs in the software, but even so the theoretical improvements are very small. Note that current GNSS nav data is much better than say back in 1990.

My testing above was with ideal GPS data. Now you want to throw in “forest cover” data. Forest cover can mean much different things. A near desert environment during the dry season with sparse trees versus a rain forest with thick vegetation and mountains thrown in for good measure. In a flat area with vegetation the primary issue is the amount of water in/on the vegetation. That makes a huge difference. You can’t just say forest cover without quantifying it.

I doubt you will find any significant improvement with precise nav data and differential processing. It sounds good, but just doesn’t really matter. Of course doing your own tests is always a good thing.

If you really think there is improvement to be had take the forest cover variable out of it and try CORS base station data collected under ideal conditions.


Hi @mcmillanan,

Welcome to the community, and apologies for the radio silence here.

Emlid Studio is specially designed to work optimally with Reach devices. The software is based on one of the RTKLIB builds and not on the rtklibexplorer version.

Therefore, it may not even be possible to configure the rtklibexplorer build you’re using to give the same results as Emlid Studio.

I also suggest comparing the results between Emlid Studio and RTKLIB with the data collected under good conditions. Float solution gives you a decimeter level of accuracy, so comparing the results between the two post-processing software would not be ideal.

If you see that the difference under ideal conditions is significant, please feel free to reach out to us and we’ll investigate the issue further.

I’ll also discuss with the team about the settings not accessible in Emlid Studio that are present in RTKLIB.


I’m interested in this thread because I want to understand (not just ignore) the differences I’ve observed between my RTKLIB and Emlid Studio solutions. There can sometimes be meaningful differences between the ultra rapid, rapid, and precise ephemerides, which is really the only reason I keep up with RTKLIB (because Emlid Studio doesn’t allow substitutions).

That said, I don’t think any of these fine details matter much under forest canopies, esp. after leaf-out. There’s usually so much signal perturbing material and moisture overhead that you’re going to get multi-path-related scatter that cannot be filtered out.