RTKLIB: Customizing the input configuration file

[This post is a little out of date at this point.  There is an updated version here]

One of the nice things about RTKLIB is that it is extremely configurable and has a whole slew of input options available. Unfortunately these can be a bit overwhelming at times, especially for someone new to the program. The RTKLIB manual does briefly explain what each option does, but even with this information it can be difficult to know how best to choose values for some of the parameters.

I won’t try to give a comprehensive explanation of all the input options here, but will explain the ones I have found useful to adjust in my experiments and include a little about why I chose the values I did. I describe them as they appear in the configuration file rather than how they appear in the RTKNAVI GUI menu but the comments apply to both. I created this list by comparing my latest config files to the default config file and noting which settings were different. The values in the list below are the values I use in my config file for a 5 Hz rover measurement rate.  The same config files can be used for either RTKNAVI, RTKPOST, or RNX2RTKP.

The settings and options highlighted in blue below are available only in my demo code and not in the release code but otherwise much of what I describe below will apply to either code.  Most of my work is done with Ublox M8N and M8T receivers with short baselines and these settings will more directly apply to those combinations but should be useful at least as a starting point for other scenarios.

SETTING1:

pos1-posmode = static, kinematic, static-start, movingbase, fixed

If the rover is stationary, use “static”. If it is moving, “kinematic” or “static-start”. I always require the rover to be stationary long enough to get first fix, in which case “static-start” usually works better because it take advantage of the knowledge that the rover is not moving initially. Use “movingbase” if the base is moving as well as the rover. In this case be sure to set “pos2-baselen” and “pos2-basesig” as well. Use “fixed” if you know the rover’s exact location and are only interested in analyzing the residuals.

pos1-frequency = l1

L1 for single frequency receivers,  L1+L2 if the rover is dual frequency

pos1-soltype = forward, backward, combined

This is the direction in time that the kalman filter is run. For real-time processing, “forward” is your only choice. For post-processing, “combined” first runs the filter forward, then backwards and combines the results. For each epoch, if both directions have a fix, then the combined result is the average of the two with a fixed status unless the difference between the two is too large in which case the status will be float. If only one direction has a fix, that value will be used and the status will be fixed. If both directions are float then the average will be used and the status will be float. Results are not always better with combined because a false fix when running in either direction will usually cause the combined result to be float and incorrect. The primary advantage of combined is that it will usually give you fixed status right to the beginning of the data while the forward only solution will take some time to converge. The 2.4.3 code resets the bias states before starting the backwards run to insure independent solutions. The demo5 code doesn’t reset the bias states to avoid having to lock back up when the rover is moving.  I only use the “backward” setting for debug when I am having trouble getting an initial fix and want to know what the correct satellite phase-biases are.

pos1-elmask = 15 (degrees)

Minimum satellite elevation for use in calculating position. I usually set this to 15 degrees to reduce the chance of bringing multipath into the solution but this setting will be dependent on the rover environment. The more open the sky view, the lower this value can be set to.

pos1-snrmask-r = off, pos1-snrmask-b = off,on

Minimum satellite SNR for rover (_r) and base(_b) for use in calculating position. Can be a more effective criteria for eliminating poor satellites than elevation because it is a more direct measure of signal quality but the optimal value will vary with receiver type and antenna type so I leave it off most of the time to avoid the need to tune it for each application.

pos1-snrmask_L1 =35,35,35,35,35,35,35,35,35

Set SNR thresholds for each five degrees of elevation. I usually leave all values the same and pick something between 35 and 38 db depending on what the nominal SNR is. These values are only used if pos1-snrmask_x is set to on

pos1-dynamics = on

Enabling rover dynamics adds velocity and acceleration states to the kalman filter for the rover. It will improve “kinematic” and “static-start” results, but will have little or no effect on “static” mode. The release code will run noticeably slower with dynamics enabled but the demo5 code should be OK. Be sure to set “prnaccelh” and “prnaccelv” appropriately for your rover acceleration characteristics.  Rover dynamics is not compatible with “moving-base” mode, so turn it off when using that mode.

pos1-posopt1 = off, on (Sat PCV)

Set whether the satellite antenna phase center variation is used or not. Leave it off for RTK but you set it for PPP. If set to on, you need to specify the satellite antenna PCV file in the files parameters.

pos1-posopt2 = off, on (Rec PCV)

Set whether the receiver antenna phase center variations are used or not. If set to on, you need to specify the receiver antenna PCV file in the files parameters and the type of receiver antenna for base and rover in the antenna section. Only survey grade antennas are included in the antenna file available from IGS so only use this if your antenna is in the file. It primarily affects accuracy in the z-axis so it can be important if you care about height. You can leave this off if both antennas are the same since they will cancel.

pos1-posopt5 = off, on (RAIM FDE)

If the residuals for any satellite exceed a threshold, that satellite is excluded. This will only exclude satellites with very large errors but requires a fair bit of computation so I usually leave this disabled.

pos1-exclsats=

If you know a satellite is bad you can exclude it from the solution by listing it here. I only use this in rare cases for debugging if I suspect a satellite is bad.

pos1-navsys = 7, 15,

I always include GLONASS and SBAS sats, as more information is generally better.  If using the newer 3.0 u-blox firmware with the M8T I also enable Galileo

 

SETTING2:

pos2-armode = continuous, fix-and-hold

Integer ambiguity resolution method. I like to think of continuous mode as an acquisition mode and fix-and-hold as a tracking mode. I normally use continuous mode for static solutions and fix-and-hold for moving rovers but if the raw measurement quality is good enough to maintain ambiguity resolution when the rover is moving then it is probably better to use continuous mode for moving rovers as well. This will avoid the risk of locking on to a false fix. If in continuous mode, a false fix will usually drop out fairly quickly but fix-and-hold will track a false fix for much longer. If “armode” is not set to “fix-and-hold” then any of the options below that refer to holds don’t apply, including pos2-gloarmode.

pos2-varholdamb=0.001, 1.0 (meters)

Starting with the demo5 b26b code, the tracking gain for fix-and-hold can be adjusted with this parameter. It is actually a variance rather than a gain, so larger values will give lower gain. 0.001 is the default value, anything over 100 will have very little effect. This value is used as the variance for the pseudo-measurements generated during a hold which provide feedback to drive the bias states in the kalman filter towards integer values.  I find that values from 0.1 to 1.0 provides enough gain to assist with tracking while still avoiding tracking of false fixes in most cases.

pos2-gloarmode = on, fix-and-hold

Integer ambiguity resolution for the GLONASS sats.  If your receivers are identical, you can usually set this to “on” which is the preferred setting since it will allow the GLONASS sats to be used for integer ambiguity resolution during the initial acquire. If your receivers are different or you are using two u-blox M8N receivers you will need to null out the inter-channel biases with this parameter set to “fix-and-hold” if you want to include the GLONASS satellites in the AR solution. In this case the GLONASS sats will not be used for inter-channel ambiguity resolution until after the inter-channel biases have been calibrated which begins after the first hold. There is an “autocal” option as well, but I have never been able to make this work.

pos2-gainholdamb=0.01

Starting with the demo5 b26b code, the gain of the inter-channel bias calibration for the GLONASS satellites can be adjusted with this parameter. Although not fully tested, the hope is that in addition, this parameter in conjunction with pos2-varholdamb will enable the possibility to null out the inter-channel biases for the GLONASS satellites when the tracking effect of fix-and-hold on the GPS satellites is not desired (i.e.. effectively continuous mode). This would be done by setting pos2-gainholdamb to a nominal value and setting pos2-varholdamb to a very large variance to push it’s tracking gain to near zero.

pos2-arthres = 3

This is the threshold used to determine if there is enough confidence in the ambiguity resolution solution to declare a fix. It is the ratio of the squared residuals of the second-best solution to the best solution. I generally always leave this at the default value of 3.0 and adjust all the other parameters to work around this one. Although a larger AR ratio indicates higher confidence than a low AR ratio, there is not a fixed relationship between the two. The larger the errors in the kalman filter states, the lower the confidence in that solution will be for a given AR ratio. Generally the errors in the kalman filter will be largest when it is first converging so this is the most likely time to get a false fix. Reducing pos2-arthers1 can help avoid this.  A larger number of satellites used for AR will increase the confidence level for a given threshold, so in theory at least, it makes sense to increase this if you are typically working with a larger number of satellites than normal.

pos2-arfilter = on

Setting this to on will qualify new sats or sats recovering from a cycle-slip. If a sat significantly degrades the AR ratio when it is first added, its use for ambiguity resolution will be delayed. Turning this on should allow you to reduce “arlockcnt” which serves a similar purpose but with a blind delay count.

pos2-arthres1 = 0.004

Integer ambiguity resolution is delayed until the variance of the position state has reached this threshold. It is intended to avoid false fixes before the bias states in the kalman filter have had time to converge. It is particularly important to set this to a relatively low value if you have set eratio1 to values larger than 100 or are using a single constellation solution. If you see AR ratios of zero extending too far into your solution, you may need to increase this value since it means ambiguity resolution has been disabled because the threshold has not been met yet. I find 0.004 to 0.10 usually works well for me but if your measurements are lower quality you may need to increase this to avoid overly delaying first fix or losing fix after multiple cycle slips have occurred.

pos2-arthres2, pos2-arthres3, pos2-arthres4

Defined but not used anywhere in the code, best to remove these from your config file

pos2-arlockcnt = 0, 5  

Number of samples to delay a new sat or sat recovering from a cycle-slip before using it for integer ambiguity resolution. Avoids corruption of the AR ratio from including a sat that hasn’t had time to converge yet. Use in conjunction with “arfilter”. Note that the units are in samples, not units of time, so it must be adjusted if you change the rover measurement sample rate.  I usually set this to zero for u-blox receivers which are very good at flagging questionable observations but set it to at least five for other receivers.

pos2-minfixsats = 4

Minimum number of sats necessary to get a fix. Used to avoid false fixes from a very small number of satellites, especially during periods of frequent cycle-slips.

pos2-minholdsats = 5

Minimum number of sats necessary to hold an integer ambiguity result. Used to avoid false holds from a very small number of satellites, especially during periods of frequent cycle-slips.

pos2-mindropsats = 10

Minimum number of sats necessary to enable exclusion of a single satellite from ambiguity resolution each epoch.  In each epoch a different satellite is excluded.  If excluding the satellite results in a significant improvement in the AR ratio, then that satellite is removed from the list of satellites used for AR.

pos2-rcvstds = on,off

Enabling this feature causes the the measurement variances for the raw pseudorange and phase measurement observations to be adjusted based on the standard deviation of the measurements as reported by the receiver. This feature is currently only supported for u-blox receivers. The adjustment in variance is in addition to adjustments made for satellite elevation based on the stats-errphaseel parameter.  I generally get better results with this turned off.

pos2-arelmask = 15

Functionally no different from the default of zero, since elevations less than “elmask” will not be used for ambiguity resolution but I changed it to avoid confusion.

pos2-arminfix = 100  (20*sample rate)

Number of consecutive fix samples needed to hold the ambiguities. Increasing this is probably the most effective way to reduce false holds, but will also increase time to first hold. Note that this value also needs to be adjusted if the rover measurement sample rate changes.

pos2-elmaskhold = 15

Functionally no different from the default of zero, since elevations less than “elmask” will not be used for holding ambiguity resolution results but I changed it to avoid confusion.

pos2-aroutcnt = 100 (20*sample rate)

Number of consecutive missing samples that will cause the ambiguities to be reset. Again, this value needs to be adjusted if the rover measurement sample rate changes.

pos2-maxage = 100

Maximum delay between rover measurement and base measurement (age of differential) in seconds. This usually occurs because of missing measurements from a misbehaving radio link. I’ve increased it from the default because I found I was often still getting good results even when this value got fairly large, assuming the dropout occurred after first fix-and-hold.

pos2-rejionno = 1000

Reject a measurement if its pre-fit residual is greater than this value in meters. I have found that RTKLIB does not handle outlier measurements well, so I set this large enough to effectively disable it. There was a recent bug fix in the release code related to outliers but even with this fix I found that I got better results with a larger value.

 

OUTPUT:

out-solformat = enu, llh, xyz

I am usually interested in relative distances between rover and base, so set this to “enu”. If you are interested in absolute locations, set this to “llh” but make sure you set the exact base location in the “ant2” settings. Be careful with this setting if you need accurate z-axis measurements. Only the llh format will give you a constant z-height if the rover is at constant altitude. “Enu” and “xyz” are cartesian coordinates and so the z-axis follows a flat plane, not the curvature of the earth. This can lead to particularly large errors if the base station is located farther from the rover since the curvature will increase with distance.

out-outhead = on

No functional difference to the solution, just output more info to the result file.

out-outopt = on

No functional difference to the solution, just output more info to the result file.

out-outstat = residual

No functional difference to the solution, just output residuals to a file. The residuals can be very useful for debugging problems with a solution.

stats-eratio1 = 300

Ratio of the standard deviations of the pseudorange measurements to the carrier-phase measurements. I have found a larger value works better for low-cost receivers, but that the default value of 100 often work better for more expensive receivers since they have less noisy pseudorange measurements. Larger values tend to cause the kalman filter to converge faster and leads to faster first fixes but it also increases the chance of a false fix. If you increase this value, you should set pos2-arthres1 low enough to prevent finding fixes before the kalman filter has had time to converge. I believe increasing this value has a similar effect to increasing the time constant on a pseudorange smoothing algorithm in that it filters out more of the higher frequencies in the pseudorange measurements while maintaining the low frequency components.

stats-prnaccelh = 1.0

If receiver dynamics are enabled, use this value to set the standard deviation of the rover receiver acceleration in the horizontal components. This value should include accelerations at all frequencies, not just low frequencies. It should characterize any movements of the rover antenna, not just movements of the complete rover so it may be larger than you think. It will include accelerations from vibration, bumps in the road, etc as well as the more obvious rigid-body accelerations of the whole rover.

stats-prnaccelv = 0.25

The comments about horizontal accelerations apply even more to the vertical acceleration component since in many applications the intentional accelerations will all be in the horizontal components. It is best to derive this value from actual GPS measurement data rather than expectations of the rigid-body rover. It is better to over-estimate these values than to under-estimate them.

ant2-postype = rinexhead, llh, single

This is the location of the base station antenna. If you are only interested in relative distance between base and rover this value does not need to be particularly accurate. For post-processing I usually use the approximate base station location from the RINEX file header. If you want absolute position in your solution, then the base station location must be much more accurate since any error in that will add to your rover position error. If I want absolute position, I first process the base station data against a nearby reference station to get the exact location, then use the ”llh” or “xyz”option to specify that location. For real-time processing, I use the “single” option which uses the single solution from the data to get a rough estimate of base station location.

ant2-maxaveep = 1

Specifies the number of samples averaged to determine base station location if “postype” is set to “single”. I set this to one to prevent the base station position from varying after the kalman filter has started to converge since that seems to cause long times to first fix. In most cases for post-processing, the base station location will come from the RINEX file header and so you will not use this setting. However if you are working with RTCM files you may need this even for post-processing.

Please help me update this list if you have had success adjusting other options or using different settings for these options, or if you disagree with any of my suggestions. I will treat this as a working document and continue to update it as I learn more.

24 thoughts on “RTKLIB: Customizing the input configuration file”

  1. Thank you for the useful post,
    I am working on a project investigating the different impact using GPS only and GPS+Galileo on the ENU accuracies and the TTFF. For this purpose, I am using the RTKLIB command to post-process (rnx2rtkp) the data as PPK. There are cases in which I don’t get convenience results and I can say one of the factors is the configuration parameters.

    I am kindly asking if you have figured out optimized parameters for the configuration option, specifically, setting 2 and statistics.
    Besides of your useful post, what other sources would you recommend to get detailed knowledge about the meaning of these parameters?
    This question might not be very related to this post, what is the reason that sometimes the post-processing of a baseline results in alternating float to fix solutions. I mean, what makes the solution to go back to float after the first fix and change at some epochs?

    note: I am using RTKLIB v.demo5 b33b2

    Like

    1. Hi Peshawa. There is information on the config parameters in the RTKLIB 2.4.2 manual which you can find online and I have additional info in this post. I also have some suggested values for the config parameters in the sample config files that are included with the demo5 exectuables.

      Liked by 1 person

  2. Hi rtklibexplore!
    So I have data from two CORS stations together with there navigation files. And I have also downloaded their IGS products ( final, rapid and ultra rapid orbit and clock ) together with precise ephemeris. I want to use one of this CORS station ad rover and the other as base. My aim to prove that using precise ephemeris and IGS products will provide more accuracy in positioning that using broadcasting ephemeris. So how do I do this wI think RTKlib and at what main information should I be focused on the results that will define what I want to achieve.

    Like

    1. Hi Kilimaba07. RTKLIB has options to use precise ephemeris/clock files, details are in the user manual. For short baselines, you will see very little improvement with the additional files since the errors are primarily cancelled through the double differencing. As the baselines get long enough you should start to see an improvement. The CORS stations list their precise coordinates so it should be easy to compare the errors in your solutions with and without precise ephemeris.

      Like

  3. Thanks a lot for this post, really really useful!

    There is a problem I usually face, which is that I can’t be sure that the provided settings were really the ones used by RTKLIB. Do you know how can I retrieve the configuration file that has been used? I think I was able at some point to make RTKLIB generate a rtklib_sol.pos.conf file, which contained the settings used. But I can’t find the way to do it again.

    Having this could be very useful to know RTKLIB’s defaults.

    Like

    1. Hi Toni. Both RTKPOST and RTKNAVI have a GUI button under the “Options” menu to save the current configuration to a file but you would need to do this manually. I usually use the RNX2RTKP command line app to calculate post-processed solution and call it from a script that also automatically saves the config file to the same folder as the solution.

      Like

      1. Thanks for your reply! I also rather work with RNX2RTKP, than using the GUI. But I am not sure if I understood your comment. I run RTKLIB like this: “rnx2rtkp rinex_file orbits_file -k config_file”. Say config_file only has a couple of entries, e.g “pos1-posmode =single” and “pos1-navsys =5”. What I would like to know is, what are the settings that RTKLIB is using for the rest of configurations that I have not specifically provided? Did you find a way to retrieve the full configurations that have been used?

        Like

        1. Hi Toni. OK, I understand better now what you are looking for. I don’t think there is a direct way to do that. If you want to get a list of all the default values you can do this by deleting rtkpost.ini (to remove any saved options), then run rtkpost and save the options to a file. The resulting file will list all the RTKLIB config parameter defaults.

          Like

  4. Excelent post. Do you have a post on how to perform a static post processing using both GPS and GLONASS constellation ? I DON´T know how to specify files.

    Like

    1. Hi Agos. Constellations used for the solution are specified with the “pos1-navsys” input parameter. My post was intended to be a supplement to the RTKLIB manual available on the RTKLIB website. It is a good source for the basics of using RTKLIB.

      Like

      1. I know. But the RTKLIB doesn´t take in both nav files (GPS and GLONASS) at the same time when I input the path of them. and the manual doesn’t say how. It just explain for one nav file

        Like

          1. Hello rtkexplorer. I use wildcards to specify nav input files to RTKLIB (something like c:\rover.*) and the reading of the multiple nav files (GLONASS AND GPS) is done but on the output file there are no processing chords. Have no idea what I’m doing wrong

            Like

  5. If you are worried about false fixes increasing the ambiguity ratio (pos2-arthes) from 3 to 5, 7, or even 10 will help with that. The default ratio of 3 is a good choice, but even under ideal conditions it will occasionally result in a wrong fix.

    You are trading time for reliability. If using only the GPS sats it could potentially add (many) minutes to your fix time. If also using other sats (Glonass, SBAS, Galileo, …) the additional time required will likely be much shorter. This makes the most sense when using two M8Ts and you don’t have to worry about bias calibrations.

    Like

  6. Hey,
    small question: what are the requirements to switch from Continous to Fix-and-Hold?
    just the following: (Min Fix Sats, Min Hold Sats, Max Pos Var for AR) ?

    Best
    u-Bloxer

    Like

    1. Hi u-Bloxer. The difference between “continuous” ambiguity resolution and “fix-and-hold” is that in fix-and-hold the results of the ambiguity resolution are used to adjust the phase-bias states and in “continuous” they are not. This is the hold part of “fix-and-hold”. Until all the criteria are met for the hold, “fix-and-hold” and “continuous” ambiguity resolution are identical. So if I interpret your question to be what input parameters are used to qualify the hold after fix has been achieved, then the answer would be “arminfix” (number of consecutive samples with fix), minholdsats (min # sats used for AR), and elmaskhold (sats below this elevation can be used for fix but not for hold).

      Like

  7. Hi!

    !!!THANK YOU VERY MUCH!!! THIS is the document many people are waiting for!!!

    My question for:
    pos1-dynamics = on
    Be sure to set “prnaccelh” and “prnaccelv” appropriately for your rover acceleration characteristics.

    I am agricultural with software from cesar. (i use reach).

    what are good settings for “prnaccelh” and “prnaccelv” or how can i find it out?

    Regards Andreas

    Like

    1. Hi Andreas. I think the easiest way to choose settings for prnaccelh and prnaccelv is to plot some of your existing solution data using RTKPLOT. You want to plot the accelerations. Prnaccelh and Prnaccelv should be set to one standard deviation for horizontal and vertical accelerations so pick values from the plots that would include roughly 68% (one sigma) of the acceleration data.

      Like

  8. Hi, another thing is: I know you’ve tried to setup a base station via STR2STR, then output RTCM3 to RTKNAVI via radio-link, how about the config files for STR2STR and RTKNAVI? For now, I can get your demo5 config file of RTKNAVI which is for two serial ports M8N/M8T modules inputting with ublx message, but no RTCM3 related. Tks~

    Like

  9. Thank you very much. This is very helpful.
    I have a couple of questions. 1. How to calibrate the inter-channel biases if the two receivers are not the same if I want to set pos2-gloarmode = on? 2. How do I know a fix is a false fix? I read your post and had this question when you mentioned to avoid false fix.

    Like

    1. Hi Ywangnokia. Setting “pos2-gloarmode=fix-and-hold” will enable GLONASS integer ambiguity resolution and calibrate out the inter-channel biases using an extension to fix-and-hold that I describe in this post. There is another option to set “pos2-gloarmode=autocal” in the release code which is also supposed to calibrate the biases but I have not been able to make that work.

      Identifying false fixes can be difficult, especially when “fix-and-hold” is enabled since the false fix can stay locked for a long time. If you know the rover is stationary, it may show up as a gradual drift in the position. Sometimes even when the rover is moving, if the movement is primarily in the x and y directions, a similar drift can be detected in the vertical position.

      Liked by 1 person

        1. Hi rogerzyj. I have not tested my changes in rtkrcv but the code is almost all common so they should work. The reason I had to make updates for RTKNAVI and RTKPOST was only to update the GUIS for the input options.

          As you mentioned the additional RTKNAVI-specific settings that I use are in the config file in my demo5 folder. Since my base station had only a receiver and a radio, no CPU, and the Ublox M8N is not capable of outputting raw measurements in RTCM, I sent the raw Ublox output over the radio, rather than RTCM. I believe it should be fairly straightforward to convert the raw output to RTCM with STR2STR but I have not done it.

          Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.