RINGO: A RINEX pre-processing software for multi-GNSS data

Abstract

We have developed a new multi-GNSS data pre-processing software “RINGO” that provides various features including editing, quality checking, clock jump correction, higher order ionosphere correction, conversion of BINEX and RTCM files, and an interactive viewer for RINEX files. The recent increase in number of GNSS satellites has made GNSS data more complex; however, the software available to pre-process them is very limited. RINGO is a command line tool capable of handling multi-GNSS data, including GPS, QZSS, GLONASS, Galileo, and other systems in RINEX 2.xx, 3.0x, and 4.00 formats, which allows users to easily manage the multi-GNSS data observed at continuously operating reference stations. We present algorithms and applications for each RINGO feature. The results of the quality check feature were compared with results estimated by other existing software packages. Our results agreed well with those of the TEQC software. With RINGO, users can easily pre-process multi-GNSS data without combining multiple tools, and the software will contribute to the popularization of the latest RINEX format.

Graphical Abstract

Main text

Introduction

There are currently thousands of continuously operating reference stations (CORS) worldwide, providing the fundamental infrastructure for geosciences as well as precise positioning and mapping. The observed data are archived and provided in “Receiver Independent Exchange Format (RINEX)” (Gurtner et al. 1989) format, which is used in huge CORS networks around the world, such as International GNSS Service (IGS) network, the GNSS Earth Observation NETwork system (GEONET) in Japan [Tsuji et al. 2017; Geospatial Information Authority of Japan (GSI) 2022a], the NOAA CORS Network (NCN) in United States (National Geodetic Survey 2021), and EUREF Permanent Network (EPN) in the European continent (Bruyninx et al. 2019). The latest RINEX 4.00 supports the multi-GNSS data and the modern navigation messages from all the GNSS constellations. Support for multi-GNSS data in RINEX has been advancing, and preparations for providing multi-GNSS data are steadily underway.

The provision of the GNSS data and the generation of products require appropriate data pre-processing, e.g., editing, merging, quality checking, millisecond receiver clock steering (clock jump) correction, and ionospheric delay correction. There are already well-known pre-processing software available, such as TEQC (Translation, Editing, Quality Checking; Estey and Meertens 1999), clockprep (Freymueller 2023; Freymuellar 2003), G-Nut/Anubis (Václavovic and Douša 2016), and GFZRNX (Nischan 2016). However, users must combine these software packages and/or develop their own software to handle multi-GNSS data, because no software supports all of pre-processing tasks, e.g., some software packages only support RINEX 2.xx. TEQC is a simple but powerful command line tool designed to solve several pre-processing problems that arise in multi-GNSS RINEX data and provides editing and quality checking. However, the TEQC official site released the final version on February 25, 2019 (UNAVCO 2019), which still cannot process RINEX version 3.0x or later data. Clockprep software corrects clock jumps by smoothing the time tag introducing corresponding jumps to phase and pseudorange, which is required in few GNSS software. It only supports GPS data in RINEX version 2.xx. GFZRNX supports all the RINEX versions; however, the main purpose is editing of RINEX files. The free version of G-Nut/Anubis software only supports quality checking of RINEX 2.xx and 3.0x editing. Thus, the need for multifunctional GNSS data pre-processing software is increasing to simplify complex multi-GNSS data management tasks.

A new software named “RINGO (RINEX pre-processing tool using GO)” has been developed at the Geospatial Information Authority of Japan (GSI), which is a command-line tool offering several pre-processing tasks for managing RINEX data (e.g., merging, splitting and editing of observation and navigation data, clock jump correction, correction of first and second orders of ionospheric effects, and quality checking). It handles multi-GNSS data including GPS, QZSS, GLONASS, Galileo, SBAS, Beidou, and NavIC in RINEX version 2.xx, 3.0x, and 4.00 formats. The RINGO software is written in the platform independent Go programming language. A web-based graphical viewer in HTML5 can be also generated by RINGO software with simple command-line operations.

This paper presents the main features and algorithms of the RINGO software. First, we describe an overview of the software. Second, algorithms implemented in RINGO are shown. Finally, examples for some of the main features of RINGO, including clock jump correction, higher order ionospheric correction, quality check, and viewer, are discussed. Furthermore, the results of quality check are compared with the results estimated by existing software packages TEQC and G-Nut/Anubis.

RINGO software

RINGO is a portable command-line tool that manipulates RINEX observation and navigation files for MS Windows, MacOS, Linux, UNIX, and many other operating systems. RINGO supports several pre-processing operations for GNSS data, such as clock jump correction, correction of higher order ionospheric refraction, and conversion of binary formats, such as Binary Exchange Format (BINEX) and Radio Technical Commission for Maritime Services (RTCM) standard to RINEX format (Table 1). For daily automated pre-processing tasks for GNSS data, the command-line interface is more convenient than the graphical user interface. The RINGO software was developed using the open-source cross-platform programming language “Go” developed by Google. Go enables the software to work on various operating systems, such as UNIX, Linux, Windows, and MacOS without any modification of the source code. Furthermore, the RINGO software was developed purely in Go language to facilitate a portable and standalone application, because the pure Go programs are compiled to a single binary with no external dependencies. Users operating several servers can easily install the command by simply copying the single executable binary.

Table 1 Main features of the RINGO software

RINGO is a single binary executable software with several sub-commands that invoke a new set of options and features (Table 1). The main command of the RINGO software has global options that are commonly used for other sub-commands, and each sub-command has its own set of sub-options. This interface design is called as “subcommand-based interface.” The subcommand-based interface enables portable, simple, and multiple features, which can be provided by a single command. The commonly used options for each feature can be integrated into root flags to distinguish between the options for specific features and their corresponding flags. Thus, users can easily understand the meaning of flags and avoid navigating through duplicate, complex, and large sets of flags. Various software adopt subcommand-based interfaces, including Generic Mapping Tools version 6 (GMT6; Wessel et al. 2019), Git, and Docker, among others.

The general syntax of the RINGO software looks as follows:

$ ringo subcommand [global options] [command options] inputfiles > outputfile

where:

• ringo—root command with a simple help printer, root options and flags

• subcommand—subcommand that invokes specific feature with its own options and flags

• global options—global options and flags

• command options—subcommand options and flags

• inputfiles—RINEX observation and navigation files, and other files that are required for each subcommand

• outputfile—output file such as edited and/or corrected RINEX file, etc.

ringo is just a root command, and subcommand switches the features of RINGO.

Presently, the RINGO software supports RINEX versions 2.xx, 3.0x and 4.00. The supported data types for the data conversion from BINEX or RTCM to RINEX files are listed in Table 2. The RINGO software also supports compressed RINEX files including UNIX compression (.Z), gzip compression (.gz), bzip2 compression (.bz2) and tar-archived RINEX navigation file (.tar, .tar.Z, .tar.gz, and .tar.bz2) for direct reading. This feature is useful for users who archive compressed RINEX files; for example, GSI provides tar archived navigation RINEX files (e.g., 02550010.22N.tar.gz; GSI 2022a). The Hatanaka-compression (.crx, .crx.Z, .crx.gz ,.crx.bz2), can also be handled if the “CRX2RNX” command, which is a part of RNXCMP software (Hatanaka 2008; GSI 2022b), is located in the PATH. Examples are shown in Fig. 1.

Table 2 Supported file types, data types of the RINGO software

Fig. 1

Examples of RINGO execution commands

Specification and pre-processing algorithm

Editing of RINEX files/merge

The RINGO “merge” subcommand offers merging and editing of RINEX files required for daily file management tasks. If multiple RINEX files are given as input, they will be merged and output to standard output by default. The RINEX header values, such as the satellite system identifier, observation types, times of first and last observation records, and GLONASS slot and frequency numbers, are automatically changed according to the changed contents of merged file. The RINEX version will be also changed to be unified in merging different versions of RINEX files. The header values can be also replaced manually by setting the flags individually.

The RINGO “merge” subcommand can also edit RINEX files. For example:

• Extraction of data for a certain period

• Sorting data by satellite system, PRN number, and time tag

• Inclusion or exclusion of certain satellite system and/or PRN from the file

• Change of data interval

• Extraction and/or reordering of observation types

These functions facilitate daily RINEX file management.

Clock jump correction/clkcorr

The “clkcorr” subcommand corrects clock jumps in RINEX observation files. Most GNSS receivers utilize low-cost quartz oscillators that cause receiver clocks to drift with time, relative to the GPS time (atomic time scale). The clock offset between the receiver clock time and the GPS time accumulates significantly in continuous GNSS observations. Numerous GNSS receivers maintain the magnitude of the clock offset within a predefined range and in some receivers, this is accomplished by shifting the receiver clock by milliseconds when the offset exceeds the limit that depends on the receiver type. This behavior is called as “clock jump” (Fig. 2).

Fig. 2

Examples of observation data using different types of clock jumps: a Type 1, b Type 2, and c Type 3 clock jumps. The top, middle and bottom panels show phase and code pseudoranges, and millisecond part of time tag, respectively. The observation data of IGS sites STK2 (January 1, 2010) and MIKL (January 1, 2015), and GEONET site P212 (January 1, 2015) are shown

A GNSS receiver introduces a clock jump in two main ways: shifting the pseudorange corresponding to the amount of clock offset relative to the GPS time (Type 1) or shifting the time tag (Type 2) (Fig. 2a, b). Considering the pseudorange (in units of distance)

$$R = c\left( {t_{r} - t^{s} } \right) = c\Delta t + c\Delta \delta + e,$$

(1)

where $R$ is the pseudorange, $c$ is the speed of light, ${t}_{r}$ is the time tag referred to the receiver clock, and ${t}^{s}$ is the signal emission time referred to the satellite clock. $\Delta t$ is the true travel time and $\Delta \delta ={\delta }_{r}-{\delta }^{s}$, where ${\delta }_{r}$ and ${\delta }^{s}$ are the receiver and satellite clock biases, respectively, and $e$ denotes the sum of other errors. Here, if we ignore ${\delta }^{s}$ and $e$, the equation becomes

$$R = c\Delta t + c\delta_{r} .$$

(2)

If a clock jump $\delta {t}_{r}$ is introduced to the receiver clock,

$$R = c\Delta t + c\left( {\delta_{r} + \delta t_{r} } \right)$$

(3)

Therefore, a clock jump can be represented by either simultaneously shifting both the code and phase pseudoranges ($R-c\delta {t}_{r}$) or shifting the time tag (${t}_{r}+\delta {t}_{r}$). In the first case (Type 1), the code and phase pseudoranges include offsets that compensate for the clock jumps. In the second case (Type 2) the time tag becomes irregular time interval. If the clock jumps are introduced in either of the above mentioned ways, they are absorbed either by the clock bias or by ambiguity estimates. However, another clock jump behavior can be observed in some RINEX files that include mixtures of Type 1 and Type 2 clock jumps; some clock jumps are Type 1, but some are mixture of Type 1 and Type 2 clock jumps occurring on both time tags and code pseudoranges simultaneously (Type 3) (Fig. 2c). This behavior is sometimes seen in a combined RINEX file, e.g., a daily RINEX file created from hourly, 3 h, or 6 h files. These files should be repaired before or during positioning, because this behavior causes inconsistency between observables and clock bias.

The “clkcorr” subcommand automatically detects the clock jump events and repairs RINEX observation files by aligning them to either the Type 1 or Type 2. The clock jump events can be detected by calculating the difference between the time tags, code and phase observables between adjacent epochs. Type 1 clock jump events were detected from the averages of all time-differenced code and phase pseudoranges for an epoch as follows:

$${\Delta }P\left( {t_{i} } \right) = \frac{{\mathop \sum \nolimits_{k} {\Delta }P^{k} \left( {t_{i} } \right)}}{{n^{s} }},{\Delta }L\left( {t_{i} } \right) = \mathop \sum \limits_{k} {\Delta }L^{k} \left( {t_{i} } \right)/n^{s} ,$$

(4)

$$\Delta t_{iP} = \left( {\frac{{\mathop \sum \nolimits_{k} \Delta P^{k} \left( {t_{i} } \right)}}{{n^{s} }}} \right)/c,\Delta t_{iL} = \left( {\frac{{\mathop \sum \nolimits_{k} \Delta L^{k} \left( {t_{i} } \right)}}{{n^{s} }}} \right)/c,$$

(5)

With

$$\Delta P^{k} \left( {t_{i} } \right) = P^{k} \left( {t_{i} } \right) - P^{k} \left( {t_{i - 1} } \right),\Delta L^{k} \left( {t_{i} } \right) = L^{k} \left( {t_{i} } \right) - L^{{\text{k}}} \left( {t_{i - 1} } \right),$$

(6)

where $i$ and $k$ denote the epoch and specific satellite, respectively, $\Delta P$ and $\Delta L$ show the epoch differences of code $P$ and phase $L$ pseudoranges (in units of distance), respectively, ${n}^{s}$ is the total number of satellites available at epochs $i$ and $i-1$. Here, $\Delta {P}^{k}({t}_{i})/c$ and $\Delta {L}^{k}({t}_{i})/c$ were rounded to the nearest integer milliseconds, and if these values were different, they were ignored as possible cycle slip. Type 1 clock jump events were detected based on the criterion $\left|\Delta {t}_{iP}\right|>0.9$ ms and/or $\left|\Delta {t}_{iL}\right|>0.9$ ms. Then, the extent of clock jump $\delta {t}_{r}$ was determined as the nearest integer milliseconds. Type 2 clock jump events can be easily detected by checking whether the fractional part of the time difference between adjacent epochs is not zero. Type 3 clock jump events were identified when the fractional part of the time difference and rounded value of $\Delta {t}_{iP}$ were equal.

Finally, RINGO corrects clock jump events by shifting either the time tags by $-\delta {t}_{r}$ or the code and phase pseudoranges by $c\delta {t}_{r}$, and the manner of clock jump becomes consistent throughout the RINEX file. The user can switch between smooth interval of time tag or code and/or phase pseudoranges using the command option “--smpr”.

Quality check algorithm

Quality control of the GNSS data is essential for the operation of the GNSS CORS network. Data quality can worsen due to several reasons: malfunction of the hardware, e.g., receiver, antenna, deterioration of the observation environment by tree growth, and construction of tall buildings. Multipath estimates and number of cycle slips are important identifiers for quality checks. Multipath error is caused when indirect signals of satellites are reflected from nearby obstructions. A cycle slip is an instantaneous jump in carrier phase measurement, which is caused by a very low signal-to-noise ratio, owing to the multipath effect, ionospheric delay, and tropospheric delay, among other factors. They can also be caused by malfunctioning of receivers and satellites. Loss of track due to the obstructions (e.g., trees and buildings) is also a common cause of cycle slip.

The RINGO software provides statistical information on quality control:

• The observation rate represented by the ratio of actual and expected observation epochs at the site

• The number of actual and expected observables at the site

• The number of satellites included in the RINEX file

• The code multipath and signal noise for each frequency

• The number of cycle slips for each satellite and satellite system

RINGO calculates code multipath and signal noise level as a standard deviation of the multipath (MP) linear combinations (Estey and Meertens 1999), and it detects cycle slips in the MP linear combination, Melbourne–Wübbena (MW) linear combination (Wüebbena 1985; Melbourne 1985), and ionosphere linear combination (Estey and Meertens 1999). Outliers and sudden jumps between adjacent epochs in the linear combinations are considered to indicate possible cycle slips. The pairs of frequencies used to estimate each linear combination are predefined in RINGO (Table 3).

Table 3 Pair of the frequency bands used for each linear combination estimate

The MP linear combinations are formulated as follows:

$$MP_{i} = P_{i} - L_{i} - \frac{{2f_{j}^{2} }}{{f_{i}^{2} - f_{j}^{2} }}\left( {L_{i} - L_{j} } \right) = P_{i} - \frac{{f_{i}^{2} + f_{j}^{2} }}{{f_{i}^{2} - f_{j}^{2} }}L_{i} + \frac{{2f_{j}^{2} }}{{f_{i}^{2} - f_{j}^{2} }}L_{j}$$

(7)

where ${P}_{i}$ and ${L}_{i}$ are the code and phase pseudoranges, respectively, ${f}_{i}$ denotes the carrier frequency, and subscripts $i$ and $j$ denote the corresponding signals with different frequencies. In the MP linear combination, the geometric and ionospheric terms are canceled, leaving only the multipath noise and DC component. The MP combination mainly varies with time due to the code multipath, signal noise, and jumps due to cycle slips. The typical value of the standard deviation of the MP combination was below ~ 0.5 m for GPS L1 and L2 (e.g., Fig. 5), and the $4\sigma$ outlier detection level was approximately 2.0 m. Thus, RINGO exploited the threshold of cycle slip detection based on the MP combination as a jump over 2.0 m with respect to the rolling average for the previous 50 epochs, by default.

The MW linear combination was also used to check the cycle slips. The MW linear combination is defined as the difference between the wide-lane phase and narrow-lane code combinations with eliminating the effects of the ionosphere, geometry, clocks, and troposphere:

$$L_{MW} = L_{w} - R_{N} = \frac{1}{{f_{i} - f_{j} }}\left( {f_{i} L_{i} - f_{j} L_{j} } \right) - \frac{1}{{f_{i} + f_{j} }}\left( {f_{i} P_{i} + f_{j} P_{j} } \right) = \lambda_{W} \left( {\Phi_{i} - \Phi_{i} } \right) - \frac{1}{{f_{i} + f_{j} }}\left( {f_{i} P_{i} + f_{j} P_{j} } \right),$$

(8)

where ${\Phi }_{i}$ denotes the phase pseudoranges (in cycles) and the remaining term represents the wide-lane phase ambiguity and signal noise (Blewitt 1990)

$$L_{MW} = \lambda_{W} N_{W} + e ,$$

(9)

With

$$\lambda_{W} = c/\left( {f_{i} - f_{j} } \right).$$

(10)

For a combination of GPS L1 and L2 observables, the effect of 1-cycle slip (${\lambda }_{W}$) is ~ 0.86 m. Following Blewitt (1990), RINGO identifies cycle slips that jumps over 4 $\sigma$ of the rolling average for previous 50 epochs by default. With a typical RMS of the 0.5 cycles for the MW combination (Dach et al. 2015) the outlier detection level of RINGO (4 $\sigma$ outlier level) corresponds to ~ 1.7 m for GPS L1 and L2.

The geometry free (GF) linear combination [e.g., Blewitt (1990)] is defined by the following equation:

$$GF_{ij} = L_{i} - L_{j} = \lambda_{i} N_{i} - \lambda_{j} N_{j} - I_{i} + I_{j}+e ,$$

(11)

where $\lambda$ is the wavelength, $N$ is the ambiguity, and $I$ denotes the ionospheric delay. The GF linear combination contains only the ambiguity and ionospheric effect. As the ambiguity terms are constant and the ionospheric delays are continuous in time, any unexpected jumps in the time series are caused by cycle slips. The GF combination cannot distinguish whether the ${L}_{i}$ or ${L}_{j}$ signal is corrupted due to a cycle slip, but it is much more accurate than MP and MW linear combinations, because the GF combination is formed by only carrier phase observables. For determining the threshold for cycle slip detection, the ionospheric delay on the frequency $i$ can be defined as follows (Estey and Meertens 1999):

$$IOD_{i} = \frac{{f_{i}^{2} }}{{f_{i}^{2} - f_{j}^{2} }}GF_{ij} = \alpha_{ij} GF_{ij}$$

(12)

RINGO detects cycle slips based on jumps in the changing rate of ionospheric delay $IOD$ that exceeds 0.05 m/sec by default. Compared to other software, TEQC uses the threshold of 0.067 m/sec. The default threshold of 0.05 m/sec for RINGO was determined to be compatible with TEQC, but it was set slightly smaller that used by TEQC to allow detection of 4-cycle slip on L1 with the sampling interval of 30 s.

It should be noted that this detection method depends on the sampling interval: the effects of 1-cycle slip for the data with time interval $\Delta t$ are ${\alpha }_{12}{\lambda }_{1}/\Delta t$ = 0.48 m/$\Delta t$ and ${\alpha }_{12}{\lambda }_{2}/\Delta t$ = 0.62 m/$\Delta t$ for L1 and L2, respectively. The standard deviation of the changing rate of $IOD$ is ~ 0.001 m/sec. Considering the case of data with a sampling interval of 30 s, the effect of 1-cycle slip on L1 decreases to ~ 0.016 m for the changing rate in $IO{D}_{1}$. Thus, the magnitude of cycle slip that can be detected with the threshold of 0.05 m/sec is more than 4 cycles for the data with the sampling interval of 30 s that are commonly used in various data centers.

In summary, RINGO uses the thresholds of 2.0 m, 4 $\sigma$, and 0.05 m/sec by default for the cycle slip detections based on MP, MW, and IOD linear combinations. At the time of writing, these thresholds are used equally for all satellite systems.

Higher order ionospheric correction

Ionospheric effects significantly affect the GNSS signals. The first-order effect can be eliminated using an ionosphere free linear combination. However, the second-order effect cannot be eliminated using solely dual-frequency measurements. The second- and higher order ionospheric effects on GNSS positionings can reach up to ~ 5 mm for horizontal and vertical components, respectively (Kedar et al. 2003; Fritsche et al. 2005; Munekane 2005). To obtain higher quality positioning results, the second-order ionospheric effect should be corrected.

RINGO directly eliminates the first- and/or second-order ionospheric effects on both the code and phase pseudoranges in a RINEX file. Ionospheric effects on GNSS signals on code and phase measurements can be modeled as follows (Bassiri and Hajj 1993):

$$P_{i} = \rho + \frac{q}{{f_{i}^{2} }} + \frac{s}{{f_{i}^{3} }},$$

(13)

$$L_{i} = \rho + N_{i} \lambda_{i} - \frac{q}{{f_{i}^{2} }} - \frac{1}{2}\frac{s}{{f_{i}^{3} }},$$

(14)

With

$$q = 40.3 \smallint Ndl,$$

(15)

$$s = 7527c \smallint N\left| {{\mathbf{B}}_{0} } \right|cos\theta_{B} dl,$$

(16)

where $\rho$ is the geometrical distance including all nondispersive terms (phase center variations, multipath, noise etc.), $N$ denote the electron density, ${\mathbf{B}}_{0}$ is the Earth’s magnetic field vector, ${\theta }_{B}$ is the angle of intersection between ${\mathbf{B}}_{0}$ and the signal propagation, and $l$ denotes the propagation path of the signal.

With the single-layer approximation [e.g., Mannucci et al. (1998)] and the total electron content (TEC) expressed as $TEC=\int Ndl$, then $q$ and $s$ can be rewritten as

$$q = 40.3 \times TEC,$$

(17)

$$s = 7527c \times \left| {{\mathbf{B}}_{0} } \right|cos\theta_{B} \times TEC.$$

(18)

The TEC and ${\mathbf{B}}_{0}$ at the ionospheric pierce point (IPP) can be estimated using the International Geomagnetic Reference Field (IGRF) (Alken et al. 2021) and the global ionospheric map (GIM) provided by IGS. During the coding and development of RINGO, the latest version of IGRF, IGRF13 (Alken et al. 2021) and the GIM in IONEX format (Schaer et al. 1998) provided by IGS were employed. The VTEC value provided by IGS was mapped toward the direction of the propagation path using the following mapping function:

$$TEC = \frac{1}{{cos\theta^{\prime}}}VTEC,$$

(19)

$$sin\theta^{\prime} = \frac{{R_{e} }}{{R_{e} + H_{IPP} }}sin\theta ,$$

(20)

where ${R}_{e}$, ${H}_{IPP}$, and $\theta$ are Earth’s radius, height of the ionospheric pierce point (IPP), and zenith angle, respectively. The height of the IPP (450 km) was obtained from the GIM data.

Examples of RINGO application

The following examples demonstrate the clock jump correction, quality check, higher order ionospheric correction, and interactive viewer output with RINGO.

Clock jump correction/clkcorr

The data of IGS site “AIRA” on January 1, 2001, show “Type 3” clock jump behavior (Fig. 3a). Clock jumps of 1 ms are introduced on time tag, and accumulated clock jumps are reset to zero every 3 h and the code pseudorange is simultaneously jumped by $-\delta t\times c$. These clock jumps were corrected by RINGO software using “clkcorr” subcommand (Fig. 3). The RINGO “clkcorr” offers both time tag smoothing (i.e., correction to “Type1”) and code and phase smoothing (i.e., correction to “Type 2”) option, which is invoked by --smpr option. “Time tag smoothing” corrected the irregularly spaced time tags to align them at regular interval. The command simultaneously imposed jumps equivalent to the amount of corrections on the code and phase pseudoranges (Fig. 3b). “Code and phase smoothing” smoothed the jumps on code and/or phase pseudoranges caused by clock jumps, and 1 ms jumps were accumulated on the time tag (Fig. 3c). Even if clock jumps larger than 1 ms occur, RINGO estimates the amount of the clock jump to be the nearest integer milliseconds from Eq. (5) and can handle them without any problem. “Time tag smoothing” is useful to align time tags to take differences of observables with other RINEX files easily. On the other hand, “Code and phase smoothing” is useful for all GNSS phase-based applications that require continuous code and phase pseudoranges, e.g., GNSS–TEC method to monitor large earthquakes (Heki 2022).

Fig. 3

Examples of clock jump corrections. a no correction, b time tag smoothed, and c code and phase smoothed. The top, middle, and bottom panels show phase and code pseudoranges, and millisecond part of time tag, respectively. The observation data of IGS site AIRA (January 1, 2001) are shown

Higher order ionospheric correction/ioncorr

RINGO “ioncorr” subcommand corrects the first- and/or second-order ionospheric effects estimated from the GIM by IGS in IONEX format. The GNSS data of the GEONET station “0255 (Komatsu)” (August 28, 2021) were chosen for demonstration and first- and second-order ionospheric effects were corrected using RINGO “ioncorr” subcommand. The ionosphere combination showed rapid change during the day over 2 m in code GF combination, 1.5 m in phase GF combination for QZSS J07 satellite (Fig. 4d, e). The ionospheric disturbances decreased drastically to less than 1 m after the “ioncorr” with first- and second-order corrections (Fig. 4d, e). The ionospheric corrections are useful for single-frequency data that cannot form an ionosphere-free linear combination for positioning. The second-order ionospheric effects cannot be canceled out even with the ionosphere-free linear combination. Thus, it is useful for positioning with millimeter-level precision, especially for equatorial areas, where the second-order ionospheric effects are larger.

Fig. 4

Example of ionospheric correction. Corrected values for a first-order and b second-order ionospheric effects, c azimuth and elevation angles, changes in geometry free combination with/without ionospheric correction for d code and e phase, and f)global ionosphere map used for the correction. The QZSS J07 data of GEONET site “0255 (Komatsu)” (August 28, 2021) are shown. The IGS Global Ionosphere Map for the same day was used

Quality check/qc

Performing quality checks are crucial for the daily operation of CORS network. The RINGO “qc” subcommand offers the quality check function capable of multi-GNSS. The quality of GPS data observed at IGS site “TSKB” was checked for the period from 1995 DOY1 to 2018 DOY217 (Fig. 5). The data interval was 30 s and the elevation mask was set 10 degrees above the horizon. The daily standard deviations of MP1 and MP2, and the daily number of slips detected by the rate of IOD change were estimated. Quality checks were also conducted using the TEQC software (version 2019 Feb25) and G-Nut/Anubis software (Free version 3.3) for comparison and validation. Cycle slip counts by G-Nut/Anubis were extracted from the “nSlp” estimates, which denotes number of identified phase cycle slips during a continuous tracking (Douša and Václavovic 2022).

Fig. 5

Example of quality check. Standard deviations of a MP1, b MP2 linear combinations, and number of cycle slips detected from c change rate of ionosphere delay, and d Melbourne–Wübbena linear combinations. Results by RINGO (blue), TEQC (orange), and G-Nut/Anubis (gray) are shown

The cycle slip detection algorithms are different between the software packages. TEQC is based on change of IOD combination with the threshold of 0.067 m/sec. G-Nut/Anubis is based on extra-wide lane (same as MW), wide lane, and narrow lane combinations with the threshold of 0.5 cycles (Zhao et al. 2015). Therefore, number of cycle slips by RINGO based on IOD combination (threshold of 0.05 m/sec) and MW combination (threshold of 4 $\sigma$) were compared with the results by TEQC and G-Nut/Anubis, respectively.

The results of quality checks at “TSKB” showed distinct change in the level of daily standard deviation (MP1 and MP2) on May 1, 2000, June 18, 2002, and October 15, 2013 (Fig. 5a, b). These changes corresponded to the end of “Selective Availability (SA)” (National Coordination Office 2001) and change of GNSS receivers (GSI 2022c), respectively, which were successfully detected by all three software packages RINGO, TEQC, and G-Nut/Anubis. The number of cycle slips detected by the rate of change in IOD showed slight decrease on May 1, 2000, distinct decrease on June 18, 2002, and increase after around September 2011 from the results by RINGO and TEQC (Fig. 5c). The first two events were consistent with the result of the changes in standard deviations of daily MP1 and MP2, but the last event did not correspond to any change of device. The number of cycle slips based on the MW linear combination showed no distinct change in the timings of SA off on May 1, 2000 and the first receiver change on June 18, 2002 (Fig. 5d). This method is not supported by TEQC. RINGO also implements the cycle slip detection based on MW combination with several times more cycle slips detected than the change rate of IOD combination.

The standard deviations of MP1 and MP2, and the number of slips based on IOD change rate estimated by RINGO were consistent with the TEQC results, except for the period before June 18, 2002. The standard deviations of MP1 and MP2 estimated by TEQC were larger than those of RINGO before June 18, 2002. The reason for these discrepancies is not clear but could be due to the calculation procedure of linear combinations without L2 signal. The tracking timing of L2 signal was significantly delayed compared to that of the L1 signal before the receiver was changed on June 18, 2002 and improved after the receiver was changed to “AOA BENCHMARK ACT” from “ROGUE SNR-8100.” Although the number of detected cycle slips based on IOD change rate was consistent between RINGO and TEQC, the result by G-Nut/Anubis had been several times larger than the RINGO MW-based result until the first receiver change, then became smaller until the second receiver change, and then became larger again (Fig. 5d). This is likely due to the differences in the detection thresholds used by each software. As mentioned before, the default threshold used by RINGO can detect cycle slips more than 4 $\sigma$ (~ 2 cycles); however, the magnitude of detectable cycle slips varies with the noise level of the data. On the other hand, G-Nut/Anubis can detect 1-cycle slip, but the threshold is fixed, resulting in larger number of cycle slips for noisy data. This setting is a trade-off depending on the situation. Then, combining the results based on the IOD change rate and the MW combination would detect cycle slips more accurately. However, it should be noted that the false detection of cycle slips also increases when the MW combination-based method is used, because it uses the code pseudoranges with higher noise level.

RINGO RINEX viewer/viewer

RINGO software can output single html file as a viewer (Fig. 6). The viewers show GNSS data and quality checking result with interactive legends and data points. The chart can be zoomed in and out, and when the cursor is placed on any data point, the observation data and estimated linear combination values are displayed. The menu in the upper left corner or left side of the window can be opened to switch between satellites. With these viewers, the users should be able to check observation data, cycle slips, noise levels in the data, etc. easily.

Fig. 6

Data visualization examples by RINGO “viewer” command. The appearances of a observation data display screen, b satellite switching screen, c quality check result display screen, and d enlarged view of the same panel. Each numerical value is also shown by tracing over the data points with the mouse cursor

Summary and conclusion

We have developed a command line tool RINGO to pre-process daily GNSS data easily. RINGO can work on various operating systems, including Windows, MacOS, Linux, and Unix; it supports RINEX versions 2.xx, 3.0x, and 4.00 (i.e., the latest version at the time of writing). RINGO offers several features necessary for daily operation of a GNSS network. The features offered by RINGO support users to manage continuous GNSS stations and to analyze those data. Although the algorithms implemented in RINGO are not that new, they ensure interoperability with existing software such as TEQC and allow users to use newer versions of RINEX.

The latest RINEX format supports most of the new features of multi-GNSS data; however, there is no doubt about the fact that pre-processing tools are lacking. RINGO would contribute toward improving this situation and will help popularize the latest RINEX format.

Future developments could include the implementation of more reliable cycle slip detection algorithms, e.g., using triple frequencies (Lacy et al. 2012; Liu et al. 2018). With the recent modernization of GNSS satellites, the availability of triple-frequency signals has created the ability to use them for performing cycle slip detection. Adding a feature for cycle slip repair might be an option for RINGO in the future. In addition, due to the increasing number of GNSS satellites in recent years, the size of GNSS data has exhibited an increasing trend. Therefore, efficiency of software is important to reduce the execution time. Finally, RINGO is a relatively new software, and further research will be critical to its development.