PARAMETER ESTIMATION
Program: GPSEST
GENERAL DESCRIPTION
The program GPSEST is the main parameter estimation program of the Bernese GPS Software. It allows the estimation of the following parameter types:
1. station coordinates,
2. receiver clock parameters,
3. orbital elements,
4. ambiguities,
5. receiver antenna offsets,
6. troposphere parameters for individual stations,
8. differential code biases (DCBs),
10. earth rotation parameters (ERPs),
11. stochastic orbit parameters,
12. satellite antenna offsets,
16. geocenter coordinates,
17. stochastic ionosphere parameters,
18. receiver antenna phase center variations,
19. global (and station-specific) ionosphere model parameters,
21. epoch-specific station coordinates,
23. epoch-specific station clocks,
24. epoch-specific satellite clocks, and
25. satellite antenna phase center variations
based on a least-squares adjustment using undifferenced (zero-difference) or double-differenced phase or/and code measurements (interferometric processing technique). Note that the numbers above correspond to the internally used parameter type numbers.
In addition, you have the possibility to combine GPSEST results on the normal equation (NEQ) level using the program ADDNEQ2. If you intend to make use of this option please note that
you have to set up all requested parameters in the GPSEST runs and that
you have to save the complete associated variance-covariance information (see option "Normal equations" in panel "GPSEST 2.1: Output Files 1").
The program GPSEST is capable of processing GPS-only, GLONASS-only, as well as GPS/GLONASS-combined data for stationary, kinematic, or spaceborne receivers. Furthermore, SLR range measurements may be processed.
GPSEST 1.1: Input Files 1
GENERAL FILES AND OPTIONS
Show all general files: Check this box to get a list of the general input files used by this program as well as the currently active campaign, session, and session table.
LEO data processing: Check this box if you intend to process data from Low Earth Orbiters. If this box is checked additional options are activated.
Default value: unmarked
Differencing level: Select whether you want to process GNSS data on the zero-difference or on the double-difference level.
Default value: DOUBLE
INPUT FILES 1
Phase observation files (single differences): Select the single difference phase file(s) to be processed. Several files/baselines may be processed in the same program run. Internally the single differences are differenced to form the double differences which are used for the actual estimation.
Phase observation files (zero differences): Select the zero difference phase file(s) to be processed. Several files may be processed in the same program run.
Code observation files (single differences): Select the single difference code file(s) to be processed. Several files/baselines may be processed in the same program run. Internally the
single differences are differenced to form the double differences which are used for the actual estimation.
If you want to resolve wide-lane ambiguities analyzing the so-called Melbourne-Wuebbena linear combination of phase and (precise) code measurements, you have to select the same code single difference files you selected for the phases. The code and phase baseline definitions have to be identical in this case (see program SNGDIF).
Code observation files (zero differences): Select the zero difference code or range file(s) to be processed. Several files may be processed in the same program run. The code zero difference files can be used to estimate station and satellite clocks epoch wise.
Station coordinates: Select an a priori coordinate file which contains all the sites you are processing. The a priori coordinates should be known within a few centimeters, otherwise you may do an additional iteration by introducing the saved coordinate estimates as new a priori values.
Example
GNSS standard orbits: Select one standard orbit file containing the information on the satellite positions. Note that the orbit file specified has to cover all observation epochs to be processed.
GNSS clock corrections: Selection of a satellite clock file is recommended only if there is a problem in terms of the receiver clock synchronization. In case of zero-difference processing you will have to include a priori satellite clock information.
Example
Earth rotation parameters: This file contains the earth rotation parameters (ERP's). It is used for the transformations between the International Celestial Reference Frame (ICRF) and the International Terrestrial Reference Frame (ITRF). This file has to be identical to the one used for the computation of the standard orbit.
Example
Troposphere estimates: Estimated troposphere values. Here you can input troposphere estimates from previous GPSEST or ADDNEQ2 runs or from other source (e.g. CODE). Do not estimate troposphere corrections while introducing estimated troposphere parameters as a priori information. You may run into inconsistencies because of different mapping functions used in the different steps.
For small networks, where the troposphere can be estimated only differentially, it is very useful to include (absolute) troposphere information for reference sites. This information can be obtained, e.g., from CODE (for a significant number of IGS sites).
Example
Ionosphere models: Selection of an ionosphere file containing local or global/regional ionosphere models is recommended when doing ambiguity resolution without using code measurements or when producing single-frequency solutions (e.g. with L1 measurements only). When processing the ionosphere-free (L3) linear combination you obviously do not need to specify any ionosphere model.
Example
Differential code biases: Selection of a code bias input file containing differential (P1-P2 or P1-C1) code biases of satellites and/or receivers is g
enerally recommended. These biases are irrelevant only when processing the L3 linear combination of code measurements from P1/P2 (not C1/X2 or C1/P2) receivers. If L1, L2, or even L5 is processed, precise satellite clocks (option "GNSS clock corrections") as well as ionosphere models (option "Ionosphere models") should be taken into account.
Example
Ocean loading corrections: If desired, a file containing the ocean loading amplitudes and phases may be specified. The format is the 'de facto' IERS standard.
Note:: For instructions on how to get ocean loading coefficients for a set of (new) points please be referred to IGS Mail 3521.
Example
GPSEST 1.2: Input Files 2
INPUT FILES 2
GNSS orbit partials: The selection of a file containing the partial derivatives of the orbital parameters is only necessary if you want to improve GNSS orbits in this run (see option "GNSS or LEO orbit determination", panel "GPSEST 5.2: Setup of Parameters and Pre-Elimination 2". The file is generated with program ORBGEN.
Kinematic coordinates: For kinematic station positioning it is possible to introduce kinematic a priori coordinates. Usually it is a result from a former run of GPSEST where the kinematic station positioning was stored in the file (see option "Kinematic coordinates" in panel "GPSEST 2.2: Output Files 2"). href=/$X/DOC/EXAMPLE.KIN>Example
Station information: This file contains station specific information. The program only considers the marker types (TYPE 005) contained in this file.
Example
Station eccentricities: Optionally a site coordinate eccentricity file may be specified containing local ties between markers.
Example
Station sigma factors: You may specify a file containing station observation sigma factors. It is used for the station-specific weighting of observations and for the rescaling of the edit level used for code observations in the zero difference processing (see option "Maximum tolerated O-C term" in panel "GPSEST 3.2: General Options 2").
Weighting of stations is important if you process pseudorange measurements from different receiver types in one program run because they may have significantly different noise levels. If you use smoothed code from program RNXSMT sigma factors for station weighting are not necessary.
The majority of sigma factors contained in the observation sigma file have to be close to unity. Otherwise the a priori sigma is rescaled.
Example
Receiver antenna orientation: Select a receiver antenna orientation file containing the azimuth of the antenna orientations for each session, where any of the antennas was not oriented to the north. This file is of special use if you have to process antenna calibration campaigns, where the antennas were oriented differently from session to session.
Example
Meteorological data: Measured surface meteorological data may be used to compute the tropospheric zenith delays. If meteorological data files (one file per station) are specified. The estim
ated troposphere parameters entered with the file specified in option "Troposphere estimates" in the previous panel have precedence over values given in the files specified here.
Under most circumstances the estimation of troposphere (see option "Site-specific troposphere parameters" in panel "GPSEST 5.1: Setup of Parameters and Pre-Elimination 1") gives much better results than the use of meteorological data to correct the tropospheric delays.
Example1, Example2, Example3
LEO INPUT FILES
Standard orbit(s): Specify an a priori LEO standard orbit if you are processing spaceborne GPS data.
Orbit partials: Specify the name of the file containing the partial derivatives of the orbital if you are processing spaceborne GPS data and are estimating dynamic or reduced-dynamic LEO orbits.
Attitude data: Specify the file containing the LEO attitude information. Original formats from CHAMP and JASON may be read.
Kinematic velocities: Epoch-specific velocities might be helpful for LEO-related applications.
Precise orbit(s): For SLR validation only, specify the LEO precise orbit file.
GPSEST 1.3: General Files
GENERAL INPUT FILES
General constants: This file contains all the physical and astronomical constants used in the Bernese GPS Software. Most probably you will never have to modify this file.
Example: $X/GEN/CONST.
Geodetic datum: This file contains the definition of the geodetic datum and of the ellipsoid to be used to compute ellipsoidal coordinates. It is used to apply antenna heights and for the printing of coordinates in the local system (north, east, up). You only have to modify this file when you want to introduce a new reference ellipsoid.
Caution: This file has no effect on cartes coordinates.
Example: $X/GEN/DATUM.
Phase center variations: This file contains receiver antenna phase center offsets and optionally elevation-dependent phase center patterns. In addition, the file may contain satellite-specific antenna phase center patterns (dependent on nadir angle) as well as offset values. Corresponding offset (correction) values, however, are not yet considered by the software. The satellite antenna offset values applied correspond to those given in $X/GEN/SATELLIT.I01.
You have to modify this file when you use a new antenna type or when you wish to consider your own PCV calibrations. The program PHCCNV allows to convert PCV information given in ANTEX format into Bernese-formatted PCV tables.
Important note: The file $X/GEN/PHAS_COD.I01 is based on the IGS ANTEX file IGS_01.ATX and contains PCV values for most of the receiver antenna types commonly used within IGS (and EUREF). These PCV values are addressed as 'relative' values as they are generally referred to a specific receiver antenna type (AOAD/M_T). For this reference antenna type (as well as implicitly all GNSS antenna types), PCV patterns are assumed to be nonexistent. In the near future it will become common to consider 'absolutely' calibrated receiv
er and satellite antenna PCV values. A corresponding file ($X/GEN/PHAS_COD.I05) based on the IGS ANTEX file IGS05_wwww.ATX is already available.
Important note: Use the file PHAS_COD.I01 always together with SATELLIT.I01, the file PHAS_COD.I05 always together with SATELLIT.I05.
Example: $X/GEN/PHAS_COD.I01.
Receiver information: This file contains in essence the code measurement types for a list of receivers. These specifications are relevant when considering so-called differential (P1-P2 or P1-C1) code biases.
Example: $X/GEN/RECEIVER.
Satellite information: This file contains general information on GNSS (and LEO/GEO) satellites. For the session to be processed, each satellite has to appear once in this file within a corresponding time window.
Note: The file $X/GEN/SATELLIT.I01 is maintained by AIUB/CODE. It includes a complete history concerning the GPS satellite constellation (and newly launched satellites are regularly added). You can get the latest version of this file from the anonymous ftp account of AIUB.
Example: $X/GEN/SATELLIT.I01
Satellite problems: This file contains information on satellite problems concerning modeling. It is used for exclusion of misbehaving satellites (and for orbit arc splitting). It may also contain (mean) epochs of GPS repositioning events.
Note: Corresponding year-specific files are maintained by AIUB/CODE. You can get the latest version of the current file from the anonymous ftp account of AIUB.
Example: $X/GEN/SAT_2003.CRX
Default value: SAT_$Y+0
Subdaily pole model: This file contains the parameters for the subdaily pole model. It has to be identical to the one used for the computation of the standard orbit.
Example: $X/GEN/IERS2000.SUB
Nutation model: This file contains the parameters for the nutation model. It has to be identical to the one used for the computation of the standard orbit.
Example: $X/GEN/IAU2000.NUT
SINEX header file: This file contains the general header information used when you want to create SINEX (Software independent exchange format) files. Adapt the file to your needs (institution name, hardware used, contacts, etc.).
Example: $X/GEN/SINEX.
IONEX control file: This file contains general information and some options you have to adapt when you want to create IONEX (IONosphere map EXchange format) files.
Example: $X/GEN/IONEX.
GPS-UTC file: Select the file containing GPS-UTC values here. You have to update this file each time a leap second is introduced. The file is only necessary together with JASON the attitude file.
Example: $X/GEN/GPSUTC.
TEMPORARY FILES
Scratch files: Enter the names of the scratch files used by this program. The scratch files need to be named differently for different programs running simultaneously. This may be achieved, e.g., by adding the job ID $J to the program name (define the job ID in the dialogue Menu > Configure > Set session/compute day).
Default values: GPSEST$J
GPSEST 2.1: Output Files 1
GENERAL
OUTPUT FILES
Program output: You can choose to have the program output written to a separate file for each program run (checkbox marked), or specify a common name for all program runs.
If you mark the checkbox, the filename will correspond to the program name with an extension containing a counter (Lnn), which is automatically incremented for each program run. If the counter reaches the maximum value, it is automatically reset, and existing files will be overwritten. The maximum value can be set in Menu > Configure > Program Names, option "Maximum program output file number".
If the checkbox is unmarked, you have to specify a name for the program output file. This allows to characterize the program run, e.g., by using the day and year ($YD+0) in the filename.
Error message: You can choose to have error messages written into the program's output file (see above), or specify a separate file to which error messages are written.
RESULT FILES 1
Normal equations: In order to have the possibility to combine GPSEST results on the normal equation level, it is recommended to specify here a NEQ filename. Later the NEQ files collected may be selected in the program ADDNEQ2 to be accumulated.
Important note:: Unresolved ambiguity parameters must be pre-eliminated (see "Ambiguities" in panel "GPSEST 5.1: Setup of Parameters and Pre-Elimination 1") if you wish to save the normal equations.
Station coordinates: Specify a filename to save the station coordinates estimated from double (or zero) difference phase (or/and code) observations.
Example
Troposphere estimates: Specify a filename to save the tropospheric zenith path delay (and gradient) parameters in a Bernese troposphere file.
Example
Troposphere SINEX: Specify a filename to save the tropospheric zenith path delay parameters in a troposphere-specific SINEX format.
Ionosphere models: Specify a filename to save local or global/regional ionosphere models in an Bernese ionosphere file. These models may be used in subsequent runs in GPSEST (e.g. for ambiguity resolution) or MAUPRP.
Example
IONEX: Specify a filename to save global/regional ionosphere models in IONEX format. For this purpose you have to adjust the content of the file specified in option "IONEX control file" in panel "GPSEST 1.3: General Files".
GNSS clock corrections: Specify a filename to save epoch-wise estimated satellite clocks to a Bernese satellite clock file. The file may also be written if the clock parameters are pre-eliminated EVERY_EPOCH.
Example
Clock RINEX: Specify a filename to save satellite and station clock estimates in the clock RINEX format. The file may also be written if the clock parameters are pre-eliminated epoch-wise.
Differential code biases: To save differential (P1-P2 or P1-C1) code biases of satellites and/or receivers. Note that P1-P2 code bias values can be saved in ionosphere map files, too.
Example
Residuals: Specify a filename to save the residuals of the linear combi
nation(s) processed. These residuals may be looked at or checked using the programs REDISP or RESRMS. Please note that, if one or more parameter types are pre-eliminated at any stage (including ambiguity parameters), it is no longer possible to save residuals in a residual file.
In order to back-substitute the solution for the parameters in order to compute the a posteriori residuals, the observation equations are written to a scratch file. This file may become very large if many observations are processed.
GPSEST 2.2: Output Files 2
RESULT FILES 2
Kinematic coordinates: Specify a filename to save the results of a kinematic station positioning.
Example
GNSS orbital elements: Specify a filename to save the improved GNSS orbital elements including dynamical and stochastic orbit parameters in an element file.
Example
LEO orbital elements: Specify a filename to save the improved LEO orbital elements including dynamical and stochastic orbit parameters the in an element file.
Bernese ERP file: Specify a filename to save estimated Earth rotation parameters in a Bernese ERP file.
Example
IERS ERP file: Specify a filename to save estimated Earth rotation parameters in the IERS format. The format is used for submission of ERP results to the IERS and to the IGS and for the program POLXTR.
Example
Phase center variations (grid): Specify a filename to save estimated receiver antenna phase center variations in the form of a grid in zenith angle and azimuth.
Phase center variations (harm): Specify a filename to save estimated receiver antenna phase center variations in the form of spherical harmonics coefficients.
Coordinate covariance matrix: Specify a filename to save the variance-covariance submatrix associated with the station coordinates in a file which may be used in the program COMPAR.
Full covariance matrix: Specify a filename to save the complete variance-covariance matrix in a file.
Caution: Such a file might become huge, if many parameters are estimated.
GPSEST 3.1: General Options 1
TITLE
This title line will be printed as header comment into the program output to document the program run. The title should characterize the program run by, e.g., giving the most important options used and the session.
OBSERVATION SELECTION
Satellite system: Observation data from a specific satellite system may be selected here.
Default value: ALL
Frequency: Here you may select one or two frequencies (linear combinations) to be processed.
L1: First frequency.
This frequency is the first choice when processing 'small' high-precision control networks (with an extent of few kilometers only) taking into account local or global/regional ionosphere models.
L2: Second frequency.
L3: Ionosphere-free linear combination (LC) of dual-band measurements.
This LC - which nearly completely eliminates the ionospheric refraction effects - is recommended to be used for most networks. By introducing already resolved wide-lane (L
5) ambiguities you get an observable which may be used to resolve the so-called narrow-lane (L1) ambiguities. One narrow-lane cycle corresponds to a wavelength of about 11 cm only. Please note that 'L3-ambiguities' are real-valued when no wide-lane (L5) ambiguities are introduced, i.e., in this case ambiguity resolution cannot be done!
L4: Geometry-free LC of dual-band measurements
which corresponds to the difference L1-L2 (in meters). This LC is useful when monitoring the deterministic component of the ionosphere and recommended when producing ionosphere models and estimating differential (P1-P2) code biases, respectively.
L5: Wide-lane LC of dual-band measurements.
In principle this LC is only used to resolve the wide-lane (L5) ambiguities without code measurements on 'medium' baselines (with lengths of few hundred kilometers only). One wide-lane cycle corresponds to a wavelength of about 86 cm which is quite large compared to the ionospheric (and tropospheric) biases expected. The site coordinates should be fixed to a previously computed L3-solution, when resolving the wide-lane ambiguities.
L1&L2: Both frequencies.
The parallel processing of both frequencies is recommended when resolving ambiguities with the SEARCH strategy. For the QIF strategy both frequencies have to be processed in parallel and the setting of L1&L2 is mandatory.
L3&L4: Ionosphere-free and geometry-free LCs.
Please do not use.
MELWUEBB: Melbourne-Wuebbena linear combination of dual-band phase and code measurements
is recommended to be used when resolving the wide-lane (L5) ambiguities with 'precise' code measurements. This LC is free of hypotheses concerning the ionosphere and the 'geometry' - where 'geometry' includes the troposphere, the satellite orbits (and clocks) as well as the station coordinates (and clocks). In order to use this option you have to select both, phase AND code single-difference files in option "INPUT FILES 1".
DTEC: Squared temporal differences of the geometry-free LC.
This kind of observable can be used to map the stochastic component of the ionosphere.
Default value: L3
Elevation cutoff angle: Only phase/code observations above the elevation cut-off angle specified here will be used in the parameter estimation program. If you process low-elevation data (below 15 degrees), an elevation-dependent observation weighting model should be activated (see option "Elevation-dependent weighting" below).
If you specify 0 (zero) here, all elevation angles will be accepted. This may be helpful if you have really bad a priori coordinates.
The elevation cutoff angle may be specified separately for ground-based and spaceborne receivers.
Default value: 3 degrees
Sampling interval: You may wish to process sampled observation epochs, i.e. only one epoch per n seconds. This time span can be specified here. If 0 is entered no data sampling will be done, i.e., all observation epochs will be used. In many cases the processing time may be consi
derably reduced by sampling the data without loss of accuracy.
If you store residual to screen the data using the programs RESRMS and SATMRK please keep in mind that you get residuals only for those observations corresponding to the sampling rate specified here. If you choose another value than 0 observations between the sampling epochs are not screened.
Default value: 0 or blank (all observations)
Tolerance for simultaneity: The correlation matrix will be computed for all the observations that are 'simultaneous', where simultaneous is defined by the time interval specified here. If you are processing 1 sec data you better change the time interval to a fraction of a second, else observations that belong to different epochs might be processed together and thus correlated.
Default value: 100 milliseconds
Special data selection: To process night-time data only might be a way to get more reliable differential code biases because of a temperate ionospheric climate on the obscured hemisphere. By eliminating data from eclipsing satellites the effect of non-predictable attitude motions of Block II and IIA satellites may be excluded. The option removes satellite data from start of the eclipse until 30 minutes after returning to sunlight.
Default value: NO
Observation window: If you switch this option on an additional panel will be displayed where you may enter the observation window to be processed. Otherwise all observations will be processed.
Default value: unmarked
OBSERVATION MODELING AND PARAMETER ESTIMATION
A priori sigma: Here you may specify the a priori sigma of unit weight, where the unit weight usually corresponds to the weight of the zero-difference L1 phase observable (at zenith). The a priori weights for the L1 phase and code observable are defined in the file $X/GEN/CONST..
The a priori sigma should approximately agree with the actual measurement noise of the one-way L1 phase observations (the post-fit sigma of unit weight given in the GPSEST output file). The value of this sigma is relevant only for the correct scaling of any a priori sigmas put on specific parameters. When changing the a priori sigma here, you also change the strength of the a priori constraints defined.
Default value: 0.001 meter (0.002 meter if no elevation-dependent weighting activated)
Elevation-dependent weighting: This option allows you to specify a model for the elevation-dependent weighting of the observations. The elevation-dependent weighting is valid for each of the correlation strategies you may choose above.
NO: All observations are equally weighted.
COSZ: Model 1 weighting function: cos(z)**2.
For test purposes the user may define his own weighting functions by modifying the subroutine WGTELV.
Default value: COSZ
Type of computed residuals:
The REAL residuals correspond exactly to the adjusted minus actual observations in each case. Vice versa, the actual observation vector plus the REAL residual vector gives the adjuste
d observation vector.
The NORMALIZED residuals are REAL residuals divided by the square root of the diagonal element of the cofactor matrix of the residuals - the difference between the inverse weighting matrix of the actual observations and the cofactor matrix of the adjusted observations. In contrast to REAL residuals, NORMALIZED residuals are always converted to one-way L1 carrier phase residuals, i.e., if you divide these residuals by the post-fit sigma of unit weight, you should get random variables with a standard deviation of 1.
If you want to detect outliers reliably using the program RESRMS when analyzing low-elevation data, applying an elevation-dependent observation weighting model, introducing satellite-specific weights, or introducing station observation sigma factors, it is recommended to save NORMALIZED residuals.
The NORM_APRIORI residuals correspond to NORMALIZED residuals scaled with the a priori (not post-fit) sigma of unit weight. This option may be useful in case of the presence of (pre-eliminated) epoch parameters.
Please be aware that, e.g., a REAL double-difference L3 carrier phase residual of 36 mm corresponds to a NORMALIZED (one-way L1-)residual of 6 mm - assuming that no elevation- or satellite-specific weighting took place.
Default value: NORMALIZED
Correlation strategy:
CORRECT: The mathematical correlations between the double-difference observations are handled correctly even when processing several baselines of a network. This correlation strategy is recommended when producing 'final' solutions, because mathematically and statistically it is the correct method to use. If more than about 30-40 sites are processed with correct correlations, the resources needed by GPSEST (CPU time, memory, etc.) might become critical. A comprise consists of a processing in clusters of sites with full correlations taken into account within each cluster.
All the observation files of one session are open simultaneously when using CORRECT. Correlations between different linear combinations are also correctly modeled (e.g. when processing L1 for some baselines and L3 for others).
FREQUENCY: With this option correlations are correctly handled within each linear combination or frequency. When processing L1 baselines and L3 baselines together the correlations within the L1 baselines and the correlations within the L3 baselines are dealt with separately. This option was sometimes used to avoid, that the scale in the L1 baselines (due to the ionosphere) would affect the L3 baselines through the correlations. A better method is the use of an appropriate ionosphere model to get rid of the scale and to process the network with correct correlations.
BASELINE: Only the correlations within each baseline are correctly modeled. Specifying BASELINE also means, that each baseline is processed sequentially (and not in parallel as in the case of correct correlations). Each single difference file is then considered to be one session interna
lly. Especially when pre-eliminating ambiguities this 'baseline mode' is very efficient, because it only needs space in memory for the ambiguity parameters of one baseline. After one baseline has been processed the ambiguities are pre-eliminated from the normal equation system and the ambiguity parameters of the next baseline may use their space.
If zero-difference observations are processed no mathematical correlations between observations exist. Nevertheless the correlation strategy CORRECT has to be used as soon as satellite clocks are estimated or code and phase observations are processed together because in both cases the observation files from the different stations resp. observation types have to be processed simultaneously.
Default value: CORRECT
GPSEST 3.1.1: Observation Window
OBSERVATION WINDOW
This panel allows to specify a time window. Only observations within this time window will be used for processing.
You may define the time window either by using session definitions, or by explicitly specifying start and end time.
Defined by year and session number: You may specify one session from the session table. The boundaries of this session define the observation window. If you use an open session table the year has to be specified in addition to the session identifier. If you use a fixed session table the year is read from the session definition and the value in the panel is ignored.
It is possible to specify a range of sessions using the corresponding menu variable ($S+-). In this case the time window starts at the beginning of the first session of the range and stops at the end of the last session of the range. If you use an open session table the year should also be given with the range variable ($Y+-).
Default values: Year $Y+0 session $S+0
Defined by start and end time: Specify date and time for the begin and the end of the observation window.
To specify a time window which is open on one side of the interval, leave the corresponding input field for the start/end date empty. The associated start/end time is then ignored.
Default values for daily processing: Start date: $YMD_STR+0, start time: 00 00 00, end date: $YMD_STR+0, end time: 23 59 59
GPSEST 3.2: General Options 2
A PRIORI TROPOSPHERE MODELING
ZPD model and mapping function: There are several possibilities to model the tropospheric delay. The models SAASTAMOINEN, HOPFIELD, ESSEN-FROOME, and NIELL are including the dry and wet component of the tropospheric delay, whereas the models DRY_SAAST, DRY_HOPFIELD, and DRY_NIELL take into account the dry part only.
It is recommended to model the hydrostatic (dry) component of the tropospheric path delay using the DRY_NIELL model and to estimate troposphere zenith path delay corrections using the WET_NIELL mapping function (option "Mapping function" in panel "GPSEST 6.3.1: Site-Specific Troposphere Parameters 1").
Special comments:
DRY_NIELL: The hydrostatic component of a Saastamoinen-based zenit
h path delay is mapped with the 'dry' Niell mapping function to obtain troposphere slant path delay values.
NIELL: This corresponds to DRY_NIELL plus an analogous model part with respect to the (badly predictable) wet component.
ESSEN-FROOME: This model is what we call a 'differential' model. It models the troposphere delay in the atmospheric layer between the lowest and the highest site. For the troposphere delay above the highest station, the Saastamoinen model is applied.
MARINI-MUR: This model is appropriate for SLR data analysis.
NONE: To suppress the use of an a priori troposphere model is not recommended (for test purposes or for LEO processing only).
Default value: DRY_NIELL (in case of estimation of troposphere parameters, else NIELL)
HANDLING OF AMBIGUITIES
Resolution strategy: Initial carrier phase ambiguities may be resolved/handled in several ways. Note that ambiguity resolution is usually done baseline by baseline.
If you process GLONASS-only or GPS/GLONASS-combined data, the following ambiguity resolution/handling strategies may be used: NONE, ROUND, and SIGMA. All these strategies work with all possible linear combinations, except for WUEBB.
NONE: Ambiguity resolution is not attempted.
ROUND: The simplest ambiguity resolution (AR) strategy which only rounds the real-valued estimates to their nearest integers without using any variance-covariance information.
SEARCH: The general search strategy includes essential elements of the Fast Ambiguity Resolution Algorithm (FARA) but is generalized to be applicable for all linear combinations. This AR strategy is very powerful for data taken in the rapid static observation scenario (with L1&L2) or the re-occupation scenario (with L1&L2 or only L1).
Attention: SEARCH is not yet GLONASS-capable.
SIGMA: The sigma-dependent strategy makes use of the full variance-covariance information. This 'standard' AR strategy is useful for linear combinations like L1, L2, L3 (with wide-lane), L5, L1&L2, and WUEBB.
QIF: The Quasi-Ionosphere-Free (QIF) AR strategy allows to directly resolve L1 and L2 ambiguities even on long baselines (with lengths up to 1000/2000 kilometers) without using the code measurements. Note that this AR strategy requires in addition the estimation of stochastic ionosphere parameters (panel "GPSEST 5.1: Setup of Parameters and Pre-Elimination 1", section "EPOCH PARAMETERS"). L1 and L2 observations have to be processed in parallel.
Attention: QIF is not yet GLONASS-capable.
Default value: NONE
Save resolved ambiguities: To save the integer values of resolved ambiguities (L1/L2 or L5) in the corresponding observation header (PSH) files is recommended when doing ambiguity resolution.
Default value: unmarked
Introduce widelane integers: To introduce the previously resolved wide-lane ambiguities is necessary when resolving narrow-lane ambiguities with L3. After successfully resolving L5 (wide-lane) and L1 (narrow-lane) ambiguities this option may be u
nmarked and the option "Introduce L1 and L2 integers" below may be marked to produce an ambiguity-fixed solution.
Default value: unmarked
Introduce L1 and L2 integers: You may produce
an ambiguity-free solution by unmarking the checkbox or
an ambiguity-fixed solution by marking the checkbox, if L1 and L2/L5 ambiguities are already resolved.
We recommend to produce an ambiguity-fixed solution as final solution by introducing the known integers.
Default value: marked
SPECIAL PROCESSING OPTIONS
Maximum tolerated O-C term: Relatively large outliers may remain in the code observations even after running the program CODSPP. This option allows to remove code (or range) outliers in undifferenced processing based on the a priori Observed-minus-Computed residuals. The option is also useful for the processing of Satellite Laser Ranging (SLR) data.
If an elevation-dependent observation weighting model is used, the O-C editing level has to correspond to the value at zenith. It is increased according to the zenith angle of the observations.
If you have specified a file containing station observation sigma factors (option "Station sigma factors" in panel "GPSEST 1.2: Input Files 2") these values are used for rescaling the edit level. For sigma factors below 1.0 or for stations without sigma factor, no rescaling is applied.
Default value: blank
Var-covar wrt epoch parameters: Correlations between pre-eliminated epoch parameters and the remaining parameters may be neglected (SIMPLIFIED) or taken into account (CORRECT) for subsequent resubstitution (of corresponding epoch parameters). Note that CORRECT may be very memory-intensive.
Default value: SIMPLIFIED
EXTENDED PRINTING OPTIONS
Selection of printing options: This option allows you to control the printing of extended output into the program output file.
NO: No extended output is printed.
YES: In an additional panel you may select what extended output shall be printed.
AS_IS: Extended output is printed as configured in panel "GPSEST 3.3: Extended Printing Options", but the panel is not displayed ('as is').
GPSEST 3.2.1: General Search Ambiguity Resolution Strategy
OPTIONS AND CRITERIA FOR TESTING
Baseline-wise ambiguity resolution: Ambiguity resolution using the general search strategy is recommended to be done baseline by baseline. In this case the normal equation system is divided into baseline-specific parts which are manipulated one after the other. Disable the option to do the general search in one step using the complete normal equation system. You may ignore this option when you process an individual baseline only.
Default value: marked
Search width in units of standard deviation: To quantify the search range for all ambiguity parameters (and all possible differences including wide-lane ambiguities) you may specify a search width in units of standard deviations which should correspond to the factor of the Student t-distribution function as a function of d
egree of freedom and a significance level which has to be assumed. To find the true set of integers
all compatible ambiguity vectors are generated after statistically testing all possible values, differences, and geometry-free LCs,
for each accepted ambiguity vector a least-squares adjustment is performed, and finally
the ambiguity vectors are sorted according to their resulting RMS error.
At the end the ambiguity vector of the best solution (with the smallest RMS) has to fulfill two additional statistical tests to be accepted as the true one - otherwise the ambiguity resolution has failed.
Default value: 5.0
Minimum allowed rms ratio re 2nd best to best: Furthermore the ratio between the a posteriori RMS errors of the second best and the best ambiguity-fixed solution must be greater than the value specified here to successfully finish the ambiguity resolution. This test value may be obtained again by evaluating the Chi**2-distribution function.
Default value: 1.4
Maximum allowed rms ratio re fixed to float: The ratio between the a posteriori RMS errors of the (best) ambiguity-fixed and the ambiguity-float solution must be smaller than the value specified here. This test value may be obtained by evaluating the Chi**2-distribution function as a function of both degrees of freedom and an assumed significance level.
Default value: 2.0
Search width for geometry-free linear combination: Here you may specify a 'hard-wired' search width for the geometry-free (L4) linear combination of L1 and L2 ambiguities when processing dual-frequency observations (L1&L2 in option "Frequency", panel "GPSEST 3.1: General Options 1") which are biased by the ionosphere. If you enter 0.0, the L4 search width is derived from the formal accuracy and the t-factor specified above.
Please note that you may ignore this option when processing single-frequency data only.
Default value: 0.1
GPSEST 3.2.2: Sigma-Dependent Ambiguity Resolution Strategy
OPTIONS AND CRITERIA FOR TESTING
Maximal number of ambiguities fixed per iteration step: Maximum number of ambiguities to be solved in one iteration step. After each iteration step an inversion of the complete normal equation matrix is done once again holding the resolved ambiguities on their integer values. In this way we increase the chance of the remaining ambiguity parameters to be resolved because of the decreasing formal accuracies of the ambiguities with increasing degree of freedom.
By entering 0 all ambiguity parameters which fulfill the resolution criteria specified below are fixed in one step. Even in this case additional ambiguity pairs may be resolved in further iteration steps due to the boot-strapping mentioned above.
Default value: 10
Ambiguity resolvable if exactly one integer within: Ambiguities are solvable if exactly one integer lies within the two-tailed confidence interval based on the real-valued estimates, the a posteriori RMS errors, and the factor of the Student t-distribu
tion function. This confidence interval is specified here.
Default value: 3.0 sigma
Maximal sigma of resolvable ambiguities: All possible double-difference ambiguity parameters with an RMS error smaller than the maximal sigma specified here (in units of cycles of the observable processed) are first sorted according to their RMS errors. Note that the wavelengths of the mostly formed linear combinations are about 19.0 cm for L1, 24.4 cm for L2, 86.2 cm for the wide-lane LC (L5), and 10.6 cm for the narrow-lane LC (L3 with introduced L5 ambiguities).
Starting with the ambiguity parameter with the best RMS error the ambiguity resolution algorithm tests whether the associated fractional part is smaller than the maximal sigma entered here. Otherwise the next double-difference ambiguity from the sorted list is checked in the same way, and so on.
Default value: 0.07 cycles
Minimal sigma used for testing: In addition you may define a minimum sigma which is used in the statistical test if the RMS error of an ambiguity is smaller than this limit. This is necessary, because often the formal RMS errors are too small and obviously resolvable ambiguities will remain unresolved due to the sigma-dependent test (see option "Ambiguity resolvable if exactly one integer within" above).
Default value: 0.05 cycles
GPSEST 3.2.3: Quasi-Ionosphere-Free (QIF) Ambiguity Resolution Strategy
OPTIONS AND CRITERIA FOR TESTING
Maximal number of ambiguities fixed per iteration step: Maximum number of ambiguity pairs (L1 and L2) to be solved in one iteration step. After each iteration step an inversion of the complete normal equation matrix is done holding the resolved ambiguities on their integer values. In this way we increase the chance to resolve the remaining ambiguity parameters because of the decreasing formal accuracies of the ambiguities with increasing degree of freedom. By entering 0 all ambiguity pairs which fulfill the resolution criteria specified below are fixed. Even in this case additional ambiguity pairs may be resolved in further iteration steps due to the boot-strapping mentioned above.
Default value: 10
Search width for pairs of L1 and L2 ambiguities: This value specifies the search width for the wide-lane (L5) linear combination of the L1 and L2 ambiguity parameters. The L5 search width should be chosen smaller than 2 minus the maximum ionospheric bias on L5 (in L5 cycles) to be expected. You may apply an ionosphere model to support the QIF strategy (option "Ionosphere models" in panel "GPSEST 1.1: Input Files 1").
Default value: 0.50 cycles
Maximal sigma of resolvable NL ambiguities: All possible double-difference ambiguity pairs, where the RMS error of the ionosphere-free (L3) linear combination of the L1 and L2 ambiguity parameter are smaller than the maximum RMS error specified here (in units of narrow-lane cycles), are sorted according to their RMS errors. Note that the wavelength of the narrow-lane observable corresponds to a
bout 10.6 cm.
Default value: 0.03 cycles
Maximal fractional part of resolvable NL ambiguities:
Starting with the ambiguity pair with the best RMS error the ambiguity resolution algorithm does a search in the (L1,L5) ambiguity space using the L5 search width specified above. A pair of integers (L1 and L2) is accepted as true ambiguity set if the associated fractional part of the narrow-lane ambiguity parameter is smaller than the maximum value entered here. Otherwise the next pair from the list of sorted ambiguity pairs is checked in the same way, and so on.
Default value: 0.10 cycles
GPSEST 3.3: Extended Printing Options
INFORMATION RELATED TO OBSERVATIONS
List of observations given in files: Printing of the number of observations present in the observation files for each satellite into the GPSEST program output file. Note that not the number of observations actually processed in a GPSEST run are printed.
Default value: unmarked
List of observations used for processing: Printing of the number of double-difference observations actually processed for each observation file and each linear combination.
Default value: unmarked
Satellite elevations: A table of satellite elevations is printed for each session processed.
Default value: unmarked
Histogram of observations by elevation angle bins: Printing of a station-specific statistics concerning the elevation- dependent observation distribution. This statistics is recommended to be printed when processing low-elevation data.
Default value: unmarked
Histogram of observations by nadir angle bins: Printing of a satellite-specific statistics concerning the nadir angle- dependent observation distribution.
Default value: unmarked
INFORMATION RELATED TO ESTIMATED PARAMETERS
List of all parameters: Print a list of all parameters that are set up in GPSEST with their characterization. This list represents the initial set up of parameters and not the final status (parameters may be removed from the normal equation, if no observations contribute to their estimation, or parameters may be pre-eliminated). Epoch-specific parameters are not contained in the list, if they are pre-eliminated after each epoch processed.
Default value: unmarked
Helmert transformation of resulting station coordinates: Print Helmert transformation parameters of the estimated station coordinates with respect to the a priori coordinates. May be used to identify problems with network tilting or scale.
Default value: unmarked
Unresolved ambiguities after each iteration step: Print all ambiguity parameters after each iteration in the ambiguity resolution procedure of sigma-dependent or quasi-ionosphere free strategies. May be used to study the development of the fractional parts of the ambiguities when more and more ambiguities are resolved.
Default value: unmarked
Suppression of output concerning epoch parameters: In case of an expected huge number of epoch parameters, suppression of correspondin
g output might make sense.
Default value: unmarked
OTHER INFORMATION
Resolved ambiguities from observation files: Print all the ambiguity information contained in the observation header files. This only includes all the a priori ambiguity information, and not the results of the current run. (Those are printed anyway).
Default value: unmarked
Constants, antenna offsets, ionosphere coefficients: Print the general constants used, the a priori antenna phase center offsets and variations, and the coefficients of the ionosphere models introduced into the GPSEST run.
Default value: unmarked
Station eccentricities, receiver information: Print antenna heights, receiver and antenna names and numbers, etc.
Default value: unmarked
Receiver synchronization errors: Print the receiver synchronization errors as derived from the single-difference observed-computed values. Only for debug purposes.
Default value: unmarked
GPSEST 3.3.1: Helmert Transformation of Resulting Station Coordinates
OPTIONS CONCERNING HELMERT TRANSFORMATION
Coordinate system for transformation: Either LOCAL or GEOCENTRIC. Specifies the coordinate system to be used for a Helmert transformation between the a priori coordinates and the estimated coordinates.
Default value: LOCAL
Rotation/Scale: You may select the set of parameters for the Helmert transformation between the a priori coordinates and the estimated coordinates: 3 rotations around the X, Y, and Z axes, and/or a scale factor.
Default value: marked
GPSEST 4: Datum Definition for Station Coordinates
DATUM DEFINITION TYPE
The following options are available for the definition of the geodetic datum of the estimated site coordinates:
Free network solution: This option allows to estimate site coordinates without any constraints applied. I.e., no explicit definition of the geodetic datum is performed. This solution is not recommended for use except for test purposes.
Coordinates constrained: Mark this option if you want to constrain coordinates of a selected set of reference stations to their a priori coordinates for defining the geodetic datum. The strength of the constraints may be specified in option "A PRIORI SIGMAS" below.
Coordinates fixed: With this option you may fix the coordinates of the selected stations to their a priori values specified in the input coordinate file selected in option "Station coordinates" in panel "GPSEST 1.1: Input Files 1". The coordinates are fixed and removed from the solution.
Caution: Be aware that fixed coordinates can never be 'unfixed' again. Therefore, do not fix station coordinates if you are writing normal equation files. Use station coordinate constraining instead.
The following possibilities are available to select the reference stations for the definition of the geodetic datum for two of the three options above
FIRST: The first station of the station list is selected automatically for constraining resp. fixing of the coordinates.
LAST: The las
t station of the station list is selected automatically for constraining resp. fixing of the coordinates.
ALL: All stations are used to realize the geodetic datum by constraining resp. fixing of the coordinates.
MANUAL: Get an additional panel allowing to select the reference sites manually from the list of all stations involved in the solution. See options in panel "GPSEST 4.1: Datum Definition for Station Coordinates".
FROM_FILE: Get an additional panel allowing to select the name of a station selection sigma file (for constraining) or station selection file (for fixing) containing the list of stations to be used as reference sites.
In case of coordinate constraining the sigmas specified in the station sigma file are used. The option "A PRIORI SIGMAS" is inactive in this case. This option allows to specify individual constraints for different stations. See options in panel "GPSEST 4.1: Datum Definition for Station Coordinates".
WITH_FLAG: Get an additional panel allowing to specify a list of flags. Stations marked with the specified flags in the a priori coordinate file are used as reference stations.
This option may be useful if you want to introduce the coordinates of another solution. See options in panel "GPSEST 4.1: Datum Definition for Station Coordinates".
A PRIORI SIGMAS
It is possible to define default sigma values for site coordinate constraining (in meters). You may define different constraints for the horizontal (north, east) and the vertical (up) components which will be applied to the selected reference sites. If you want to specify individual constraints for the reference sites you have to create a station sigma file and introduce it using the FROM_FILE option in the field above.
GPSEST 4.1: Datum Definition for Station Coordinates
STATION COORDINATES TO BE CONSTRAINED
The coordinates of the selected set of stations will be constrained to the coordinates specified in the a priori coordinate file specified in panel "GPSEST 1.1: Input Files 1". Depending on the options selected under "Coordinates constrained" in panel "GPSEST 4: Datum Definition for Station Coordinates" you may input additional information in one of the following fields.
Manual selection: The field is active if you selected MANUAL to specify the reference sites. Push the button next to the field in order to get the list of stations involved in the solution. You may select manually the reference sites you want to constrain. Specify the values for the constraints in the section "A PRIORI SIGMAS" in the previous panel.
List of stations (and sigmas) from file: The field is active if you selected FROM_FILE to specify the reference sites. Specify the name of a station sigma file containing the names and the values of the constraints (in meters) for the sites you want to constrain.
Example
Stations with specific flags in CRD file: The field is active if you selected WITH_FLAG to specify the reference sites. Specify a list of flags. Those
stations which are marked in the a priori station coordinate file with one of the specified flags are constrained. Specify the values for the constraints in the section "A PRIORI SIGMAS" in the previous panel.
The character # stands for all non-blank flags, @ for all stations in the file.
GPSEST 4.1: Datum Definition for Station Coordinates
STATION COORDINATES TO BE FIXED
The coordinates of the selected set of stations will be fixed to the coordinates specified in the a priori coordinate file specified in panel "GPSEST 1.1: Input Files 1" and removed from the solution. They can no longer be 'unfixed'. Depending on the options selected under "Coordinates fixed" in panel "GPSEST 4: Datum Definition for Station Coordinates" you may input additional information in one of the following fields.
Manual selection: The field is active if you selected MANUAL to specify the reference sites. Push the button next to the field in order to get the list of stations involved in the solution. You may select manually the reference sites you want to fix.
List of stations from file: The field is active if you selected FROM_FILE to specify the reference sites. Specify the name of a station selection file containing the names of the sites for which you want to fix the coordinates.
Example
Stations with specific flags in CRD file: The field is active if you selected WITH_FLAG to specify the reference sites. Specify a list of flags. Those stations which are marked in the a priori station coordinate file with one of the specified flags are fixed.
The character # stands for all non-blank flags, @ for all stations in the file.
GPSEST 5.1: Setup of Parameters and Pre-Elimination 1
This and the following panel allow to set up parameters for estimation as well as to specify whether and at which stage of the processing they shall be pre-eliminated. To set up a specific parameter type activate the corresponding checkbox. The checkbox may be inactive if for a specific configuration of input files. It is, e.g., not possible to estimate clock parameters if single-difference files are specified as input, or orbit estimation is not possible if no file containing partials is specified.
Pre-elimination is useful, e.g., to reduce the size of the output NEQ or to increase processing speed. If, e.g., you do not wish to have site troposphere parameters explicitly in your stored NEQ file, use option PRIOR_TO_NEQ_SAVING for this parameter type. In this way, you may drastically reduce the size of your NEQ files. Please note that all pre-eliminated parameters are internally included in the least-squares adjustment scheme.
Be careful in selecting appropriate constraints when pre-eliminating parameters and saving normal equation files. The parameters remain, with the constraints applied, implicitly in the system. The constraints are 'frozen in' in the output NEQs and can never be modified again.
Please note that, if one or more parameter types are pre-eliminated a
t any stage, it is no longer possible to save residuals in a residual file (except for epoch-wise preelimination).
In case of normal equation storing you have to pre-eliminate the ambiguity parameters.
The following pre-elimination options are available:
NO: The parameters are not pre-eliminated and remain explicitly in the system. They appear in the solution and in the normal equation file if an output file is specified.
EVERY_EPOCH: Parameters are pre-eliminated epoch by epoch. This option is only available for epoch parameters, i.e., for kinematic station coordinates, receiver and satellite clock corrections, and stochastic ionosphere parameters.
AS_SOON_AS_POSSIBLE: Ambiguity parameters are pre-eliminated as soon as they are replaced by a new ambiguity for the same station-satellite combination. This option is only available for ambiguity parameters.
EVERY_SESSION: Parameters are pre-eliminated for each session or, for baseline-wise processing, for each baseline. Correlations between parameters from different sessions are thus neglected. The parameters are already pre-eliminated when the complete normal equation matrix is inverted ('before inversion'), i.e. they are not contained in the solution vector and thus their estimates are not available for the user.
PRIOR_TO_NEQ_SAVING: Parameters are pre-eliminated after the inversion of the full normal equation matrix but before saving of the output normal equation file. This option is useful, if you want to save a reduced normal equation system and still have the possibility to verify the estimates of the pre-eliminated parameters in the program output.
STATION-RELATED PARAMETERS
Station coordinates: Station coordinates are set up in any case for all stations providing observations. This option allows you to pre-eliminate station coordinates. The option may be reasonable only in very specific cases and is not recommended to be used.
Default value: NO
Ambiguities: In general, phase ambiguity parameters may be pre-eliminated because their values are not of particular interest. If normal equations are saved, the parameters must be pre-eliminated. When saving a residual file, however, pre-elimination of ambiguity parameters is not permitted.
Which pre-elimination option is selected depends on the available resources. More frequent pre-elimination (AS_SOON_AS_POSSIBLE) requires less memory on the expense of processing time while less frequent pre-elimination needs more memory but is more efficient with respect to computing time. To perform ambiguity parameter pre-elimination just every n seconds, a corresponding number, n, might be entered in the input field.
Note:: If ambiguity resolution is activated, either NO or (newly) PRIOR_TO_NEQ_SAVING may be selected. The latter possibility enables (in principle) saving of a NEQ file directly from a GPSEST run dedicated to ambiguity resolution.
Default value: AS_SOON_AS_POSSIBLE
Receiver antenna offsets: With this parameter ty