Derechos de Crédito que respaldan la emisión de los Bonos

Bernese GPS software v. 5.0 is used to process the data from a set of stations by a DD strategy. Bernese can be customized for the user’s needs thanks to its modular design. For this Thesis, the standard processing is an automatic near real-time processing using up to 34 GPS stations providing 15 minutes observation files.

Bernese Processing Engine (BPE) is a tool that runs Bernese in a fully automatic mode and has been used for the GPS data analysis. Individual scripts are set-up and processed, allowing for a much faster analysis of the data. Parallelization of some scripts also decreases the processing time. The data fed to BPE must be downloaded to the corresponding folders and pre-processed. The output is safely stored in different places to avoid overwriting. Detailed information about the software can be found in the manual provided by Dach et al. [2007]. A list of the input parameters for a near real-time processing in Bernese are summarized in Table E.1. The specific Bernese setup for the test cases will be further detailed in the corresponding Chapters (5, 6, 7 and 8).

4.1.1 Data Provision

Before starting with the analysis, preparations must be made. Necessary data is obtained from the on-line services provided by different organizations. Observation files are downloaded as well as available orbit and Earth rotation parameters (ERP) data files, all automatic and on a near real-time basis:

RINEX (Receiver Independent Exchange) observation files are obtained with 15 minutes latency and 1 Hz sam- pling rate from the corresponding FTP servers at ROA, IGS and EUREF.

IGS Ultra-Rapid products are fetched from [ftp://cddis.gsfc.nasa.gov/gps/products/WWWW], where WWWW refers to the corresponding GPSWeek. Orbits and ERP files are automatically downloaded every 6 hours, at 04:07, 10:07, 16:07 and 22:07. It must be pointed out that minute 07 has not been chosen randomly: this way it is unlikely that, for a daily near real-time continuous processing, the main process is overlapped. This is because the main process is set up to begin every 15 minutes starting in the minute 10 of each hour, and takes around 10 minutes to finish (see Section 4.1.3.2).

From CODE database [ftp://ftp.unibe.ch/aiub/CODE], ionospheric information for each day is also downloaded. 4.1.2 Data Evaluation and Documentation

Evaluation strategy and observation interval, as well as the reference station selection, must be verified for the process. Once achieved, two steps are needed in order to determine sub-daily movement for each receiver. First, static coordinates are estimated, using atmospheric parameters and fixing ambiguities, see Section 1.2. After that, the kinematic analysis is performed. In the end, a Perl script stores the estimated kinematic (cartesian and ellipsoidal) coordinates and residuals with respect to the initial coordinate into a plain text file for each station for the further processing.

Every 15 minutes, a file is downloaded for each station, containing 1 Hz GPS observations for the last 15 minutes. Such measurements files in RINEX format are aggregated into 6 hour packs, because it is mandatory to process more than 6 hours of data in order to obtain a suitable ambiguity resolution [Dach et al., 2007]. No more than 6 hours is advised for this number of stations and the current strategy and machine in use because running the whole process must take less than 15 minutes to avoid overlapping with the following execution. This number has been obtained after testing several options, looking for the best ratio ambiguity resolution/time consumed. The aforementioned packages are then transformed into Bernese binary format. After that, clocks are synchronized with GPS time and approximated station coordinates are calculated using zero-difference measurements. Polar motion information is transformed into Bernese format. Orbital data also needs to be processed before its informa- tion is integrated into the subsequent steps, generating tabular orbits and clock files. Tabular orbits are combined with the pole motion data, obtaining the so-called standard orbits. In the following step, single-difference base- lines are formed. Optimal results, in terms of resolved ambiguity ratio, are reached when baselines are defined by the maximum number of observations between two stations3 (OBS-MAX4). This procedure of single differenc- ing eliminates the satellite clock error terms in the model. Tropospheric and ionospheric effects are also reduced through single differencing, especially for those stations close to each other. The last step in preprocessing consists of searching and correcting for cycle slips. Finding cycle slips formed during single differencing allows further determination or even the elimination of ambiguities. In addition to the data cleaning process, this step can be used to determine a first coordinate solution without fixing ambiguities.

In order to obtain kinematic coordinates, good static coordinates must be estimated first, as well as troposphere parameters. In the main processing part, residuals in the observations (Section 1.4) based on Double Differences are estimated according to the standard proceeding, as explained in Bernese 5.0 manual, pages 172-183 [Dach et al., 2007]. In this step, an ionosphere-free linear combination (L3) is used. With this combination, the iono- spheric path delay is cancelled, because of the linear combination using zero- (L1, 1.2) and double-difference (L2, Equations 1.2) phase observables. Inconsistent observations are marked so that they are not used in further processing. This is, a first order ionosphere-free equation is formed with unknown ambiguities. Later, ambiguities are fixed. The resolution strategy depends on the length of the baseline considered: Short-Lane strategy for base- lines up to 50 km, Widelane-Narrowlane (WL-NL) for baselines from 50 to 200 km and Quasi-Ionosphere-Free (QIF) for baselines longer than 200 km. For each session, the static solution is found after solving the ambiguities in the phase observations (see Equations 1.5). Such ambiguities are applied later for the calculation of kinematic coordinates from the last 15 minutes. Troposphere parameters are also required for the kinematic processing, so they are estimated as well.

Figure 4.1: Scheme for the 6 hours Bernese processing. First, ambiguities are resolved in a 6 hours processing. Ambiguities are extracted from the 6 hours and fixed for the last 15 minutes, from which and a kinematic time series is computed.

Finally, a 1 Hz kinematic processing is carried out for the last 15 minutes dataset and one of the stations in each selected baseline. By convenience, the receiver considered as fixed is the first in the baseline, and the

3 _{Sometimes it is necessary to fix baselines in order to obtain specific results. This will be explained in Section 5.5.}

4 _{Other strategies, like STAR, are used in this Thesis, see Section 6.3. STAR baseline selection uses one defined station as the center}

second is treated as kinematic. The evaluation is performed as an ionosphere-free combination with fixed (known) ambiguities. If baselines are short, tropospheric parameters are very similar for each station in the baseline, but for longer baselines, such parameters must be considered. They are taken from the last 6 hours of output data. Resulting kinematic coordinates are saved for further analysis. The whole procedure is summarized in Figure 4.1. In the Chapters where an a posteriori analysis is indicated, a similar procedure to the previous is followed, with a small modification: 15 minutes GPS data are aggregated into daily packages, ambiguities are fixed for the whole period and later 1 Hz kinematic coordinates are estimated for the same whole day.

4.1.3 Automated Processing by Bernese Processing Engine

GPS receivers are prepared to measure a vast amount of data during surveys that can last weeks or months, and also from continuous observations. Such volume of data clearly demands an automated analysis. Bernese software can execute all possible tasks in batch mode, using parallel processing where feasible. Its evaluation procedure can be defined by the so-called "Process Control Files". In this Section, the procedure for a continuous processing of a network of 34 stations is detailed. Kinematic coordinates are estimated every 15 minutes for the last 15 minutes data available, by using the observations from the previous 6 hours.

4.1.3.1 Parallelization

The objective of parallelization is shortening the duration of the processing. Subprograms related to baseline or single station processing run once for each baseline or station, so if they run in parallel the processing time highly decreases. Hence, as long as the computer has more than one core, parallelization allows running one baseline or station in each computer core, without overlapping.

Time saved by parallelizing depends on the number of stations to be processed and the number of cores avail- able. The machine used in this analysis has two processors and eight cores. Ambiguity resolution subprogram parallelization reduces up to 7 minutes out of 10. The rest of the subprograms parallelized (aggregate 15-minutes files into 6-hours packs, transformation into Bernese format, clock synchronization and search and erase cycle slips after single-differencing) save around one minute each. Therefore, after parallelization the processing time is shortened by almost the half, from 23 to 12 minutes.

4.1.3.2 Timeline

• Minute 0-15: GPS receivers record the data.

• Minute 15-25: The agencies that own the data (EUREF, IGS, ROA) change the format, compress the datasets and upload them to an FTP server.

• Minute 25: A script is launched to download the data files. They are uncompressed and stored in the designated folder for the campaign.

• Minute 26-37: The data files are processed, and the kinematic coordinates of the selected stations are derived.

• Minute 38-39: Data is screened and filtered when necessary. • Minute 40: Results are stored for the selected stations.

4.1.3.3 Date Change

Bernese standard session is 24 hours; in this case, a non-standard session of a 6 hours sliding window needs some boundaries. To process a timespan of 6 hours belonging to two consecutive days, some considerations must be taken into account and the change of date must be handled carefully. To solve it, the Session Table in Bernese needs to be forced to consider data from two different days. Also, orbits, ERP and ionosphere files must be

prepared for the change of the day. This is done by concatenating the old with the new ones that are uploaded every six hours in case of IGS Ultra-Rapid products, or daily in case of ionosphere files.