The first procedure is the campaign setting. Basically, the campaign duration and directory structure needed by the Bernese software are established. The campaign has to be created (or identified, if already existent) and, if the necessary subdirectories are inexistent, they need to be created too (see Figure 4.2). Each campaign directory structure, named campaign area, will be created within the data area defined in the LOADGPS script. To achieve both tasks, Panel 1.1 and Panel 1.2 are used, respectively.
Figure 4.2 2002 campaign directory structure.
In addition, session duration must be defined by filing Panel 1.3.2; the wildcard string ???O should be used to represent any session (day of the year), and 24-hour sessions should be set so that all available data may be processed.
To process GPS data, several auxiliary files are needed. The names of some of these files have to be specified in Panel 0.3.1, particularly the name of the Earth’s rotation file (ERP) and the satellite manoeuvers file (CRX) need to be checked (see Figure 4.3).
The second procedure is the data conversion from Receiver Independent Exchange (RINEX) ASCII format to the Bernese binary format. In this process, the Bernese software can modify the RINEX header information, using translation tables for station names (STA), receiver and antenna types (TRN), and antenna heights (HTR). A RINEX file will be discarded if its header information is different from the one expected in the translation tables.
The translation tables for station names and antenna heights require to be located in the STA subdirectory in the campaign area, whereas the receiver and antenna translation table must be located in the GEN directory in the program area.
Figure 4.3 Panel 0.3.1 – General Dataset Names.
The translation tables for the selected stations can be found in Annex B.
Unfortunately, due to receiver software limitations in the conversion to RINEX, FCUL stations header information was often incomplete, so it was necessary to correct this problem.
To alter the header information in those files the TEQC software was applied. This program, developed by UNAVCO (University NAVSTAR Consortium) is able to read binary and RINEX version 2 files from some receiver manufacturer, and convert those files into standard RINEX version 2 format. In the conversion process, the RINEX header information can be corrected. TEQC is executed from a shell command line. Therefore, a batch file can be created to execute several similar command lines and correct many data files. This batch file was written using a Fortran program (UTEQC) developed by the author.
A user manual for the UTEQC program can be found in Annex C.
The UTEQC program requires an input file with the header information of a specific station and the time period of data files to be corrected. In addition, standard file compression tools can be used (for data storage purposes). The input file information is used to write blocks of command lines for every data file into the batch file (see Annex C), to be then executed. The command lines are written for the LINUX operating system.
After FCUL stations data files correction, all RINEX files pertaining to a particular campaign require to be copied to the RAW subdirectory in the campaign area. Bernese data conversion (RINEX to Bernese) program (RXOBV3) is executed from Panel 2.7.1.
In the next procedure, satellite orbital information is converted for Bernese software use. For a regional campaign processing, IGS precise satellite orbits should be used. Two operations must be performed: precise orbits in the terrestrial system are converted in tabular satellite positions in the celestial reference frame, followed by the creation of standard orbits for each satellite using the tabular positions as pseudo-observations.
A standard orbit may be composed of one or more standard arcs, for a specified time interval each, given as particular solutions of the equations of motion that best fit the tabular satellite positions. The reference system conversion accounts for effects on the satellite’s orbit caused by Sun, Planets and Moon, also reflected in the Earth’s polar motion and ocean tides, whose effects can be furthermore considered.
In addition, a low degree polynomial for every satellite is customarily adjusted to the clock information from precise orbits files. Then, this polynomial may be used to compute satellite clock corrections for each observation epoch. A single 24-hours arc was used, as suggested in the Bernese GPS Software manual [Hugentobler et al., 2001], and two quadratic polynomials for 12-hours clock corrections each.
As previously stated, the Bernese GPS Software can consider the effects on the satellite’s orbit caused by Sun, Planets and Moon. In order to attain that, the needed planetary ephemerides in binary version must be retrieved from the Jet Propulsion Laboratory (JPL) anonymous ftp (ftp://nav.jpl.nasa.gov/ephem/export/unix/). The binary files are available in 50 years blocks, each block having the start year and the ephemerides type identified in the file name. If more than one file is required, then a Fortran program is offered to merge contiguous files. In this study, the JPL DE200 ephemerides were used (the corresponding binary file is located in the GEN directory in the program area with the name DE200.EPH).
The IGS precise orbits files must be copied into the ORB subdirectory, in the campaign area. The conversion to tabular satellite positions program (PRETAB) runs from Panel 3.2, whereas the standard orbits creation (ORBGEN) is executed from Panel 3.3.
A Fortran program (UMUDNO) was written to change the name of the IGS precise orbits file to the corresponding name required by the Bernese (see Annex C for details).
The pre-processing part is the next procedure, where the first operation is to attain receiver clock corrections with accuracy better than 1 µs.
It would be possible to determine these clock corrections as unknown parameters in the final least-squares adjustment, but this would increase considerably the number of parameters. Nevertheless, a priori clock corrections can be computed with sufficient accuracy using the ionosphere-free time (code) linear combination. In this study, every reached clock corrections were used in the corresponding epochs, although a low degree polynomial could be adjusted to them in order to resolve a posteriori smoother clock corrections.
The code processing for clock corrections program (CODSPP) runs from Panel 4.2.
Bernese software uses mainly phase double differences as basic observables. Hence, the next task is the creation of single differences (between receivers) and subsequent storage in files, which are used later to compute the double differences.
To attain the set of independent baselines used in single differences computation one criteria must be selected. The available criteria include the shortest baselines, the maximum number of single differences or a star configuration (all independent baselines formed using the most central station of the network as reference). User baseline choice is also available, introducing that information manually or through a definition file. A strategy using all possible baseline combinations (therefore linearly dependent) is also available. In this study, the used strategy was the one giving the maximum number of single differences.
The single differences program (SNGDIF) is executed from Panel 4.3.
Before the final adjustment, cycle-slip screening is performed. Cycle-slip is the name given to a leap in the phase measurement by an integer number of cycles caused by the loss of signal lock. When found, a cycle-slip is repaired if the integer leap number of cycles can be attained, marked as an outlier or a new ambiguity is introduced in the final least-squares adjustment. The methods used to detect cycle-slips consist in checking the observed phase value against the expected phase value estimated with a low degree polynomial and in inspecting triple difference solutions, because one cycle-slip only corrupts one triple difference solution. The cycle-slip screening program (MAUPRP) is executed from Panel 4.4.2.
The final procedure is the least-squares adjustment that leads to the positioning solution. The basic observables are phase double differences that are computed from the single differences created before the adjustment. Different processing strategies are possible and a number of those possibilities are discussed in the next section.
The final least-squares adjustment program (GPSEST) runs from Panel 4.5.