Improved Static AR Fix?


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?

I did not plan for maximum satellites. The results are for complete log. And Forward first good fix at about 5-7 minutes, so see upload for expected real-time forward only…

I’m not sure how much testing of this latest version has been done as some of the revision seem a little hard to decipher in the RTKLIBexplorer blog. I also don’t know if they can be used realtime.
He has recently started testing low-moderate priced L1L2 receivers, so I don’t expect any upgrades. Most of the last changes are changes in the RTKCONV module.
EDIT Corrected RTKLIBExplorer Forward. Typo error on my RTLCONV OPTIONs.

Note that processing FORWARD only and selecting only FIX after good FIX yields the same ENU values as the FORWARD-REVERSE plot. The FORWARD only yields slightly increased STDDEV. In this case, it is insignificant compared to my placement accuracy.

Sample rate was 5Hz…

1 Like

Hello all,
This is a conceptual question.
As per my knowledge from the books I’ve read, fix status is achieved when the integer ambiguity of the carrier wave is resolved by the gps receiver, anyone have an idea how does this happens in reach, moreover on what factors and settings the fix status what external factors and what settings in the reach view app.
Thank you!

To my understanding this is how its done in Reach. Please do correct me if im wrong

1 Like

So, here is same data with Emlid RTKCONV and using same options. Emlid RTKCONV PPK forward got FIX sooner (by several minutes) than other RTKCONV. COMBINED results were very similar (0.2mm).

I am impressed…


0.2mm… That is ok :wink:

What is the difference between EMLID RTKCONV and “other RTKCONV”? Also, isn’t this PPK done in RTKPOST not RTKCONV?


I’m not sure what the difference is between the Emlid and RTKExplorer last update. Apparently, it is not much.

Yes, the processing is done with RTKPOST. However, in post processing, the raw data UBX files are converted into .OBS RINEX files by RTKCONV. It is my understanding that some the recent changes were in the RTKCONV application and had to do with transitions between good and bad satellites making loss of lock less likely.

(Please note that GLO Fix&Hold works here because ROVER and BASE receivers are identical.)

Now you can directly log and download the RINEX files from the latest version of reachview app eliminating the use of rtkconv.

Edit**** Corrected FORWARD plot for RTKLIBExplorer…See previous plots… Not too shabby for obstructed sky both Rover and Base…Good correlation with Emlid post processing.

I have had successes with the RTKExplorer binaries lately as well - also with obstructed sky. For static points, I was using all available constellations, static mode, continuous AR, minimum 40 SNR, and a 5Hz log.

1 Like

It appears that Emlid Post Processing is either the same or close to RTKLIBExplorer latest version. What may be missing in the Emlid DOCs is the OPTIONS entries and mask modifications. In my view, they are so close that I don’t see much difference. I have not tried new RINEX logs saved by ReachView to do post processing.

In terms of masking, everything below 15 degrees is usually much noisier, 35-40dBhz mask on SNR will be good as well. It is not really that critical to get it “exactly right”. It is just a tool to exclude data that is definitely bad.

I agree. The mask setup, though, that I was referring to was the signal mask in RTKCONV .

Looking good…