These release notes contain information on system and disk space requirements for installing and running ODTK; information on new capabilities and features introduced in the current version of ODTK, including issues resolved from the prior version; transition information -- cautions, workarounds and operational tips -- to help maximize your successful use of the product; and a brief introduction to online help resources.
ODTK 6.4.0 Features
- GPS Objects Renamed
- New License
- GNSS Constellation
- Rinex 2.12 and 3.0.2 Support
- New Signal Types and Frequencies
- Measurement Types
- SP3 Updates
- Navigation Solutions
- Solar Radiation Pressure Models
- Attitude Profiles
- HTML Utilities
- Reporting and Graphing
- User Interface
- GNSS Catalog Files
- Tracking Instrument
- Miscellaneous
GPS objects renamed
The GPS related objects GPS Constellation, GPS Receiver, and GPS Satellite have been named to GNSS Constellation, GNSS Receiver, and GNSS Satellite, respectively to reflect the more generic nature of multiple GNSS constellations. Backwards compatibility for loading pre-6.4 scenarios is supported (the object class names will be changed appropriately on the fly); but any external scripts or code will need to be updated manually to use the new object class names. The names of the objects themselves will remain unchanged (e.g. object GPSReceiver/Receiver1 is now GNSSReceiver/Receiver1). If your scenarios didn’t use any of these objects then no script changes are required.
New license
We have introduced a new license, ODGNSS, as part of a new product offering oriented toward customers who need to estimate GNSS constellations. If you are currently estimating GNSS constellations, please contact your AGI sales representative and we will work with you to get the new license. Customers who use a GNSS constellation as part of estimating a non-constellation object (e.g. a satellite with a GNSS receiver on it) do not require the new license and will be unaffected.
GNSS constellation
Multiple GNSS constellation objects can now exist in the scenario, one for each of the constellations listed above. This includes a System Time offset used to support multi GNSS applications. It defines the time offset between a particular GNSS system and “the reference” with a clock state (phase, frequency, aging) that can be just an input, or an a priori input and then estimated. It can also be simulated.
Full support for all PRNs used in each of the constellations has been added. 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
RINEX 2.12 and 3.0.2 support
We have added support for the RINEX 2.12 (QZSS extensions) and 3.0.2 format observation files.
The way ODTK associates TrackerIDs with RINEX MARKER NUMBER records has changed when the RINEX MARKER NUMBER record contains an IERS DOMES number. The normal behavior is that ODTK reads the MARKER NUMBER record until a non-numeric value is encountered. This limited DOMES numbers to associate with five-digit TrackerIDs, because the sixth character is usually an "S" or "M" followed by 3 more digits. The new behavior converts the sixth character to a zero, allowing association with nine-digit TrackerIDs by default. The change allows co-located receivers having unique DOMES numbers to also have unique TrackingID associations by default.
New signal types and frequencies
We have added support for the following signals:
- CA = Coarse Acquisition
- C = Modernization Civilian signal
- P = GPS legacy precision code
- I = In phase code
- X = (I+Q) Quadraphase code
- M = military code*
We have added support for the following frequencies:
- l5 - When available measurements from this band can be combined with L1 CA, L1 C, and L2 C measurements to form dual-frequency measurements. 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.
Added support for the Inter-Signal Group Delay Differential Corrections (ISC). These are controlled by a data file that the user can modify.
Measurement types
The ability to construct and process Differenced One Way Doppler (DOWD) measurements has been added. DOWD measurements are constructed by differencing two simultaneous one way Doppler (3L Doppler) measurements taken from a single user satellite through two TDRS satellites.
We have added support for the GNSS measurements listed below:
| GNSS Measurement Types supported | |
|---|---|
| GNSS Type | Description |
| L1C Phase | GPS civilian carrier phase broadcast on the L1 frequency. This measurement is available with the first Block III launch. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
| L1C SD Phase | L1C Single-difference (single-frequency) phase count: The modeled measurement is the difference of two SV phase-count measurements (two L1C measurements). Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. However, ionosphere has not been eliminated. If SD Phase measurements have been requested, then the "raw" phase-count measurements are converted to SD Phase measurements, and no "raw" phase-count measurements are processed. |
| L1C Pseudo-range | GPS L1 civilian pseudo-range. This measurement is available with the first Block III launch. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
| L1C SD Pseudo-range | L1C single difference pseudo-range: The modeled measurement is the difference of two distinct SV L1 C code range measurements. Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. If L1C SD measurements have been requested (by adding L1 SD Pseudo-range to the GPS receiver MeasurementStatistics and to the MeasTypes on the satellite), then L1C measurements are converted to L1C SD measurements, and no pure L1C measurements are processed. |
| L2C Phase | GPS civilian carrier phase broadcast on the L2 frequency. This measurement is available with Block IIR-M and later. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
| L2C SD Phase | L2C Single-difference (single-frequency) phase count: The modeled measurement is the difference of two SV phase-count measurements (two L2C measurements). Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. However, ionosphere has not been eliminated. If SD Phase measurements have been requested, then the "raw" phase-count measurements are converted to SD Phase measurements, and no "raw" phase-count measurements are processed. |
| L2C Pseudo-range | GPS L2 civilian pseudo-range. This measurement is available with the first Block IIR-M and later. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
| L2C SD Pseudo-range | L2C single difference pseudo-range: The modeled measurement is the difference of two distinct SV L1 C code range measurements. Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. If L1C SD measurements have been requested (by adding L2 SD Pseudo-range to the GPS receiver MeasurementStatistics and to the MeasTypes on the satellite), then L2C measurements are converted to L2C SD measurements, and no pure L2C measurements are processed. |
| L5 Phase | GPS civilian carrier phase broadcast on the L5 frequency. This measurement is available with Block IIF and later. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
| L5 SD Phase | L5C Single-difference (single-frequency) phase count: The modeled measurement is the difference of two SV phase-count measurements (two L5 measurements). Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. However, ionosphere has not been eliminated. If SD Phase measurements have been requested, then the "raw" phase-count measurements are converted to SD Phase measurements, and no "raw" phase-count measurements are processed. |
| L5 Pseudo-range | GPS L5 civilian pseudo-range. This measurement is available with the first Block IIF and later. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
| L5 SD Pseudo-range | L5 single difference pseudo-range: The modeled measurement is the difference of two distinct SV L1 C code range measurements. Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. If L1C SD measurements have been requested (by adding L2 SD Pseudo-range to the GPS receiver MeasurementStatistics and to the MeasTypes on the satellite), then L2C measurements are converted to L5 SD measurements, and no pure L5 measurements are processed. |
|
L2C_L1C DF Phase L2C_L1CA DF Phase L5_L1CA DF Phase L5_L2C DF Phase |
GPS dual frequency (DF) phase measurements (using the modernization signals) computed by mathematically by combining the two single-frequency “raw” carrier phase measurements to produce a measurement that is independent of the first order effects of the ionosphere. If the user selects DF measurements, then the corresponding “raw” single-frequency measurements are converted to DF measurements, and no single-frequency measurements are processed. |
|
L2C_L1C DF SD Phase L2C_L1CA DF SD Phase L5_L1CA DF SD Phase L5_L2C DF SD Phase |
A singly differenced dual frequency measurement using GPS modernization signals’ DF phase. This means that the DF Phase is computed for two satellites that are being simultaneously tracked and that these two DF measurements are then differenced. These types of measurements are free from the effects of the ionosphere and the receiver clock bias. |
|
L2C_L1C DF Pseudo-range L2C_L1CA DF Pseudo-range L5_L1CA DF Pseudo-range L5_L2C DF Pseudo-range |
GPS dual frequency (DF) range measurements (using the modernization signals) computed by mathematically by combining the two single-frequency “raw” pseudo-range measurements to produce a measurement that is independent of the first order effects of the ionosphere. If the user selects DF measurements, then the corresponding “raw” single-frequency measurements are converted to DF measurements, and no single-frequency measurements are processed. |
|
L2C_L1C DF SD Pseudo-range L2C_L1CA DF SD Pseudo-range L5_L1CA DF SD Pseudo-range L5_L2C DF SD Pseudo-range |
A singly differenced dual frequency measurement using the GPS modernization signals’ DF pseudo-range. This means that the DF Pseudo-range is computed for two satellites that are being simultaneously tracked and that these two DF measurements are then differenced. These types of measurements are free from the effects of the ionosphere and the receiver clock bias. |
| LEX Phase | QZSS experimental measurement. Carrier phase measurement broadcast on the LEX frequency (same as Galileo E6 frequency). Not currently supported (TBS) |
| LEX SD Phase | LEX Single-difference (single-frequency) phase count. Not currently supported (TBS) |
| LEX Pseudo-range | QZSS experimental measurement. Range measurement using LEX frequency (same as Galileo E6 frequency). Not currently supported (TBS) |
| LEX SD Pseudo-range | LEX single difference pseudo-range: Not currently supported (TBS) |
|
E1 Phase E5a Phase E5b Phase E6 Phase |
Galileo Carrier Phase Measurements broadcast on the E1, E5a, E5b, and E6 frequencies respectively. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
E1 SD Phase E5a SD Phase E5b SD Phase E6 SD Phase |
Galileo single-difference (single-frequency) phase count: The modeled measurement is the difference of two SV phase-count measurements (two E1, or two E5a, or two E5b, or two E6 measurements). Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. However, ionosphere has not been eliminated. If SD Phase measurements have been requested, then the "raw" phase-count measurements are converted to SD Phase measurements, and no "raw" phase-count measurements are processed. |
|
E1_E5a DF Phase E1_E5b DF Phase |
Galileo dual frequency (DF) phase measurements computed by mathematically by combining the two single-frequency “raw” phase measurements to produce a measurement that is independent of the first order effects of the ionosphere. If the user selects DF measurements, then the corresponding “raw” single-frequency measurements are converted to DF measurements, and no single-frequency measurements are processed. |
|
E1_E5a DF SD Phase E1_E5b SD DF Phase |
A singly differenced dual frequency measurement using Galileo signals’ DF phase. This means that the DF phase is computed for two satellites that are being simultaneously tracked and that these two DF measurements are then differenced. These types of measurements are free from the effects of the ionosphere and the receiver clock bias. |
|
E1 Pseudo-range E5a Pseudo-range E5b Pseudo-range E6 Pseudo-range |
Galileo the E1, E5a, E5b, and E6 pseudo-range measurements. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
E1 SD Pseudo-range E5a SD Pseudo-range E5b SD Pseudo-range E6 SD Pseudo-range |
Galileo single-difference (single-frequency) pseudo-range: The modeled measurement is the difference of two SV pseudo-range measurements (two E1, or two E5a, or two E5b, or two E6 measurements). Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. However, ionosphere has not been eliminated. If SD pseudo-range measurements have been requested, then the "raw" pseudo-range measurements are converted to SD pseudo-range measurements, and no "raw" pseudo-range measurements are processed. |
|
E1_E5a DF Pseudo-range E1_E5b DF Pseudo-range |
Galileo dual frequency (DF) range measurements) computed by mathematically by combining the two single-frequency “raw” pseudo-range measurements to produce a measurement that is independent of the first order effects of the ionosphere. If the user selects DF measurements, then the corresponding “raw” single-frequency measurements are converted to DF measurements, and no single-frequency measurements are processed. |
|
E1_E5a DF SD Pseudo-range E1_E5b SD DF Pseudo-range |
Galileo the E1, E5a, E5b, and E6 pseudo-range measurements. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
E1 Pseudo-range E5a Pseudo-range E5b Pseudo-range E6 Pseudo-range |
A singly differenced dual frequency measurement using Galileo signals’ DF pseudo-range. This means that the DF Pseudo-range is computed for two satellites that are being simultaneously tracked and that these two DF measurements are then differenced. These types of measurements are free from the effects of the ionosphere and the receiver clock bias. |
|
RCA Pseudo-range RCB Pseudo-range |
GLONASS SA pseudo-ranges. RCA is associated with the G1 frequency; RCB is associated with the G2 frequency. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
RCA SD Pseudo-range RCB SD Pseudo-range |
GLONASS SA single difference pseudo-range: The modeled measurement is the difference of two distinct SV SA pseudo- range measurements. Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. If RCA/RCB measurements have been requested (by adding RCA SD Pseudo-range or RCB SD Pseudo-range to the receiver MeasurementStatistics and to the MeasTypes on the satellite), then “raw” measurements are converted to SD measurements, and no pure “raw” measurements are processed. |
| RDF Pseudo-range | GLONASS dual frequency (DF) range measurements) computed by mathematically by combining the two HA single-frequency RP1 and RP2 pseudo-range measurements to produce a measurement that is independent of the first order effects of the ionosphere. If the user selects DF measurements, then the corresponding “raw” single-frequency measurements are converted to DF measurements, and no single-frequency measurements are processed. |
| RDF SD Pseudo-range | A singly differenced dual frequency measurement using GLONASS DF pseudo-range. This means that the DF Pseudo-range is computed for two satellites that are being simultaneously tracked and that these two DF measurements are then differenced. These types of measurements are free from the effects of the ionosphere and the receiver clock bias. |
|
RP1 RP2 Pseudo-range |
GLONASS SA pseudo-ranges. RCA is associated with the G1 frequency; RCB is associated with the G2 frequency. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
RCA RCB Pseudo-range |
GLONASS HA pseudo-ranges. RP1 is associated with the G1 frequency; RP2 is associated with the G2 frequency. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
RLA RLB Phase |
GLONASS SA carrier phase measurements. RLA is associated with the G1 frequency; RLB is associated with the G2 frequency. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
RLA SD RLB SD Phase |
GLONASS SA single difference phase: The modeled measurement is the difference of two distinct SV SA phase measurements. Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. If RLA/RLB measurements have been requested (by adding RLA SD Pseudo-range or RLB SD Pseudo-range to the receiver MeasurementStatistics and to the MeasTypes on the satellite), then “raw” measurements are converted to SD measurements, and no pure “raw” measurements are processed. |
|
RL1 RL2 Phase |
GLONASS HA pseudo-ranges. RP1 is associated with the G1 frequency; RP2 is associated with the G2 frequency. The user's S/C - SV range is the modeled measurement. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
RCA RCB Pseudo-range |
GLONASS HA carrier phase measurements. RL1 is associated with the G1 frequency; RL2 is associated with the G2 frequency. Receiver clock phase error and clock frequency error (user spacecraft clock) are modeled and estimated |
|
RL1 SD RL2 SD Phase |
GLONASS HA single difference phase: The modeled measurement is the difference of two distinct SV SA phase measurements. Note that in this case, the receiver clock errors are eliminated from the measurement model, obviating the need to estimate receiver clock phase and frequency. If RL1/RL2 measurements have been requested (by adding RL1 SD Pseudo-range or RL2 SD Pseudo-range to the receiver MeasurementStatistics and to the MeasTypes on the satellite), then “raw” measurements are converted to SD measurements, and no pure “raw” measurements are processed. |
|
RDF |
GLONASS dual frequency (DF) phase measurement computed by mathematically by combining the two HA single-frequency RL1 and RL2 phase measurements to produce a measurement that is independent of the first order effects of the ionosphere. If the user selects DF measurements, then the corresponding “raw” single-frequency measurements are converted to DF measurements, and no single-frequency measurements are processed. |
|
RDF SD |
A singly differenced dual frequency measurement using GLONASS DF phase. This means that the DF Phase is computed for two satellites that are being simultaneously tracked and that these two DF measurements are then differenced. These types of measurements are free from the effects of the ionosphere and the receiver clock bias. |
SP3 updates
Our SP3 code has been updated to recognize the QZS (QZSS), GAL (Galileo), and GLO (GLONASS) time system indicators and support the range of PRNs used by each of the constellations listed above.
We can now generate an SP3 file for each constellation based on the estimated orbit and clock states.
Added a new capability to read an SP3 file containing data from multiple constellations and generate separate SP3 files for each constellation.
The simulator, filter, and smoother now have the option to output SP3 files during the actual processing interval and/or a prediction interval. This is useful when estimating GNSS constellations.
Navigation solutions
The generation of single frequency navigation solutions (via the HTML utility GenerateNavSolutions or a direct call to the ODTK GenerateNavSolutions function) will now include ionosphere corrections and the group delay. For ground receivers, GenerateNavSolutions will now include troposphere corrections.
Solar Radiation Pressure models*
We will add support for GPS III and QZSS solar radiation pressure models once these have been published (or provided to us directly). We are not aware of any public models at this time.
Attitude profiles
The QZSS and Galileo standard attitude profiles are now supported.
HTML utilities
A new HTML utility CreateReceiverSite has been added to quickly build a ground based GNSS receiver and attached antenna based on the data from a RINEX file.
A new HTML utility RINEXClockToSimrun.html has been added to read a RINEX file and convert the clock information in it to a .simrun file. This is useful for then analyzing the clock statistics using the Allan Variance or Hadamard Variance output styles.
Reporting and Graphing
The static product builder user interface has been updated to allow standard hot key support for copying (Ctrl-C) and pasting (Ctrl-V) products in the product list on the left side of the panel. Drag and drop capability has also been added.
We have added additional report and graph styles to calculate the Allan and Hadamard variance for the clocks used in the scenario.
The accumulated and average Delta-V parameters have been added to the Finite Maneuver Summary table. These are useful when trying to figure out how much Delta-V was applied during a finite maneuver.
User Interface
The Filter, IOD, and Least Squares wizards have been removed from the user interface.
GNSS catalog files
The GPS_Catalog.txt file has been updated to reflect the launches of SVN 67, 68, and 69. New catalog files for BeiDou, Galileo, GLONASS, and QZSS have been added (and can be updated using the Data Update Utility).
Tracking instruments
Satellites have a new sub-object called TrackingInstrument. The TrackingInstrument is used to measure models that used to be held by the satellite object itself (e.g. space based right ascension and declination, ephemeris position and velocity, etc.). We moved these off the satellite object because we found that in some cases satellites had multiple sensors capable of generating these measurements, each requiring their own specific measurement model configuration.
If you currently have satellites hosting measurement models (as seen in the satellite's MeasurementStatistics properties, then these will automatically be converted on scenario load to a properly configured TrackingInstrument sub-object and the scenario should operate properly. However, if you have scripts or other code that references the satellite's MeasurementStatistics properties, it will NOT work any more and must be updated to reference the TrackingInstrument instead of the satellite.
Miscellaneous
ODTK Message Viewer log files were always created by default in the %TEMP% directory of the current user. In order to be consistent with STK the default log file location is set to My Documents/ODTK 6/Config/Logs. The default location can be changed by editing HKEY_CURRENT_USER/Software/AGI/ODTK/6.0/LogPath registry key.
The truncated versions of the GRAIL derived lunar gravity models (GL0420A and GL0660B) have been replaced with complete versions of the models.
The scenario now exposes the Measurements.LookAheadBufferSize used for sorting observations in time order. This is useful when processing measurement files where observations appear out of time order. The buffer will automatically sort the next N measurements. However, if you make N large then filter processing will slow down.
Atmospheric density, pressure, temperature and mean molecular mass have been added to the drag model plugin interface.
The Dynamic Earth Data files have been updated to properly reflect the new leap second announced for June 30, 2015. These updates are also available on our FTP site via the Data Update Utility.
Capabilities added and issues resolved from the prior release
| New Capabilities and Resolved Issues in ODTK 6.4 | |
|---|---|
| Tracking No. | Description |
| 04881 | Hot key functionality created for data products in the Static Data Products builder. You can now use Ctrl + C to copy and Ctrl + V to paste. |
| 47801 | The space based tracking paradigm has been updated through the addition of TrackingInstrument sub-objects, which can be added to satellites. All measurement statistics for space based tracking are now defined in the new TrackingInstrument objects. Advantages of the new paradigm include the ability to model multiple instruments, which produce the same types of measurements, but at different qualities and with different fields-of-view, and the ability to model the offset between the tracking reference point and the center of mass of the spacecraft. Old scenarios will automatically create new TrackingInstrument sub-objects upon loading when appropriate. |
| 60812 | Integrated Delta-V has been added to the list of reported quantities in the finite maneuver summary table. Information is reported in inertial coordinates as well as in the radial, in-track, cross-track, tangential, and normal directions. |
| 71620 | The reading of SP3 files for use in GNSS constellation specification and estimation has been updated to be compatible with the Galileo and QzSS GNSS constellations. |
| 72680 | The attitude model for QZSS (GPS augmentation) satellites has been added to the list of available satellite attitude profiles. |
| 72681 | The attitude model for the Galileo in-orbit validation (IOV) satellites has been added to the list of available satellite attitude profiles. |
| 78956 | Removed the Initial Orbit Determination, Least Squares, and Filter wizards. |
| 79525 |
The time tag bias and facility location partials for certain measurements models were incorrectly assuming that the satellite position internally was always in the J2000 frame when it could be in the ICRF frame (depending on the setting of the scenario level parameter SuppressICRF). However, the difference between the two frames is small enough that it does not materially affect the calculation of the partial. The affected measurement models are Declination, Right Ascension, Delta Declination, Delta Right Ascension, Direction Cosine, Face Horizontal, and Face Vertical. A similar issue was found with the Direction cosine measurement model when calculating the computed direction cosine. It was incorrectly assuming the internal satellite state was in J2000. The difference is small enough that we do not believe it has a significant impact on the end user. These issues are corrected. A workaround for an older release is to set the Scenario level SuppressICRF to True to force the computations in ODTK to be done in J2000. |
| 79654 | The GPSCatalog.txt file was updated to reflect the operational status of SVN 67 as PRN 06. |
| 79829 | The AGI Downloads section has been removed from the ODTK built-in LaunchPad utility. You can access and download ODTK resources from www.agi.com/resources. |
| 79862 | ODTK now includes support for RINEX 3.02 files using 3rd party open source GPSTk 2.4 library (Apr. 2014). |
| 79920 | The way that ODTK associates TrackerIDs with RINEX MARKER NUMBER records has changed when the RINEX MARKER NUMBER record contains an IERS DOMES number. The normal behavior is that ODTK reads the RINEX MARKER NUMBER record until a non-numeric value is encountered. This limits DOMES numbers to associate with five-digit TrackerIDs because the sixth character is usually an "S" or "M" followed by three more digits. The new behavior converts the sixth character to a zero, allowing association with nine-digit TrackerIDs by default. The change allows co-located receivers having unique DOMES numbers to also have unique TrackingID associations by default. |
| 80088 | The option to consider exceeding the maximum iteration limit in least squares estimation as success has been added. This allows for least squares restart records and ephemeris prediction to be performed when the maximum number of iterations are exceeded. |
| 80283 | Exact alignment of space-based GPS receiver clock epochs and the epoch of their host satellite initial state is no longer required to allow for simulator or filter execution. The allowed time difference is now controlled by the existing maximum number of orbit periods allowed for the epoch alignment setting on the simulator and filter objects. |
| 80285 | Rename of the GPS objects (GPS Constellation, GPS Receiver, and GPS Satellite to GNSS Constellation, GNSS Receiver, and GNSS Satellite. Backwards compatibility is supported for pre-6.4 scenarios, but scripts need to be updated manually to use the new names. |
| 80419 | ODTK.Application.GenerateNavSolution() and GNSSReceiver.SiteSolution() functions now have an additional (last) argument which takes in a string with name of GNSS Constellation ("GPS,"GALILEO," "GLONASS," "BeiDou") that will limit algorithm to use only obs originated from GNSS satellites that belong to said constellation. | 80507 | The truncated versions of the GRAIL derived lunar gravity models (GL0420A and GL0660B) have been replaced with complete versions of the models. |
| 80523 | The StateFile_To_SP3.html utility is now able to generate *.clk files that contain solutions for Satellite Clock Bias values at higher frequency than standard SP3 files. |
| 80938 | ODTK now exposes the size of the internal LookAheadBuffer used for sorting observation in the time order. This will help to process measurement files where observation appears out of time order on the large scale. |
| 80939 | The ability to construct and process Differenced One Way Doppler (DOWD) measurements has been added. DOWD measurements are constructed by differencing two simultaneous one way Doppler (3L Doppler) measurements taken from a single user satellite through two TDRS satellites. |
| 81086 | The IAgAsDragModelResultEval interface used in support of the drag model plugin point has been extended to expose additional properties related to the atmosphere including the atmospheric density, temperature, pressure, and mean molecular mass. While the density will always be available, the other atmosphere related properties are only currently supported when an MSIS atmospheric density model is selected. |
| 81135 | A new license ODGNSS is added to ODTK. License hierarchy is the following: ODGNSS > ODMSS > ODSNGL. Once ODTK has checked for the ODGNSS license it will not check for other license. With the ODGNSS license, you can estimate multiple GNSS and non-GNSS satellites. |
| 81347 | A new setting for the measurement statistics of GNSS phase measurements has been added (ClockNoiseScaling) to account for uncertain clock behavior during the cycle count interval. This new setting is primarily useful for the processing of simulated observations where the clock behavior is known, as opposed to, real data processing where the clock behavior is discovered through the measurements. |
| 81533 | The use of GPS Constellation source file start and end buffers has been created. Setting the start buffer to a small amount (1 second) now allows you to avoid error messages when GPS tracking data simulation is performed; where the simulation start time is the same as the start time of a specified SP3 file. |
| 81878 | GNSSConstellation.SVError.SVDefaultCovSource enumeration options have been updated to remove "GPS" from their names: GPSCatalogFile and GPSConstellationObject now became "CatalogFile" and "ConstellationObject." |