Following was written by rtklibexplorer. As of now, all comments expressed on this page are of rtklibexplorer and the original source document can be found here.
I’ve added it here for ease access, as well as it’ll allow Google’s SEO engine to capture the content to help others as well as create even more awareness of rtklibexplorer’s top notch work. In the past, I’ve googled some of these settings and it would take me to released source code and not to either rtklib manuals.
static, kinematic, static-start, movingbase, fixed
If the rover is stationary, use “static”. If it is moving, use “kinematic” or “static-start”. “Static-start” will assume the rover is stationary until first fix is achieved and then switch to dynamic mode, allowing the kalman filter to take advantage of the knowledge that the rover is not moving initially. You can use “movingbase” if the base is moving as well as the rover, but it is not required unless the base is moving long distances. I often find that “kinematic” gives better solutions than “movingbase” even when the base is moving. “Movingbase” mode is not compatible with dynamics, so be sure not to enable both at the same time. If the base and rover remain at a fixed distance apart, set “pos2-baselen” and “pos2-basesig” when in “movingbase” mode. Use “fixed” if you know the rover’s exact location and are only interested in analyzing the residuals.
l1, l1+l2, l1+l2+l5
Use “l1” for single frequency receivers, “l1+l2/E5b” if the rover is using L2 GPS/GLONASS/Beidou and/or Galileo E5b., and “l1+l2+l5” for L5 GPS/GLONASS/Bediou and or Galilo E5a
forward, backward, combined
This is the direction in time that the kalman filter is run in post-processing. The “combined” mode 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. In “combined” mode the bias states are reset before starting the backwards run to maximize the independence of the forward and backwards solutions. In “combined mode-no phase reset”, the bias states are not reset to avoid needing to re-converge at the start of the backwards solution.. 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.
Minimum satellite elevation for use in calculating position. I usually set this to 10-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. Low elevation satellites will also have larger atmospheric errors so this is another reason to exclude the lowest elevation satellites.
Minimum satellite SNR for rover (-r) and base(-b) for use in calculating position. The optimal value will vary with receiver type and antenna type so I leave it off in the defaults but often enable it to improve results when working with more challenging data sets to remove low quality satellites.
Set SNR thresholds for each five degrees of elevation. I usually leave all values the same and pick something between 30 and 38 db depending on what the nominal SNR is. These values are only used if pos1-snrmask_x is set to on. If you are using dual frequencies, you will need to also set “pos1-snrmask_L2 and/or pos1-snrmask_L5”
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 no effect on “static” mode. Be sure to set “prnaccelh” and “prnaccelv” appropriately for your rover acceleration characteristics. Rover dynamics is not compatible with “movingbase” mode, so turn it off when using that mode.
off, on (Sat PCV)
Set whether the satellite antenna phase center variations are used or not. Leave this off for RTK since the antenna offsets will cancel. Recommended for PPP. but if set to on, be sure to specify the satellite antenna PCV file in the files parameters.
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.
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.
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. You can also force an unhealthy satellite to be used by prefixing the satellite number with “+”.
I almost always include all satellite systems available since more information is generally better. The exception is that SBAS should not be enabled if using the EGNOS satellites.
Integer ambiguity resolution method. “Continuous” mode does not take advantage of fixes to adjust the phase bias states so it is the most immune to false fixes. “Fix-and-hold” does use feedback from the fixes to help track the ambiguities. I prefer to use “fix-and-hold” for dynamic rovers and adjust the tracking gain (pos2-varholdamb) low enough to minimize the chance of a false fix. If “armode” is not set to “fix-and-hold” then any of the options below that refer to holds don’t apply.
0.1, 1.0 (meters)
In the demo5 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.1 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.
on, fix-and-hold, autocal
Integer ambiguity resolution for the GLONASS sats. If your receiver types are identical or both have zero Glonass hardware biases, you can set this to “on”. If your receiver biases are different you will need to account for the inter-channel biases. The easiest way do do this is to set this parameter to “fix-and-hold” In this case the GLONASS sats will not be used for ambiguity resolution until after the inter-channel biases have been calibrated which begins after the first hold. Alternatively, you can set this parameter to “autocal” and then specify the differential hardware offset between base and rover with the “pos2-arthres2” parameter. This will allow the GLONASS sats to be used for ambiguity resolution immediately and hence will generally give better performance than the “fix-and-hold” setting. The “autocal” feature can also be used to determine the inter-channel biases with a zero or short baseline using an iterative approach.
In the demo5 code, the gain of the inter-channel bias calibration for the GLONASS satellites can be adjusted with this parameter.
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 leave the nomiinal ratio 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.
If these values are set equal to pos2-arthres then the ambiguity resolution threshold will be fixed. Otherwise the threshold will be adjusted based on the number of satellites used in the ambiguity resolution. The nominal value is used for 8 satellite pairs and decreases with more satellites and increases with less satellite. The adjusted value is clipped by the min and max threshold limits. The adjustment rates are based on those used by the FFRT method but are adjusted only for the number of satellites and not for model strength.
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.
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 and are using a single constellation or single frequency 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.
Relative GLONASS hardware bias in meters per frequency slot. This parameter is only used when pos2-gloarmode is set to “autocal” and is used to specify the inter-channel bias between two different receiver manufacturers. To find the appropriate values for common receiver types, as well as how to use this parameter for an iterative search to find values for receiver types not specified, see this post.
Initial variance of the GLONASS hardware bias state. This parameter is only used when pos2-gloarmode is set to “autocal”. A smaller value will give more weight to the initial value specified in pos2-arthres2. I use 1e-9 when pos2-arthres2 is set to a known bias, and 1e-7 for iterative searches.
Kalman filter process noise for the GLONASS hardware bias state. A smaller value will give more weight to the initial value specified in pos2-arthres2. I use 0.00001 when pos2-arthres2 is set to a known bias, and 0.001 for iterative searches.
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 may need to 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 higher for other receivers.
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.
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.
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.
Experimental feature. Enabling this feature causes 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.
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.
20-100 (5-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 and time to reacquire a hold. As the ambiguity tracking gain is reduced (i.e. as pos2-varholdamb is increased), and the number of observations increases, arminfix can be reduced. Note that this value may need to be adjusted if the rover measurement sample rate changes.
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.
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.
Reject a measurement if the kalman filter residual are greater than this value in meters. Previous to the demo5 b33 code, this value was applied without adjustment to both code and phase measurements. In the newer versions, this value is still applied without adjustment to the phase measurements but is multiplied by eratio for the code measurements. This allows it to be set to values appropriate for the phase measurements. I usually set it to 1.0 which is very helpful to catch and reject unflagged cycle slips but occasionally find I need to set it higher. Setting it too low can cause the kalman filter to diverge with low quality data so I have set the default to 2.0 even though I usually use 1.0.
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.
No functional difference to the solution, just output more info to the result file.
No functional difference to the solution, just output more info to the result file.
No functional difference to the solution, just output residuals to a file. The residuals can be very useful for debugging problems with a solution and can be plotted with RTKPLOT as long as the residual file is in the same folder as the solution file.
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.
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. It can be estimated by running a solution with this value set to a large value, then examining the accel values in the solution file with RTKPLOT
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.
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. Although labeled approximate, this will normally be precise if you are using a rinex file from a CORS reference station. Otherwise, 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 where I don’t know the exact base location, I use the “single” option which uses the single solution from the data to get a rough estimate of base station location.
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.
Interpolates the base station observations. I generally set this to “on” if the base station observations sample time is larger than 5 seconds.