Keywords

1 Introduction

The Center for Orbit Determination in Europe (CODE, Dach et al. 2013) is providing satellite orbits, satellite and receiver clock corrections, Earth rotation parameters, ionosphere maps, station coordinates, and troposphere products based on GPS since the start of the activities of the International GNSS Service (IGS, Dow et al. 2009) in the early 1990s. In the late 1990s the IGS ran the IGS GLONASS EXperiment (IGEX, Willis et al. 1999) to investigate the potential introduction of GLONASS into the IGS services. CODE contributed to the IGEX with a GPS and GLONASS orbit solution (Ineichen et al. 2003). In 2003 CODE started to provide a rigorously combined GPS and GLONASS solution in the final, rapid, and ultra-rapid product lines (Dach et al. 2009).

One decade later the GNSS community is again subject to considerable changes. The established GNSS GPS and GLONASS are under modernization: New signal types (e.g., L2C), a third frequency (L5), and new Block IIF satellites with improved atomic clocks are introduced for GPS. The next generation of spacecraft is already announced. The GLONASS constellation has been fully re-established and a new satellite generation (GLONASS-K) with code division multiple access capability is being tested. In addition, new GNSS (e.g., Galileo, BeiDou) and regional services [e.g., the Quasi-Zenith Satellite System (QZSS)] are under development. The IGS reacted to these developments by launching the Multi-GNSS-EXperiment (MGEX, Montenbruck et al. 2013) and by the development of a new version of the Receiver INdependent EXchange data format (RINEX3, MacLeod and Agrotis 2013). The MGEX incorporates most components of the IGS processing chain consisting of data collection, data dissemination, data processing, and product combination.

CODE contributes to MGEX with a raw data monitoring since spring 2012, by providing orbit products since mid 2012 (Prange et al. 2012), and by providing clock products since late 2012 (Prange et al. 2013) based on MGEX data. The MGEX-related processing is currently run in a campaign-wise effort, but not yet with the fixed schedule as the other IGS-related products. The Bernese GNSS Software (Dach et al. 2007) and the processing algorithms used for generating the IGS products at CODE are step-by-step extended to be prepared for the new GNSS, new signals, and RINEX3 data format. The CODE MGEX orbits, Earth rotation parameters, satellite clock corrections, and inter-system biases (ISBs) are made available for public use via the MGEX product directory at the IGS data center CDDIS (see ftp://cddis.gsfc.nasa.gov/gnss/products/mgex/, file name abbreviation for CODE results is “com”).

The data basis and the tracking network used for the CODE MGEX analysis are introduced in Sect. 2. Section 3 describes the orbit solution and orbit validation. The clock solution and its results are presented in Sect. 4. A precise point positioning based on the CODE MGEX orbit and clock products is demonstrated in Sect. 5. The results are summarized in Sect. 6.

2 Data Basis and Network

The IGS-related processing schemes running at CODE make use of raw data of the IGS station network distributed by the global IGS data centers and of data from additional stations provided by some regional data centers. In early 2012 the data acquisition and monitoring of content and completeness of the RINEX observation files at CODE has been extended to data from the IGS-MGEX archives at CDDIS, BKG, and IGN. In addition the RINEX3 archive of the EUREF Permanent Network (EPN, Bruyninx et al. 2011), located at the BKG, is considered since day 80 of the year 2013. Selected results of the raw data monitoring are publicly available on the ftp server of the AIUB (Lutz et al. 2013, see ftp://ftp.unibe.ch/aiub/mgex/README.TXT for details).

Figure 1 shows that the number of monitored sites providing RINEX3 data increased from about 30 in spring 2012 to about 100 in mid 2013. The sudden increase around DOY (Day Of the Year) 80/2013 is due to the inclusion of EPN sites into the data monitoring, starting at that time. All stations are tracking GPS and nearly all GLONASS in addition. Galileo, BeiDou, QZSS, and SBAS are tracked by fewer sites. The best-supported new GNSS is Galileo. Most of the Galileo-tracking stations provide data on L1 (E1) and L5 (E5a), whereas other frequencies are only supported by a limited number of stations. The most commonly available Galileo signals are L1X/C1X and L5X/C5X. The focus of this article is on Galileo and its L1 and L5 signals.

Fig. 1
figure 1

Number of stations providing RINEX3 data considered in CODE’s raw data monitoring

For the determination of GNSS satellite orbits and clock corrections not only the number of tracking stations is relevant, but also their spatial distribution. A homogeneous distribution of the tracking sites around the globe is preferable in order to achieve a redundant visibility all the time, which is especially important for the estimation of epoch-wise clock corrections (Bock et al. 2009). In 2012, when we started the MGEX processing, usually only 30 Galileo tracking sites were available. All of them were considered in the MGEX processing. Later on, data of more stations outside Europe became available. The additional inclusion of EPN sites into CODE’s data monitoring in 2013 further increased the number of stations available for us, but also the imbalance of their global distribution (more sites than necessary in Europe vs. sparse station distribution in other regions). Therefore a station selection has been used since early 2013: All non-European plus a selection of European sites result in a network of about 35–45 Galileo tracking stations. In addition to the MGEX stations about 120 IGS stations providing only GPS and GLONASS measurements in RINEX2 format are included in the processing. The resulting station network selected for the CODE MGEX orbit and clock solutions is shown in Fig. 2.

Fig. 2
figure 2

Distribution of GNSS tracking stations contributing to the CODE MGEX orbit and clock determination (status mid 2013). Black dots represent stations tracking GPS (altogether 145–150 sites) and/or GLONASS (altogether about 125). Red stars represent stations tracking also Galileo (about 35–45) 

3 CODE MGEX Orbit Solution

The CODE MGEX orbit processing scheme is a double-difference network solution that is consistent to the state-of-the-art GNSS processing standards following the IGS and IERS conventions (see code.acn, CODE 2013). The basic setup was extended to include Galileo L1 and L5 measurements and RINEX3 data. The fully integrated, triple-system (GPS, GLONASS, and Galileo) processing solves for satellite orbits, Earth orientation parameters, station coordinates, and troposphere parameters. Satellite orbits with arc lengths of 1 day and 3 days are computed. For the 3-day arcs the satellite positions of the middle day are provided in the result files. The orbits are available for the time interval DOY 145/2012 to DOY 180/2013 at the CDDIS.

The orbit quality is assessed (with the focus on Galileo) with different validation methods (see the statistics in Table 1). Orbit differences at the day boundaries (computed in the celestial reference frame) show the orbit misclosure between two consecutive daily orbits (naturally there should be no jumps of the orbits in the celestial reference frame). In a longarc fit a dynamical orbit (represented by the initial orbital elements plus coefficients of the radiation pressure model according to Beutler et al. 1994) is computed from the satellite positions at three consecutive days by numerical integration. The RMS of the orbit fit indicates how well the estimated orbit positions represent the physical orbit model within the integration time. It is also a measure for the continuity/smoothness of the estimated orbit. Both validation methods show clear advantages of 3-day orbits over 1-day orbits for all selected satellites (see Table 1 and Fig. 3).

Fig. 3
figure 3

RMS of 3-day longarc fits through orbit positions of three consecutive days. Top: 1-day arc solution. Bottom: Middle day of 3-day arc solution

Table 1 Orbit validation results: mean orbit differences at the day boundaries (1-day vs. middle day of 3-day arc solution), mean RMS of 3-day longarc fits through daily orbit positions (1-day vs. middle day of 3-day orbit), weekly mean bias and standard deviation of SLR residuals for orbits (middle day of 3-day arc) of selected satellites (unit is cm in all cases)

The results in Table 1 show that Galileo benefits more than GPS and GLONASS from long arcs. This is due to the still more sparse and uneven station distribution of the Galileo tracking sites and the longer revolution period of the Galileo satellites. Galileo’s long revolution period of more than 14 h has another side-effect: The Galileo groundtracks are shifted every day. This causes a changing observation geometry and observation number from 1 day to another, if the stations are unevenly distributed (which is still the case for the current MGEX network). As a result the quality of the estimated Galileo orbits may vary day by day. Longarcs significantly reduce this effect. Due to the clear advantage of the 3-day longarcs (especially for Galileo) only the middle days these orbits are considered in the following parts of this work and are made available for public use (see Sect. 1).

Satellite laser ranging (SLR) may provide a validation of mainly the radial component of GNSS orbits with an independent space-geodetic technique (Flohrer 2008). About 15–20 SLR stations provide some hundred range measurements per week. From the residuals of each week the mean offset and standard deviation is computed per satellite. The values for the 3-day Galileo orbits are listed in Table 1. The SLR residuals of the Galileo In Orbit Validation (IOV) satellites show a correlation with the elevation angle of the Sun w.r.t. the orbital planes (named β in Fig. 4). Possible explanations are issues with the radiation pressure modeling (e.g., related to the area-to-mass ratio), deviations from the nominal attitude model, or outgasing effects. Further investigations are needed to understand this effect.

Fig. 4
figure 4

Standard deviation of weekly SLR residuals of CODE MGEX Galileo orbits. Green curve: Absolute value of the Sun’s elevation angle (β) w.r.t. the orbital plane of E11 and E12. Black curve: Absolute value of the Sun’s elevation w.r.t. the orbital plane of E19 and E20

4 CODE MGEX Clock Solution

Like the orbit processing the CODE MGEX clock processing is consistent to the state-of-the-art GNSS processing standards following the IGS and IERS conventions (see code.acn, CODE 2013). Again the basic CODE setup was extended to make use of Galileo L1 and L5 measurements and RINEX3 data. The dual-system (GPS and Galileo) zero-difference processing scheme solves for epoch-wise satellite and receiver clock corrections (5 min sampling) and inter-system biases (ISB; one per combined GPS and Galileo tracking station and day). Orbits, Earth rotation parameters, troposphere parameters, and station coordinates are introduced from the double-difference solution (see Sect. 3) and kept fixed. They are defining the reference frame for the clock solution. The estimated clock corrections are provided in the clock-RINEX and SP3 format. The biases are provided in the CODE DCB and BIAS SINEX formats.

The estimation of satellite clocks is especially sensitive to the availability of redundant measurements at each observation epoch. Therefore, the completeness of the Galileo satellite clock corrections (see Fig. 5) benefits significantly from the contribution of new Galileo tracking sites outside Europe since early 2013, filling some gaps in the tracking network (see also Sect. 2).

Fig. 5
figure 5

Percentage of epochs, at which satellite clocks could be estimated

One performance indicator for satellite clocks is the RMS of the daily linear fit through the epoch-wise clock estimates. It characterizes how close a clock comes to the ideal of a linear drift and is, e.g., suitable for monitoring the long-term (weeks, months, years) clock characteristics. The daily fit RMS of the estimated clocks of two GPS Block IIF satellites (G01 and G25) is shown in Fig. 6, top for comparison. The corresponding results for the Galileo IOV satellites are displayed in Fig. 6, bottom. The latter figure shows that the Galileo satellite clock estimates are correlated with the elevation angle of the Sun w.r.t. the orbital plane in the same way as the SLR residuals (see Fig. 4). Possible explanations are orbit errors being mapped into the satellite clock estimates or effects affecting both (orbit estimates and clock corrections) in the same way (e.g., deviations from the nominal attitude model). Figure 6, top suggests that a correlation with the Sun’s elevation angle exists also for GPS Block IIF satellite clocks, but it is less pronounced.

Fig. 6
figure 6

RMS of daily linear fit through estimated epoch-wise satellite clocks (big dots). Top: Selected GPS Block IIF satellites. Bottom: Galileo IOV satellites. The shaded areas mark the eclipsing seasons of G01 (top, red), G25 (top, black), E11, E12 (bottom green), and E19, E20 (bottom, black). The curves show the absolute value of the elevation of the Sun w.r.t. the satellite’s orbital planes (β) with the same color code as the boxes

Montenbruck et al. (2012) reported an abnormal behavior of satellite clock corrections during eclipse phases (induced by increased orbit errors, thermal effects, and outgasing effects) for GPS SVN62 (currently PRN G25). This is confirmed by the linear clock fit RMS displayed in Fig. 6, top – indicating degraded clock estimates for G01 and G25 during the eclipse phases. In opposition to G01 and G25 the clock fit RMS is reduced during the eclipse seasons for the Galileo IOV satellites (see Fig. 6, bottom). Again, a similar behavior can be seen for the Galileo SLR residuals (see Fig. 4) – though less clearly. The reasons for the different characteristics of the estimated GPS Block IIF and Galileo IOV satellite clocks during eclipse seasons are unclear so far. Further investigations in the frame of MGEX could potentially bring more clarity on this issue.

The above-mentioned variability of the clock estimates accuracy due to eclipses and β-angle dependency makes it difficult to evaluate the true stability of the Galileo satellite clocks. Assuming a degradation of the satellite clock estimates due to the radiation pressure acting in radial direction for low β-angles the real performance of the satellite clocks is supposed to be represented better during periods with large β-angles. Figure 6, bottom shows that the linear clock fit RMS of the Galileo clocks is at a level of about 0.1–0.2 ns in such periods. This is comparable to the values obtained for GPS Block IIF satellites (see Fig. 6, top).

Another way to assess the clock quality are Allan deviations describing the clock stability over different time scales. They are, however, susceptible to clock jumps at the day boundaries and are more or less a snapshot of the clock characteristics at a certain moment. Notice that day-to-day changes in the Galileo network used to define the zero-mean condition for the GPS-Galileo ISBs affect exclusively the Galileo clocks and may contribute to day boundary jumps of the Galileo clock estimates. Figure 7 shows Allan deviations of CODE MGEX clock estimates of GPS Block IIF and Galileo IOV satellites at two different times. The clocks of the Block IIF satellites behave similar at both times. The characteristics of the Galileo clocks are apparently changing: Around DOY 180 the Galileo E11 and E12 clocks show a bulge indicating a once-per-revolution signal in the clocks. Around DOY 100, in contrast, E11 shows even better characteristics than the Block IIF clocks. Both snap-shots agree well with the time series of the linear clock fit RMS (see DOY 100 and 180 in Fig. 6).

Fig. 7
figure 7

Modified Allan deviation for 5-day time intervals (reference clock: BRUX). Left: Around DOY 100/2013. Right: Around DOY 180/2013

The shown results suggest that the performance of the Galileo IOV clocks is at a level comparable to the clocks of the GPS Block IIF satellites. This is, however, not always reflected in the estimated clock corrections, which are affected by effects related to the Sun’s elevation w.r.t. the orbital plane. It is worth to point out the different number of tracking stations contributing to the GPS and Galileo satellite clocks (150 for GPS vs. 35–45 for Galileo).

5 Precise Point Positioning

The quality of the generated MGEX orbits and satellite clock corrections is assessed by a precise point positioning (PPP, Zumberge et al. 1997). A set of MGEX stations is selected with the focus on maximum simultaneous visibility of all four Galileo IOV satellites within the time interval DOY 75–84/2013. A static and a kinematic PPP (epoch sampling 300 s) are performed using GPS only, GPS and Galileo together, and even Galileo only, respectively. The PPP-derived coordinates are compared to the coordinates obtained in the double-difference network solution of the same day. Both coordinate sets refer to the reference frame defined by the double-difference network solution. From the differences between network coordinates and PPP coordinates the mean value and standard deviation are computed per station. In order to prevent the statistics from being affected by few large outliers, coordinate differences exceeding a rejection threshold (30 cm in the static and 10 m in the kinematic case) are excluded from the statistics computation.

The comparison results in Table 2, top show that the GPS-only and combined solutions are on the same level of performance, i.e., the added Galileo observations do not contribute significantly to the static PPP. This is expected given the small number of Galileo measurements.

Table 2 Difference between PPP coordinates and network coordinates (in mm). Color code: GPS and Galileo, GPS only, Galileo only. Top: Static PPP (threshold 30 cm). Bottom: Kinematic PPP (threshold 10 m)

The four currently available Galileo satellites may, however, slightly contribute to a kinematic PPP (see Table 2, bottom). In this scenario the improved observation geometry achieved by the availability of additional satellites overcompensates for their reduced orbit and clock quality. Table 2, bottom shows also that a kinematic PPP using only the four Galileo IOV satellites is possible with standard deviations on the decimeter- to meter-level. Notice that due to the lack of redundancy these results represent mainly the satellite geometry. The Galileo-only kinematic PPP is of course limited to those time intervals when a tracking station has simultaneous visibility to all four IOV satellites (about 1–3 h per day for the selected stations in the time period DOY 75–84/2013).

6 Summary and Conclusion

The CODE analysis center contributes to the IGS MGEX with a triple-GNSS (GPS, GLONASS, and Galileo) orbit solution, and a dual-GNSS (GPS and Galileo) clock solution, which are publicly available. Galileo is currently the new GNSS that is best tracked by the MGEX network. The most commonly tracked Galileo frequencies are L1 (E1) and L5 (E5a). Therefore, the focus of our MGEX activities is on Galileo L1 and L5 signals so far.

The orbit validation shows that Galileo orbits benefit more than GPS and GLONASS orbits from long orbit arcs. Reasons are the Galileo tracking network with its still more sparse and inhomogeneous station distribution and the longer orbital period of the Galileo satellites (allowing less than two full revolutions per day). The CODE MGEX orbits made available to the public are therefore based on 3-day longarc solutions. The SLR validation of the Galileo orbits has a standard deviation of about 1 dm and shows a strong correlation with the Sun’s elevation w.r.t. the orbital plane. The same correlation is observed for the estimated Galileo satellite clock corrections. These effects will be further investigated by CODE in the frame of MGEX.

The CODE MGEX orbit and clock products are used for a static and for a kinematic PPP. It is demonstrated that the Galileo products may slightly contribute to a combined kinematic PPP solution. Moreover a Galileo-only PPP is possible for limited time intervals and selected stations. The achieved accuracies on the meter-level reflect mainly the observation geometry because of the lack of redundancy.

The analysis of RINEX3 data provided in the frame of MGEX turned out to be very useful for extending, adapting, and testing the Bernese GNSS Software, CODE’s raw data monitoring, and processing chains as a preparation for future IGS developments. It also helps to identify relevant topics for further investigations and improvements. We therefore thank the contributing station operators and data centers for providing the data. It is our plan to continue with further improvements of our analysis strategy and observation modeling, further studies about the characteristics of the new observations and satellites, support of additional GNSS, and occasional product releases.