The GNSS Constellation Object

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
Property Description
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.
SignalList

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 code

M = military code (TBD)
ISCDelayData

Inter-Signal Group Delay Differential Correction (ISC).

 

Reference IS-GPS-200 paragraph 30.3.3.3.1.1.1, IS-GPS-705B paragraph 20.3.3.3.1.1.1., and IS-GPS-800B paragraph 3.5.3.9.

 

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).

 

Notes:

  1. ISC values are not currently supplied via RINEX-formatted ephemerides and must be sourced elsewhere.
  2. This file currently only applies to GNSS that produce “GPS” compatible signals (GPS, QZSS).
  3. The Tgd parameter which is used in conjunction with the ISC delay, and applies to all signals for a given SV, is input from the Catalog file and given in the PRNList table.
  4. For Galileo, the broadcast cast group delay (BGD) parameters are input via the catalog and given in the constellation PRNList table.
  5. Currently there is no group delay considerations for GLONASS.
SVEstimatedStates

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.

  • Orbit = true if SV orbit states are to be estimated
  • SolarPressure = true if SV solar pressure state(s) are to be estimated. Hidden if Orbit = false.
  • Clocks = true if SV clock state(s) are to be estimated
  • ClockEstimationMode = Method used estimate the system of SV and Ground Receiver clock states. Available models:
    • OpenLoop: In this mode all clocks states are estimated and nothing is done to prevent the clock covariance to grow "without bound" due to the observability issue related to using clock-to-clock difference measurements.
    • MasterClock: In this mode the SV clock, designated by the PRNUsedAsGPSTimeRef attribute, is used as the reference or master clock. This SV clock is assumed to be deterministic (no initial covariance and no process noise) , i.e. it is not included in state space; its phase and frequency values are input via the GPSSourceFile.
    • CompositeClock: In this mode all clocks are estimated. Those defined in the ReferenceClocks list are estimated using Kenneth Brown’s GPS Composite Clock covariance reduction algorithm (see above reference) to keep the covariance of these clocks from growing without bound. Clock covariance reduction is not applied to those not in the ReferenceClocks list.
  • PRNUsedAsGPSTimeRef (for MasterClock mode): the PRN to serve as the time reference.
  • ReferenceClocks (for CompositeClock mode): Click this attribute and add one or more reference clocks to be used in this mode.
  • ClockCovReductionSigma (for CompositeClock mode): specifies the root-variance of the ε (epsilon) noise parameter in Brown’s model. The default is sqrt(1.0e-15 sec2) = 31.62 nanosec.
  • ClockCovReductionUpdateInterval (for CompositClock mode): controls the frequency of applying the Covariance Reduction.

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.

SVReference.Catalog.Filename

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 GPSCatalog.txt. The default file path is given by the GPS Source Files File Find entry.

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.
SVReference.Source
...Filename

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.
...BufferBeforeFileStart
...BufferAfterFileStop

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.
SVReference.PRNList

List of PRN model data for each PRN identified in the source file. This list includes:

  • PRN = PRN number (Read only). Note to support multiple GNSS receivers, the PRN numbers are offset by a Base number so displayed PRN is Base + PRN.
    • GPS - base is 0
    • Galileo – base is 100
    • QZSS – base is 192
    • GLONASS – base is 300
  • SVN = The Space Vehicle Number associated with this PRN. The SVN increases for each GPS SV launched, whereas the PRN stays within the fixed range 1-31. (Read only)
  • BlockType = SV Block Type, e.g. II, IIA, IIR, etc. (Read only)
  • BeamFOV = Defines a conical field of view with the vertex at the GPS satellite and axis passing through the center of the Earth. During simulation of GPS measurements, a user satellite is considered to be visible to the GPS satellite only if it is not obstructed by the Earth and is within the field of view.
  • ClockType = displays the type of clock (cesium or rubidium) being used by the PRN. This display is currently for information purposes only. The displayed data derives from the GPSCatalog.txt file. Typically the clock type is indicative of clock stability statistics, which in turn impact the noise statistics for measurement processing.
  • ClockA0, ClockAminus1, ClockAminus2, ClockAgingWN = SV clock noise statistics: Frequency-modulated (FM) clock white noise , FM clock flicker noise, FM clock random walk, and FM clock drift, respectively.
  • GroupDelay = The SV group delay differential between L1 and L2. This correction term only applies to single frequency measurements (reference ICD- GPS-200, 20.3.3.3.3.2). The group delay is unique to each SV. It is initially calculated via a ground calibration and then can be updated to reflect on-orbit performance.
  • AntennaOffsetX, AntennaOffsetY, AntennaOffsetZ = SV antenna offsets in SV body coordinates.
  • SVErrScaleFactor = a multiplier that provides scaling of the 8x8 (or 9x9 if clock aging is included) orbit/clock sigma/correlation matrix for individual PRNs. This scaling applies both when 1) the SVs are not estimated and used as a reference, and 2) when the SV satellite objects are created and the SVError->SVDefaultCovSource attribute is set to "GPSConstellationObject". Note that the multiplier is applied in "sigma" space and not in "covariance" space.

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.

SVReference.
SVEphemerisReference

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

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.
SVFrequencies

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 Simulator.

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).

GPSUTCTimeSteering

(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".

  • EnableTimeSteering = true to enable the time steering control
  • TimeSystem =
    • "GPS" if the initial bias does not include the GPS-UTC leap second difference.
    • "UTC" if the initial bias includes the GPS-UTC leap second difference.
  • InitialBiasEpoch = Epoch time of the (InitialBias, InitialDrift) polynomial. The (Bias, Drift) at the filter start time is computed by propagating the (InitialBias, InitialDrift) from the Initial BiasEpoch. The propagation is strictly a linear propagation (i.e. drift rate is set to zero); that is, the propagation to the Filter start uses the steering control algorithm.
  • InitialBias = Bias at the InitialBiasEpochTime
  • InitialDrift = Drift at the InitialBiasEpochTime. Note that the drift units are sec/sec, which display as unitless in the Object Properties window.
  • MaxSteeringRate = Maximum Steering Rate (i.e. maximum drift rate)
  • BiasErrTolerance = Error Tolerance test to determine if steering will be applied across the next time update interval. Steering is appied if any of the following are true:
    • The steering discriminant function > BiasErrTolerance
    • The current |Bias| > BiasErrTolerance
    • Sign(Discriminant function) = Sign(drift)

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.

PRN List, Enabling & Disabling PRNs, and Estimation Settings

Please note the following regarding the EnabledPRNs and PRNList attributes, and their relationship to the settings for estimation of orbits and clocks:

 

ODTK 6.5