Improved Static AR Fix?

Been testing RTKLIB changes in RTKExplorer Demo1 and RTKLIB 3.4.3b9 recent developments.

On short baseline dual Reach static survey, my impression has been positive. Results for me have gone from skeptical to close to 100 percent RTKPost Fix solutions over a one hour test.

I use dual gps/Glonass and reject many satellites with RTKPOST. My tests have been near buildings & tall Pine Trees.

Has anyone else tested these recent versions? Any results to share?

1 Like

Hi Richard,

Rtklibexplorer does really great improvements. We are testing them and slowly merging into what is running on Reach. For example a recent fix regarding the solution loss when a new satellite would appear.


Sounds good to me.

Looking forward to future versions of ReachView


Could you list your Config settings used for the static points?

1 Like

Did you compare stock Reach software with rtklibexplorer fork and got significantly better results with the latter?

I would also be happy to see that! Especially your criteria for rejecting sats…


Rabun: Made a copy of config file for RTKPOST, but been too busy to post it. Will try to get it uploaded.

Igor: I’ve run some additional tests using the latest RTKLIB development releases and seem to do better with the RTKPOST processing on static AR Fix and Hold. I’ve recently got good results on a 2 meter baseline survey. With the Reach real-time RTK setup, I rarely get a good fix. With proper setup, I can get good fixes with obstructed sky views( Pine trees, etc.)

Johannes_Eberenz: The emphasis on improving the single carrier processing appears to be on identifying the possible slips and identifying how to lessen the effect on the resulting calculations. This is more difficult with the real-time processing, I can watch the coordinates zero in on a solution with Reach in float mode and then jump to start converging once again without getting into fix mode.

This subject is more likely to be of interest where the sky views are obstructed.

I use the sky view in RTKPLOT to identify satellites with slips. First, I make sure the receiver position in RTKPLOT is identified properly. Otherwise you may not get good satellite visibility plots.

I look at the RINEX files (Square Button to upper right of ,OBS files in RTKPOST). Look at the signal levels. The values will vary depending on the receiver and antenna. I try to set the minimum value of SNR a few db below the maximum levels of the weakest receiver. The assumption here is that bad data is likely to have a lower SNR.

Next, go to the satellite visibility buttom (The Round Button to the upper right of the .OBS file names in RTKPOST). This will bring up the satellites in view with their potential cycle slips. Find all the satellites with slips and reject them in RTKPOST configuration. If there are enough good satellites left(recommend GPS + GLO), your chance of a good fix is enhanced considerably.

These new versions of RTKLIB are developmental, so no guarantees.


1 Like

Oh, I believe GLO has to be checked in the RTKPLOT config to be seen in the satellite visibility plots.


1 Like

Rhanks! But this selection only makes sense when using the latest RTKLIB dev release? I’ll give it a try.

Hi Igor,

Yes, the jumps in fix/float mode appear to have not been as much in Reach real time mode lately. It seems as though the trend toward the fix mode gets better.

The Demo4 version has been doing well for me in post processing.

It seems that the cycle slips and satellite changes were significant
in compromised environments. UAVs get a pass in clear skies, but anything to help ground vehicles, bikers, surveyors, UAVs that get too close to trees etc., seems like a good deal to me and hopefully to the RTKLIB / Emlid community.

Hi everyone,

Since this topic was started, several improvements have been added by Emlid. RTKLIBEXPLORER has just posted the latest developmental version to provide improved FIX results. I know that several members on the Emlid forum follow those improvements and help with feedback.

This latest change appears to help in FIX retention. If anyone can test the DEMO5 latest code, it would be interesting to see the results.


See Reach News beta v2.2.2 . Even better…

Has anyone investigated the latest fixes from RTKExplorer?


Great improvements in last year. Do most of my RTKPOST with latest version. Emlid also has upgraded with improvements. See the DOCs. I must admit that i have not tested the Emlid upgrade because I get good results. For short baselines, I typically get 1 mm STATIC resolutions in reasonable skyviews and with less than 1 hour of data. Marginal locations are free of earlier data glitches.

Where to download RTKLIB 3.4.3b9?

Are you sure this is the version your are looking for?

Keep in mind that this is definitely Beta and different branches.

I’m using binaries posted in /downloads/rtklib-code/ as DEMO5.

Emlid version appears to have most upgraded versions, but the time corrections of last RTKExplorer binaries may not be there. (I don’t use time tags, so I would would watch out for possible time related effects after this change.) The latest version I have relates to improving realtime results. It seems to give better results on maintaining FIX in post-processing. I have not tried RTKNavi, so I don’t know if the improvements are there in realtime. I am using ReachView realtime which satisfies my needs.

One area that appeared to be improved in latest RTKExplorer was Combined forward-backward results. This is no help in realtime, but the data trend toward convergence and lock appears better in post-processing, so I don’t know why RTKNavi would not be be improved.

RTKLIB and RTKExplorer versions are similar , but not necessarily the same.

1 Like

With improvements thanks to RTKLIB, Emlid, and RTKExplorer, I find less need to choose rejecting satellites and signal strengths.

My last post for short baseline static was with good skyview. This is Emlid Reach with last RTKLIBExplorer Post Processing version. RTKCONV options as follows:


Environment: Poor Skyview both ROVER and Base. Much of sky blocked by Pine trees. Notice varying signal levels and SBAS blocked satellite.
Post Processing: forward + reverse ; 100% GPS+GLONASS+GAL+SBAS

Resolution less than 0.2 mm .

Did not test latest EMLID PostProcessing.

Time to forget last .2mm resolution and move on.

Very nice result! Please tell us a little more:

  • which AR modes did you have selected?
  • do your pics show the entire log or a portion of it? (Like did you log for 24hrs and then process the best hour from that?)
  • did you plan your mission ahead of time to have the most satellites in view?