The GNSS Constellation Object

ODTK represents a GNSS Constellation object in the Browser and in the ODTK toolbar using the icon. Use this object to define properties for GNSS systems.

ODTK specifically supports the following GNSS systems: GPS, GLONASS, Galileo, QZSS and BeiDou. You could use ODTK to support other GNSS systems by configuring one of these supported systems as necessary. Two or more constellation objects are allowed to support receivers that receive signals from two or more GNSS systems. You can only define each GNSS system once, and each must have one constellation object. Each constellation requires a catalog file for initialization. In addition, GNSS systems that produce GPS signals (GPS/QZSS) also require an intersignal component (ISC) file to define group delay-related data. ODTK either can read in ephemeris and clock data for the constellation satellites from a reference source file or estimate it.

See ODTK Applied to GNSS Satellite Orbits and Clocks for an overview of and guide to the application of ODTK to GNSS satellite and clock estimation.

You can add GNSS Satellite objects as children of the GNSS Constellation object either directly from the Object Catalog or through the use of GNSS Constellation menu options that enable you to either 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, you can select whether or not to estimate orbit and clock. If no source file exists but GNSS Satellites exist, ODTK estimates their orbits and clocks.

ODTK Help provides a list of the unsupported measurement types.

The following options are available for the GNSS Constellation object:

GNSS Constellation properties
Property	Description
System	This is a read-only property giving the GNSS system name: GPS, QZSS, Galileo, GLONASS, BeiDou, or Custom. 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 that system name and description. ODTK will cycle through the allowed GNSS constellation types as you create new GNSS constellations in the scenario. You can configure the order in which the GNSS constellations are created by going to the Edit menu, selecting Preferences, and selecting GNSS settings.
CustomSystemName	This is a read-only property, giving the name of a Custom GNSS constellation as read from the catalog file. It is only visible for Custom GNSS constellations.
CentralBody	This is a read-only property, giving the name of the central body about which the GNSS constellation is centered, as read from the catalog file. The default value is Earth.
SVEstimatedStates	This defines where the Orbit/SolarPressure/Clock states are to be estimated. If you do not add a GNSS Satellite object to the constellation, the following attributes are not available. Instead, a single attribute, EnabledPRNs, appears (see the section on PRN List, Enabling & Disabling PRNs, and Estimation Settings). Click this attribute to open a dialog box in which you can enable or disable selected PRNs. Orbit is true if SV orbit states are to be estimated. SolarPressure is true if SV solar pressure state(s) are to be estimated, but it is hidden if Orbit = false. Clocks is true if SV clock state(s) are to be estimated. ClockEstimationMode is a method used to estimate the system of SV and Ground Receiver clock states. Available models: OpenLoop: In this mode, ODTK estimates all clocks states and does nothing to prevent the clock covariance from growing "without bounds" due to the observability issue related to using clock-to-clock difference measurements. MasterClock: In this mode, ODTK uses the SV clock, designated by the PRNUsedAsGPSTimeRef attribute, as the reference or master clock. It assumes this SV clock to be deterministic (no initial covariance and no process noise). Thus, it is not included in state space; its phase and frequency values are input via the GNSS Source Information. CompositeClock: In this mode, ODTK estimates all clocks. It estimates those clock defined in the ReferenceClocks list using Kenneth Brown's GPS Composite Clock covariance reduction algorithm (see the reference below) to keep the covariance of these clocks from growing without bounds. ODTK does not apply clock covariance reduction to those not in the ReferenceClocks list. PRNUsedAsGPSTimeRef (for MasterClock mode) is 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 sec²) = 31.62 nanoseconds. ClockCovReductionUpdateInterval (for CompositClock mode) controls the frequency of applying the Covariance Reduction. (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	This is the file to use for PRN-dependent model parameters, including clock data, group delay, antenna offsets, and active/inactive status. Use this file to provide values for the included parameters. Make changes by creating a modified version of the file. The default catalog filename is `GPS_Catalog.txt`. The default file path is given by the GPS Source Files File Find entry. Producers of SP3 information often use different antenna offsets for the same GNSS constellation. For example, the NGA antenna offsets for the GPS system have historically been kept constant and are reflected the default `GPS_Catalog.txt` and `GPS_Catalog_NGA.txt`. The IGS uses a different set of antenna offsets, which are occasionally updated. The catalog file, GPS_Catalog_IGS.txt, contains these offsets for a specific GPS week as indicated inside the file. When using SP3 files that represent the center of mass of the satellites, it is important to use the compatible catalog file to ensure that accurate antenna phase center locations are computed. The parameter data used for 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. Versions of ODTK prior to version 7.1 provide the means for you to modify data in the PRNList.
SVReference.Source.FileType	Select the type of file for ODTK to use to specify source information (orbit and clock data) for the GNSS Constellation. The options are: SP3 SEM Almanac YUMA Almanac AUX RINEX When you select SP3, you can specify two or more files . For all other selections, you can only select a single file. For Custom GNSS constellations, SP3 is the only option available.
SVReference.Source.Files	This is available when you select SP3 as the FileType . Specify a list of SP3 files that will provide the ephemeris and clock information for the GNSS Constellation. The content of two or more SP3 files should be contiguous, and you should enter the files in time order. ODTK supports files which follow the SP3a, SP3c, and SP3d formats.
SVReference.Source.Filename	This is available when you select a FileType other than SP3. ODTK uses this file for GPS SV ephemeris and clock data. You can only enter one file per filter initiation; the filter start/stop time must be consistent with the file start/end span. Files can be of type .aux, .rinex, .sem, .al3, .yuma, or .alm. The .aux files contain covariance data, but ODTK ignores it. For the purpose of measurement deweighting when SV states are not estimated, ODTK uses the default covariance model specified in the SVError attributes. The GPS source file must cover the process time span in either of the following conditions (but not both): There are no GPS satellite objects added under the GNSS Constellation object and you are simulating/filtering GNSS measurements There are GPS satellite objects added under the GNSS Constellation object and you are estimating either orbits or clocks. 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 you add GNSS satellite objects to the GNSS Constellation object. If ODTK is estimating both GNSS orbits and clocks, the SVReference.Source attribute is hidden (and not needed) after you add the GPS satellites.
SVReference.Source.InterpAcrossBoundaries	Set this to true to allow interpolation across the boundaries of SP3 files when more than one SP3 file is included in the Files list. This is only available when you set FileType to SP3.
SVReference.Source.StartTime	This is the start time of the source information. 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. This is for information purposes only, not to be changed.
SVReference.Source.StopTime	This is the stop time of the source information. 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. It is not displayed for YUMA or SEM almanac files. This is for information purposes only, not to be changed.
SVReference.Source.NumberOfPrns	This is the number of PRNs (or SVs) in the source file, for information purposes only, not to be changed. You can identify GPS satellites 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 1-31 and can be reused after a satellite becomes inactive or decommissioned.
SVReference.Source.BufferBeforeFileStart SVReference.Source.BufferAfterFileStop	If a buffer value is set to zero (0), then there will be no extrapolation before the start time nor after the end time of the set of SP3 files (depending on the attribute), and ODTK will skip any measurement to be simulated or processed at that time. The set of measurements that ODTK would skip under these conditions includes measurements with a time tag identical 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 enables extrapolation past the end time of the set of files. Typically, you should only need to set the time before the start of the first file to one second to accommodate light-time delay effects. The start buffer value is defaulted to one (1.0) second. The time after the end of the last 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. Versions of ODTK earlier than v6.4 have a default value of 0.0 for the start time buffer, which can result in 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.
SVReference.Source.ClockData.UseRINEXFile	Set this to true to use a RINEX clock data file to override clock information in a specified *.SP3 file. SP3 files typically provide ephemeris and clock information on a 15-minute time grid. RINEX clock files are used to specify SV clock information at a finer granularity, typically on a five (5) minute or finer (30 second, five (5) second) time grid. The use of RINEX clock information can provide improved interpolation of the SV clock data, which unlike the ephemeris, is not smooth.
SVReference.ClockData.Filename	This is the file to use for GNSS SV clock data as an override option when SV ephemeris is specified via an SP3 file. Files must adhere to the RINEX clock file format (.clk). You can only enter one file per filter initiation, so the filter start/stop time must be consistent with the file start/end span. While .clk files can contain uncertainty data, ODTK ignores this data. For measurement deweighting when SV states are not estimated, ODTK uses the default covariance model specified in the SVError attributes. AGI recommends using .SP3 and .clk files from the same source with matching time spans.
SVReference.ClockData.WeekReferenceEpoch	This is the epoch used as the reference for the GPS week number found in SEM and YUMA almanac files. Usually, you should set should this to the latest week reference option so that it is still prior to the current analysis period. This is only available when a SEM or YUMA almanac file is specified in the SVReference.Source.Filename.
SVReference.ClockData.StartTime	This is the start time of the clock data source file, which is the time of the first point in the file. This is for information purposes only, not to be changed.
SVReference.ClockData.StopTime	This is the stop time of the clock data source file, which is displayed as the time of the last point in the file plus one additional time step. For example, since daily files typically contain information from the start of the day until one time step before the end of the day, the stop time is displayed as the start of the next day. This is for information purposes only, not to be changed.
SVReference.ClockData.BufferBeforeFileStart SVReference.ClockData.BufferAfterFileStop	If you set a buffer value to zero (0), then there is no extrapolation before or after the start or end time of the clock file (depending on the attribute). ODTK will skip any measurement to be simulated or processed at that time. The set of measurements skipped under these conditions includes measurements with a time tag identical to the start of the clock data. ODTK skips these measurements because it needs orbit and clock information prior to this time 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, you should only need to set the time before the start of the file to one second to accommodate 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 five (5) minutes to enable extrapolation to the start of the next clock file based on an anticipated clock file time step of five (5) minutes.
SVReference.Source.OverrideSourceFileTimes	To use a start time 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 not available when using a YUMA or SEM almanac file as the source file. In the case of two or more SP3 source files, the effective time of data in all files is shifted by the change in the start time of the first file.
SVReference.Source.AddGPS	InitialStateEpochTime is the time that ODTK be use 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.Source.SP3BatchOperations	This setting is not visible in the GUI, but you can use it to improve performance when adding SP3 files to the Files list through the automation interface. Set SP3BatchOperations to true prior to adding a set of files to the Files list. You can then set SP3BatchOperations to false when the file additions are complete to avoid re-reading the files in the list after each insertion. You can also use this when removing individual files from the list. Neglecting to set SP3BatchOperations to false after it has been set to true results in undefined behavior.
SVReference.PRNList	This is a read-only list of PRN model data for each PRN identified in the source file. Content is pulled from the associated catalog file. This list includes: PRN = PRN number (read only). To support two or more GNSS receivers, the PRN numbers are offset by Base, so displayed PRN is Base + PRN. GPS - Base is 0 Galileo – Base is 100 QZSS – Base is 192 GLONASS – Base is 300 BeiDou - Base is 400 Custom - Base is 500 SVN is the Space Vehicle Number associated with this PRN. The SVN increases for each GNSS SV launched, whereas the PRN stays within its fixed range. BlockType is the SV Block Type, such as II, IIA, IIR, etc. ClockTypedisplays the type of clock (cesium or rubidium) the PRN is using. This display is for information purposes only. The displayed data derives from the XXX_Catalog.txt file, where XXX denotes the specific GNSS system. Typically the clock type is indicative of clock stability statistics, which in turn impact the noise statistics for measurement processing. ClockA0, ClockAminus1, ClockAminus2, ClockAgingWN are SV clock noise statistics: Frequency-modulated (FM) clock white noise , FM clock flicker noise, FM clock random walk, and FM clock drift, respectively. GroupDelay is 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 is the SV antenna offsets in SV body coordinates. SVErrScaleFactor is 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 when both of the following are true: ODTK is not estimating the SVs nor using them as a reference You created the SV satellite objects and set the SVError->SVDefaultCovSource attribute to "ConstellationObject" ODTK applies the multiplier in "sigma" space and not in "covariance" space. You can only modify the contents of this list by changing the GNSS Catalog file. For further information, see the section that discusses PRN List, Enabling and Disabling PRNs, and Estimation Settings.
SVReference. SVEphemerisReference	This 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. You can obtain this by reading in the APC ephemeris directly or by 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; you must match the ReferencePoint to the GPS source file selection. 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 (ODTK ignores it). The ODTK SV antenna offset model accounts for the phase center offsets given in the PRNList table, which themselves were derived from the NGA offset data table, but it does not account for the GYM95 Yaw attitude model . AntennaOffsetSource, which is visible when the ReferencePoint = “Center of Mass” and ApplyAntennaOffset is true, indicates the source of the mean phase center offset data. The default value is CatalogFile, which indicates that ODTK will extract the mean phase center offset from the file identified in the SVReference.Catalog setting. Alternatively, the value AntexFile indicates that ODTK will determine the mean phase center from the file identified in the SVReference.SVEphemerisReference.AntexFilename setting. You should use the Catalog File as the source of mean antenna phase center offsets when using SP3 files from the NGA. You should use the Antex File as the source of mean antenna phase center offsets when using SP3 files from the IGS. ModelPhaseCenterVariations defaults to false, but you can set it to true to include phase center variations from the Antex File identified in the SVReference.SVEphemerisReference.AntexFilename setting. These phase center variations, which are dependent on the frequency and direction between the GNSS satellite and the GNSS receiver, provide small corrections to pseudo-range and carrier phase measurements that may be important for high accuracy applications. ANTEXFilename is visible when you set AntennaOffsetSource to “ANTEXFile” or when you set ModelPhaseCenterVariations to true, or both. The standard file from IGS, igs14.atx, contains antenna mean phase center offset and antenna phase center variations for all of the currently operational GNSS satellites. IGS also retains historical versions of ANTEX files in an archive folder, listed in order by GPS week. 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 it does not affect the solar pressure model. If you did not add GPS satellites 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. ODTK uses these settings 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.
SVReference.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 you can modify it. This list is only used during simulation to determine which signals are available to each PRN. ODTK will simulate signal types that are available, included in the receiver Measurement statistics, and included in the MeasTypes lists. 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 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 is the 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; then you can update it. 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). ISC values are not supplied via RINEX-formatted ephemerides and must be sourced elsewhere. This file only applies to GNSS systems that produce “GPS-compatible" signals (GPS, QZSS). 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. For Galileo, the broadcast cast group delay (BGD) parameters are input via the catalog and given in the constellation PRNList table. There are no group delay considerations for GLONASS.
SVError	SVError is a 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 for ODTK to use with the GNSS 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. ODTK applies this single covariance to all GNSS ephemerides, whether predicted or postfit, without regard to prediction interval. As such, you should not consider the covariance realistic, but you may set it sufficiently large to bound the real error and thus be conservative. The filter uses SVError as part of the GNSS pseudorange and phase count measurement error variance computation. The simulator does not use it.
SVError.SVDefaultCovSource	Select ConstellationObject or CatalogFile. When ODTK is not estimating SV states, the SV Covariance Data defines the "nominal" orbit/clock uncertainity in the GNSS measurement modeling using the "GNSS Source Information" as the source for the orbit/clock. When ODTK estimates SV states, the SV Covariance Data defines the "initial" SV orbit/clock covariance.
SVFrequencies	Satellite Transmitted Frequencies 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. ODTK assumes that all satellites within the constellation transmit on the same L1 frequency, nominally at 1575.42 Mhz (see E1 below). L2 frequency: This is nominally 1227.60 MHz. For GPS, this frequency carries the P code used for the precise positioning service (PPS). When available, you can combine the L2 P code with L1 P code to form dual-frequency measurements. For GPS Modernization, this frequency can also carry a L2 C civilian code, which you be combine with L1 CA and L1 C signals to form dual-frequency measurements. ODTK assumes that all satellites within the constellation transmit on the same L2 frequency. This is not used for navigation systems that are single frequency. L5 frequency: This is a band added with GPS modernization, nominally 1176.45 MHz. When available, you can combine measurements from this band with L1 CA, L1 C, and L2 C measurements to form dual-frequency measurements. See E5 below. LEX frequency: This is an experimental signal added with QZSS, nominally 1278.75 MHz. It’s the same frequency as the Galileo E6 signal. It is not supported in ODTK. E1 – Galileo E1 frequency: This is nominally the same frequency as GPS L1, 1575.42 MHz. E5 – Galileo E5 frequency band (E5a + E5b): This is nominally 1191.795 MHz. E5a – Galileo E5a frequency band: Tis is nominally the same frequency as GPS L5, 1176.45 MHz, used with E1 measurements to support F/NAV OS. E5b – Galileo E5b frequency band: Use this with E1 measurements to support I/NAV OS. The frequency is nominally 1207.140 MHz. E6 – Galileo E6 frequency band: Use this to support PRS, C/NAV. The frequency is nominally 1278.75 MHz. G1 – GLONASS G1 frequency: This is nominally 1602 MHz. Use this with RCA, RP1, RLA and RL1 measurement types. G2 – GLONASS G2 frequency: This is nominally 1246 MHz. Use this with RCB, RP2, RLB and RL2 measurement types. G3 – GLONASS G3 frequency: This is nominally 1202.03 MHz. B1 – BeiDou B1 frequency: This is nominally 1561.1 MHz. B2 – BeiDou B2 frequency: This is nominally 1207.14 MHz. B3 – BeiDou B3 frequency: This is nominally 1268.52 MHz.
SimConstraints	Use this to collect constraints applied to the simulation of the GNSS Constellation.
SimConstraints.GainPatternConstraint	Use this to apply a link constraint based on GNSS gain pattern geometry when generating simulated measurements. This constraint applies to satellites within the constellation for which you set the GainPatternConstraint to “Based on GNSS Constellation.” The options are: Off - Apply no constraint based on the gain pattern of the satellite antenna. During GNSS measurement simulation, ODTK will consider a satellite visible to a GNSS constellation’s satellites only if it is not obstructed by Earth. L1: Main Lobe - Defines a field of view for the satellites in the GNSS constellation using the L1 Main Lobe data in the Gain Geometry Data File at ProgramData/AGI/ODTK 7/Databases/GNSS/GNSSGainGeometry.txt. For more information, see GNSS Gain Characterization Data. L1: Main & First Side Lobe - Defines a field of view for the satellites in the GNSS constellation using the L1 Main and First Side Lobe data in the Gain Geometry Data File at ProgramData/AGI/ODTK7/Databases/GNSS/GNSSGainGeometry.txt. For more information, see GNSS Gain Characterization Data. Custom - Defines a field of view for the satellites in the GNSS constellation using the constellation’s SimConstraints.HalfAngleFOV property.
SimConstraints.HalfAngleFOV	Defines a conical field of view with the vertex at the GNSS satellite and an axis passing through the center of Earth. During simulation of GNSS measurements, ODTK considers a satellite to be visible to a GNSS constellation’s satellites only if it is not obstructed by Earth and is within the field of view.
Ionosphere	This is the ionosphere model to use in the processing of single frequency measurements. IRI 2016 is the only model available. The filter uses ModeledUncertainty to increase the measurement error variance to account for the error in the selected ionospheric model. The filter uses Sigma for the uncertainity in the pseudorange measurements and RateSigma for the uncertainity in phase count measurements. The uncertainty can be stated in these terms or as a percentage of the computed ionospheric effect. The simulator does not use ModeledUncertainty. 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). Ionosphere settings only apply to GNSS constellations in orbit about the Earth.
SystemTimeOffset	Use it to support different GNSS applications. It defines the time offset between a GNSS system and “the reference” with a clock state (phase, frequency, aging), which you can enter or have ODTK estimate from the apriori input. You can also simulate it. See the Satellite->Clock for details.
GPSUTCTimeSteering	This is available only if you have added GPS satellites to the constellation. It has 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, when set to true, enables 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 is the 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 is the bias at the InitialBiasEpochTime. InitialDrift is the drift at the InitialBiasEpochTime. The drift units are sec/sec, which display as unitless in the Object Properties window. MaxSteeringRate is the maximum Steering Rate (i.e., maximum drift rate). BiasErrTolerance is the error tolerance test to determine if ODTK will apply steering across the next time update interval. ODTK applies steering if any of the following are true: The steering discriminant function > BiasErrTolerance The current \|Bias\| > BiasErrTolerance Sign(Discriminant function) = Sign(drift) You can reset the steering Bias, Drift, Steering Rate, and Tolerance parameters at the Filter Restart times if the Filter.Restart.ResetGPSUTCSteering flag is set to true. 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.

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. Ionosphere settings are only available for Earth-centered GNSS constellations.

PRN List, Enabling and Disabling PRNs, and Estimation Settings

The following information describes the EnabledPRNs and PRNList attributes and their relationship to the GNSS Catalog file, the GNSS Source data, the usage of PRNs during simulation and estimation processes, and the settings for estimation of orbits and clocks.

Relationship to the Catalog file and source information

The PRNList is a reflection of the contents of the Catalog file, and the number of entries in the PRNList is limited to those PRNs that exist in the source file(s). If a PRN is not contained in the source file(s), it will not appear in the PRNList attribute. The content of the entry for a specific PRN is based on the SVN to which the PRN is mapped during the time period of source information. The PRNList is a read-only attribute. To change the content displayed in the list, construct a new catalog file with new settings and the new file assigned as the GNSS Catalog file.

In the typical case where GNSS Satellites are not populated, the EnabledPRNs attribute contains an entry for each PRN in the source information. PRNs will be listed as disabled if they exist in the source information but cannot be associated with a mapping to a SVN during the time period of the source information. You can actively disable PRNs. Disabling a PRN in the EnabledPRNs list will exclude it from a simulator or filter run, but it will not have the effect of removing it from the PRNList.

Relationship to GNSS satellites

ODTK uses the data from the PRNList to populate the GNSS constellation during the Add GNSS Satellites operation. ODTK will add every PRN specified by the source file to the constellation, regardless of the setting in the EnabledPRNs list. The PRNList is hidden when you add GNSS Satellites, as ODTK will take all settings required for simulation and estimation processes from the satellites. The content of the EnabledPRNs list will update when you add or remove GNSS satellites to reflect the current set of satellites. If ODTK is estimating GNSS Satellite orbits or clocks, then the EnabledPRNs attribute is no longer needed and will be hidden.

PRN inclusion in simulation and estimation

The set of PRNs that are included for analyses is determined by:

The set of PRNs defined in the GNSS source information
The user-settable Enabled flag for each PRN in the EnabledPRNs attribute
The presence of GPS satellites (if so, ODTK only uses the PRNs of those satellites)

Estimation of orbits and clocks

Estimation of GNSS orbits and clocks is only possible when you add GNSS satellites. ODTK only performs estimation for the orbits and clocks of GNSS satellite objects in the scenario.

Creating custom GNSS constellations

Global Navigation Satellite Systems have a large number of configuration details. You must properly specify these in order to achieve realistic modeling. You cannot configure all of the parameters in ODTK. The goal of this section is to provide the necessary steps to create and configure a custom GNSS and to identify potential pitfalls in the process.

The first step in creating a custom GNSS constellation is creating a catalog file that describes the satellites in the constellation. The SYSTEM settings at the top of the catalog file serve to identify the Type {GPS, Galileo, QZSS, Glonass, Beidou, Custom} of the GNSS and to define the single character identifier used to identify this GNSS system in standard file formats (SP3 and RINEX). For a custom GNSS, the SYSTEM settings can also specify the central body about which the GNSS operates. Other important information in the catalog file includes the SV and PRN IDs of all the satellites, the block identifiers and availability times for each satellite, the block data sections, and the clock data sections. A sample file, Custom_Catalog.txt, is provided as part of the ODTK install in ProgramData\AGI\ODTK X\Databases\GNSS to serve as a starting point and format reference. It is important to match the single character identifier in the SYSTEM settings of the catalog file with associated markers in the SP3 files used to provide ephemeris and clock information and RINEX files used to provide observation data. Certain characters (G – GPS, E – Galileo, J – QZSS, R – Glonass, C – Beidou, I - IRNSS) are used to indicate existing systems; you should avoid them when creating a custom GNSS constellation, unless the intent is to override one of the existing systems. Overriding an existing system will be necessary if you use a source file format other than SP3, since SP3 is the only option for Custom GNSS constellations.

When configuring a custom GNSS about another central body, you must use SP3 files as the source of ephemeris and clock offset since the almanac propagation algorithms are specific to the Earth. The PRN designations and single character system identifier in the SP3 should match what is specified in the catalog file. For the purpose of simulations, it is acceptable to set the clock information in the SP3 file to zero if simulated clock data is not available. One method for creating an SP3 for use with a custom GNSS system is to populate a GNSS Constellation with satellites configured with the desired initial conditions and the SVEstimatedStates in the constellation configured to estimate orbits and clocks. Satellites populated under the constellation should match the content of the catalog file. Run the ODTK simulator, typically over a single day, to generate a time history of simulated orbits and clocks. Then use the StateFile_To_SP3 HTML tool to extract an SP3 file from the simulator output.

Each existing GNSS has a unique set of frequencies, signals, and measurement types. You should configure custom GNSS systems to use frequencies, signals, and measurement types that are associated with GPS.