One of the less well documented features in RTKLIB is the capability to set receiver options. These are different from the solution options that are specified in the configuration file or through the GUI option menus. They are also different from the receiver commands that are used to send configuration messages directly to the receivers. The receiver options are specific to each receiver type. Actually, to be more precise, they are unique to each receiver output format, not each receiver. If a u-blox receiver is outputting RTCM3 messages, then only RTCM3 specific receiver options will be applied, not any u-blox options.
The receiver options are applied when translating the raw receiver output messages into internal RTKLIB observations or rinex files. In this post, I will describe the most commonly used options specific to u-blox receivers and the demo5 version of RTKLIB. Some of these options are also supported by other receivers and other versions of RTKLIB and I will try to make that clear in the discussion as well. I will also explain how to apply receiver options in the different RTKLIB apps.
First of all, here is a list of the receiver options available for the u-blox receivers in the demo5 RTKLIB code. They are listed along with options for all the other receivers in Appendix D.5 of the RTKLIB user manual. I have recently updated the demo5 version of the manual for the u-blox receivers but other listed receivers may not be fully up to date.
U-blox Receiver Options in Demo5 RTKLIB
– EPHALL: Input all of ephemerides
– INVCP: Invert polarity of carrier-phase
– TADJ=tint: Adjust time tags to multiples of tint (sec)
– MULTICODE: Preserve multiple signal codes for single freq
– MAX_STD_CP=n: Reject observations with StDev > n
-STD_SLIP=n: Set cycle slip for phase obs with StDev > n
TADJ=tint:
The most commonly used option is “-TADJ”. Unlike most other receivers, the u-blox receivers include the estimated receiver clock error in the observation time stamps. This causes them to deviate from nice round numbers. With most receivers, if you set the sample interval to one second, you will get observation timestamps at 1.0000, 2.0000, 3.0000… . With the u-blox receivers you will see something more like 0.9973, 1.9973, 2.9973… . This doesn’t cause any issues with downstream RTKLIB processing and so there is normally no need to adjust the timestamps. However, other applications sometimes expect the timestamps to occur on the rounded intervals and complain if they don’t. One of the most common questions I get is from readers asking how to deal with this problem.
Setting the receiver option to “TADJ=1.0” will adjust each observation so that it falls on the nearest rounded second. “TADJ=0.1” will do the same thing, except round to the nearest tenth of a second. Note that it is not enough for the code to just change the timestamp. To maintain consistency in the observations, the pseudorange and carrier phase measurements are also adjusted by a distance equivalent to the change in time of the timestamp. This option is available in all versions of RTKLIB.
MAX_STD_CP=n:
The u-blox binary observation messages include a standard deviation estimate for each pseudorange and carrier phase measurement. The internal RTKLIB observation variables and the rinex file format only handle the observations, not the uncertainty estimates, so this additional information is lost. Instead of just discarding this information, RTKLIB uses it to filter the observations. In the 2.4.3 code and until the most recent version of demo5 code, the default behavior was to discard all carrier phase observations with standard deviation estimates greater than 5. Typically, discarding the lowest quality observations gives better solutions than including them. However, I found that the scale of the standard deviation estimates of the Gen9 u-blox modules (e.g. F9P) seem to be a little different than the Gen8 modules (e.g. M8T) Because of this I have increased the default threshold to discard the carrier phase observations for Gen9 modules from 5 to 8 in the most recent version of the demo5 code. I have not modified the default threshold for Gen8 modules.
The “MAX_STD_CP=n” option allows the user to choose this threshold themselves if they don’t feel the default is optimal. The optimal value can also vary depending on use case. For example, when assisting with some research on precise tracking of birds, I found that when using the M8T modules, the default value of “5” was fine for lower acceleration migratory birds, but increasing the threshold to “8” improved the solutions when tracking higher acceleration birds of prey.
Be aware this option is only available if you are logging the binary u-blox messages. If you are using the RTCM3 messages, then all observations are passed on, regardless of quality. In environments with good sky views where most of the observations are of high quality, this difference will be negligible, but in more challenging environments with obstructed sky views, this adjustment can make a bigger difference. This option is only available in the demo5 code, the 2.4.3 code uses a fixed threshold of five for all u-blox modules.
STD_SLIP=n
The “STD_SLIP=n” option is similar to the previous option. However, in this case, instead of discarding the observations with standard deviations greater than a threshold, it sets a cycle slip if the standard deviation is greater than or equal to the threshold. The two options can be used together to set a cycle slip on the lower quality observations but discard the lowest quality observations. However I prefer to just use the previous option and not this one. This option is also available in the 2.4.3 code but since observations with standard deviations greater than 5 are always discarded in that code, it is of only very limited use.
– MULTICODE
This option only applies to the F9P dual frequency module and is only in the demo5 code. The F9P outputs different GPS L2C observation codes depending on whether it decoded the CM or the CL codes in the raw signal. It usually reports the long code (CL) but will occasionally report some medium code (CM) messages as it is acquiring a new satellite. The 2.4.3 version of RTKLIB reports these observation codes as is. Unfortunately RTKLIB does not handle multiple code observation types for a single constellation frequency well and they tend to degrade the solution. To avoid this issue, I have followed the lead of the Emlid version of RTKLIB code and modified the default behavior of the demo5 version to combine both observation codes into a single combined observation code (L2X) which is reported regardless of whether the F9P reports the CM observation code (L2S) or the CL observation code (L2L). For processing RTKLIB solutions this is the preferred option, but for other uses, users might prefer to keep the original codes. Using the “-MULTICODE” option, reverts back to this behavior.
I have never found a need to use the remaining two options (-EPHALL, -INVCP) and am not familiar with any situation where they would be used.
Setting Receiver Options
How to set these options varies depending on which RTKLIB app you are using. It only applies to those apps which work directly with the raw receiver messages or files. These include RTKCONV and CONVBIN for post-processing, and RTKNAVI and RTKRCV for real-time processing.
In RTKCONV, use the “Receiver Options” box in the “Options” menu as shown on the left below. In RTKNAVI, use the “Receiver Option” box selected from the “Opt” option in the “Input Streams” menu as shown on the right below.
You can include multiple options in the box as shown in the examples above.
In CONVBIN, use the “-ro” option on the command line. For example
convbin run1.ubx -ro “-MAX_STD_CP=3 -TADJ=1.0”
The quotes are only necessary if including more than one option.
At this point, RTKRCV does not appear to support receiver options but I hope to add this capability to the demo5 version in the near future.
I think that’s all there is to receiver options but if I’ve left anything out, let me know in the comments below and I will try to answer any questions.
rtklibexplorer 