Data flow and network setup

The network processed by the GOP AC consists of stations primarily located at the central or Eastern Europe (Fig.1). Additionally, we included also stations from the western parts not analysed by any other analysis centre (Belgium, the Netherlands and UK). Except 8 stations operated by the Met Office UK, all others belong to the EPN and are available through the regular EUREF/IGS data centres. About 8-10 sites were additionally selected on the European borders to extend the regional network and stabilize the absolute troposphere estimation. Our experience shows that the data flow is one the most important issues for the stable NRT processing. We have thus concentrated much effort to the stability of this step in past. Our NRT processing was started in the period, when the hourly GPS data was only in its testing stage. Consequently, and together with initiating other NRT activity at the GOP AC, we have established a data centre (DC) [Dousa, 2001] to separate the external data flow from the processing itself. Although the DC was primarily designed only for our internal purpose (to support various NRT analyses), the activities of the centre have been extended and in 2002 it was officially adopted by the EPN service. At the beginning, the DC was only mirroring the EUREF and IGS data centres for the hourly GPS observations, meteorological data and navigation files, but also the other products and information useful for a NRT processing (precise orbits, ERP's, site-log files, etc.). Today, the GOP DC is ready to receive the data directly from the operational centres, to check and manipulate the files, to convert them into a unique format, etc. The GOP DC also contains anonymous and non-anonymous subsystems of its internal structure to separate freely accessible EPN sites from those sites provided only for the COST-716 NRT Demonstration campaign (e.g. data from Met Office UK). It regularly operates to collect as much as hourly data before the NRT processing starts. All the data used in GOP NRT analysis are thus temporarily available in the GOP data centre.

Network design

As already noticed above, GOP approach is based on double-differenced (DD) GPS data (network solution), which enables to eliminate many errors (or their significant parts). The first differences between the receivers design the network by system of baselines. After special tests devoted to the network configuration [Dousa, 2002], we apply the Bernese AUTO-STAR strategy (i.e. the baselines are generated from the site at centre of network). In reality, this approach is simulated using MANUAL baseline setting, because the standard AUTO-STAR strategy in Bernese software selects the central point station purely for its geographical location. Additionally, we apply condition for minimal rate for number of observations at the central station with respect to actual maximum of observations at any other site. One practical advantage of the AUTO- STAR strategy is simple baseline exclusion when a problem occurs in any step during the analysis and it is not then necessary to incorporate the alternative baseline for completing the network. The AUTO-STAR strategy enriched by a proper central station selection eliminates also the dissemination of errors/problems in the network solution. Disadvantage of this strategy can be seen in designing generally longer baselines and in the high dependence on data quality of the central station.

Pre-processing steps

In the pre-processing steps we use 30sec GPS data for last two hours. The two hours were set up primarily for a testing purpose for various strategies. This is not necessary for GOP official solution however, two-hour batches are useful for better evaluation of the actual orbit quality as well as for saving the special 2-hour NEQ (Normal Equation) files for coordinate estimation. Any station arriving to DC mostly late for hourly processing (actually >30min) is also included in the long-term solution for the station coordinates and is always ready to produce official ZTD results. This trick can help to avoid an initialising step for new station as well. The basic steps are more or less standard within the processing network by Bernese GPS software. The exceptions consist mostly in iterative procedures while the problems occur due to poor NRT orbit quality. The code observations are used only for receiver clock estimation. The triple-difference solution is applied for cleaning the phase observations from cycle-slips. Although the above pre-processing steps can already identify the significant problem with single satellite orbit predictions, the DD residuals are finally exploited for the procedure of the most sensitive evaluation of the individual orbit quality. The ambiguities are solved for as the float numbers since the solution can be corrupted by fixation their improperly estimated integer values. Due to a short-term validity, the ZTD's are more sensitive to each estimated ambiguity than e.g. the coordinates with their long-term validity. This problem was also tested in precise post-processing solution in [Dousa, 2002]. At the end of the pre-processing part, the normal equations (NEQ) are set up for the DD solution. The two variants are prepared in this case – the two-hour solution and the last-hour solution. The first is used for combining for coordinates, while the latter for an official ZTD evaluation, Fig. 3. When creating hourly NEQ system for later ZTD estimation, the coordinates are already kept 'fixed' (heavily constrained) to their actual values because the ambiguities are already eliminated and not saved in normal equations.

Processing scheme

The GOP AC starts the NRT COST-716 processing at HR:30, 24 times per day. The first step of the main routine is a simple request for copying the GPS data, precise orbits and broadcast clocks using a Network File System (NFS) connection to the GOP data centre. Figure 2 shows the system of the analysis performed by the Bernese GPS software. This routine takes approx. 15 minutes on 1.4MHz standard PC running with Debian GNU/Linux and processing 50 sites. The frames in the figure represent the main strategy steps and the arrows mark the iterative repetition if necessary due to decreased quality of the orbits.

Orbit usage

In GOP NRT analysis, the last update of the ultra-rapid IGS orbits is always introduced. If there is a problem or product missing, the previous one is used for the prediction until 24+4 hours after the last fitted orbit portion. The broadcast satellite clocks are applied for a code single point positioning. The individual orbits are checked for its SP3 accuracy code – the zero codes and codes larger then 10 are criteria for the satellite exclusion. Later, the individual satellite orbit quality indicator is derived from a procedure using a statistics from residuals. The principle of this method was already described in [Springer and Hugentobler, 2001]. The difference in our approach consists in two-step iterative procedure performed baseline by baseline. In the first step the satellite is excluded for the whole network solution whenever its statistics from all baselines exceeds the given criteria. In the second step the criterion is applied to each baseline independently and means the satellite exclusion only from the baseline. Though the first step has started to be nearly obsolete during 2002, we have left it in GOP processing scheme to keep the full robustness of the system.

Coordinates and ZTD estimates

Concerning the basic set up for the ZTD estimation the double-difference GPS data are used and mapped into the zenith applying a Niell mapping function [Niell, 1996]. No a priori troposphere model is introduced. The elevation cut-off mask of 10 degrees is set up together with an elevation dependent weighting for the data. As already mentioned above, the coordinates are estimated using a two-hour NEQ combined solution covering a period of last 7 days. The reference frame is realized applying a free-network approach based on the Helmert transformation between the resulted and a priori coordinates for a set of selected stations. Three translations, three rotations and the scale parameters are in this way additionally set up (with heavily constraints) for the weekly coordinate solution. The final combination for ZTD parameters covers the interval of last 12 hours (last 12 NEQ files). The coordinates actually calculated are kept 'fixed' as in the case of hourly normal equation set up. One ZTD parameter is estimated every hour for each individual site. The absolute constraints for ZTD parameters are completely loose (1m a priori sigma), but the relative constraints (for difference between successive parameters) is set up approximately two times higher than the formal error to take effect in the problematic results. The formal errors were mostly about 0.7-0.9mm of ZTD's depending on site. Both combinations of normal equations are performed using a Bernese program ADDNEQ2 [Mervart, 2000].

Acknowledgements:

The works on NRT GPS analysis and the data flow were supported by the Ministry of Education, Youth and Sports of the Czech Republic (OC 716.001, LN00A005, LC506).

Near real-time tropospheric products

The GOP routine near real-time zenith tropospheric delay (ZTD) product has contributed to the EU COST Action 716 (2001-2003) and the EC project TOUGH (2003-2005) since February 2001. Since 2005 the product has been distributed within the E-GVAP (EUMETNET GPS Water Vapor Programme). Tropospheric products are hourly updated and uploaded to the ftp server at the UK Met Office in COST-716 format (specifications can be found at www.oso.chalmers.se/~kge/cost716.html/ (working group 3 - data format spec). The files are also archived at ftp.pecny.cz. The BUFR format is generated based on COST-716 files at the UK Met Office and distributed within the meteorological community by the GTS network.

The official solution is based on the IGS ultra-rapid orbits and processing double-difference GPS observables using the in network mode Bernese GPS software (BSW). The BSW V4.2 has been used since 2000 until March 2005 and the COST-716 format files has the acronym 'gope'. Only one constant ZTD value were estimated for each hour tagged by the mid-epoch. As of January 2005 the BSW V5.0 is used and the files has the acronym 'gop_' for official ambiguity-free solution and 'gopx' for testing ambiguity-fix solution. In this new solution, the ZTD were estimated as piece-wise linear function, thus ZTDs are reported at boundary of the valid interval (HR:00 and HR+1:00 epoch). Since COST-716 format does not allow duplicity, the latter (and less accurate) value 'HR+1:00' is tagged as HR:59 and in the following solution is in fact "replaced" by starting ZTD estimates with higher accuracy. An overlapping period of a few months (January - May in 2005) was provided for both products using different version of Bernese GPS software and modified analysing strategy. In January 2010 we have modified the strategy by increasing processing window to 4 hours and we have developed a first hourly global ZTD solution ('gopg','goph' acronyms). These are routinely provided to the Met Office UK database since August 2010. In April 2011 we have implemented a multi-GNSS solution (GPS+GLONASS) running in a paralel to the official solution. This is based on unofficial IGS ultra-rapid GPS+GLONASS orbits (igv).

Post-processing/off-line tropospheric products

The GOP post-processing (offline) tropospheric product are provided either within a specific processing campaigns for comparisons or they are provided within EUREF processing. These products are based on the IGS final orbits and processed on daily basis.

References

• Dousa J, Bennitt GV (2013), Estimation and evaluation of hourly updated global GPS Zenith Total Delays over ten months, GPS Solut, Springer, 17:453–464, doi:10.1007/s10291-012-0291-7, (ISSN online:1521-1886 printed: 1080-5370)
• Dousa J (2010), Precise near real-time GNSS analyses at Geodetic observatory Pecný - precise orbit determination and water vapour monitoring, Acta Geodyn. Geomater., Vol. 7, No. 1 (157), 1-11. http://www.irsm.cas.cz/materialy/acta_content/2010_01/2_Dousa.pdf
• Dousa J (2009), The impact of errors in predicted GPS orbits on zenith troposphere delay estimation., GPS solutions (first-online), Springer Berlin/Heidelberg, Vol 13, No 3(2010), pp.229-239. doi: 10.1007/s10291-009-0138-z
• Dousa J (2004), Precise Orbits for Ground-Based GPS Meteorology: Processing Strategy and Quality Assessment of the Orbits Determined at Geodetic Observatory Pecný, J Met Soc Japan, Vol. 82, pp. 371-380.
• Dousa J (2003), Evaluation of tropospheric parameters estimated in various routine analysis, Physics and Chemistry of the Earth, 29/2-3, pp.167-175.
• Dousa J (2003), On the Specific Aspects of Precise Tropospheric Path Delay Estimation in GPS Analysis, In: Vistas for Geodesy in the New Millenium, IAG Symposium, Adam, J. and K.-P. Schwarz (eds.), Springer-Verlag, Berlin Heidelberg, Vol. 125, pp. 285-290.
• Dousa J (2001), The Impact of Ultra-Rapid Orbits on Precipitable Water Vapor Estimation using Ground GPS Network, Physics and Chemistry of the Earth, Part A, 26/6-8, pp. 393-398.