Introduction

The proliferation of BeiDou and Galileo satellites, alongside the modernization efforts of GPS and GLONASS, has led to a substantial increase in the available information from the Global Navigation Satellite System (GNSS). With the advent of multi-frequency and multi-GNSS, significant revisions have been made to the Receiver Independent Exchange Format (RINEX) (Gurtner and Estey 2013) observation file over time. Thanks to the RINEX format, GNSS receiver-dependent proprietary format is no longer a problem for the GNSS community. International GNSS Service (IGS) adopted the RINEX format for disseminating the GNSS observations data.

While RINEX 2.xx observation format is mainly designed to support GPS and GLONASS, RINEX 3.xx accommodates multi-GNSS and multi-frequency data. Signal modulations (tracking modes) are not ambiguous in RINEX 3.xx as in RINEX 2.xx. For example, second frequency phase observation (L2) in RINEX 2.xx could refer to any of the following frequencies: L2D, L2S, L2L, L2X, L2P, L2W, L2Y, L2M, and L2N as specified in the RINEX 3.xx format. RINEX 4.xx format was mainly created to improve the navigation file, and no changes were made in the observation format (Janssen 2024). Data volume in RINEX 3.xx is significantly higher than in RINEX 2.xx, due to its unambiguous signal modulation in RINEX 3.xx. More than 100 GNSS observation codes belonging to multi-GNSS constellations can be available in a RINEX 3.xx file. Because of some software and/or hardware restrictions or other unknown issues, some epochs and frequencies can be lost in RINEX file. Before processing RINEX file for point positioning such as Precise Point Positioning (PPP) (Zumberge et al. 1997; Ogutcu et al. 2023a) or Relative Precise Point Positioning (El Shouny, A et al. 2019; Alcay et al. 2019), data quantity should be investigated. Depending on the positioning algorithm, only specific observation frequencies are generally used, not all available frequencies. Therefore, users need to obtain the availability of the specific observation frequencies in RINEX file. For example, first frequency phase observation (L1) in RINEX 3.xx can be recorded on the two different tracking modes i.e., L1C and L1W. Users typically prefer to choose the signal with higher availability among these two first GNSS observation codes options.

Some publicly available preprocessing GNSS software packages are available, such as TEQC (Estey and Meertens 1999), G-Nut/Anubis (Vaclavovic and Dousa 2016), GFZRNX (Nischan 2016), RINGO (Kawamoto e al. 2023), GDPS (Lu et al. 2024), GDP (Chen et al. 2020) and BKG Ntrip Client (Weber and Mervart 2009). Most of them were mainly created to investigate RINEX data quality, such as multipath, Carrier-to-Noise Ratio (CNR), and cycle slips. Before investigating data quality, data quantity should be investigated to determine whether any GNSS receiver software or hardware malfunction exists. Epoch and GNSS observation code analyses are not possible in most publicly available preprocessing GNSS software packages, especially when considering BLOCK dependence. For example, TEQC only supports GPS and GLONASS satellites data and it has reached the end of its life with the final release on February 25, 2019. Free version of G-Nut/Anubis only works in LINUX operating system, and it has no Graphical User Interface (GUI). Parallel processing is also not available for the free version of G-Nut/Anubis. GFZRNX has also no GUI and does not support parallel processing. Some of the abovementioned software have GUI and support parallel processing, but they are not primarily designed for epoch and GNSS observation codes availability analyses of large RINEX datasets. Data integrity analysis can be conducted using with some research GNSS software, such as GipsyX (Bertiger et al. 2020), GAMIT/GLOBK (Herring et al. 2010), Bernese (Dach et al. 2015), and PRIDE (Geng et al. 2019). However, these software packages require a strong professional background and custom-type scripts to use them efficiently. Moreover, they are not specifically designed to efficiently investigate RINEX data availability, and many of them are not open source.

To address the above limitations of the publicly available preprocessing GNSS software packages, the open-source RINEX SCAN software was designed for multi-GNSS observation codes and epoch data availability analysis. The software was designed to scan epochs and multi-GNSS frequencies as quickly as possible. The organization of this article is as follows: Firstly, the main features of the software functionality is given in detail. In the Experimental Setup and Result section, a speed test was conducted using a one-month RINEX dataset from all IGS-MGEX stations in the CDDIS (The Crustal Dynamics Data Information System) archive, which included 11,772 RINEX files with 30-second intervals. In addition, a speed test was conducted using high-rate RINEX data with 1-second intervals over four days (DOY 001–004 in 2024). Each 15-minute RINEX file with 1-second intervals were merged to create daily (24-hour) RINEX files with 1-second intervals. Subsequently, the epoch and observation codes availabilities are summarized for the RINEX files with 30-second intervals. Finally, the corresponding conclusions are given.

Rinex scan software

RINEX SCAN offers users a fast and easy processing experience with a user-friendly and intuitive Graphical User Interface (GUI). The software was written in C#. For now, the software is supported only by Windows operating system. The main functionality of the software is to scan the epoch and code/phase frequencies of GNSS that are included in the RINEX header. Some auxiliary data files are needed to efficiently scan multi-GNSS frequencies. These are the up-to-date Antenna Exchange Format (ANTEX) file and predefined “BLOCK_TYPES_SPECIFIC_FREQUENCIES” (BTSF) text file. These files are used to diagnose whether the empty frequencies in the RINEX file are related to receiver malfunctioning, or the related satellites are not broadcast the specific frequencies. This situation is also critical for low-cost receivers, as most of them output civilian frequencies. For example, the third civilian GPS signal (L5) is only broadcast for GPS satellites belonging to BLOCK IIF and newer blocks. GPS satellites belonging to the older BLOCK types are not broadcasting L5 signals. Since the Pseudorandom Noise (PRN) numbers and BLOCK types of satellites change over time, the ANTEX file is necessary to determine which BLOCK type is defined for the corresponding GPS satellites at the time of the RINEX file. A similar situation exists for GLONASS satellites. If this control is not conducted, the result of the average GNSS observation codes availability will be lower than the real value. To illustrate this issue, one month of daily RINEX data (DOY:001–030, 2024) from u-blox ZED-F9P low-cost receivers was used. The availability of L2_C (C2X/L2X) GPS second-frequency civil observation codes for code and phase data was investigated, both with and without considering the BLOCK types. Code/phase second frequency availabilities of 74.2% / 72.1% and 95.6% / 92.8% were computed without using BLOCK type and with using BLOCK type, respectively.

Since all signals broadcasting from Galileo and BeiDou belong to civil frequencies, the ANTEX file is not needed to explore the causes of the empty frequencies for Galileo and BeiDou satellites.

The RINEX SCAN program processes RINEX files by reading them line by line without fully loading them into RAM, ensuring optimal memory usage even as the number of files increases. To limit (input/output) I/O operations and enhance responsiveness, the default mode sets the concurrent parallel process count to half the number of CPU cores. Users can also check the “Max Parallel Operation” checkbox to fully utilize the available processing power. It can utilize all available processor cores and process multiple files in parallel, resulting in efficient performance in terms of speed and time. When this option is unchecked, this ensures that other tasks on the user’s computer do not become unresponsive if they are running simultaneously. The users can also input the Hatanaka format of the RINEX files. If the input files are in the Hatanaka format, the compressed Hatanaka files are converted to uncompressed RINEX files using CRX2RNX.exe file before processing. After the processing, they are converted to compressed Hatanaka files to save the space. To ensure the software runs smoothly without critical errors, try-catch structures have been implemented while processing RINEX files. This handles cases such as loading non-RINEX files or encountering unusual issues within RINEX files, allowing the software to continue functioning without interruption or crash. This control structure is not only used in file import and read process but is also applied within various loops, such as reading epochs and frequencies of RINEX files. Figure 1 shows the GUI of the RINEX SCAN software. Figure 2 shows the workflow of the RINEX SCAN.

Fig. 1
figure 1

GUI of the RINEX SCAN (Upper part: Before processing, Bottom part: during processing)

Full size image
Fig. 2
figure 2

Workflow of the RINEX SCAN

Full size image

The BTSF file is created to distinguish the BLOCK-specific GPS and GLONASS frequencies that are not broadcast by every satellite. For example, the new GPS L1C civil signals only broadcast from GPS BLOCK III satellites. Similarly, GLONASS G3 Code Division Multiple Access (CDMA) signals are broadcast from GLONASS satellites belonging to BLOCK K and M+. Since BLOCK types can change over time, detecting BLOCK-specific signals requires specifying the date of the RINEX files and using an up-to-date ANTEX file. RINEX SCAN determines the corresponding BLOCK types based on the date of the RINEX files. If this control is not conducted, the average availability of the BLOCK specific frequencies cannot be computed correctly. In conclusion, users cannot definitively determine whether the low availability results are related to issues with the receiver.

In some cases, BLOCK specific GPS and GLONASS satellites defined in BTSF file are not included in the ANTEX file for the corresponding dates of the RINEX file. When the satellites are in the test stages, they broadcast the corresponding frequencies in a few epochs in the RINEX file. For example, in 2023/01/02, some receivers recorded the data of the GPS G28 satellite for a few epochs. In 2023/01/02, the G28 satellite was not assigned in the up-to-date ANTEX file. In this situation, RINEX SCAN does not compute the availability for the satellites that are not included in the ANTEX file, and the “ER_ATX” message is written in the output file for the corresponding satellites. RINEX SCAN also outputs the times corresponding to the missing epochs in the additional text file if there are some missing epochs in the RINEX file. Epoch and GNSS observation codes availabilities are computed in RINEX SCAN as follows:

$$\:Epoc{h}_{availability}\left(\%\right)=\frac{Expected\_epochs}{Number\_of\_epochs}*100$$
(1)
$$\:Frequency\_availability\left(\%\right)=\frac{Expected\_frequency}{Number\_of\_frequency}*100$$
(2)

where \(\:Expected\_epochs\) is the total number of epochs that should theoretically exist in the RINEX file. \(\:Expected\_epochs\) can be computed as the ratio between the observation duration and observation interval. RINEX SCAN first attempts to read the observation interval from the RINEX header. If the RINEX header does not include the interval, RINEX SCAN computes it as the minimum time interval between adjacent epochs in the RINEX file. \(\:Number\_of\_epochs\) is the total number of epochs in the RINEX file. For example, daily observation RINEX files theoretically should contain 2880 epochs. \(\:Expected\_frequency\) is the total number of frequencies for the corresponding signal types that should theoretically recorded in the related parts in the RINEX file. \(\:Number\_of\_frequency\) is the total number of frequencies for the corresponding signal types belonging to the recorded satellites in the RINEX observation data blocks. Table 1 shows the BLOCK specific channels that are defined in the BTSF file.

Table 1 BLOCK specific channels in BTSF file
Full size table

Since some QZSS satellite frequency diversity information is not available in the latest ANTEX file, satellite-based frequency-dependent information has been included in the codes instead of the block-dependent information in the ANTEX file. Currently, there are two special conditions for QZSS frequency-dependent information. Before March 24, 2022, J04 was not broadcast for the L1S/L1-SAIF channels. After this date, the legacy J04 was replaced by J04 QZS-1R (SVN: 05), which then began broadcasting the L1S/L1-SAIF frequency channels (https://qzss.go.jp/en/overview/notices/qzs1_230915.html and https://qzss.go.jp/en/overview/notices/qzs1r_220314.html, access: 17 September 2024). Before 2023, only the J01 satellite was broadcasting on the L6D, L6P, and L6(D + P) frequency channels. To the best of the author’s knowledge, after addressing these two conditions, no special issues regarding satellite-specific frequency support remain.

Process data

RINEX data set spanning one month in 2024 (DOY:001–031) belong to all IGS-MGEX stations from CDDIS archive (https://cddis.nasa.gov/archive/gnss/data/daily/2024) were scanned using RINEX SCAN software. RINEX files were downloaded using GAMP II – GOOD (Gnss Observations and prOducts Downloader) (https://github.com/zhouforme0318/GAMPII-GOOD) open-source software. Some daily RINEX files whose data duration below 12 h were removed. In total 11,772 daily RINEX 3.xx files were scanned. A high-rate (1-second) multi-GNSS RINEX data set including spanning four days in 2024 (DOY:001–004) was downloaded from http://igs.ign.fr/pub/igs/data/highrate/2024 using GAMPII-GOOD software. When the merged daily high-rate RINEX files were investigated, the file size changed significantly due to some missing data during downloading. To effectively test the RINEX SCAN with daily high-rate RINEX files of the highest possible data volume, files under 1 GB were excluded from processing. As a result, the average file size is 1.3 GB, with a maximum file size of 1.7 GB for the remaining high-rate RINEX files. The header parts of the merged 15-minute files were not removed during the merging process. This did not cause any problem during RINEX SCAN processing, thanks to try-catch structures implemented in the RINEX SCAN. Scanning the frequencies and epochs took approximately 50 min for 11,772 daily RINEX 3.xx files with 30-second intervals using an Intel Core i9 9960X CPU. “Max Parallel Operation” option was used in RINEX SCAN. In this way, all available cores were used efficiently. When total processing time is considered, each daily RINEX 3.xx file with a 30-second interval took approximately 0.25 s to scan the epochs and frequencies. When only epochs are scanned, it took approximately 16 min for 11,772 daily RINEX 3.xx files with 30-second interval. For the 120 high-rate RINEX files, it took approximately 4 min to scan the epochs and 14 min to scan both epochs and frequencies without using the “Max Parallel Operation” option. In this version of the software, we do not recommend processing RINEX files larger than 1GB with 1-second intervals using the “Max Parallel” option. The reason for this could be various factors (such as overwhelming the task scheduler or causing queuing delays in execution, as well as I/O limitations). However, in future versions, the algorithm will be optimized to handle such large files more efficiently. Since RINEX SCAN scans every available observation in the RINEX header, the baseline code and phase observations belonging to GPS, GLONASS, Galileo, BDS-2, and BDS-3 were extracted from the output file. These observations are the conventional signals that most of the IGS ACs use them to create satellite orbits and clock products. Most of the IGS receivers can record these baseline frequencies. Moreover, most of the precise point positioning software use these frequencies as default frequencies. The common phase and code observations for BDS-2 and BDS-3 (B1/B3) were chosen. Table 2 shows the scanned phase and code observations.

Table 2 Considered frequencies from the output file
Full size table

Since GLONASS L1 and L2 CDMA observations required special firmware update (Steigenberger and Montenbruck 2024), most of the GNSS stations cannot record these observations. Therefore, only GLONASS G3 CMDA observations were taken into consideration.

Results

The epoch and GNSS observation codes availabilities are considered as two independent analyses. Figure 3 shows the results of the epoch availability.

Fig. 3
figure 3

The result of epoch availability

Full size image

The mean epoch availability percentage indicates that the total number of epochs for most IGS-MGEX stations is nearly equal to the theoretical total number of epochs that should exist. A few stations show unusually low epoch availability during the one-month period. The most evident ones are POLV and GLSV stations. The mean epoch availabilities are 87.9% and 94.2% for POLV and GLSV stations, respectively. To investigate the unusually low rate observed during DOY 001–031 of 2024 for these stations, we also examined DOY 214–244 of the same year. It was observed that the same phenomenon continues during DOY 214–244 of 2024. The mean epoch availability during the DOY 214–244 of 2024 is 88.7% and 86.7% for POLV and GLSV stations, respectively. Moreover, for most days, observation durations of these RINEX files are below 24-h for these stations. During DOY 214–244 of 2024, the approximate observation duration of the POLV station is 20.5 h, while for DOY 001–031 of 2024, the approximate observation duration of the GLSV station is 21 h. The data loss identified in this study for these two stations was reported to the IGS Central Bureau (IGSB), then IGSB, which then informed us as follows: The data from the Ukrainian permanent GNSS stations have had poor quality and low quantity since February 24, 2022, due to blackouts, rockets, bombs, kamikaze drone attacks, jamming, spoofing, etc.

Figures 4, 5, 6, 7, 8 show GPS, GLONASS, Galileo, and BeiDou-2-3 signal availabilities, respectively, as explained in Table 2. Table 3 shows the mean code and phase signal availability percentage for each GNSS constellation.

Fig. 4
figure 4

The result of the GPS signal availability

Full size image
Fig. 5
figure 5

The result of the GLONASS signal availability for 1 C and 2 C observations

Full size image
Fig. 6
figure 6

The result of the GLONASS signal availability for 3Q and 3X observations

Full size image
Fig. 7
figure 7

The result of the GALILEO signal availability

Full size image
Fig. 8
figure 8

The result of the BeiDou-2-3 signal availability

Full size image
Table 3 The average code and phase signal availabilities (unit: %)
Full size table

When examining the signal availability results, it is observed that the code and phase availabilities for the second frequency are lower than those for the first frequency in each GNSS constellation. The second frequency data loss is more evident for GLONASS satellites (86.5% and 85.5% for code and phase observations, respectively). Upon examining each GLONASS satellite from the output file, it is concluded that the GLONASS R06 and R23 satellites, which belong to the GLONASS-M BLOCK, do not broadcast the second frequency code and phase data. This observation holds not only for the test period but also for other days in 2024 and prior.

When the first frequency code and phase availabilities are examined, it becomes evident that Galileo has the lowest data availability (except for GLONASS 3Q/3X). For the second frequency, Galileo has the second lowest signal availability, following GLONASS. Despite the GLONASS G3 CDMA 3Q observation having over 90% availability (91.3%), the lowest observation availability is found for the second frequency of the GLONASS G3 CDMA 3X observation (36%).

Some stations show the problematic recording for the second frequencies of GPS, GLONASS, Galileo, and BeiDou. These problematic stations are more evident for the second frequency of Galileo (C5Q/L5Q) and BeiDou (C6I/L6I). One representative problematic station related to the second frequencies was chosen for each GNSS constellation, and the results are presented in Fig. 9.

Fig. 9
figure 9

The representative problematic stations for the second baseline frequencies

Full size image

As seen in Fig. 9, the availability of the second baseline frequencies of the chosen stations is significantly lower than the average results for each GNSS. The first baseline frequencies of the chosen stations show no unusually low availability for any of the GNSS constellations. Some stations record additional frequencies along with the second baseline frequency. For example, SYDN00AUS station records also E5b observations in addition to E5a observations. Despite the significantly low availability of the L5Q observations (15.95%), the availability of L7Q observations is sufficiently high (88.30%).

To investigate the highest availability percentage among all phase and code frequency channels recorded by the IGS-MGEX stations, the average availability percentage for each GNSS was computed using the output file from RINEX SCAN. To compute the average availability percentage, a RINEX data set spanning one month in 2024 (DOY:001–031) was used. The results are given in Table 4.

Table 4 Signals availability contained in RINEX3 observation files during the test period
Full size table

The signal availabilities in Table 4 indicate that nearly all IGS-MGEX stations record the baseline frequencies of GPS, GLONASS, and BeiDou. For Galileo, 57% of IGS-MGEX stations record the E1, E5a, E5b, and E5 frequency bands, while 50% record the E6 frequency band. The Galileo results indicate that the availability of the E5 quadrature channels (Q, data signal) is higher than that of the E5 in-phase channels (I + Q, pilot signal). The results for the other observation frequencies described in the RINEX 3.xx format were not provided due to their unavailability for the IGS-MGEX stations.

As indicated by Cao et al. (2021) and Ogutcu et al. (2023a), among the IGS-MGEX stations that record BDS-3 signals, only a limited number are capable of recording all BDS-3 satellites. By using the output file of RINEX SCAN, it is concluded that 36% of the IGS-MGEX stations that record BDS-3 signals can record all available BDS-3 satellites.

Conclusions

In the field of post-processed precise positioning, the integrity of phase and code data for the GNSS constellation in the RINEX file plays a crucial role. After reaching the Full Operational Capability (FOC) of Galileo and BeiDou-3, a RINEX 3.xx file can contain more than 100 observation frequencies along with GPS and GLONASS. For post-processed precise positioning or other processes related to such as troposphere or ionosphere, data availability of the relevant observation frequencies and epochs is an important pre-processing step.

This paper presents RINEX SCAN, a new open-source software for analyzing multi-GNSS and multi-frequency epoch and observation codes availability. It supports RINEX 2.xx and RINEX 3.xx observation files, featuring a user-friendly GUI. Thanks to speed-optimized code and the parallel processing option, the execution time for processing large numbers of RINEX files and high-rate RINEX files is significantly shorter compared to other software designed for reading observations for the pre-processing step. By using the ANTEX file, missing observations of GPS and GLONASS in the RINEX file can be easily attributed to BLOCK-dependent issues or receiver malfunctions. RINEX SCAN was extensively tested using 11,772 daily RINEX 3.xx files with 30-sec interval and 120 daily RINEX 3.xx files with 1-sec interval. The current version of the software works as a standalone application and does not require the installation of any plugins. The source code, exe file of RINEX SCAN and the auxiliary files can be accessed by https://github.com/behlulozdemir/RinexScan.