RTKLIB: Support Information

RTKLIB: Support Information

update 2021/04/08

Inquiry

First of all, please read again the manual and the release notes (refer RTFM as well.) If they do not solve your problem(s), send the e-mail to the following address. (It may take a long time to receive the answer due to lack of our time for support.)

rtklib_support(a)gpspp.sakura.ne.jp (replace (a) by @)

Forum

There is no formal support forum but the followings sometimes make discussions on RTKLIB.

FOSS-GPS -- Open Source GPS-related discussion and support.
Geospector GPS-Forum (vormals kowoma GPS-Forum) (in Germany)
DIY Drones The Leading Community for Personal UAVs - GPS
OpenStreetMapForum-users: Russia (in Russian)

Wiki

OpenStreetMap: RTKLIB

Blog

rtklibexplorer: Exploring ultra-low cost precision GPS with RTKLIB and Ublox receivers

GitHub

Issues or Pull Requests for the GitHub repository may provide helpful info.
The beta versions of RTKLIB are available as a development branch of the GitHub repository.

https://github.com/tomojitakasu/RTKLIB
https://github.com/tomojitakasu/RTKLIB/tree/rtklib_2.4.3

Bug and Known Problem List

No.153 100 nsec errors of time-tags in RINEX OBS converted from high-rate BINEX (RTKCONV, CONVBIN)

Plus-minus 100 nsec errors of time-tags are shown in a RINEX OBS file converted from high-rate BINEX files as like follows (The second of the time-tag should be 00.0600000).

> 2019 10 06 03 35 00.0599999 0 31
G06 21114484.710 110957367.520 ...

Due to a bug in RTKLIB/src/rcv/binex.c. Insufficent resolution of the internal time representation introduces additional time-tag errors. It will be fixed in the next release. Wait for the release, or edit the following lines and rebuild APs. (2021/04/08)

RTKLIB/src/rcv/binex.c L.1091 (RTKLIB 2.4.3 b34)

raw->time=timeadd(epoch2time(gpst0),min*60.0+msec*0.001);
->
raw->time=timeadd(epoch2time(gpst0),min*60.0);
raw->time=timeadd(raw->time,msec*0.001);

No.152 Unable to read more than 99 satellites' data in a SP3-d precise ephemeris file (RTKPOST, RNX2RTKP, ver. 2.4.3 b34)

APs can not read SP3-d precise ephemeris if the file contains more than 99 satellites' data.

Due to a bug in RTKLIB/src/preceph.c. Improper decoding of a SP3-d header field causes an error in reading the file. It will be fixed in the next release. Wait for the release, or edit the following line and rebuild APs. (2021/01/14)

RTKLIB/src/preceph.c L.91 (RTKLIB 2.4.3 b34)

ns=(int)str2num(buff,4,2);
->
ns=(int)str2num(buff,3,3);

No.151 Inproper RINEX OBS conversion of receiver logs (RTKCONV, CONVBIN, ver. 2.4.3 b34)

If a receiver log file contains NULL observation data records in start portion, observation data after the NULL part are not properly converted to RINEX. Only the last observation data record is converted into the RINEX OBS file. In this case, navigation data in the log file are properly converted into the RINEX NAV file.

Due to a bug in RTKLIB/src/convrnx.c. Insufficient initialization of observation data buffer at start of the second pass of convertion causes inproper behaviour. It will be fixed in the next release. (2021/01/06)

No.150 Memory access violation execption in reading RINEX OBS and NAV data (RTKPLOT, ver.2.4.3 b34)

If option "Receiver Postion" set to "Single Solution", RTKPLOT raises a memory access violation exception in reading RINEX OBS and NAV data.

Due to a bug in RTKLIB/app/winapp/rtkplot/plotdata.cpp. Insuffient memory allocation for an array causes out of memory access exception. It will be fixed in the next release. Wait for the release or edit the following line and rebuild AP RTKPLOT. (2021/01/06)

RTKLIB/app/winapp/rtkplot/plotdata.cpp L1192 (RTKLIB 2.4.3 b34)

double pos[3],azel[2];
->
double pos[3],azel[2*MAXOBS];

No.149 Map View by Leaflet library does not properly work (RTKPLOT, SRCTBLBROWS, ver.2.4.3 b34)

Map View of RTKPLOT and NTRIP Browser by Leaflet library does not properly work. Map View has no response or a script execution error occures in RTKLIB/bin/leaflet/leaflet.js.

Older version behaviour of WebBrowser component used in the Map View of RTKPLOT or NTRIP browser might make trouble with Leaflet. Add the following entry of Windows resistries by regedit (Registry Editor) to run the WebBrowser component in IE11 emulation mode. (2020/12/30)

- Key: HKEY_LOCAL_MACHINE - SOFTWARE - Microsoft - Internet Explorer - Main - FeatureControl - FEATURE_BROWSER_EMULATION
- Name: rtkplot.exe
- Type: REG_DWORD
- Data: 11000 (decimal)

- Key: Same as above
- Name: srctblbrows.exe
- Type: REG_DWORD
- Data: 11000 (decimal)

No.148 Map view of NTRIP Browser does not work (SRCTBLBROWS)

Map view of NTRIP Browser does not work. Map view only shows a blank page.

Add the following entry of Windows registries by regedit (Registry Editor) to run the WebBrowser component on NTRIP Browser as IE 11.

- Key: HKEY_LOCAL_MACHINE - SOFTWARE - Wow6432Node - Microsoft - Internet Explorer - MAIN - FeatureControl - FEATURE_BROWSER_EMULATION
- Name: srctblbrows.exe
- Type: REG_DWORD
- Data: 11000 (decimal)

Additionally, obtain your own API Key by yourself and edit the header line of the HTML file rtklib/bin/rtklib_gmap.htm as follows. (2020/07/10)

<script src="http://maps.google.com/maps/api/js?v=3&sensor=false"
->
<script src="http://maps.google.com/maps/api/js?key={YOUR_API_KEY}&v=3&sensor=false"

RTKLIB 2.4.3 b34 has replaced Google Maps by Leaflet and OSM (OpenStreetMap). API Key can be input as a Map View Option. See also No.149 for another issue. (2020/12/30)

No.147 Galileo ephemeris in BINEX is not recognized (RTKCONV, RTKNAVI, CONVBIN, RTKTRCV)

A BINEX message of Galileo upgraded decoded ephemeris (record 0x01, subrecord 0x14, 0x01-14, ref) is not recognized. It is just ignored but logged in log file.

The BINEX Galileo upgraded decoded ephemeris is not yet supported. Use older Galileo decoded ephemeris (record 0x01, subrecord 0x04, 0x01-04, ref) instead. It will be supported in the next release. (2019/07/25)

RTKLIB 2.4.3 b34 has supported BINEX Galileo upgraded decoded ephemeris (0x01-14). RTKLIB 2.4.2 p13 still does not support the message. (2020/12/30)

No.146 GLONASS carrier-phase data are unrecognized in RTCM MSM 4 or 6 (RTKCONV, RTKNAVI, CONVBIN, RTKRCV)

Carrier-phase data of GLONASS are unrecognized in a RTCM MSM 4 or 6 message (MT1084 or 1086) without GLONASS ephemeris messages (MT1020). All carrier-phases in the observation data show 0 values.

Due to the lack of the GLONASS satellite FCN (frequency channel number) info. The carrier-phase data are represented as phase-ranges in RTCM MSM messages. They require the FCN info to be converted to carrier-phase in cycle. RTCM MSM 4 and 6 do not contain the FCN info. The FCN info are provided as the externded satellite info field in RTCM MSM 5 or 7 (MT1085 or 1087) or the GLONASS ephemeris message (MT1020). Provide the GLONASS ephemeris messages (MT 1020) together or use RTCM MSM 5 or 7 (MT1085 or 1087) instead. (2019/05/13)

In RTKLIB 2.4.3 b34, GLONASS FCNs can be obtained by FCN table if it enabled and specified as conversion options of RTKCONV. However, CONVBIN has not yet implemented such feature. (2020/12/30)

No.145 Unable to handle data of BeiDou C36 and C37 satellites (RTKPLOT, RTKCONV, RTKNAVI, RTKPOST, CONVBIN, RTKRCV, RNX2RTKP)

Data of BeiDou C36 and C37 satellites can not be handled. Observation and navigation data for these satellites are rejected as having invalid PRN number.

PRN 1 - 37 are assigned to BeiDou satellites according to BeiDou SIS-ICD (ref). However, the current definition of maximum PRN number of BeiDou in RTKLIB is 35 as the constant MAXPRNCMP. BeiDou PRN 36 - 37 are recognized as invalid PRN number and rejected. It will be fixed in the next patch. Until the release, modify the following source code and rebuild APs. (2019/01/10)

rtklib/src/rtklib.h L166 (rtklib 2.4.2 p13)

#define MAXPRNCMP 35 /* max satellite sat number of BeiDou */
->
#define MAXPRNCMP 37 /* max satellite sat number of BeiDou */

RTKLIB 2.4.3 b34 has supported BeiDou PRN1-63 (C01-C63). RTKLIB 2.4.2 p13 still supports only PRN1-35 (C01-C35). (2020/12/30)

No.144 The API strwrite() drops a message written to a TCP server stream (RTKNAVI, RTKRCV, STRSVR, STR2STR)

If aTCP server is opened by the API stropen(), the server is connected by multiple TCP clients and one of the TCP clients disconnects from the server, a message written by the API strwrite() may drop and may not be sent to other TCP clients. It occurs only one time after the TCP client disconnected.

Due to a bug in the stream library rtklib/src/stream.c. The function writetcpsvr() immediatelly returns if sending message to one of the TCP clients failed. The message is not sent to remains of the TCP clients in this case. It will be fixed in the next release. Until the release, please modify the following source codes and rebuild APs. (2018/11/15)

rtklib/src/stream.c L1109-1110 (rtklib 2.4.2 p13)

updatetcpsvr(tcpsvr,msg);
return 0;
->
updatetcpsvr(tcpsvr,msg);
/* (deleted) */

RTKLIB 2.4.3 b34 has fixed the issue. RTKLIB 2.4.2 p13 still has the problem. (2020/12/30)

No.143 Invalid RTCM MSM message generation with wrong number of Cell-mask (STRSVR, STR2STR)

In case of (number of satellites) x (number of signals) exceeds 64, invalid RTCM MSM messages with wrong number of Cell-mask are generated by the RTCM 3 encoder.

Due to a bug on the RTCM MSM encoder rtlib/src/rtcm3e.c. The (number of satellites) x (number of signals) should not exceed 64 in a RTCM MSM message as defined as RTCM 3.2 or 3.3 (3.5.16.3). In this case, the messages should be separeted to multiple ones. It will be fixed in the next release. (2018/10/22)

It is fixed in rtklib 2.4.3 b31. The problem still remains in rtklib 2.4.2 p13. The API gen_rtcm3() does not accepts observation data in which {nsat} x {nsig} exeeds 64 (max number of RTCM MSM cell-masks). If {nsat} x {nsig} of the input observation data exeeds 64, separate them to multiple ones and call gen_rtcm3() multiple times as user responsibility. ({nsat} = number of valid satellites, {nsig} = number of signals in the observation data). (2018/11/15)

No.142 GMView (Google Map View) of RTKPLOT is not properly shown (RTKPLOT)

GMView (Google Map View) of RTKPLOT is not properly shown. GMView shows a warning dialog and a dark map screen with messages "For development purposes only".

Due to the Google policy change to keyless usage of the Google Maps API. After June 11, 2018, the usage of Google Maps API always needs the API key (ref). If you want to use GMView, please obtain your own API Key by yourself and edit the header line of the GMView HTML file rtklib/bin/rtklplot_gm.htm as follows. (2018/09/26)

<script src="http://maps.google.com/maps/api/js?v=3&sensor=false"
->
<script src="http://maps.google.com/maps/api/js?key={YOUR_API_KEY}&v=3&sensor=false"

In RTKLIB 2.4.3 b34, Your API Key can be input as a Map View Option. (2020/12/30)

No.141 Unable to handle data of Galileo E31 - E36 satellites (RTKPLOT, RTKCONV, RTKNAVI, RTKPOST, CONVBIN, RTKRCV, RNX2RTKP ver.2.4.2)

Data of Galileo E31 - E36 satellites can not be handled. Observation and navigation data for these satellites are rejected as having invalid PRN number.

PRN 1 - 36 (E1B/C, E5a, E5b) are assigned to the Galileo satellites according to Galileo OS-SIS-ICD 3.6. However, the current definition of maximum PRN number of Galileo in RTKLIB is 30 as the constant MAXPRNGAL. Galileo PRN 31 - 36 are recognized as invalid PRN number and rejected. It will be fixed in the next patch. Until the release, modify the following source code and rebuild APs. (2018/07/30)

rtklib/src/rtklib.h L140

#define MAXPRNGAL 30 /* max satellite PRN number of Galileo */
->
#define MAXPRNGAL 36 /* max satellite PRN number of Galileo */

RTKLIB 2.4.3 b34 has supported Galileo PRN1-36 (E01-E36). RTKLIB 2.4.2 p13 still supports only PRN1-30 (E01-E30). (2020/12/30)

No.140 RTCM 3 MSM generated by STRSVR or STR2STR is not recognized (STRSVR, STR2STR)

RTCM 3 MSM messages (RTCM MT 107x, 108x, 109x, 110x, 111x and 112x) generated by STRSVR or STR2STR with Conversion option (receiver raw -> RTCM 3) are not recognized in some rover receivers.

Due to a bug on encoding the lock time field in the RTCM MSM messages by the RTCM 3 encoder rtklib/src/rtcm3e.c. Inproper lock time filed makes a trouble to recognize the RTCM MSM messages. It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29).

No.139 GMView (Google Map View) of RTKPLOT does not work (RTKPLOT)

GMView (Google Map View) of RTKPLOT does not work. RTKPLOT only shows the error message "You are using a browser that is not supported by Google Maps JavaScript API. Consider changing your browser".

Add the following entry of Windows registries by regedit (Registry Editor) to run the WebBrowser component on GMView as IE 11. (2017/12/05)

- Key: KEY_LOCAL_MACHINE - SOFTWARE - Wow6432Node - Microsoft - Internet Explorer - MAIN - FeatureControl - FEATURE_BROWSER_EMULATION
- Name: rtkplot.exe
- Type: REG_DWORD
- Data: 11000 (decimal)

No.138 Galileo E30 satellite is not trackable and usable (RTKPLOT, RTCONV, CONVBIN, RTKNAVI, RTKRCV ver.2.4.2)

Galileo E30 satellite is not trackable and usable. There is no satellite in the skyplot.

The maximum PRN number of Galileo satellites was set to 27 as MAXPRNGAL in rtklib/rtklib.h. It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.137 Invalid decoding of signed 1-byte fields in raw receiver data by ARM-GCC (RTKCONV, CONVBIN, RTKNAVI, RTKRCV, STRSVR, STR2STR ver. 2.4.2)

Signed 1-byte binary fields in raw receiver data are not properly decoded in ARM-GCC environment.

Some codes imply "char" as "signed char". However, whether "char" as "signed char" or as "unsigned char" is machine-dependent. In ARM-GCC environment, "char" is recognized as "unsigned char" as default. Invalid sign decoding of the field leads improper value. It is fixed in the patch rtklib_2.4.2_p13 (source, binary).(2018/01/29)

No.136 GEView (Google Earth View) of RTKPLOT does not work (RTKPLOT)

GEView (Google Earth View) of RTKPLOT does not work. RTKPLOT shows only a blank plot.

GEView uses Google Earth API provided by Google. The Google Earth API is terminated on January 11, 2017 (reference). There is no way to support GEView without the Google Earth API. (2017/01/26)

No.135 The leap second before 2017/01/01 00:00:00 UTC is not involved (All ver. 2.4.2 p11)

The leap second before 2017/01/01 00:00:00 UTC (2016/12/31 23:59:60 UTC) is not involved. Some problems might arise by the leap second insertion after 2017/01/01 00:00:00 UTC especially on GLONASS data handling.

Due to the lack of the record in the hard-coded leap second table in rtklib/src/rtkcmn.c. It is fixed in the patch 2.4.2 p12. Refer GitHub (source, binary) for the patch. (2017/01/03)

No.134 Loss-of-lock status is not recognized in RTCM MSM 6 or 7 (RTKCONV, CONVBIN, RTKNAVI, RTKRCV ver. 2.4.2)

The loss-of-lock or cycle-slip status is not recognized in RTCM MSM 6 or 7.

Due to a bug of rtklib/src/rtcm3.c. The field size of the lock-time in RTCM MSM 6 or 7 is 10 bits. However, the previous lock-time value is saved in 8-bit unsigned int in rtcm_t struct. The cycle-slip is unable to be catched in case of reversal of the lock-time.

It will be fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.133 Potential carrier-phase range overflow or underflow in RTCM MT1001-1004, 1009-1012 (STRSVR, STR2STR ver. 2.4.2)

The PhaseRange-Pseudorange fields in RTCM MT 1001-1004, 1009-1012 (DF012, DF018, DF042, DF048) generated by RTKLIB could overflow or underflow the range. The rollover is handled at +-1500.0 cycle in rtklib/src/rtcm3e.c cp_pr() but the +-1500.0 cycle corresponds to +-285.44m (GPS L1) and +-366.32m (GPS L2), which are out of the proper range (+-262.14m). The problem may cause the invalid carrier-phase value where the RTCM message received.

It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.132 UBX-TRK-MEAS and UBX-TRK-SFRBX are no longer available by u-blox M8N F/W 3.01

Unofficial raw-messages UBX-TRK-MEAS (0x03 0x10) and UBX-TRK-SFRBX (0x03 0x0F) are no longer available by u-blox M8N F/W 3.01. The command file data/ubx_m8n_glo_raw_1hz.cmd and data/ubx_m8n_bds_raw_1hz.cmd don't work properly for M8N F/W 3.01. (2016/01/30)

No.131 The code of L2C in RTCM MT1004 is not properly recognized (RTKCONV, CONVBIN ver.2.4.2)

By RINEX conversion, the code of L2C in RTCM MT1004 messages is not properly recognized. For RINEX 3, the L2C data are decoded as "2C" (L2C/A). For RINEX 2, the L2C pseudorange data vanish in RINEX by misinterpretation of the code.

It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.130 NVS receiver's measurement data is not recognized on ARM CPU (RTKRCV, STR2STR ver.2.4.2)

NVS receiver's data is not recognized on an ARM CPU board (BeagleBone etc).

In the NVS driver, the time-tag in the xf5-raw measurement data message is checked by comparing with the previous message's time-tag in order to reject wrong data. The first message is compared with the CPU time. If the difference of the first time-tag from the CPU time is more than 1 day, all messages are discarded. It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.129 Bus error on ARM with RTKRCV or STR2STR by decoding Javad (RTKRCV, STR2STR ver.2.4.2)

Bus error occures by RTKRCV or STR2STR on an ARM processor by decoding the Javad steram.

Due to a byte-boundary limitation of a multiple-byte-word on ARM. It may not occure on x86 environment. It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.128 A minor bug on displacement computation by OTL (RTKPOST, RNX2RTKP, RTKNAVI, RTKRCV ver.2.4.2)

The station displacement by OTL (ocean tide loading) for PPP has a following minor bug. (src/ppp.c L241) The effect of the bug rearches 1 cm as horizontal and 2 cm as vertical of PPP-kinematic solutions.

(wrong) days=timediff(epoch2time(ep),epoch2time(ep1975))/86400.0;
(correct) days=timediff(epoch2time(ep),epoch2time(ep1975))/86400.0+1.0;

It is fixed in rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.127 Rejection of RTCM SSR messages by IOD inconsistency between orbit and clock correction (RTKPOST, RTKNAVI, RNX2RTKP and RTKRCV ver.2.4.2)

With "Broadcast+SSR APC" or "Broadcast+SSR CoM" as the "Satellite Ephemeris/Clock" option typically in PPP-modes, input RTCM SSR messages are frequently rejected by IOD inconsistency error. The warning message "inconsist ssr correction: ..." is found in the debug trace file.

Due to bugs in rtklib/src/postpos.c and rtklib/src/rtksvr.c. They are fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.126 Invalid station posiiton in RTCM 3 messages by STR2STR with -p option and format converters (STR2STR ver.2.4.2)

Invalid station position is found in the sending RTCM 3 messages (MT1005 or MT1006) generated by STR2STR with option -p and format converters.

Due to a bug in rtklib/app/str2str/str2str.c. It is fixed in the patch rtklib_2.4.2_p13 (source, binary). (2018/01/29)

No.125 Invalid ionosphere correction for GLONASS or BeiDou in "SINGLE" and "PPP" modes (RTKPOST, RNX2RTKP, RTKNAVI, RTKRCV ver.2.4.2 p10)

In case of "SINGLE", "PPP-STATIC","PPP-KINEMATIC","PPP-FIXED" and the "ionosphere correction" option set to "Broadcast", "SBAS", "IONEX TEC", "QZSS Broadcast" or "QZSS LEX", the ionosphere correction for pseudorange and carrier-phase for GLONASS or BeiDou satellites is invalid. The frequency difference between GPS L1 and GLONASS L1/BeiDou B1 should be taken into account for the correction.

Due to bugs in rtklib/src/pntpos.c, ppp.c. Apply the patch rtklib_2.4.2_p11.zip. (2015/03/23)

No.124 Invalid pole tide correction due to incorrect ERP interpolation (RTKPOST, RNX2RTKP ver.2.4.2 p10)

With setting "Solid/OTL" as "Earth Tides Correction" and filling "EOP Data File", invalid pole tide correction is applied due to wrong interpolation of ERP values in the function geterp().

Due to a bug in src/rtkcmn.c. Apply the patch rtklib_2.4.2_p11.zip. (2015/03/23)

No.123 Invalid solutions for "Moving-Base" with "Combined" Filter Type (RTKPOST, RNX2RTKP ver.2.4.2 p10)

With "Moving-Base" as Positioning Mode and "Combined" as Filter Type, the solutions are invalid.

Due to a bug in rtklib/src/postpos.c. Apply the patch rtklib_2.4.2_p11.zip. (2015/03/23)

No.122 Positioning mode "PPP-FIXED" can not be selected by RTKRCV (RTKRCV ver.2.4.2 p10)

The positioning mode "PPP-FIXED" can not be selected by RTKRCV.

Due to a bug in rtklib/src/options.c. It will be fixed in the next patch or release. Apply the patch rtklib_2.4.2_p11.zip. (2015/03/23)

No.121 Antenna type "*" is not replaced by RINEX header field "ANT # / TYPE" (RTKPOST, RNX2RTKP ver.2.4.2 p10)

Even if setting "Options" - "Antenna Type" to * (auto), the antenna type is not replaced by the RINEX header field "ANT # / TYPE".

It's due to a bug in rtklib/src/postpos.c (L895). The auto read by "*" is only valid with "Satellite Ephemeris/Clock" is set to "Precise" or "Broadcast+SSR CoM". Apply the patch rtklib_2.4.2_p11.zip. (2015/03/23)

No.120 Problem on parsing of command line options for STR2STR (STR2STR ver.2.4.2 p10)

The command line options for STR2STR are not properly recognized if -in or -out option includes the format (stream#format).

Due to a bug in app/str2str/str2str.c of rtklib 2.4.2 p10. Apply the patch rtklib_2.4.2_p11.zip. (2015/03/23)

No.119 Some bug fixings and features by 2.4.3 betas are incorpolated. (All ver. 2.4.2)

The following bug fixings and features provided by 2.4.3 betas are incorpolated. Apply the patch rtklib_2.4.2_p10.zip. (2014/11/8)

(1) add 3-panel and veritical-panel modes for RTKNAVI
(2) add sky image overlay to skyplot for RTKPLOT
(3) add pos2-bdsarmode for beidou amb-res option for RTKRCV and RNX2RTKP
(4) add beidou amb-res option for RTKNAVI and RTKPOST
(5) add option -a, -i and -o to STR2STR
(6) support stdin/stdout if -in/-out omitted in STR2STR
(7) support message RXM-RAWX and RXM-SFRBX for u-blox NEO/LEA-M8T
(8) replace strtok() by strtok_r() in expath() for thread-safe
(9) fix problem on week rollover in RTCM 2 type 14
(10) fix problem on reading "C2" in RINEX 2.11 and 2.12
(11) fix bug on clock error variance in peph2pos()
(12) fix bug on P0(a[3]) computation in tide_oload()
(13) fix bug on m2 computation in tide_pole()
(14) fix bug on receiver option -GL*,-RL*,-JL* for JAVAD
(15) fix bug on receiver option -GL*,-RL*,-EL* for NovAtel
(16) fix bug on return value of var_uraeph() if ura<0||15<ura

No.118 AR performance of baseline processing degraded by unhealthy satellites (RTKNAVI, RTKPOST, RTKRCV, RNX2RTKP ver. 2.4.2)

AR (ambiguity resolution) performance is degraded if unhealthy satellites are incorpolated in baseline processing.

Due to a bug in rtklib/src/rtkpos.c. The ambiguities for unhealthy satellites, which should be excluded, are involved in the AR process. Apply the patch rtklib_2.4.2_p10.zip. (2014/11/8)

No.117 GLONASS ephemerides are not properly read from a RTCM stream without obsevation data (RTKNAVI, RTKRCV, STRSVR, STR2STR ver. 2.4.2)

GLONASS ephemerides (MT 1020) are not properly read from a RTCM stream without observation data. For example, the problem appears in case of using the IGS-RTS RTCM3EPH stream.

RTKLIB uses the time in observation data to solve the day ambiguity for tk or tb in GLONASS ephemerides. Without such information, RTKLIB initially uses CPU time but the time is not updated in the long operation of the input stream. After the vaild time expired in 1 day, invalid ephmemerides with wrong tk or tb values are read. Apply the patch rtklib_2.4.2_p10.zip. (2014/11/8)

No.116 No support of local or non-standard extensions for RINEX 2 (RTKPOST, RTKCONV, RNX2RTKP, CONVBIN ver.2.4.2)

RTKLIB does not support the following local or non-standard RINEX extensions.

- RINEX "2.11 extended" by UNAVCO TEQC (reference).
- RINEX 2.11 extensions for Galileo, QZSS and BeiDou navigation data.
- RINEX 2.12 extensions for BeiDou navigation data

The only supported extension is "RINEX 2.12 QZSS extension" by JAXA. (reference)

These non-standard RINEX files cannot be properly read by RTKLIB APs. (2014/9/8)

No.115 Input stream error "get comconfig error (87)" over Bluetooth virtual COM port (RTKNAVI, STRSVR ver.2.4.2)

Over a virtual COM port by Bluetooth SPP (serial port profile), RTKNAVI or STRSVR sometimes fails to start by the error "get comconfig error (87)". The "(87)" means Windows error code #87 "ERROR_INVALID_PARAMETER". Refer the topic for additional information (in Germany).

Apply the patch rtklib_2.4.3_p10.zip. (2014/11/8)

No.114 Invalid format of saved image by RTKPLOT (RTKPLOT ver.2.4.2)

Even if selecting JPEG as the format by the menu "Edit" - "Save Image...", RTKPLOT saves the image not as JPEG but as Windows BMP.

Due to a bug in app/rtkplot/plotmain.cpp. Apply the patch rtklib_2.4.2_p10.zip. (2014/11/8)

No.113 Invalid identification of obs type "C2" in RINEX 2.11 or 2.12 (RTKPOST, RNX2RTKP, RTKCONV, CONVBIN ver. 2.4.2 p9)

The obs type "C2" of GPS in RINEX 2.11 or 2.12 is recognized as "C2W" (L2 Z-tracking) as RINEX 3. It shuould be "C2S", "C2L" or "C2X" (L2C) in RINEX 2.11 and "C2D" (C/A + (P2-P1)) in RINEX 2.12.

Due to a bug in src/rinex.c to convert RINEX 2 obs codes to RINEX 3. "C2" in RINEX 2.11 is recognized as "C2X". "C2" in RINEX 2.12 is recognized as "C2W". Apply the patch rtklib_2.4.2_p10.zip. (2014/11/8)

No.112 Some features supported for receiver message handling (RTKNAVI, RTKRCV, RTKCONV, CONVBIN, STRSVR, STR2STR ver.2.4.2)

The following features are supported for receiver message handing.
(1) Trimble RT17 messages for GPS raw observation data and navigation data.
(2) u-blox TRK-TRKD5 for raw observation data.
(3) Error check of GLONASS ephemeris strings in u-blox TRK-SFRBX message.

Apply the patch rtklib_2.4.2_p9.zip. (2014/08/27)

No.111 Improper decoding of GLONASS ephemeris IODE in JAVAD [NE] (RTKNAV, RTKRCV, RTKCONV, CONVBIN ver.2.4.2)

Improper decoding of the GLONASS ephemeris IODE in JAVAD [NE]. IODE 64 - 127 are output as wrong value 0 - 63. No problem for IODE 0 - 63. IODE is usually used to determine corresponding ephemeris for RTCM SSR correction. GLONASS satellites are often unavailable caused by wrong IODE for JAVAD stream.

Due to a bug in src/rcv/javad.c. Apply the patch rtklib_2.4.2_p9.zip. (2014/8/27)

No.110 No swap function of solution status files for RTKNAVI or RTKRCV (RTKNAVI, RTKRCV ver.2.4.2)

In case of continous operation of RTKNAVI or RTKRCV, the size of the solution status file increases too largely. It is not easy to handle such large-size files. It is desireble to separate it into muliple files.

There is no function to swap such the solution status file. Apply the patch rtklib_2.4.2_p9.zip. (2014/8/27)

No.109 CPU overload with abnormal telnet shutdown on the RTKRCV command console (RTKRCV ver.2.4.2)

With abnormal telnet shutdown on the RTKRCV command console, an infinite input loop causes CPU overload. It is not able to login from another console as well.

Due to a bug in rtklib/app/rtkrcv/rtkrcv.c. Apply the patch rtklib_2.4.9_p9.zip. (2014/08/27)

No.108 Unable to read u-blox UBX-RXMRAW messages (RTKNAVI, RTKRCV, RTKCONV, CONVBIN, STRSVR, STR2STR ver. 2.4.2 p8)

UBX-RXMRAW messages are unable to read from u-blox receiver streams if the stream contains UBX-NAVSOL or UBX-NAVTIME.

Due to a bug in rtklib/src/rcv/ublox.c, which was modified in the patch rtklib_2.4.2 p8. Apply the patch rtklib_2.4.2_p9.zip. (2014/08/27)

No.107 Some features supported for receiver message handling (RTKNAV, RTKRCV, RTKCONV, CONVBIN, STRSVR, STR2STR ver.2.4.2 p7)

The following features are supported for receiver message handling.
(1) u-blox M8N message TRK-MEAS and TRK-SFRBX for raw observation and navigation data.
(2) Javad [lD] message for GLONASS raw navigation data.
(3) Receiver command "!HEX" to generate a general HEX message.

Appy the patch rtklib_2.4.2_p8.zip. (2014/06/29)

No.106 Restriction of the visible satellite number for baseline processing (RTKPOST, RNX2RTKP, RTKNAVI, RTKRCV ver. 2.4.2 p7)

In baseline processing cases including "Kinematic" or "Static", the number of visible satellite over 32 might have a trouble. Some satellites cannot be used to get solutions.

The constant MAXOBS is defined in rtklib/src/rtklib.h as 64. The sum of the visible satelite numbers in both rover and base-station sides should be below MAXOBS. If the number exceeds MAXOBS, the remains are discarded.
Appy the patch rtklib_2.4.2_p8.zip. (2014/06/29)

No.105 A memory exception in reading RINEX 2 obs data (RTKPOST, RTKPLOT, RNX2RTKP, RTKCONV, CONVBIN ver.2.4.2 p6)

In case of reading RINEX 2 observation data, a memory exception aborts the APs.

Due to a bug in rtklib_2.4.2_p6.zip. Not-terminated obs code table causes a memory access violation in obs2code(). Apply the patch rtklib_2.4.2_p7.zip. All modifications by rtklib_2.4.2_p5 and rtklib_2.4.2_p6 are included in the patch. (2014/05/29)

No.104 A memory exception in a baseline analysis with triple-frequency+GPS+GLO+BDS (RTKPOST, RTKNAVI, RNX2RTKP, RTKRCV ver.2.4.2 p6)

In case of a baseline analysis with triple-frequency+GPS+GLO+BDS, a memory exception aborts the APs. It also occures with triple-freqency+GPS+GLO+GAL, triple-frequency+GPS+GAL+BDS and triple-frequency+GLO+GAL+BDS and dual-frequency+GPS+GLO+GAL+BDS.

Due to a bug on rtklib/src/rtkpos.c. Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.103 No single-point solutions with GLONASS, Galileo or BeiDou only (RTKPOST, RTKNAVI, RNX2RTKP, RTKRCV ver.2.4.2 p5)

No single-point solutions can be obtained in case selecting a single system of GLONASS, Galileo or BeiDou. GPS is always needed for single-point solutions.

Due to a bug in rtklib/src/pntpos.c of rtklib_2.4.2_p5.zip. Apply the patch rtklib_2.4.2_p7.zip. All modifications by rtklib_2.4.2_p5 are also included in rtklib_2.4.2_p6. (2014/05/28)

No.102 Unable to incorporate BeiDou satellites in post-processing and real-time solutions (RTKPOST, RTKNAVI, RNX2RTKP, RTKRCV ver.2.4.2)

BeiDou satellites are not incorporated in post-processing and real-time solutions even with BeiDou enabled.

In ver.2.4.2, BeiDou is not yet supported for post-processing and real-time solutions. RTKLIB can handle BeiDou data only for convert and plot. To enable solutions with BeiDou, apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.101 Unable recovery of a NTIRP connection down by an inactive timeout (STRSVR, STR2STR, RTKNAVI, RTKRCV ver.2.4.2)

After an inactive timeout of a NTRIP connection, RTKLIB tries to re-connect to the NTRIP caster. If a temporal DNS timeout occures in the re-connection process, the NTRIP connection can never be restored as an error-state. In this case, users have to stop and re-start the APs to recover the connection.

Due to a problem in rtklib/src/stream.c. Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.100 Unable Multipath-Elevation Plot without SNR data (RTKPLOT ver.2.4.2)

Without SNR data in RINEX OBS files, it is not able to generate the Multipath - Elevation plot.

Due to a bug in rtklib/app/rtkplot/rtkdraw.cpp. Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.99 Dropping the last field of RTCM 3 SSR messages (RTKNAVI, RTKRCV ver.2.4.2)

The last correction field of RTCM 3 SSR messages could be dropped in some cases. The orbit and clock corrections for the last satellite in a message might not be properly applied in PPP cases.

Due to a bug in rtklib/src/rtcm3.c. Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.98 Invalid IODE field in decoded BINEX 0x01-02 messages (GLONASS ephemeris) (RTKNAVI, RTKRCV ver.2.4.2)

The IODE field in decoded BINEX 0x01-02 messages (GLONASS ephemeris) is invalid. The SSR orbit and clock corrections for GLONASS is not properly applied to BINEX input data stream by the IODE incompatibility problem.

Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.97 Invalid satellite antenna offset correction for PPP (RTKNAVI, RTKPOST, RTKRCV, RNX2RTKP ver.2.4.2)

The satellite antenna offset for PPP is based on only the L1 value. The antnena phase center should be the iono-free LC position of L1 and L2 offsets. If the L1 and L2 offsets are different, it is not properly corrected. Note that IGS08.ATX has no problem because all of L1 and L2 offset for GPS and GLONASS have the same values.

Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.96 Not compliant to RINEX 3.02 for BeiDou observation codes (RTKPLOT, RTKCONV, CONVBIN ver.2.4.2)

The current RTKLIB is based on RINEX 3.02 draft (December 10, 2012) in which the BeiDou B1 signal is represented as C2, L2, D2 and S2. The final RINEX 3.02 (April 3, 2013) defines the observation codes for BeiDou B1 as C1, L1, D1 and S1, which were changed from the draft. So RTKLIB cannot handle the observation codes of BeiDou C1, L1, D1 and S1 in the final RINEX 3.02.

Apply the patch rtklib_2.4.2_p7.zip. (2014/05/29)

No.95 Issues pointed out in GitHub issue list (ALL ver.2.4.2)

The following issues pointed out in the GitHub issue list are fixed and incorporated in the patch.
# 9 rtkplot: calculate mutipath for SBAS L1
#10 Negative Pseudorange
#11 NVS conversion error (floating point overflow)
#12 PPP ionosphere model defaults to OFF, not BRDC

Apply the patch rtklib_2.4.2_p4.zip. (2013/09/01)

No.94 Unable to read Galileo E1 pseudorange in RINEX 2.12 OBS (RTKPOST, RTKPLOT, RNX2RTKP ver.2.4.2)

Galileo E1 pseudorange data as "C1" cannot be properly read from RINEX 2.12 OBS files. There is no problem in RINEX 3 OBS files.

Due to a bug in rtklib/src/rinex.c. It is fixed in the patch rtklib_2.4.2_p4.zip. (2013/09/01)

No.93 Invalid time fields in NMEA sentences (RTKPOST, RTKNAV, RNX2RTKP, RTKRCV ver.2.4.2)

The NMEA solutions show invalid time fields with sec=60. For example, the second line in the following sententences shoud be "$GPRMC,115800.00,..."

$GPRMC,115759.00,A,...
$GPRMC,115760.00,A,...
$GPRMC,115801.00,A,...

Due to a bug in rtklib/src/solution.c. It is fixed in the patch rtklib_2.4.2_p4.zip. (2013/09/01)

No.92 Unable correction of satellite antenna PCV for PPP (RTKPOST, RTKNAVI, RNX2RTKP, RTKRCV ver.2.4.2)

Satellite antenna PCV (phase center variation) is not properly incorporated in PPP computation. The value for the zero nadir angle is always used.

Due to a bug in rtklib/src/rtkcmn.c. rtkcmn.c L3439 should be:

dant[i] = interpvar(nadir*R2D*5.0,pcv->var[i]);

It is fixed in the patch rtklib_2.4.2_p4.zip. (2013/09/01)

No.91 NVS cannot be selected as an input stream format (RTKRCV ver.2.4.2)

NVS cannot be selected as the input stream format for RTKRCV.

The NVS definition is missing in the format option table of rtklib/app/rtkrcv/rtkrcv.c. Please relpace L.182 of rtkrcv.c by the following line and rebuild the AP. (2013/06/30)

#define FMTOPT "0:rtcm2,1:rtcm3,2:oem4,3:oem3,4:ubx,5:ss2,6:hemis,7:skytraq,8:gw10,9:javad,10:nvs,15:sp3"

No.90 Some problems to port RTKLIB to Android (RTKRCV, CONVBIN, STR2STR ver.2.4.2)

Some problems are pointed out as the issues #2 - #8.

These problems are fixed. Apply the patch rtklib_2.4.2_p3.zip. (2013/06/02)

No.89 Unable to read Galileo navigation data for NovAtel OEM6 (RTKNAV, RTKCONV, STRSVR, RTKRCV, CONVBIN, STR2STR, RTKRCV ver. 2.4.2)

The Galileo navigation data message GALEPHEMERISB, GALALMANACB, GALIONOB and GALCLOCKB for NovAtel OEM6 cannot be properly read by message length errors.

Due to bugs in src/rcv/novatel.c. The patch will be released. Apply the patch rtklib_2.4.2_p3.zip. (2013/06/02)

No.88 Unable playback of log file with time-tags in 64-bit environement (STR2STR, RTKRCV ver. 2.4.2)

A Log file with time-tags cannot be properly playbacked by STR2STR or RTKRCV which is built in 64-bit environment.

Due to a bug in src/stream.c. File pointers in the time-tag file is not properly read because the program assumes 32-bit pointers. It does not affect to 32-bit APs. Windows binary APs included in the RTKLIB package also have no problem. The patch will be released. Apply the patch rtklib_2.4.2_p3.zip. (2013/06/02)

No.87 Invalid read of RTCM MSM stream with BeiDou data (RTKNAV, RTKCONV, STRSVR, CONVBIN, STR2STR ver.2.4.2)

If a RTCM MSM stream contains BeiDou measurement data, the time-tag indicates 14s offset. The MSM messages for other navigation systems are not able to be read in this case.

The current version assumes the epoch time of BeiDou MSM messages based on GPST. If the epoch time is based on BDT, the time offset of 14s between GPST and BDT induces invalid data read of MSM stream. Apply the patch rtklib_2.4.2_p3.zip. (2013/06/02)

No.86 Unable automatic update of real-time solution plot after the real-time buffer full. (RTKPLOT ver.2.4.2)

After the real-time ring-buffer of solution reaches full, the solution plot stops to be updated.

Due to a bug in app/rtkplot/plotmain.cpp. Apply the patch rtklib_2.4.2_p2.zip. (2013/05/18)

No.85 Unable decoding of BINEX message 0x7f-05 (RTKNAVI, RTKCONV, STRSVR, CONVBIN, STR2STR ver.2.4.2)

The BINEX message 0x7f-05 cannot propery decoded in case that the obsflags(1) does not follow obsflags(0).

Due to a bug in src/rcv/binex.c. Apply the patch rtklib_2.4.2_p2.zip. (2013/05/18)

No.84 Some minor bugs in v.2.4.2 (ALL ver.2.4.2)

The following minor bugs are found in ver. 2.4.2.

(1) Invalid standard deviation computation of precise clocks. (src/preceph.c)
(2) Invalid week number of Galileo ephemeris in RINEX for Javad. (src/rcv/javad.c)
(3) Invalid nutation coefficient table for ast_args(). (src/rtkcmn.c)
(4) Unable to select GLO, GAL, QZS and GEO nav files for RINEX ver. 2.12 in RTKCONV. (app/rkconv/convmain.cpp)
(5) Unable to build rnx2rtkp in Linux environment. (app/rnx2rtkp/gcc/makefile)

Apply the patch rtklib_2.4.2_p1.zip. (2013/05/08)

No.83 One second offset in converting Javad stream to RTCM 3 (STRSVR, STR2STR ver.2.4.2)

In case of converting a JAVAD raw stream to a RTCM 3 stream by STRSVR or STR2STR, one second offset is introduced in the time-tag of observation data.

Due to a bug in src/streamsvr.c. Apply the patch rtklib_2.4.2_p1.zip. (2013/05/08)

No.82 Unable to read GLONASS and GEO ephemerides in RINEX 3 (RTKPOST, RTKPLOT, RTKCONV, RNX2RTKP, CONVBIN ver.2.4.2)

GLONASS and GEO ephemerides in RINEX 3 can not be read. GLONASS and SBAS (ranging signal) satellites cannot be used for processing without ephemerides.

Due to a bug in src/rinex.c. Apply the patch rtklib_2.4.2_p1.zip. (2013/05/08)

Support Information for ver.2.4.1

Support Information for ver.2.4.0

Support Information for ver.2.3.0

Support Information for ver.2.2.2

Support Information for ver.2.2.1

Support Information for ver.2.2.0

How to apply a patch

(1) Extract zip file of the patch. Copy and overwrite it to the AP(s) and source program(s) in RTKLIB directory.
(2) From ver.2.3.0, all the patches include the executable binary AP(s) for Windows as well as source program(s). So usually you do not need to rebuild AP on Windows. If you want to build AP by yourself, try the following procedure.

(a) Execute Embarcadero C++ builder (http://www.embarcadero.com). Open the project file (*.cbproj) in the application program directory (rtklib_<ver>\app\<ap>) and rebuild the application program. For details, refere the manual 2.1 and 4.1.
(b) Execute install.bat in the application program directory. It copies the new program to the directory of binaries (rtklib_<ver>\bin).