Multiple global navigation satellite system (GNSS) measurements exist that can be used for position, velocity, and time (PVT) computations. These include code, carrier, and doppler measurements. RTK uses carrier phase measurements to provide more precise PVT than code-based positioning. Theoretically, RTK is able to provide centimeter-level positioning to its users [1]. Multiple GNSS receivers exist that provide RTK solutions, but commercial software packages are expensive [2]. A list of the available open-source and closed-source GNSS packages with RTK capabilities is provided by the National Geodetic Survey (NGS) [3]. RTKLIB is one of the open-source packages available to the public.

RTKLIB was first developed in April 2006 by Tomoji Takasu, first released to the public as an open source in January 2009, and is currently distributed under a BSD 2-clause license [4]. The latest version from Takasu’s branch is 2.4.3 b34, which was released on 29 December 2020, but multiple forks exist, including the one from the author of this paper, Tim Everett. For user interface, RTKLIB offers graphic user interface (GUI) access points (AP) on Windows and Console apps on both Windows and Linux environments. RTKLIB is a powerful GNSS data analysis tool that can process various types of GNSS, data including receiver independent exchange format (RINEX) [5] and radio technical commission for maritime services (RTCM) formats [6]. Using the input data, it is able to carry out various position computations, including single point positioning (SPP), differential GNSS (DGNSS), real-time kinematic GNSS (RTK-GNSS), post-processing kinematic GNSS (PPK-GNSS), and precise point positioning (PPP). Over the years, numerous updates have been made to the RTKLIB for the support of multi-constellation and multi-frequencies. For this paper, we look at the PPK solution, since it does not require any real-time navigation solution computations, and PPK is able to provide higher accuracy position solutions than SPP and PPP [7]. Furthermore, all the GNSS observables and ephemeris information from nearby base stations required for PPK are available from various public servers.

GSDC was a Kaggle competition held by Google in 2021 (with a second expected offering in 2022). The objective was to generate the most accurate position solutions for a large number of raw observation data sets collected using Android devices inside a moving vehicle in the San Francisco Bay area [8]. In 2021, two sets of data, training and test, were provided by Google on Kaggle [9]. There were 29 routes and 73 smartphone data in the train set, and 19 routes and 45 data in the test set. There were multiple data for each route because multiple Android devices, spaced approximately 20 cm apart, were logging the data at the same time. During the drive, truth data was also collected using a NovAtel SPAN ISA-100C unit. This is because the SPAN unit is able to provide a horizontal accuracy of up to 0.01 m RMS [10]. As the smartphones were not in the same location as the antenna, their relative displacements with respect to the NovAtel antenna were taken into account for the smartphone truth determination. The training set was provided with the corresponding truth positions, but the truth for the test set was used for the Kaggle leaderboard determination. The data collected was provided in both RINEX and raw GnssLogger format. Although the raw format is what is logged by the smartphone, Google also provided a translation of the raw measurements into the RINEX format for those who preferred the more commonly used format. The measurements were filtered by Google during the conversion, and more details on this are provided in the Data Conversion section.

The drive routes can be classified into highway, street, and downtown, depending on the amount of expected multipath in the signals [11]. The highway is mostly open-sky, the street is open-sky with some attenuation from trees and nearby buildings, and downtown is heavily affected by attenuation and multipath from high-rise buildings. For the phone setup, the devices were located on the dashboard of the vehicles with no ground plane, which means that they were exposed to significant amounts of additional signal attenuation, and multipath at least at the level as to what would be expected if the antennas were placed on the roof of the vehicle.

The scores for the competition were determined by averaging the 50th percentile and 95th percentile errors of the computed latitude and longitude positions at each time epoch. The errors were computed using truth provided by the NovAtel SPAN unit. As the truth was not released for the test set, the scores were available upon submitting a list of the computed positions to the Kaggle website. In order to allow the participants to test the Kaggle website interface, a baseline results file was provided by Google as well. The algorithms used by Google to obtain the positions in the baseline file were proprietary, but some details about how the results were processed were provided to all participants [12].

Coupled with commercial receivers such as u-blox, RTKLIB has been able to provide centimeter level of accuracy [13]. However, as RTKLIB was originally designed for commercial GNSS receivers with survey type measurements, multiple adaptations are required for its use in GSDC, where only the GNSS measurements from smartphones are available. The smartphones used in GSDC (Google Pixel4 variants, Samsung S series variants, and Xiaomi Mi8) have several differences from commercial GNSS receivers, particularly with respect to antenna design/performance [14]. Consequently, the quality of the measurements is worse, leading to greater signal noise, increased number of carrier phase cycle slips, and increased multipath. This issue is illustrated by Qiong [15], when raw GNSS measurements from a Xiaomi Mi8 smartphone and a geodetic receiver collected at the same time were processed using RTKLIB. When GPS L1 measurements from both devices were processed using the same kinematic PPP mode, the geodetic receiver had horizontal position errors of approximately 1 m, while the smartphone’s errors were approximately 3–5 m, due to fewer observed satellites and lower carrier to noise ratio density (C/N₀) for the tracked satellites.

In the 2021 GSDC, the 1st-place winner used factor graph optimization, coupled with Takasu’s version of the RTKLIB, to obtain a score of 1.62 m [11]. Other teams used Google’s baseline Android navigation engine [16] or their own proprietary navigation engines [17]. In the Results section of the paper, the performance of the updated RTKLIB against other navigation engines will be provided using the official Kaggle scoring system. The comparison candidates are Google’s baseline solution and the scores of other participants. The goal will be to assess where the performance of the suggested RTKLIB adaptation stands among other available navigation engines used in the competition.