This object is used to define properties for GNSS systems.
ODTK specifically supports the following GNSS systems: GPS, GLONASS, Galileo, QZSS and BeiDou. Other GNSS systems could be supported by configuring one of these systems as necessary. Multiple constellation objects are allowed to support receivers which receive signals from multiple GNSS systems. One constellation object is required for each GNSS system used; each GNSS system can only be defined once. Each constellation requires a catalog file for initialization. In addition, GNSS systems that produce GPS signals (GPS/QZSS) also require an ISC (Inter-signal component) file to define group delay related data. Ephemeris and clock data for the constellation satellites can either be read in from a reference source file or estimated.
Note: See ODTK 5 Applied to GPS Satellite Orbits and Clocks for an overview of and guide to the application of ODTK 5 to GPS satellite and clock estimation.
Note: GNSS Satellite objects can be added as children of the GNSS Constellation object either directly from the Object Catalog or through the use of GNSS Constellation menu options that let you populate a GNSS constellation with satellites on the basis of data in the GNSS source file and GNSS catalog, or remove them all in a single step.
When there are GNSS Satellite objects, satellite-related values (antenna offsets, clock values) come from the GNSS Satellite objects instead of the catalog file. If a source file exists, the user can select whether or not to estimate orbit and clock. If no source file exists but GNSS Satellites exist, their orbits and clocks shall be estimated.
Note: Here is a list of the currently unsupported measurement types.
The following options are available for the GNSS Constellation object:
|GNSS Constellation Properties|
|System||Read only property giving the GNSS system name: “GPS”, “QZSS”, “Galileo”, “GLONASS” or "BeiDou". The system name is defined by the Catalog file (e.g., BeiDou_Catalog.txt). To change the GNSS system name, the Constellation object must point to a Catalog file that contains the desired system name and description.|
The Signal List is applicable to only constellations that produce “GPS” signals (GPS, QZSS). The purpose is to identify which frequencies (L1, L2, L5) and tracking codes (CA, C, P, I, X, M) are available for each PRN. This list is initialized from data in the Catalog file and then can be modified by the user. This list is only used during simulation to determine which signals are available to each PRN. Signal types which are available, and included in the receiver Measurement statistics, and included in the MeasTypes lists will be simulated. For the filter and least squares estimation processes the availability of “signal types” is determined by the observation file. The tracking codes follow the Rinex 3 convention:
CA = Coarse Acquisition
C = Modernization Civilian signal
P = GPS legacy precision code
I = In phase code
X = (I+Q) quadraphase codeM = military code (TBD)
Inter-Signal Group Delay Differential Correction (ISC).
Reference IS-GPS-200 paragraph 188.8.131.52.1.1.1, IS-GPS-705B paragraph 184.108.40.206.1.1.1., and IS-GPS-800B paragraph 220.127.116.11.
Filename: File containing ISC data to be read in. See ODTK GPS ISC File Description for a description of the file.
DelayTable: contains ISC data that is initially read in from the ISCDataDelay file; it can then be updated by the user. The table contains ISC data for the following GPS signals: L1CA, L1Cp, L1Cd, L2C, L5I5, L5Q5, L1M, L2M.
For L1/L2, L1/L5 and L2/L5 users, L1CA, L2C, L5I5, L5Q5 is available in NAV message type 30, see IS-GPS-200 Table 20-IV. For L1C users, L1Cp, L1Cd is available in the NAV message subframe 2, reference IS-GPS-800B Table 3.5-1. For military users L1M and L2M is available (TBD).
Defines where the Orbit/SolarPressure/Clock states are to be estimated.
Note: If no GNSS Satellite object has been added to the constellation, the following attributes are not available. Instead, a single attribute, EnabledPRNs, appears (see section on PRN List, Enabling & Disabling PRNs, and Estimation Settings, below). Click this attribute to open a dialog box that lets you enable or disable selected PRNs.
Reference (for clock estimation modes): Kenneth R. Brown, Jr. "The Theory of the GPS Composite Clock," IBM, in ION GPS-91; Proceedings of the 4th International Technical Meeting of the Satellite Division of the Institute of Navigation, Albuquerque, NM, Sept. 11-13, 1991 (A93-21126 06-17), pp. 223-241.
The file to use for PRN-dependent model parameters, including
clock data, group delay, antenna offsets, beam FOV and
active/inactive status. This file is used to provide default values
for the parameters, but the user can override the defaults by
clicking on the PRNList attribute and modifying the associated
table. The default catalog filename is
Note: The file defaults the parameter entries when (and only when) a new GPS Source.Filename or SVCatalog.Filename is selected. Overridden parameters written to a saved scenario will not be reverted to the default values when reloading. However, they will be changed if after the load the SVCatalog.Filename is reselected.
Note: The parameter data used to default a given PRN is made by matching (for each PRN in the GPS Ephemeris file) the ephemeris start time to the SV/PRN launch/decommission lifetime given in the catalog file.
For more information on the GNSS catalog file, click Description and Maintenance.
|SVReference.ISCDelayDataFilename||See ODTK GPS ISC File Description.|
The file to use for GPS SV ephemeris and clock data. Note that only one file can be entered per filter initiation, so that the filter start/stop time must be consistent with the file start/end span. Files can be of type .aux, .sp3, .rinex, .sem or .yuma. While .aux files contain covariance data, this data is currently ignored. For the purpose of measurement deweighting when SV states are not estimated, ODTK uses the default covariance model specified in the SVError attributes.
Note: The GPS source file must cover the process time span in either of the following conditions: there are no GPS satellite objects added under the GNSS Constellation object and you are simulating/filtering GNSS measurements, or there are GPS satellite objects added under the GNSS Constellation object and you are estimating either orbits or clocks but not both. Otherwise, if the source file does not cover the process time span, anomalous behavior occurs: If you are estimating clocks and not orbits, the process will not run. If you are estimating orbits and not clocks, the process writes error messages when attempting to get clock phase from the source file. In addition the GNSS source file must also span the InitialStateEpochTime when GNSS satellite objects are added to the GNSS Constellation object. If both GNSS orbits and clocks are estimated, the SVReference.Source attribute is hidden (and not needed) after the GPS satellites are added.
|...StartTime||The start time of the source file. For SP3 and AUX files this is the time of the first ephemeris point. For NAV RINEX files this is the epoch time (derived from “toe”) of the first data block. When source is a .yuma or .sem almanac then this is the almanac epoch time. When source is a .yuma or .sem almanac then this is the almanac epoch time. This is for information purposes only, not to be changed.|
|...StopTime||Stop time of the source file. For SP3 and AUX files this is the time of the last ephemeris point. For NAV RINEX files this is the epoch time (derived from “toe”) of the last data block. Not displayed for .yuma or .sem almanac files. This is for information purposes only, not to be changed.|
|...NumberOfPrns||The number of PRNs (or SVs) in the source file. This is for information purposes only, not to be changed. Note that GPS satellites can be identified by their SV identifiers or their pseudorandom noise (PRN) code identifiers. The SV identifier is unique for each launched GPS Satellite. The PRN number is in the range from to 1-31 and can be reused after a satellite becomes inactive or decommissioned.|
If a buffer value is set to zero (0), then there will be no extrapolation before or after the start or end time of the SP3 file (depending on the attribute), and any measurement to be simulated or processed at that time will be skipped. The set of measurements which would be skipped under these conditions includes measurements with a time tag indentical to the start of the SP3 data since orbit and clock information prior to this is needed in the measurement model when light time delay is included. Making these values larger than zero allows for extrapolation past the ends of the file. Typically, the time before the start of the file should only need to be set to one second to accomodate light-time delay effects. The start buffer value is defaulted to one (1.0) second. The time after the end of the file is defaulted to 15 minutes to allow extrapolation to the start of the next SP3 file based on a nominal SP3 time step of 15 minutes.
Prior versions of ODTK (earlier than v6.4) had a default value of 0.0 for the start time buffer, which can result in undesired error messages when simulating or processing data at the start time of the SP3 file. Changing the value of BufferBeforeFileStart to one (1) second should eliminate the error messages and allow for proper measurement modeling.
|...OverrideSourceFileTimes||To use a StartTime other than that of the source file, change OverrideStartTime to true and enter the desired value for NewStartTime (defaults to the scenario's start time). This option is useful for simulations where you may not have GPS data available during the desired timeframe for the simulation. This option is currently not available when using a .yuma or .sem almanac file as the source file.|
|...AddGPS||The InitialStateEpochTime is the time that will be used as the epoch of the satellites added to the constellation when you run the Add GNSS Satellites tool. This time should be between the start and stop times of the source file, or between the overridden start and stop times.|
List of PRN model data for each PRN identified in the source file. This list includes:
Note: The Read only parameters can only be modified by changes to the GPS Catalog file.
Note: Once a PRN ceases to exist in a loaded source file, the associated changes to the PRNList for that PRN are lost. If the new source file contains a PRN not in the previous source file, the values for that PRN will be defaulted to the catalog values.
For further information, see the section on PRN List. Enabling & Disabling PRNs, and Estimation Settings, below.
Defines the reference point for the ephemeris data contained within the Source.FileName entry, where the reference point can be either the Antenna Phase Center (APC) or Center of Mass (CM).
The ODTK GPS measurement modeling algorithm requires the GPS APC location. This can be obtained either by reading in the APC ephemeris directly or reading in the CM ephemeris and transforming to APC using the ODTK antenna offset model.
ReferencePoint defaults to Antenna Phase Center, independently of the file type; the user must match the ReferencePoint to the GPS source file selection (note that SP3 files may be either APC or CM, while .sem, .yuma, .aux and .rinex are APC).
ApplyAntennaOffset defaults to true when ReferencePoint = Center of Mass and is hidden if ReferencePoint = "AntennaPhaseCenter (and is ignored in code processing).
Note: That ODTK SV antenna offset model accounts for the phase center offsets given in the PRNList table (which themselves were derived from http://earth-info.nga.mil/GandG/sathtml), but it does not account for the GYM95 Yaw attitude model .
AttitudeBlockII, AttitudeBlockIIA - Choose between a nominal block II or IIA attitude profile, which always maintains the nominal yaw angle, or the GYM95 model, which attempts to model the yaw bias in sunlight and the complex yaw motion during and after eclipse periods and in the vicinity of the noon turn. The attitude profile will affect the location of the antenna phase center for measurement modeling but does not affect the solar pressure model. If GPS satellites are not populated under the constellation, satellites labeled as block IIR or IIR-M in the PRN list will use the block IIR nominal profile while block II satellites and block IIA satellites will use the attitude profile specified by the AttitudeBlockII and AttitudeBlockIIA settings respectively. These settings are also used as the default attitude profiles for block II and block IIA satellites that you add by selecting Add GPS Satellites from the GPS Constellation menu. If GPS satellites are populated under the constellation, the setting of the attitude selection on the GPS satellite objects controls the attitude for locating the GPS satellite antenna phase center for measurement modeling.
SVError is an 9x9 ephemeris/clock error covariance (in RIC sigma/correlation form) that is intended to represent 'nominal' SV errors, providing a default orbit and clock covariance to be used with the GPS ephemerides specified via SVReference.Source.Filename. The full covariance is specified as a 6x6 Orbit covariance, followed by a 3x3 Clock covariance and the OrbitClockCorrelation terms.
This single covariance is applied to all GPS ephemerides, whether predicted or post-fit, without regard to prediction interval. As such, the covariance cannot be considered realistic, but may be set sufficiently large to bound the real error, and thus be conservative.
Currently, SVError is used in the filter as part of the GPS pseudo-range and phase count measurement error variance computation. It is not currently used in the simulator.
|SVError.SVDefaultCovSource||Select ConstellationObject or CatalogFile. When SV states are not estimated the SV Covariance Data defines the "nominal" orbit/clock uncertainity in the GPS measurement modeling using the "GPSSourceFile" as the source for the orbit/clock. When SV states are estimated the SV Covariance Data defines the "initial" SV orbit/clock covariance.|
Satellite Transmitted Frequencies
L1 = L1 frequency. For GPS, this frequency carries the C/A code used for the standard positioning service (SPS) and the P code used for the precise positioning service (PPS). For GPS Modernization this frequency can also contain a L1 C civilian code different from the CA code and more compatible with the Galileo E1 signal. Currently ODTK assumes that all satellites within the constellation transmit on the same L1 frequency, nominally at 1575.42 Mhz (see E1 below).
L2 = L2 frequency. For GPS, this frequency carries the P code used for the precise positioning service (PPS). When available the L2 P code can be combined with L1 P code to form dual-frequency measurements. For GPS Modernization this frequency can also carry a L2 C civilian code which can be combined with L1 CA and L1 C signals to form dual-frequency measurements. Currently ODTK assumes that all satellites within the constellation transmit on the same L2 frequency. Not used for navigation systems that are single frequency. Nominally 1227.60 MHz.
L5 – L5 frequency band added with GPS modernization. When available measurements from this band can be combined with L1 CA, L1 C, and L2 C measurements to form dual-frequency measurements. (see E5 below). Nominally 1176.45 MHz.
E1 – Galileo E1 frequency band. Nominally the same frequency as GPS L1, 1575.42 MHz.
E5 – Galileo E5 frequency band (E5a + E5b). Nominally 1191.795 MHz.
E5a – Galileo E5a frequency band. Nominally same frequency as GPS L5, 1176.45 MHz Used with E1 measurements to support F/NAV OS.
E5b – Galileo E5b frequency band. Used with E1 measurements to support I/NAV OS. Nominally 1207.140 MHz.
E6 – Galileo E6 frequency band. Used to support PRS, C/NAV. Nominally 1278.75 MHz.
|SystemTimeOffset||Used to support multi-GNSS applications. Defines time offset between this GNSS system and “the reference” with a clock state (phase, frequency, aging) that can be input, or estimated from the a-priori input. It can also be simulated. See the Satellite->Clock for details.|
|Ionosphere||Ionosphere model to be used in the processing of single
frequency measurements. IRI 2007 is the only model currently
available. ModeledUncertainty is used by the Filter to increase the
measurement error variance to account for the error in the selected
ionospheric model. Sigma is used for the uncertainity in the
pseudo-range measurements; RateSigma is used for the uncertainity
in phase count measurements. The uncertainty can be
stated in these terms or as a percentage of the computed
ionospheric effect. ModeledUncertainty is not currently used by the
If you do not select an ionosphere model, an UnmodeledSigma and UmodeledRateSigma fields appear, used in the deweighting of measurements for CA, CA SD, and single frequency phase count measurements. These values do not affect the processing of DF or DF SD or dual-frequency phase count measurements (see note below).
(Available only if GPS satellites have been added to the constellation.) Parameters for the Time Steering algorithm which implements the control of the ODTK-estimated GPS time. The steering objective is to null the bias and drift of the ODTK-estimated GPS time minus a "reference" time, where the reference time could be "GPS" or "UTC".
Note that the steering Bias, Drift, Steering Rate, and Tolerance parameters can be reset at the Filter Restart times if the Filter.Restart.ResetGPSUTCSteering flag is set to true.
NOTE: Steering commands are only used for GNSS constellations with clock estimation enabled. There can only be one GNSS constellation with clock estimation enabled in a filter run.
NOTE: The ionosphere model is important only if you are using single frequency measurement (e.g. CA, CA SD, L1 Phase, L1 SD Phase) types. If you are using DF, DF SD, DF Phase or DF SD Phase measurements, the ionospheric effects have already been eliminated.
Please note the following regarding the EnabledPRNs and PRNList attributes, and their relationship to the settings for estimation of orbits and clocks: