Keywords

Introduction

Global Navigation Satellite Systems are globally used for user position estimation in a still increasing number of applications. Nevertheless, their ability to sense water vapour in the troposphere is known to a much lesser extent. The concept of a method called GPS meteorology was successfully introduced by Bevis et al. (1992) and since then a lot of investigations were made in this field. For years, only the U.S. GPS system was used for GPS meteorology. In most recent times the term transformed from GPS meteorology to GNSS meteorology since other GNSS systems like GLONASS, BeiDou or Galieo have been started to be used as well (Douša 2010; Li et al. 2014). However, in the presented study only signals from GPS satellites were processed so the term GNSS refers only to GPS unless otherwise is stated.

Microwave signal travelling from GNSS satellite to ground-based receiver enters two parts of Earth’s atmosphere, the ionosphere and the troposphere. Since the ionosphere is a dispersive medium for GNSS signal frequencies of 1–2 GHz, its influence can be eliminated by the appropriate combination of two signals at two different frequencies. On the contrary, the troposphere represents a non-dispersive medium for described signals and its effect therefore cannot be eliminated directly from observations. However, it can be precisely calculated by determining the signal delay due to the troposphere. The typical total signal delay due to the troposphere is about 2.3 m in the zenith direction for a receiver placed at mean sea level. This parameter is called Zenith Total Delay (ZTD) and is the main outcome of GNSS meteorology processing. The total signal delay can be separated into hydrostatic part (Zenith Hydrostatic Delay, ZHD), caused by the atmospheric constituents, and wet part caused specifically by water vapour (Zenith Wet Delay, ZWD). The hydrostatic part accounts for 80–90% of the total delay and is much less variable in space and time than the wet part. ZHD can be precisely computed using Saastamoinen model (Saastamoinen 1972) which relies on atmospheric pressure values in the place of GNSS receiver antenna. After quantifying ZTD and separating ZHD, it is possible to convert ZWD into the Integrated Water Vapour (IWV). This parameter represents a total amount of water vapour in the zenith direction above the GNSS receiver in millimetres.

Both ZTD and IWV values can be assimilated into NWP models. However in reality usually ZTD values are assimilated since they represent original GNSS meteorology output not distorted by ZWD to IWV conversion shortcomings. The operational usage of GNSS meteorology products for NWP assimilation started approximately a decade ago. In Europe, this activity is coordinated mainly in the framework of the EUMETNET EIG GNSS Water Vapour Programme (E-GVAP, 2005–2017, Phase I-III, http://egvap.dmi.dk). Many studies demonstrated a positive impact of the GNSS meteorology products assimilation on weather forecasts of precipitation, especially of the short-time ones (Vedel and Huang 2004; Guerova et al. 2006; Shoji et al. 2009; Bennitt and Jupp 2012; Mahfouf et al. 2015). GNSS data processing for those purposes are currently still running in a near real-time mode with the delivery of results usually between 90 and 120 min after the observations. However, with the development of high update-rate NWP models and growing need for using ZTD fields for nowcasting and monitoring of short-term extreme weather events the demand for ZTD products with much shorter latency and still high quality is growing. Therefore, GNSS ZTD data processing running in real-time is inevitable. For a more detailed information about the GNSS meteorology and its state of the art the reader is referred to Guerova et al. (2016).

A significant step in a development of real-time ZTD solutions was an official start of the IGS real-time service (RTS, http://www.igs.org/rts) in the December 2012. Within this service a set of products with corrections of broadcasted ephemeris and satellite clock errors are provided in real-time using RTCM formats and NTRIP protocol for their network dissemination. Several research institutions presented their first results of GNSS ZTD real-time processing soon after the IGS RTS started. Douša and Václavovic (2014) realized a nine-month long campaign for 36 global GNSS reference stations using their own G-Nut/Tefnut software. When their real-time ZTDs were compared to official post-processed ZTD products a mean standard deviation (SDEV) of about 6–10 mm was acquired and significant biases up to 20 mm occurred at some stations. Results from one-month long period including 20 global stations processed in BKG NTRIP Client were presented by Yuan et al. (2014) where the RMSE of real-time ZTDs were below 13 mm. A comprehensive validation of atmospheric parameters (ZTD, IWV, horizontal gradients, STD) retrieved from GNSS multi-constellation real-time processing was presented by Li et al. (2015). It showed that combined solution based on a multi-constellation performed with higher accuracy and robustness than solutions based only on a single GNSS (e.g. GPS, GLONASS, BeiDou, Galileo). A positive impact of GPS + GLONASS real-time ZTD processing against a single GPS or GLONASS processing was also reported by Lu et al. (2016). Ahmed et al. (2016) presented an extensive comparison of real-time ZTD solutions based on three different software (G-Nut/Tefnut, PPP-Wizard and BKG NTRIP Client) using a month-long period, 22 global stations and three different RTS products. In terms of standard deviation solutions from the G-Nut/Tefnut performed the best followed with BKG NTRIP Client. PPP-Wizard without implementation of precise antenna models reached much worse results especially in terms of bias.

In the April of 2015 the Real-time Demonstration campaign (RT-Demo) has started within the COST ES1206 Action (GNSS4SWEC, “Advanced Global Navigation Satellite Systems tropospheric products for monitoring severe weather events and climate”). So far seven institutions joined this activity and are delivering their ZTD solutions for all or a set of 32 GNSS reference stations. One of them is based on NWP model forecasts, the rest on GNSS observation processing. The first validation results (Douša et al. 2016) are very promising for some of the solutions reaching SDEV values around 6-10 mm while confronted with official post-processed ZTD products (IGS and EUREF final solutions). However, most of the solutions showed rather large biases up to 20 mm at some stations. An online monitoring tool for this campaign is freely available at http://www.pecny.cz/cost/rt-tropo/. GNSS real-time ZTD solution called RT03 presented in this study is the solution called TUOG within the RT-Demo campaign.

The aim of this study was to evaluate a potential of RTKLIB software library for GNSS meteorology purposes both in real-time and post-processing mode since it has not been investigated yet.

GNSS Data Processing in RTKLIB

RTKLIB is an open source program package allowing standard and precise positioning with GNSS observations. It offers a very broad functionality in terms of supported positioning modes (single, DGNSS, PPP, RTK), input data formats and protocols, tools for GNSS data editing and visualizing, etc. It comprises of individual executable application programs (AP) when most of them are available both in GUI (Graphical User Interface) and CUI (Command Line User Interface) versions. For this study RTKLIB version 2.4.2 with applied p11 patch was used. For presented real-time ZTD solutions application program RTKNAVI was used and for post-processed solutions RTKPOST in its CUI version called RNX2RTKP.

Description of real-time positioning in RTKLIB and available troposphere modelling options are provided in the following sub-chapters. For more information about RTKLIB, the reader is referred to Takasu (2009), Takasu (2010) and the official website at http://www.rtklib.com/rtklib.htm.

Real-Time GNSS Positioning

Application program RTKNAVI (in CUI form called RTKRCV) allows a real-time positioning in all abovementioned positioning modes. Nevertheless, for real-time ZTD processing the Precise Point Positioning method is the most suitable one. The technique was introduced by Zumberge et al. (1997) and independently processes observations from a single receiver (zero-differenced observations). Due to that data processing from many receivers can be easily distributed on individual hardware devices unlike the typical network solution based on double-differenced observations. PPP relies on precise products of satellite ephemeris and corrections of satellite clock errors. Its well-known disadvantage is a long convergence time interval of about thirty minutes which the solution needs to reach high quality (positioning) results. Also, ambiguities can be resolved to their integer values if only uncalibrated phase delays corrections from external source are provided and applied.

PPP in RTKLIB is supported in three different versions—PPP kinematic (receiver is moving during the measurement), PPP static (receiver position is static during the measurement) and PPP fixed (coordinates of the receiver are fixed to a known position and only other unknown parameters are estimated from observations). In this study the second option was used. Raw input observation data and precise products can come from Real-Time streams in RTCM format or from a set of (proprietary) file formats. Observations from GPS, GLONASS, Galileo and BeiDou satellites can be processed. As abovementioned in this study only GPS was used while a GPS + GLONASS constellation testing for real-time ZTD solution is planned to be done in a near future. Whole estimation process of PPP solution is based on an extended Kalman filter (Gelb 1974). Available models in the RTKLIB include receiver and satellite antenna phase center offsets and variations, solid earth tides, ocean tide loading (cannot be applied in real-time mode), phase wind-up effect or detection of eclipsing satellites. Information about applied settings for presented PPP ZTD solutions can be found in Table 2.

Troposphere Modelling

RTKLIB supports three different ways of troposphere modelling. The first simple option is based on a Saastamoinen model and standard atmosphere parameters. The second option relies on tropospheric corrections of MOPS model from Satellite-based Augmentation System (SBAS) signals. The last possibility represents a precise troposphere model and it was used in this study. The precise model is based on a typical approach of ZTD computation during precise GNSS data processing. ZHD value is modelled by Saastamoinen model and standard atmosphere parameters and then ZWD is estimated as an unknown parameter during the processing. For mapping the observations from their original elevations to zenith direction the Niell mapping function (Niell 1996) is applied. Since RTKLIB version 2.4.2 the Global Mapping Function (GMF, see Böhm et al. 2006) representing a more current approach is supported however only after recompiling of application programs what was not done for the purposes of presented study.

Linear horizontal gradient parameters representing the first-order spatial asymmetry of the delay around the station can be optionally estimated together with ZTD values as unknown parameters in RTKLIB. This step is generally meant to have a positive impact on troposphere modelling for post-processed GNSS ZTD solutions. Usually a model presented in MacMillan (1995) is used for horizontal gradients computation however the official user manual of RTKLIB version 2.4.2 does not describe the form of implementation of this functionality. In case of presented real-time ZTD solutions horizontal gradients were not estimated in order not to further increase the number of unknown parameters in the processing system. However, it is planned to test this step and evaluate the real influence of horizontal gradients on real-time ZTD estimation and their own quality.

Selected GNSS Reference Stations and Period

Originally data from nine European GNSS reference stations and thirty-two days long period from November 9 to December 10 2016 were processed. Since IGS final ZTD solution was used as the reference one in this study and station MALL is not a part of the IGS station network, this station had to be excluded from the evaluation. From this reason, all the comparisons presented in this paper are based on eight stations and basic information about them are presented in Table 1.

Table 1 Information about selected GNSS reference stations
Full size table

ZTD Solutions Description

As already mentioned four individual ZTD solutions were realized in RTKLIB. Two of them were running in a real-time mode (RT01 and RT03) and the other two in a post-processing mode (PPFR and PPBS). Basic information about all solutions are given in Table 2.

Table 2 Information about GNSS ZTD solutions realized in RTKLIB
Full size table

The only difference between both real-time ZTD solutions was the used IGS real-time stream with satellite ephemerides and clock error corrections. RT01 solution used the IGS01 product and RT03 the IGS03 product. IGS01 represents a single epoch product available for GPS satellites when both ephemerides and satellite clock corrections are provided in 5 s interval. IGS03 product is based on a Kalman filtering approach and is available for GPS and GLONASS satellites. It provides corrections for broadcasted ephemerides in 60 s interval and corrections for satellite clock errors in 10 s interval.

As is apparent from Table 2 the only difference in settings of two post-processed ZTD solutions PPFR and PPBS was the applied strategy of PPP solution. In case of PPFR (Post-processed Forward) only a forward running Kalman filter was used so the solution is similar to the real-time processing in this regard. For PPBS (Post-processed Backward Smoothing) a backward smoothing in time is added after forward Kalman filter run. This step should improve the quality of tropospheric parameters and avoid problems of PPP convergence or re-convergence period previously mentioned in the paper. RTKLIB manual unfortunately does not provide a description of implemented backward smoothing algorithm. Both post-processed solutions were processing observations from RINEX files with 30 s sampling rate and used a full set of IGS Rapid products (precise ephemerides, satellite clock errors corrections and earth rotation parameters files).

RTKLIB runs a separate instance of RTKNAVI application program to process data from one station. Each instance must have it owns access both to observation data stream and stream with ephemeris and clock corrections (correction stream). On top of that if a broadcasted navigation message is not a part of an observation stream, one more stream must be used which provides these information (e.g. RTCM3EPH stream from IGS RTS). During the presented study one extra instance of RTKNAVI was running to only receive correction stream (or broadcasted navigation message stream) and store it into a text file to reduce the computer network load. Then all other instances of RTKNAVI performing the ZTD solution for a selected station were reading the IGS RTS stream or RTCM3EPH stream from this file.

For validation purposes the IGS final tropospheric product (Byram et al. 2011) containing ZTD and horizontal gradient values were used as a reference ZTD solution. The stated ZTD accuracy of this solution is 4 mm and values are available in 5 min interval. The processing itself is based on the PPP technique realized in Bernese GPS Software 5.0 with the use of IGS final precise products.

Results

Results for realized comparisons between the reference IGS final ZTD product and all RTKLIB ZTD solutions are presented in this chapter. Firstly, general information about the validation methodology are given followed by evaluation of ZTD availability and finally ZTD quality.

ZTDs in IGS final solution are provided in five minutes’ interval therefore this was the interval selected for presented comparisons. Since post-processed solutions were based on individual processing of daily RINEX files (it means one PPP run per one day and one GNSS reference station) ZTDs from the first and the last hour of the day were excluded from the comparisons to eliminate the influence of PPP convergence period and day boundary problem.

Availability of Produced ZTDs

Percentage of available ZTD epochs for individual solutions is presented in Table 3. For both RTKLIB post-processed solutions and the IGS final solution the average availability was around 99% and except one case (IGS final solution at station ONSA) always stayed above 96%. The real-time ZTD solution RT01 based on IGS01 product reached only a little bit lower average availability of 97%. However, the second real-time ZTD solution RT03 based on the combined IGS03 product was worse with 89% of available ZTD epochs on average. The difference was mainly due to visibly lower availability of ZTDs in RT03 solutions at stations BRST, MATE, NICO and ONSA while the other four stations performed very similarly to RT01. The lower availability for RT03 solution can be due to data gaps both in observation data streams and correction product streams related to computer network load.

Table 3 Percentage of available ZTD epochs for individual solutions (all = 100%)
Full size table

Quality of Produced ZTDs

For the computation of comparison statistics only the epochs where ZTD values from all five solutions were available had to be selected. Therefore, if a ZTD value from a single solution was missing for a specific epoch, the epoch did not enter the comparison at all. For the comparison results presented below in Figs. 1 and 2 and Table 4 an outlier detection and their exclusion was applied. Firstly, standard deviation values were computed for comparisons between the IGS final solution and all evaluated RTLIB solutions from all available epochs of ZTDs. Secondly, all epochs where the difference between ZTD value from IGS final product and ZTD value from a selected RTKLIB solution exceeded 3× the computed SDEV, were excluded from the final statistics computation. Numbers of epochs excluded from individual RTKLIB solutions are shown in Table 4.

Fig. 1
figure 1

Comparison between ZTDs from IGS final solution and RTKLIB real-time (RT01, RT03) and post-processed (PPFR, PPBS) solutions—bias (top) and standard deviation (bottom)

Full size image
Fig. 2
figure 2

Real-time ZTD RT03 solution daily mean bias (top) and standard deviation (bottom) with respect to IGS final ZTD solution

Full size image
Table 4 Comparison of ZTD from IGS final ZTD solution and solutions realized in RTKLIB
Full size table

Figure 1 presents results of comparisons between the IGS final ZTD product and all RTKLIB ZTD solutions at individual GNSS reference stations and Table 4 summary results for individual solutions over all stations. RKTLIB showed a reasonable performance in both versions of post-processed ZTD solutions. The standard deviation representing the stability of solutions oscillated around 4.5 mm at all stations except BRST where it reached almost 7 mm. PPFR solution based only on a forward Kalman filter delivered better bias values than PPBS solution. PPBS also had nearly three times more outlier ZTD values than PPFR solution which were excluded from the statistics computation as is apparent from Table 4. The applied backward-smoothing (PPBS solution) therefore surprisingly did not bring any positive income to the post-processed ZTD solution.

The degradation of quality of real-time ZTD solutions compared to post-processed ones can be seen in approximately doubled SDEV values ranging from 10.2 to 13.8 mm in case of RT01 and from 8.4 to 12.2 mm in case of RT03. The RT03 solution based on IGS03 combined product showed better quality of ZTDs than RT01 not only in terms of SDEV but also in bias and number of excluded outlier values. The RT03 overall RMSE values ranged between 8.4 and 11.0 mm at individual stations with an exception of 12.4 mm for station BRST and biases never exceeded ±5 mm. Within the E-GVAP project various user requirements for GNSS meteorology were defined including requirements on accuracy of ZTD and IWV values for their use in NWP models and meteorological nowcasting (Offiler 2010). The threshold value for ZTD accuracy was set to 15 mm, target value to 10 mm and optimal value to 5 mm. If we consider the IGS final ZTD product as true reference the presented real-time RT03 ZTD solution from RTKLIB meets the threshold value in case of all stations and oscillates around the target value in case of all except the BRST station.

Besides the results based on a whole time period also a daily stability of real-time RTKLIB ZTD solutions was evaluated. Figure 2 shows daily mean biases and standard deviation values for RT03 solution at all reference stations. The daily mean biases stayed rather stable within the range of ± 6 mm at all stations with a few occasional exceptions at some of stations. Similar situation was present also for standard deviation. Poorer overall results of station BRST when compared to other stations were partly caused by a period between day 5 and 12 of the processed period. During these days SDEV values of BRST reached up to 16.6 mm and were visibly higher than those of all other stations. Daily stability of RT01 real-time solution showed similar patterns as presented RT03 solution in terms of bias. However daily SDEV values evinced higher day-to-day variation with a typical range of about ±8 mm.

Conclusion

The main focus of this paper was to initially evaluate quality of GNSS ZTD processing in the freely available RTKLIB program package. Observations from eight GNSS reference stations and month long period were processed in two versions of real-time solutions based on different IGS RTS products and two versions of post-processed solutions. All four ZTD solutions from RTKLIB were then compared with the IGS final ZTD product.

Post-processed ZTD solution PPFR based on a forward Kalman filter reached on average virtually no bias and SDEV of 4.7 mm. The second post-processed solution PPBS adding a backward smoothing in time to the forward Kalman filter had an average bias of +2 mm over all stations and showed problems with outlying ZTD values. The step of applying backward smoothing for PPP ZTD solution in RTKLIB therefore cannot be recommended upon obtained results. Daily stability of both post-processed solutions was at the level of a few millimetres both in bias and SDEV.

Real-time solution RT03 based on a combined IGS03 IGS RTS product reached an average standard deviation of 9.9 mm with biases ranging at individual stations between −4.6 and +4.7 mm. With its overall mean RMSE value the RT03 solution was close to the 10 mm value defined as a target ZTD accuracy needed for meteorology applications. The other real-time solution RT01 based on a single epoch IGS01 IGS RTS product was systematically shifted against the IGS final solution of about −2.2 mm on average with individual station biases ranging from −7.2 to 0.2 mm. It also provided slightly higher mean SDEV value of 11.7 mm and much more outlying ZTD values than RT03. On the other hand RT03 solution had availability problems at half of the processed stations where RT01 solution performed flawlessly.

The relatively low number of processed GNSS reference stations together with not extensive time period could distort the absolute values of statistical parameters obtained in the comparison however should still provide a reasonable information about RTKLIB usability for ZTD PPP processing both in real-time and post-processed mode what was the main motivation of this study. A much more comprehensive evaluation of real-time ZTD solutions including the RT03 solution from presented study are planned within the abovementioned RT-Demo campaign of GNSS4SWEC COST Action. To conclude it seems that at least on the basis of presented results the RTKLIB program package is able to provide good quality ZTD estimates from its PPP processing run both in post-processing and real-time mode.