Introduction

The FORMOSAT-7/COSMIC-2 (F7C2) is a follow-on mission to the FORMOSAT-3/COSMIC (F3C) mission. Its goal is to continuously provide radio occultation (RO) data for monitoring the earth’s atmospheric state and contributing to improvements of near real-time (NRT) numerical weather prediction. The follow-on F7C2 mission will carry the Tri-G receiver, which will allow tracking GLONASS signals in addition to the GPS signals. Tri-G’s GALILEO channels have not (yet) been activated.

RO is a remote sensing technique that retrieves vertical profiles of neutral atmospheric and ionospheric variables. An RO event occurs whenever a Low Earth Orbiter (LEO) occults with respect to a GNSS satellite behind the earth’s limb. The tangent point, which represents the point closest to the earth’s surface along the occultation path, descends from about 100 km to a few hundreds of meters above the earth’s surface, depending on topography, thus allowing for deriving vertical profiles of atmospheric parameters, i.e., bending angles, through proper algorithms and observational models.

The F7C2 is expected to provide more RO events (~ 8000) per day than the F3C mission (~ 2000). GNSS-RO products are mainly derived from the atmospheric excess phase, which is defined as the difference of the observed phase in the presence of the atmosphere minus the phase that would have been observed for the same transmitter–receiver geometry in the absence of the atmosphere (Schreiner et al. 2010). To precisely estimate the excess phase, receiver clock errors need to be minimized and thus three strategies are usually used for that purpose: the undifferenced, single-differenced, and double-differenced techniques. In the undifferenced strategy, it is possible to minimize the phase noise and improve the RO quality when using a clock that is sufficiently stable (e.g., 10−12 over a time interval of 10 s), such as the ultra-stable oscillator (USO) onboard the Metop and GRACE satellites (Beyerle et al. 2005; Montenbruck et al. 2008, 2013). However, for the F3C satellite, which has a less favorable clock than the USO by an order of 10−2–10−3, the receiver clock effect must be removed using the single-differenced strategy (Schreiner et al. 2010; Tseng et al. 2014). In a double-differenced strategy, a large number of ground stations must be introduced, and a large number of ambiguities must be resolved. The process of the double-differenced strategy is time-consuming and does not meet the NRT requirement.

According to the NRT requirement in the F7C2 mission, the NRT GNSS-RO products need to be delivered within a latency of 5 min. The time of data process is started when GNSS scientific data, such as GNSS observations collected by both the POD and RO antennas, is dumped from the F7C2 satellites and is fed into Taiwan Data Process Center (TDPC), which is located at the Taiwan Central Weather Bureau. The time of data process is finished when the GNSS-RO products are delivered to global users. That is, tasks of Blocks 1.0–7.0 in Fig. 1 need to be done within 5 min. Such a requirement is specifically designed for the purpose of weather forecast.

Fig. 1
figure 1

Function diagram in TROPS

Full size image

When using either the undifferenced or single-differenced strategy, the accuracy of the excess phase is dominated by both the GNSS clocks and orbits. Currently, we use ultra-rapid orbits from CODE (the Center for Orbit Determination in Europe), which have an orbit accuracy of nearly 2.0 cm with respect to the rapid orbits obtained from IGS (http://acc.igs.org/media/Gmt_sum_ultra_all_orb_smooth.gif). However, the GNSS ultra-rapid clocks are only available four times per day, at 03:00, 09:00, 15:00, and 21:00 UT. This product contains 48 h of clock information; the first half is computed and updated from observations, and the second half is extrapolated or predicted from updated data. However, the latency of the ultra-rapid clock does not meet NRT RO requirements that need to be updated every 10 min or less. Additionally, the predicted clock accuracy of the ultra-rapid product is, on average, approximately 2.0 ns, which is equivalent to a ranging error of 60.0 cm (http://acc.igs.org/media/Gmt_sum_ultcmp_all_clk_smooth.gif). This accuracy is not suitable for RO data processing (Li et al. 2014).

On the other hand, an exclusive analysis of the GNSS clock stabilities was conducted by Griggs et al. (2015). They estimate the GNSS clock stabilities using the carrier-to-noise ratio (C/N0) and conclude that GLONASS clocks over 1–200 s provide the least stability among all GNSS clocks. Thus, they suggest that high-rate clock corrections to the GLONASS RO observables are essential for producing comparable retrievals with respect to GPS RO products.

The goal of this study is to precisely determine the NRT GNSS clocks and to assess their impacts on positioning and RO retrievals. Both the NRT GPS and GLONASS clocks are determined using streaming fiducial data. The method used to stream the fiducial data has been conventionalized by the Radio Technical Commission for Maritime Services (RTCM). We begin with an automatic RO process system, called the Taiwan RO Process System (TROPS), which has been developed using the Bernese GNSS software version 5.2 (Dach et al. 2015). Subsequently, we present a strategy of data processing to determine the NRT GNSS clocks, whose accuracy is then assessed in terms of the clock rate, stability and quantification of the clock error on positioning. Additionally, we present the impacts of GNSS clocks on RO retrievals. A summary of all data and their interpretation are given in the end.

Taiwan RO process system (TROPS)

TROPS is specified for the data processing in both the F3C and F7C2 satellite missions and consists of three elements: (1) NRT precise orbit determination (POD), (2) atmosphere retrievals and (3) ionosphere retrievals. Here, we focus only on the NRT POD system, which comprises both the GNSS clock determination and LEO POD. The former is detailed in the following section, whereas a more detailed description of the latter can be found in Hwang et al. (2009, 2010).

Figure 1 shows a diagram illustrating the main functions of TROPS, and only the segments of Blocks 2.0, 3.0 and 4.0 are discussed in this section. Collections of GNSS measurements from a ground network, namely fiducial data, are done in Block 2.0. The TROPS system is able to automatically stream the NRT 1-Hz fiducial data using the Networked Transport of RTCM via Internet Protocol (NTRIP) method (Weber 2006). This NTRIP method comprises three components: the source, server, and client. NTRIP sources are conceptualized as a database in which ground stations provide large quantities of GNSS data. The NTRIP server acquires the GNSS data streamed from NTRIP sources and forwards these data to an NTRIP caster. This caster acts as an intermediary between the NTRIP server and its clients by simultaneously distributing data to a series of NTRIP clients. Once the GNSS data is streamed to the NTRIP client, authenticated users can access the data via the Internet. Therefore, a stable Internet connection is essential for streaming the fiducial data.

Figure 2 shows well-distributed ground stations used in TROPS. We list 85 IGS stations, which are well-distributed and can simultaneously collect signals from both GPS and GLONASS satellites. These fiducial data are available from three NTRIP casters: www.igs-ip.net, www.euref-ip.net and http://mgex.igs-ip.net. In the procedure of data collection, we sometimes suffer from intermittent Internet discontinuities, indicating that some of the data availabilities are poor and may be discarded in the clock determination. To mitigate the effect of Internet discontinuity, the minimum number of observation epochs is set to 225 for each station every 5 min. This setup is mainly to stabilize clock solutions.

Fig. 2
figure 2

Well-distributed ground stations used in TROPS. Two stations marked in black are AUCK and NRC1, which are located in New Zealand and Canada, respectively, and used for the analysis of clock-induced positioning errors

Full size image

In Block 3.0 of Fig. 1, TROPS can automatically prepare station-, GNSS-, and LEO-related information for the GNSS clock determination. This information is summarized in Table 1 and is required for use in the Bernese software. In terms of station-related information, the accuracy of station coordinates partly defines the accuracy of the determined GNSS clocks. Therefore, we use the CODE weekly solution as an initial value. Furthermore, the determined accuracy of the satellite clocks is highly associated with the accuracy of the station’s vertical component, which is optimized using the corrections of the antenna’s phase center offset (PCO) and phase center variation (PCV) in igs08.atx (Rebischung et al. 2012). The station displacement caused by tidal loadings is also considered in the clock determination, especially for atmospheric tides, which may cause displacements of up to several millimeters in the vertical component (Dach et al. 2010). Other factors, such as the solid Earth, pole and ocean tides in Bernese are conventionalized by IERS2010 (Petit and Luzum 2010).

Table 1 Summary of the station-related, GNSS-related and LEO-related information required for the GNSS clock determination
Full size table

In providing GNSS-related information, we use the CODE ultra-rapid products in connection with the GPS-defined coordinate and time frames. Because the orbits, clocks and earth rotation parameters are highly correlated when determined, it is essential to use products from a consistent source to produce better clock solutions. The CODE differential code bias (DCB) is only used for the GPS clock determination, but the GLONASS DCB is estimated in this study. This is because the GLONASS signal is frequency-dependent and its DCB varies with both the receiver and antenna types. Additionally, the GLONASS orbits are modeled using the new empirical CODE model to account for the effects of solar radiation pressure in reducing the systematic bias (Sośnica et al. 2015).

To implement the LEO data process in Block 4.0 of Fig. 1, it is essential to use GNSS observations and LEO attitude data. The LEO orbit is determined using the so-called reduced-dynamic technique, which requires both NRT GNSS clocks and orbits. The reduced-dynamic orbit determination benefits from using empirical parameters, e.g., stochastic pulses in the Bernese software, which are mainly used to absorb non-gravitational forces such as drag, solar radiation pressure and even the effect of geocenter motion on the orbit perturbation (Tseng et al. 2017). The reduced-dynamic orbit is usually used to estimate the atmospheric excess phase. This is because such an orbit is smoother than the so-called kinematic orbit, which is epoch-wisely determined by using a pure geometry method without the force models. Additionally, the reduced-dynamic orbit can compensate for gaps occurring in the time series of the kinematic orbits (Tseng et al. 2014).

Data processing for GNSS clock determination

GPS and GLONASS use CDMA and FDMA techniques, respectively, to transmit their navigation signals. The DCB from an external source, such as the CODE product, is introduced in the GPS data processing. However, this is not the case for GLONASS, which is frequency-dependent; the inter-frequency bias (IFB) must, therefore, be estimated to account for the hardware delay between a receiver and a specific satellite. When using a combination of GPS and GLONASS, it is necessary to estimate the inter-system bias (ISB). In this combining case, this estimation procedure may consume more system resources than a single satellite constellation. Because this may not meet NRT requirements, we do not process both data together for the GNSS clock determinations, but instead, perform them in parallel to shorten the total computing time.

In TROPS, 1 Hz fiducial data is streamed every 5 min and first screened with the TEQC software for detecting both multipath and cycle slips (Estey and Meerten 1999). If either the multipath or the number of cycle slips exceeds a threshold, e.g., 1 m for the multipath and 50 events for cycle slips, the station will then be marked and discarded in the data processing. Subsequently, the GNSS data is re-sampled at intervals of 30 s and accumulated to an observed time length of 4 h to stabilize the clock solution. In practice, we determine the GPS and GLONASS clocks in parallel every 5 min, in which each 5-min solution contains 4-h clock values tabulated by 30 s. However, the TROPS system occasionally suffers from Internet discontinuities, resulting in data gaps. To minimize the effects of the data gaps on the clock solution, we, therefore, define a threshold for the minimum number of observing epochs per station for detecting anomalous stations.

Figure 3 illustrates the flowchart of processing GNSS data for the clock determination in TROPS. The clock determination is consistently implemented using the undifferenced strategy, in which the GNSS orbits are always kept fixed. In this estimation procedure, we use the ionosphere-free combination of dual-frequency observations to remove the first-order ionosphere effect. A 5° cutoff angle is setup to remove low-elevation signals, which may contain the high-order ionosphere and multipath effects that may degrade the clock solution. In the clock determination, code observations are first smoothed from phase observations to obtain better initial clock values, which are then used to clean the phase data and detect outliers (Dach et al. 2015).

Fig. 3
figure 3

Flowchart of the GNSS data process for the clock determination in TROPS

Full size image

As previously mentioned, we use the weekly CODE solution as an initial value with strong constraints to update station coordinates and zenith troposphere delays (ZTDs). Note that both the phase and smoothed code observations are used together by taking different weightings in the estimation procedure. This is because (1) the smoothed code can directly access clock parameters, which are prevented by the ambiguity term in the phase measurement, and (2) the phase is much more accurate than the smoothed code. With these updated coordinates and ZTDs, the GPS clock is determined in a zero-mean condition. In comparison to GPS, the only difference in determining the GLONASS clock is that of the code IFB estimation, owing to its frequency-dependent properties.

In general, the measurement bias caused by the GLONASS FDMA technique can be divided into the phase IFB and the code IFB. The former is usually absorbed by estimating the receiver clock if the ambiguity is considered as a float solution. However, the latter cannot be fully absorbed by the estimation of receiver clock and indirectly degrades the satellite clock solution. Therefore, the code IFB needs to be estimated in this study. Otherwise, the measurement error caused by the code IFB may be propagated into the GLONASS clock solution.

As a final remark, we compare the clock solution obtained from the PPP-derived station coordinates using 4-h observations to that obtained from the CODE weekly solution. This comparison shows that the PPP-derived clock solution with the 4-h observations on the station is less accurate than that yielded by the CODE weekly solution. This is because using the 4-h observations to estimate station coordinates cannot remove the diurnal and semi-diurnal tidal effects (Yeh et al. 2011; Chung et al. 2016). However, this is not the case for the CODE weekly solution, in which the tidal effects are minimized. Consequently, the clock solution obtained using the CODE weekly solution outperforms that obtained using PPP-derived coordinates if the observing length is less than 1 day.

Quality assessment of NRT GNSS clocks

In general, the clock quality is assessed by its stability, which is mainly linked to a time series of clock rates. Furthermore, in view of the kinematic PPP technique, the clock-induced positioning error also can be an indicator of the clock quality. In this section, we assess the quality of NRT GNSS clocks in terms of the STD of clock rates, clock stability, and the clock-induced positioning error.

GNSS clock rates

Because an RO event only lasts a few minutes, the information of the relative clock variations during the event is crucial for the estimation of the atmospheric excess phase. The clock rate represents an epoch-wise clock difference over an equal-distance time interval and is expressed as

$$r = \frac{{k_{i + 1} - k_{i} }}{\Delta t} \cdot c$$
(1)

where r denotes the clock rate in unit of mm/s, k denotes the determined clock value with i being the index of the epoch in unit of s, \(\Delta t\) denotes the sampling rate in unit of s, and c denotes the speed of light in unit of m/s. In (1), the clock rate does not contain the clock bias, which mainly accounts for the definition of the reference clock used to determine the GNSS clocks. In addition, the clock bias will be absorbed by the phase ambiguity term in a standard positioning procedure.

We determine a 4-h clock solution every 5 min, which generates 288 clock solutions per day and thus 2304 solutions for 8 days (DOY 205-213, 2016). When determining the GNSS clocks, we occasionally suffered from unstable Internet connections, resulting in poor clock solutions. Figure 4 shows the example of the poor clock solutions, which are circled in red. The time spans of these poor solutions are just 5 min, implying that these solutions are likely associated with 5-min streaming data. If the Internet is disconnected between some casters or stations, these stations may not be observed by some GNSS satellites, resulting in the collection of an insufficient number of observations for the clock determination. Therefore, a stable Internet connection is crucial for stabilizing the NRT GNSS clock solutions.

Fig. 4
figure 4

Examples of the poor clock solutions circulated in red (DOY 012, 2016)

Full size image

We average the STD values of the time series of the 4-h clock solutions over these 2304 clock solutions. To obtain reasonable statistical information, we use a 3-sigma criterion to remove outliers and larger poor clock solutions. The ratio of outliers is less than 2%. If the outliers and poor clocks are very close to a mean clock rate, they may not be able to be removed but may be identified or marked by a quality controller in both the positioning and the RO data processing. Figure 5 records the mean values of 4-h STDs in GPS and GLONASS clock rates over 2304 solutions. A series of corresponding statistical information is summarized in Table 2. As a comparison, we also record the final clock solutions obtained from the ESA/European Space Operations Centre. The ESA is an IGS Analysis Center that simultaneously provides both GPS and GLONASS clock solutions, which are very close to the IGS final solutions.

Fig. 5
figure 5

Mean values of 4-h STD in clock rate (mm/s) for GLONASS (top) and GPS (bottom) over 2304 clock solutions for 8 days (DOY 205-213, 2016)

Full size image
Table 2 Mean STD values of clock rates (mm/s) for NRT GLONASS and NRT GPS over 2304 solutions
Full size table

Figure 5 demonstrates that most of the GLONASS clock rates are determined less than 1 mm/s in both TROPS and ESA solutions, with the exception of PRN115 and PRN123, which record relatively large clock rates. In comparison, the GPS clock rates are determined less than 1 mm/s in both TROPS and ESA solutions, and some of them such as PRNs 01, 03, 06, 09, 10, 25, 26, 27, 30 and 32 are even as low as 0.1 mm/s (see Table 2 for more information). Those satellites belong to the latest Block IIF type, which is equipped with a more stable clock than the Block IIR type. This is also evidenced in Hauschild et al. (2013). As observed in Table 2, the STDs of clock rates obtained from TROPS agree with those obtained from ESA within 0.05 mm/s, except for PRNs 115, 07, 16 and 22, which yield larger STD values of 0.11, 0.10, 0.17 and 0.10 mm/s, respectively. Overall, the differences in STD between TROPS and ESA may be caused by (1) differences in accuracy between the ultra-rapid and final orbits and (2) differences in the sizes of ground networks: 85 and 160 stations for TROPS and ESA, respectively (http://navigation-office.esa.int/products/gnss-products/esa.acn). For the former, the accuracy of the ultra-rapid orbit agrees with that of the final orbit to nearly 10 cm. The latter provides the number of stations, which governs the station geometry viewed by satellites.

GNSS clock stabilities

The in-flight clock stabilities of GNSS satellites can be an indicator to account for the quality of the determined clocks. The clock stability can be computed using the Modified Allan deviation \(\sigma {}_{y}(\tau )\) (Allan 1987):

$$\sigma {}_{y}(\tau ) = \left\{ {\frac{1}{{2\tau^{2} n^{2} (N - 3n + 1)}}\sum\limits_{j = 1}^{N - 3n + 1} {\left( {\sum\limits_{i = j}^{n + j - 1} {\left( {k_{i + 2n} - k_{i + n} } \right) - \left( {k_{i + n} - k_{i} } \right)} } \right)^{2} } } \right\}^{1/2}$$
(2)

where N is the number of k i , \(\tau = n \cdot \Delta t\) is the averaging time window, and n is a number to determine the length of \(\tau\). In (2), \(\sigma {}_{y}(\tau )\) is mainly dominated by the values of the pairs \((k_{i + 2n} - k_{i + n} ) - (k_{i + n} - k_{i} )\). When n = 1, the pair \((k_{i + 2n} - k_{i + n} ) - (k_{i + n} - k_{i} )\) is associated with the relative variations of the clock rates [see (1)].

Figure 6 shows the 4-h (TROPS) and 1-day (ESA) stabilities of the GNSS clocks. For the GPS clock, \(\sigma {}_{y}(\tau )\) values are clearly divided into two groups in both the TROPS and ESA solutions. At a time interval \(\tau\) of 30 s, clocks with relatively good stabilities belong to the latest Block IIF type (from 3 × 10−13 to 4 × 10−13) and are nearly one order of magnitude better than those onboard the IIR Block types (2 × 10−12–3 × 10−12). This is also confirmed in Fig. 5. However, the clock stabilities from TROPS over the time span of 100–1000 s slightly disagree with those from ESA; this disagreement can be attributed to poor clock determination from TROPS (Fig. 4).

Fig. 6
figure 6

Four-hour (TROPS) and 1-day (ESA) stabilities of GNSS clocks on DOY 213, 2016: The clock stabilities of GPS from TROPS (top left), GPS from ESA (top right), GLONASS from TROPS (bottom left) and GLONASS from ESA (bottom right)

Full size image

In comparison, most GLONASS clock stabilities obtained from both TROPS and ESA range from 1 × 10−12 to 5 × 10−12 at a time interval \(\tau\) of 30 s. Additionally, the stabilities of both PRNs 115 and 123 are less favorable than those of other satellites. This agrees with the results depicted in Fig. 5. Overall, the clock stabilities of GLONASS are approximate to those of GPS Block IIR, except for the Block IIF type.

As a final remark, the requirement of clock stability for the GNSS-PPP is different from that for the GNSS-RO retrieval. For example, in a case of continuously tracking satellite signals without cycle slips, it takes 1800–2400 s to converge the PPP solution with float ambiguities (Cai and Gao 2013). Over such a time interval, 1-Hz phase noise caused by the clock instability (10−13) is minimized to nearly 0.03 mm level. This implies that measurement errors caused by the GLONASS clocks may be at a level similar to those caused by the GPS clocks. However, this is not the case for the RO retrieval. An RO event only lasts a few minutes, so a clock stability at a 10−12 level over a period of 1–200 s is essential for reducing the phase noise for the RO retrievals (Griggs et al. 2015). As such, GNSS-PPP requires the clock stability over the longer time interval (at least 30–40 min for the solution convergence) than GNSS-RO does.

GNSS clock-induced positioning errors

The F7C2 has the capability of collecting the GNSS signal, which can be used to derive the GNSS-POD. To quantify TROPS NRT clock errors on positioning, we use the PPP technique with three different clock solutions, namely GPS-only, GLONASS-only and GPS+GLONASS (2G), to estimate the station’s kinematic coordinates, which are then compared to the CODE weekly solution. Here, the GNSS orbits from ESA are kept fixed in all testing cases. Two stations, AUCK and NRC1, marked in black in Fig. 2 are used for an experiment of the clock-induced positioning error. Additionally, to avoid the positioning accuracy contaminated by the diurnal and semi-diurnal tidal effects, we combine every 5-min NRT clock solution to a 24 h length of clock solution. This indicates that there are 288 NRT clock solutions generated per day and these clock solutions are combined into a 24 h NRT clock solution via the least-squares adjustment. In this study, we use 864 clock solutions from a 3-day period from DOY 037 to 039, 2017 to assess the impact of NRT clocks on positioning.

According to Shi et al. (2013) and Cai and Gao (2013), the code noise of GLONASS is larger than that of GPS and is mainly associated with the code IFB, which varies with both the receiver and antenna types. Additionally, Cai and Gao (2013) and Yi et al. (2016) demonstrate that both the post-fit ionospheric-free phase residuals and the positioning accuracy of GLONASS are at a level similar to those of GPS. As such, for our data process strategy in this study, epoch-wise receiver-related parameters such as kinematic coordinates and clock are estimated only using the ionospheric-free phase measurements. Here, phase ambiguities are based on float solutions. In addition, the phase IFB is absorbed by estimating the receiver clock in the GLONASS-related data process (GLONASS-only and 2G). In the 2G case, the receiver coordinates are commonly estimated from GPS and GLONASS measurements. Two receiver clocks, one from GPS and the other from GLONASS, are set up in the normal equations.

Figure 7 shows the post-fit phase residuals as a function of elevation angle, separately derived from GPS-only, GLONASS-only and 2G solutions over a period covering from DOY 037 to 039, 2017. Here, the residuals from the ESA final clock solutions are used for comparisons. The differences in post-fit residuals between TROPS (blue) and ESA (red) are caused by the different satellite clock accuracies, which are initially resulted from the ultra-rapid and final orbits. Since a 5° cutoff angle is applied to the position estimation, there are no residuals below the elevation angle of 5°.

Fig. 7
figure 7

Post-fit ionosphere-free phase residuals as a function of elevation angle, separately derived from GPS-only, GLONASS-only and 2G solutions for stations AUCK and NRC1 over a 3-day period from DOY 037-039, 2017

Full size image

Table 3 shows the STD values of post-fit phase residuals; here, a 2σ criterion is used for outlier detections. The STD difference between TROPS and ESA reflects the deficiencies of the NRT clocks in modeling the equation of GNSS observation. In addition, the GPS-derived STD in NRC1 is mainly deviated by some satellites with poor clock solutions, such as PRNs 02, 06, 17, and 20 (marked in black in Fig. 7). However, the residuals from these satellites in AUCK are insignificant and closer to the ESA solutions. This is mainly caused by the station geometry changes viewed from satellites when the satellite clocks are initially determined. Overall, the STDs in TROPS cases agree with those in ESA cases to a range of 2–3 cm. Such a range is equivalent to 0.07–0.10 ns in clock accuracy, which is much better than the clock accuracy of 2.0 ns in the ultra-rapid product.

Table 3 STD values of post-fit phase residuals derived from GPS-only, GLONASS-only and 2G solutions for stations AUCK and NRC1 over a 3-day period from DOY 037-039, 2017
Full size table

In addition, we present a time series of position differences with respect to the CODE weekly solution for station AUCK, as shown in Fig. 8. Discontinuities or offsets of position differences at day boundary are clearly found for GPS-only (blue) and GLONASS-only (green) solutions in both the TROPS and ESA cases. This is related to the clock-related parameters such as satellite clocks (clock jumps) and phase ambiguities which are discontinued at the day boundary due to daily computation batches (Tseng et al. 2014). Such discontinuities are significantly mitigated in the 2G solution. This needs to be further studied. Note that the time series of the 2G solution is more disturbed than that of the GPS-only solution in both the TROPS and ESA cases. In most of the cases, the time series of the 2G solution has similar patterns to that of the GLONASS-only solution.

Fig. 8
figure 8

Position differences with respect to CODE’s weekly solution in the north (N), east (E) and height (U) direction for station AUCK over 3-day period from DOY 037-039, 2017: The top for the TROPS case; the bottom for the ESA case

Full size image

Table 4 presents the averaged root-mean-square (RMS) differences in coordinates between the PPP-derived solution and the CODE weekly solution from DOY 037–039, 2017. In both the GPS-only and GLONASS-only cases, the clock-induced positioning errors from TROPS are larger than those from ESA by nearly 3 and 7 cm for AUCK and NRC1, respectively. In both the TROPS and ESA cases, the GLONASS-only solutions provide similar results to the GPS-only solutions. In the 2G case, the ESA 3-D solutions agree with those individually derived from GPS-only and GLONASS-only clock to few millimeters. Although the offset is improved, the time series of the ESA 2G solution is more disturbed than that of the GPS-only solution, thus resulting in the 2G RMS larger than the GPS-only RMS. By contrast, the TROPS 2G solution is significantly improved by 30.0% and 45.3% for AUCK and NRC1, respectively, as compared to the GPS-only solution. This is because the TROPS 2G solution greatly improves the offset that causes larger influences on RMS than the time series of the positioning differences does (see Fig. 8).

Table 4 Averaged RMS differences in cm between station coordinates computed from TROPS products and CODE weekly solution over a period covering from DOY 037-039, 2017
Full size table

In Table 4, the RMS values still contain common uncertainties such as the orbital error in both the TROPS and ESA cases. In order to remove the common uncertainties, the ESA solution is regarded as the true value to define the TROPS clock-induced positioning errors. Overall, the TROPS clock-induced 3-D positioning error is about 3.3, 3.2 and 0.9 cm for AUCK and 6.9, 6.3 and 3.1 cm for NRC1 over 864 NRT clock solutions for the GPS-only, GLONASS-only and 2G cases, respectively.

As a final remark, Cai and Gao (2013) presented that the convergence time of the 2G PPP solution was significantly improved in a post-process case, in which the ESA final orbits and clocks were used. However, the positioning accuracy was not improved in that case. Li et al. (2015) demonstrated that both the convergence time and the positioning accuracy were significantly improved in the 2G NRT PPP solution. In addition, Cai and Gao (2013) also imply that the NRT GNSS precise clocks combined with the ultra-rapid orbits are helpful for fast converging and stabilizing the PPP solution. Based on the results from these two papers and this study, we generalize that (1) the satellite geometry of 2G combination effectively improves the convergence time of the PPP solution in both the post-process and NRT cases and (2) the clocks from the 2G combination improve the positioning accuracy only in the NRT case, not in the post-process case.

Impact of GNSS clocks on bending angles

In this section, we attempt to assess the impact of TROPS NRT GNSS clocks on the atmospheric bending angle (BA) retrievals in preparation for the upcoming F7C2 mission. The bending angle profiles are derived using the excess phase estimations and are currently assimilated in numerical weather prediction (NWP) models.

When using a single-differenced strategy, as in this study, the errors in the excess phase estimations are mainly dominated by the LEO orbits, the GNSS orbits and the GNSS clocks errors (Schreiner et al. 2010). According to Li et al. (2014), the BA derived by the excess phase is not sensitive to the LEO orbit quality, within the orbital error of several cm, e.g., 5 cm. Therefore, to simplify and reduce the impact of these factors on the BA estimation, we use a fixed retrieval procedure to derive the BA. Here, the GNSS and LEO orbits are kept fixed in the retrieval procedure, and the GNSS clocks are the only factor affecting the BA profile.

We use the CDAAC (COSMIC Data Analysis and Archive Center) software from UCAR (University Corporation for Atmospheric Research) to assess the quality of TROPS GNSS clocks for the BA retrieval. Ho et al. (2012) demonstrated that the qualities of RO products from UCAR are consistent with those of other centers implementing RO data processing, such as the Radio Occultation Meteorology (ROM) Satellite Application Facility (SAF), the European Organization for the Exploitation of Meteorological Satellites (EUMETSAT), the German Research Centre for Geosciences (GFZ), the Jet Propulsion Laboratory (JPL), and the Wegener Center/University of Graz (WEGC). Therefore, the BA profile from CDAAC is convincing so that CDAAC software can be used as a tool for our purpose.

We use three different GPS clock sources, namely TROPS, CDAAC and IGS, to assess the clock-induced errors in the BA retrieval, in which BA profiles derived by the IGS clock are regarded as true values. Figure 9 shows the RMS differences in the BA profile across 828 RO events, as detected by F3C satellites on DOY 123 in 2016 and Table 5 records the information of RMS differences. In Table 5, the difference between the TROPS- and IGS-derived BAs falls within the range of 0.1–1.0 μrad at altitudes of 5–20 km, and from 0.01–0.1 μrad at altitudes of 20–50 km. The difference between the CDAAC- and IGS-derived BAs is slightly better than that observed between the TROPS- and IGS-derived BAs. The TROPS-derived BA agrees with the CDAAC-derived one within 1 μrad at 5 km, 0.1 μrad at 10–15 km, and 0.01 μrad at 20–50 km. Such differences between TROPS and CDAAC might be caused by (1) the different sizes of the ground network used for the GPS clock determination and (2) the different methods to estimate the troposphere zenith delay (ZTD). For the latter, the ZTD estimation in CDAAC might be based on the double-differenced approach and then the resulting ZTD is fed into the procedure of GPS clock determinations. However, this is not the case for the TROPS ZTD estimation, which is based on the PPP approach. In general, the BA ranges from approximately 0.00 to 0.02 rad as the altitude increases from 3 km to 30 km. Ho et al. (2012) indicated that inter-comparisons of BA differences are small and range from few μrad to 20 μrad at altitudes of 8 to 30 km. As a result, the TROPS GPS clock-induced error in BA is sufficiently small to remain consistent with the profile obtained by the CDAAC.

Fig. 9
figure 9

RMS differences in the BA profile over 828 RO events, as detected by F3C satellites on DOY 123 in 2016

Full size image
Table 5 RMS difference (μrad) in BA profile over 828 successful RO events detected by F3C satellites on DOY 123, 2016
Full size table

Although the clock-induced positioning error from GLONASS agrees with that from GPS to few millimeters (Table 4), this does not indicate that the accuracy of RO retrievals from GLONASS will be similar to that from GPS. Since the RO event only lasts a few minutes, the short-term clock stability at the 10−12 level is crucial for the GNSS-RO retrieval. As mentioned before, the GLONASS clock over 1–200 s is less stable than the GPS clock and might degrade the accuracy of GLONASS-RO retrieval.

To date, there are no GLONASS-RO events that can be studied. Therefore, we take the common 828 RO events of DOY 123, 2016 and process them using the GLONASS clocks instead of the GPS clocks, thus allowing us to simulate a GLONASS-RO analysis. The clock of GLONASS is slightly less favorable than that of GPS Block IIF type. This degradation can be regarded as the relatively large clock errors in \((k_{i + 2n} - k_{i + n} ) - (k_{i + n} - k_{i} )\) of (2). In this sense, we individually multiply two scale factors of 2 and 3 by the original IGS GPS clocks to simulate GLONASS clocks, which are referred to as GLN_1 and GLN_2. These two scaling factors used here are mainly based on the assumption that the determined GLONASS clock is not less stable than 10 × 10−12 (\(\tau = \, 30\;{\text{s}}\)). Such an assumption is consistent with the results given in Griggs et al. (2015). By doing so, we can simulate the GLONASS clock stabilities that are very similar to results obtained by the ESA in Fig. 6, thus allowing us to assess the GLONASS clock-induced error on the BA profile.

Table 5 indicates that the GLONASS clock-induced errors in BA are relatively larger than the GPS clock-induced errors, particularly at altitudes of 5 km, where they yield values of 26.88 and 11.53 μrad for GLN_2 and GLN_1, respectively. The difference in the BA profile of GLN_2 is twice as large as that observed in GLN_1. This indicates that the noise of the BA retrieval is dominated by the clock stability, which is highly associated with the clock rate. Overall, the GLONASS clock-induced errors in BA are 10–100 times greater than those of the GPS clock. This result suggests that different weightings should be used for GPS- and GLONASS-derived BA when both BA datasets are together assimilated in NWP models.

On the other hand, we are also interested in knowing the impact of GNSS orbit qualities on BA retrieval, which is not sensitive to the LEO orbit quality. Therefore, here, we fix the IGS GPS clock and LEO orbit in the retrieval procedure, thus causing the GNSS orbit quality to become the key factor in governing the BA profile. The quality of the GLONASS ultra-rapid orbit is several cm worse than that of the GPS ultra-rapid orbit. We assign both the ultra-rapid (IGU) and final (IGS) orbits to represent the GLONASS orbit and the GPS orbit, respectively, thus accounting for differences in orbit quality between the GLONASS and GPS satellites. The statistical information in the final column (IGU-IGS) of Table 5 demonstrates that the GNSS orbit-induced error on RO is much smaller (10−3–10−2) than the clock-induced error on the BA profile. This analysis suggests that the GNSS orbit-induced error is not significant and can thus be ignored in the process of BA retrieval.

Summary and conclusions

The F7C2 is the first satellite constellation to implement both the multi GNSS-POD and the multi GNSS-RO. The Taiwan self-contained TROPS system is capable of generating the NRT GNSS (GPS + GLONASS) clocks for use in F7C2 POD and RO data processing. The quality assessment of the NRT GNSS clocks is first implemented by comparing the clock rate with the final solution yielded by the ESA. The differences in clock rates between the TROPS and ESA solutions may be caused by (1) differences in accuracy between ultra-rapid orbits and final orbits and (2) differences between sizes of ground networks. Overall, the STDs of clock rates from TROPS agree with those from ESA final solutions within 0.05 mm/s.

With these well-determined clock rates, the stabilities of GPS clocks are divided into two groups (Fig. 6): relatively good clock rates are linked to the latest Block IIF type, whose stability is one order of magnitude better than the Block IIR types. However, the stability of GLONASS clock at \(\tau\) = 30 s is less favorable than that of the GPS IIF clock and ranges from approximately 10−11–10−12, which produces a random error of 10–20 μrad in the BA at an altitude of 5 km. This error magnitude may affect NWP forecasts when the GLONASS-RO data is assimilated.

In addition, the GNSS-RO retrieval requires the clock stability (10−12) over a shorter time interval than the GNSS-PPP does. The RO event only lasts a period of 1–200 s but by contrast, the clock stability (nearly 1 × 10−13) over 1800–2400 s is essential for the GNSS-PPP in a case of no cycle slips. We quantify the NRT clock positioning error in preparation for the GNSS-derived F7C2 POD. The 3-D clock-induced positioning errors are 3.3, 3.2 and 0.9 cm for AUCK and 6.9, 6.3 and 3.1 cm for NRC1 over 864 NRT clock solutions for the GPS-only, GLONASS-only and 2G cases, respectively. This indicates that the use of the GPS+GLONASS clocks for the F7C2 NRT POD provides the better positioning solution, mainly associated with the improvement of the offset at the day boundary. However, the GNSS-based POD still needs to be confirmed with the satellite laser raging (SLR) validation. Additionally, the variations in the quality of the GNSS orbits within 5 cm do not significantly affect the BA profile. In conclusion, this study serves as a reference for assessing the impact of GNSS clocks on both the GNSS-POD and GNSS-RO in preparation for the F7C2 satellite mission.