It’s been quite a while since I’ve updated my guide to the RTKLIB configuration file. Since the last update I’ve added a couple of new features and learned a bit more about some of the existing features. For previous updates, I’ve just updated the original post, but this time I thought I would re-publish it to make it easier to find.
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 software. 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 for RTK solutions with Ublox M8N and M8T receivers and short baselines and these settings will more directly apply to these combinations but should be useful at least as a starting point for other scenarios.
This post is intended to be used as a supplement to the RTKLIB manual, not as a standalone document, so please refer to it for information on any of the input parameters not covered here.
pos1-posmode = 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.
pos1-frequency = l1
“l1” for single frequency receivers, “l1+l2” if the rover is dual frequency GPS/GLONASS/Bediou, “l1+l2+e5b” if Galileo E5b is included. Starting with the dem05 b33 code, Galileo E5b is included in the L2 solution, so “l1+l2” is equivalent to “l1+l2+e5b”
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 always 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 if ambiguity resolution is set to “continuous” but does reset them if it is set to “fix-and-hold”. 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 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.
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.
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. If you are using dual frequencies, you will need to also set “pos1-snrmask_L2”
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 “movingbase” 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.
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.
pos2-armode = continuous, fix-and-hold
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” 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, including pos2-gloarmode.
pos2-varholdamb=0.001, 0.1 (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.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, autocal
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 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 in the 2.4.3 code. In the demo5 code I have added the capability to this feature to preset the initial inter-channel bias, variance, and calibration gain. I then set the biases to known values for the particular receiver pair and set the gain very low. This defeats the auto calibration aspect of the feature but does provide a mechanism to specify the biases which is otherwise missing in RTKLIB. When “autocal” is used, the GLONASS satellites will be used for the initial acquire. 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.
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.
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-0.10
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.
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. This parameter is defined but unused in RTKLIB 2.4.3
pos2-arthres3 = 1e-9,1e-7
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. This parameter is defined but unused in RTKLIB 2.4.3
pos2-arthres4 = 0.00001,0.001
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. This parameter is defined but unused in RTKLIB 2.4.3
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. If not using the demo5 RTKLIB code, set this higher since the “arfilter” feature is not supported.
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 = 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 should also 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, 0.2
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. With non-ublox receivers which typically are not as good at flagging outliers, I sometimes have to set this back to the default of 30 or even lower to attempt to handle the outliers but this is a trade-off because it can then cause other issues, particularly with initial convergence of the kalman filter.
Outlier rejection has been improved in the demo5 code starting with version b33. In addition to better handling of the outlier measurements, the way this number is applied to code and phase measurements has changed. Previously this value was applied without adjustment to both code and phase measurements. In the newer version, 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 0.2 which is very helpful to catch and reject unflagged cycle slips.
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 and can be plotted with RTKPLOT as long as the residual file is in the same folder as the solution file.
stats-eratio1 = 300
stats-eratio2 = 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 = 3.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. 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
stats-prnaccelv = 1.0
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.
Interpolates the base station observations. I generally set this to “on” if the base station observations sample time is larger than 5 seconds.
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.
44 thoughts on “Updated guide to the RTKLIB configuration file”
I’ve revisited the settings of this, and I’ve figured in a an area with very tall hills and often buildings on the hills, the absolute bane of accuracy is the elevation being too low; it appears even 45 gives a tremendous improvement (e.g. restarting the rtk solution: it locks back to the same coordinates unlike the mess of massive multipath); snr could be even off (which is almost the inverse of what this article suggests).
LikeLiked by 1 person
In case it wasn’t clear, I implied a high snr with a low el (or no el filter) appears to be much worse in that situation. It appears to clearly prefer an elevation filter in combination with not caring about an snr filter (which indicates strongly the easiest path to ..multipath in that situation is the elevation being too low and reflecting on buildings or hills).
LikeLiked by 1 person
I agree that the elevation filter is more effective than the SNR filter for reducing multipath but I still find it helpful to set the SNR threshold high enough to eliminate the lowest SNR signals.
Adjusting the elevation masks can help a lot with reducing multipath. I prefer to leave the overall elevation mask (pos1-elmask) fairly open but adjust the elevation mask used for ambiguity resolution (pos2-arelmask) for the data environment. For short baselines, I will use 10 degrees for very open skies (drone), 15 degrees for typical conditions, and up to 25 degrees for high multipath environments. I usually prefer not to increase the threshold above 25 degrees because the chances of false fixes also increases as you increase this threshold.
Is there a way to get rtklib to load the coordinates of a RTK base station from a posefile when using rtkrcv? I have tried but have been unable to get it to work and I have been unable to locate anything the documentation for demo5 for how to preform this action.
You can specify RTK base station coordinates in RTKRCV with a station position file by setting the “ant2-postype” option in the config file to “posfile”. Look for “station position file” in the RTKLIB user manual for a description of the required format for this file.
The explanation to pos2-arthres is bit confusing. If the error is large then AR ratio will be low so the solution will not be a fix. So, why it is likely time to get a false fix when Kalman filter is converging ? At the time of converging, if the error is large, AR will be low and hence will not considered as a fix. Please correct.
Secondly, I’m currently using demo5 v34f1. Can you please specify which options are for arthres1,arthres2,arthres3,arthres4 in the RTKPOST GUI application ?
When the errors in the model are large, the confidence in the AR ratio is lower. Although it is true that the AR ratio will usually be low when the solution is converging, this is not guaranteed and, in my experience, false fixes occur most frequently when the solution is converging.
Arthres1 is the “Max Pos Var for AR”, arthres2 is the “GLO HW Bias”. Arthres3 and arthres4 are not adjusted in normal operation and they are not configurable in RTKPOST.
Hello, I have been following your developments and found that you have recently added a new repositories CARVIG(https://github.com/rtklibexplorer/carvig). There seems to be the implementation of wide lane ambiguity search algorithm(resamb_WL), but the code here is quite different from rtklib. It is difficult for me to transplant this to rtklib. Do you have any plans to do this
Hi Bruce. I fairly recently cloned several Github repos into my Github account that I thought were interesting and might be useful for me or other people. At this point I don’t have any specific plans to import any features directly from them into RTKLIB. The CARVIG repo is clearly based on RTKLIB and has most of the same file names with just the extension changed from c to cc so it may not be too difficult to move a feature from one to the other. I believe the resamb_WL function was in earlier versions of RTKLIB but was dropped, so you may be able to find it in an older, more easily portable version. I have played with this function myself and found that it only considers satellites that have valid measurements from both frequencies from both base and rover. Low cost dual-freq receivers like the u-blox F9P still tend to have many satellites with only one frequency so I found too much information was lost by dropping all these satellites from the solution. However, it may be possible to leverage this into a combination of wide lane and single frequency observations.
thaks, very appreciate！i got it
in function udbias() rtkpos.c
line 785 and line 788
should “initx(rtk,0.0,0.0,IB(i,k,&rtk->opt))” be “initx(rtk,0.0,SQR(rtk->opt-std),IB(i,k,&rtk->opt))”
i think initial bias variance can not be 0?
Hi Bruce. Lines 785 and 788 are just flagging the biases as uninitialized. The actual initial biases are set at line 854.
thaks, i got it
Do you know how to decrease the time-to-first-fix? I find the time-to-first-fix of the rtklib with the real-time dynamic positioning is much longer than commercial receivers. In the real-time positioning, the state sometimes changes from fix to float, and requires more time to fix.
Thank you very much.
One of your fans.
Hi Yan. It’s true that my default config files are more geared towards post-processing where time-to-first-fix is less important. However, I recently posted a comparison of time-to-first-fix between the internal u-blox F9P solution and the RTKLIB solution using the most recent demo5 code. It showed very similar time-to-first-fix results between the two.
Thanks, I will read it.
do you know if it is possible to output the receiver clock estimate from RTKPOST? e.g. as part of the .pos file? Apologies if I’ve missed something obvious
Big fan of the blog and the website
Hi Oliver. You can get the clock estimates by enabling “Residuals” in the Output tab of the Position options. They will be in the .pos.stat file with the following format for RTK/PPK solutions in the demo5 code:
Excuse me, are you in America? What is the number of satellites available for the four major satellite navigation systems in the United States? In China, there are generally 6-8 GPS satellites available, 4-6 Galileo and GLONASS satellites available, and 12-16 Beidou satellites available.
Thank you very much.
Hi Bruce. Yes I’m in Colorado in the U.S. The number of GPS, GLONASS, and Galileo satellites available here is similar to what you see but I typically have much less Beidou satellites and signals available, both because the u-blox F9P does not fully support the Beidou satellites yet and because some of the Beidou orbits are regional over China.
OK,thank you very much.
I’m not sure about the distribution of GPS, Galileo and GLONASS satellites, but I’m familiar with the distribution of Beidou: http://www.beidou.gov.cn/xt/jcpg/202101/t20210110_21809.html
hi,do you have any idea of this situation：
sometimes all the post-processing methods can get fixed solutions, and the real-time dynamic positioning is all floating-point solutions with the same parameters ‘prcopt_t’
Hi Bruce. Two possibilities are:
1) The real-time solution is a cold-start or warm-start and the receiver has no ephemeris data. This will increase time-to-first-fix in the real-time solution but not the post-processed solution. If the data set is short it can prevent getting a fix at all.
2) The age of differential between base and rover is too large. It’s best to keep this below 1 second, more than that may start to degrade the real-time solution.
OK，thaks，i got it
Hi,thank you for your excellent work. we have benefited a lot from it.
I have a thought,RTKLIB looks not support wide lane integer ambiguity solution.i don’t think it gives full play to the advantages of dual frequency,so i want have a try to wide lane integer ambiguity solution,did you know any open source projects about this issue,thank you very much
Hi Bruce. It has been pointed out to me that there is an old version of RTKLIB available here with some modifications for wide-lane ambiguity resolution. I have not looked closely at it so don’t know it’s exact status. If you get something working let me know.
thank you very much, i will have a try
The PRN of China’s third generation Beidou system is more than 37 now
set this max prn MAXPRNCMP from 37 to 46 is a good choice
Hi Bruce. Yes, that’s a good point. I just checked in a change to increase MAXPRNCMP from 37 to 61. This number is not the number of satellites in the constellation but the max PRN. I’m not very familiar with the Beidou constellation but it looks like the highest PRN is now 61. Let me know if this is incorrect.
yes, you are right,the highest PRN is now 61.
but from 47 to 61,it is always only one satellite can be seen with prn number 60,so i set MAXPRNCMP to 46 to save time and memory
sorry , it is two with prn 59 60
Hi Bruce. OK, makes sense. I’ve just committed a change to reduce the max Beidou PRN to 46.
Beidou system website：
Many thanks for this, I am new to RTKLIB, emlid RS+ and done little survey work with other platforms such as Leica, so between the manual, emlid community and your blog I have to learn fast for a research project in Patagonia. Any suggestions on resources and tips welcome!
Hi Adussa. In many cases a Google search for specific questions is probably your best bet, but Navipedia is one good resource for general GNSS questions.
Thank you for your work it has realy helped me to this date!
For UAV RTK application, let’s say we know we have a good fix before takeoff, is there a parameter that would enable a lock to this fix and keep it no matter what during the entire flight? Some kind of way to increase the level of confidence in a solution?
We have found that during a flight the AR ratio frequently drops from 999 to 0 instantly, then goes right back to 999 in a few seconds. I have checked the obs data and there are practically no cycle slips so I figured this must be a software issue.
Hi Podos. Large jumps in the AR ratio are normal as satellites are added and removed from the ambiguity resolution calculations. However these jumps will not normally drop below the min AR ratio threshold (typically 3.0). Are you certain you are seeing the AR ratio drop all the way to zero, or is it possible that it is just dropping to a small number near zero but still greater than the min AR ratio? The actual AR ratio can not drop below 1.0 so if you are seeing 0 that means the AR ratio was not calculated, most likely because the position variance was too high. You can adjust the configuration parameters to increase the tracking gain of the ambiguities (set AR mode to fix-and-hold and adjust pos2-varholdamb to a smaller number). This will keep you locked to the same fix for longer but actually reduces confidence in the solution since the chances of a false fix are higher. I suggest keeping pos2-varholdamb between 0.1 (more tracking gain) and 1.0 (less tracking gain) to maintain a good balance between maintaining fix and avoiding a false fix.
Do you know how the option out-solstatic=single work ?
I have a postprocess case, runned in static mode with a very good solution when I ran it with out-solstatic=all (33060 fix and only 2 float). When i change the option to single i have no solution ?
Hi Tophe. Out-solstatic=single is meant to be used for static solutions when you only want the final position, rather than a position solution for every epoch. Because there is only one position in the solution it might appear that there is no solution if you plot it with RTKPLOT and don’t see the single dot. I did just double-check that it is still working with the b31a demo5 code and it worked fine for both a forward and a combined solution.
Thanks for all your work, it’s much appreciated. I wonder if misc-timeinterp can also be used to have a different interval for different constellations (I noticed that normally if I use a 2sec interval on constellations other than GPS, the fix drops, and I don’t see the interpolation option on the UI to test it easily (though I may test it anyway eventually)).
Hi Epigramx. In general I find that enabling interpolation of the base observations with the “misc-timeinterp” option improves the solution anytime the sample rate of the base observations is less than one per second. I have not worked with data in which the sampling rate is different between constellations but suspect it may help in that case too.