Tracking data formats
There are a number of data formats supported by ODTK, and each one supports various sets of measurements. Depending on the file type, you can provide some measurements individually, such as range only. For other measurements, you must pair them, such as azimuth and elevation.
| Tracking Data Formats | ||||
|---|---|---|---|---|
| Format | Type | Source | Use | Measurements Supported |
| 2SOPS | binary | Air Force Space Command 2nd Space Operation Squadron RAW GPS tracking data; see Format for 2SOPS tracking data(.2SOPS) | Ground GPS data to support OD for GPS Constellation |
(in raw form):
Measurements from different GPS satellites at a given time can be combined to create other measurements:
|
| ACTRAC | text | ACTRAC format originated with Northrup Grumman's ACTRAC OD package | launch tracking |
|
| B3 | text | Air Force Space Command Document AFSPC 160-102, 11 March 1996; see B3 OBS Formats for the approximation to that format | space surveillance |
|
| CCSDS TDM | text | Consultative Committee for Space Data Systems (CCSDS) Tracking Data Message, based on RECOMMENDED STANDARD CCSDS 503.0-B-2, available at https://public.ccsds.org/Publications/AllPubs.aspx | generic tracking data |
As of version 7.9, ODTK implements the following data types:
TDRS measurement types are supported through a special TDRS version of TDM. ODTK translates the above TDM data types into a larger variety of ODTK measurement types as described in more detail here. The CCSDS TDM format is designed to support a large number of measurement types and to provide flexibility in how measurements are specified. Different providers of tracking data in the CCSDS TDM format have different standard practices in terms of what they include in their tracking data files. It is therefore advisable to examine TDM files from tracking data providers carefully to look for potential incompatibilities with processing software. The CCSDS TDM tracking data provider also has properties of its own that control certain aspects of its behavior. You can access the following settings via the Plugins tab of the Edit-Preferences dialog on the ODTK GUI. Click on “click to display” in the Config column of the row containing the CCSDS tracking data reader. The settings are: TwoWayRepresentation This applies to normal (non-DSN) range and Doppler measurements. ODTK supports an AGI-specific keyword TWO_WAY_REPRESENTATION to indicate whether the range and Doppler values are ONEWAY or TWOWAY. The TDM specification allows for either convention, but has no method for indicating which is in use. If the keyword exists in a file being read for observations, it is honored. If the keyword is not found, then this setting is used to determine the sense of the observation values. SectionByMeasType If set to true, then ODTK uses separate sections to store different measurement types during simulation. Exceptions are that ANGLE_1 and ANGLE_2 measurements are kept together and TRANSMIT_FREQ and TRANSMIT_FREQ_RATE measurements are kept together. LTDOffsetForSavingFreqRamps This applies to the simulation of DSN range and Doppler measurement types. These measurement types require transmit frequency information that covers the timespan of the observation plus a period of time prior to the first observation to account for the roundtrip light time delay. This setting allows the amount of time prior to the first observation that frequency information becomes available to be specified. For example, if a value of 3600 seconds is specified, then transmit frequency information will start one hour prior to the time tag of the first saved measurement. |
| COB | text | Air Force Satellite Control Network | AFSCN tracking |
|
| CRD | text |
Consolidated Laser Ranging Data Format (CRD) ODTK can process data in versions 1.00 and 2.01 formats R.L. Ricklefs, The University of Texas at Austin/Center for Space Research C.J. Moore, EOS Space Systems Pty Ltd. For the ILRS Data Formats and Procedures Working Group https://ilrs.gsfc.nasa.gov/data_and_products/formats/crd.html |
Laser ranging |
|
| DSN TRK 2-34 | binary | NASA/JPL Deep Space Network tracking data format TRK-2-34; documented in 820-013 Deep Space Mission System (DSMS) External Interface Specification JPL D-16765 | Deep space tracking |
|
| Ephemeris | text | See STK Ephemeris file format (*.e) When using *.e files as measurements, the file must be named *\TrkId(nnnn)*.e, where nnnn is the TrackingId of the associated satellite. |
analysis |
|
| Generic | binary | AGI for ODTK | stores any measurement in common internal format | Everything in ODTK |
| GEOLOC | text | Format for Geolocation Tracking Data File (.geoloc) | Geolocation Data |
|
| GEOSC | text | The AGI extension of the generic GEOSC format | multiple civilian programs | as used in ODTK:
Support of Space-based Right Ascension/Declination is an addition specific to ODTK. Native GEOSC does not support space-based angles or range. The GEOSC format has been extended to allow the specification of the True Equator Mean Equinox of Date (TEME) reference frame as the coordinate system for RA/Dec measurements. The reference frame is specified by putting a 2 in column 34 and a 3 in column 35 of the ground based RA/Dec record (type 10) and or the space based RA/Dec record (type 12). If the coordinate system is set in the GEOSC record, it cannot be overridden from the ODTK Object Properties window. |
| ILRS | text | International Laser Ranging Service's Fullrate format version 2 (formerly MERIT II), as specified here. | laser ranging |
Normal points can be used if read as "NPRange". |
| ITC Ephemeris | text | JSpOC SP ephemeris (*.itc) format. The trackingID is taken to be the SSC Number on the *.itc. |
analysis | .Eph Pos .Eph Vel |
| MDP | binary | NGA GPS monitoring station format | GPS Data to support OD for GPS Constellation |
CA Pseudo-range P1 Pseudo-range P1 Pseudo-range LA Phase L1 Phase L2 Phase Measurements from different GPS satellites at a given time can be combined to create other measurements: DF Pseudo-range (dual frequency, combines P1 and P2) DF Phase (dual frequency, combines L1 and L2) SD DF Pseudo-range SD DF Phase |
| MPC | text |
Minor Planet Center format - optical observations in support of detection and tracking of near-Earth objects; see the Minor Planet Center website https://minorplanetcenter.net/iau/info/OpticalObs.html for a description of the format Tracking IDs for trackers and targets are text strings and therefore require the use of the ODTK alias system to map scenario objects to the textual IDs in the file. It is common for astronomers who contribute data in Minor Planet Center format to use different identification strings to refer to the same artificial satellite. This will require that you add each of those strings as an alias for the satellite object. As another option, you could use the tracking data plugin settings for the MPC file type to override all of the satellite ID designations from files in the MPC format and set the satellite ID to your own string. To do this, go to the Edit menu, select Preferences, and go to the Plugins page. Locate the MPC tracking data loader and click the Config settings. You can use these same settings to eliminate observations having insufficient precision in the time tag. The time of day is represented in decimal days, and observations in the MPC format nominally have days to a precision of five to six digits past the decimal. Some observers may supply time tags that are significantly less precise, which can adversely affect orbit determination results. |
Amatuer astronomer observations |
Right Ascension Declination |
| NAVSOL | text | Navigation Solution tracking file | GPS Data | Single and dual frequency GPS navigation solutions |
| OpNav | text | Optical Navigation tracking data file with this format | Optical observations |
These are optical observations of the following possible types:
Data is in the form of Right Ascension and Declination, with additional possible Range data for the Limb type. |
| RINEX | text |
Receiver Independent Exchange Format; see GNSS Measurement Types ODTK supports only a subset of RINEX 3 and RINEX 4 tracking types as measurements. ODTK does not support the Indian NacIC/IRNSS GNSS system. ODTK only partially supports the Chinese BeiDou and Russian GLONASS GNSS systems. |
GNSS data |
ODTK supports the following RINEX versions: RINEX 2.10 RINEX 2.11 RINEX 2.12 (QZSS extension) RINEX 2.20 RINEX 3.01 (QZSS extension) RINEX 3.02 RINEX 3.03 RINEX 3.04 RINEX 3.05 RINEX 4.0 RINEX format definitions are at: https://www.igs.org/formats-and-standards/ For input, ODTK recognizes and determines processing from the version number in the RINEX Observation file header. For output, ODTK uses the version specified in the RINEX Measurement Plugin Config parameter. Edit->Preferences->Plugins->Config->Output Version Parameter Alternatively, you can set the windows environmental variable AGI_ODTK_RINEX2_FORMAT=2.12 |
| UTDF | binary | NASA's Tracking and Acquisition Handbook for the STDN (450-TAH-STDN), October 1994 | various civilian programs | The data that ODTK uses are the following:
Measurement times are represented by the year followed by the number of seconds into the year in UTC. By convention, the computation of the number of seconds into year ignores the existence of leap seconds occuring between the beginning of the year and the time of the measurement. |
Troposphere and ionosphere delay settings
Some formats, such as the GEOSC format, include flags to indicate whether or not the data has been corrected (for processing purposes). In other words, if whoever generated the tracking data file has already removed the effects of troposphere or ionosphere, they would set the flag indicating the measurements have been corrected.
Our generic simulation format also keeps track of these flags. From a simulation point of view, if troposphere or ionosphere is not included for a measurement, the flag is set to indicate the measurements have been corrected, or that the measurements do not contain unmodeled biases. If troposphere or ionosphere is enabled, then the flags are set indicating that the measurements do contain those effects.
When the filter processes measurements, if the tracking data flags are set to indicate that corrections have been made for ionosphere or troposphere already, then the user settings for modeling those effects are ignored. However, if the tracking data does contain unmodeled biases, you need to make sure you model those effects if desired. Thus you have the choice to model or not model troposphere.
The exceptions to this discussion are the GPS CA, P1 and P2 pseudorange and phase measurements. The modeling of these effects is controlled entirely by user settings.
In the GEOSC format, a flag value of 0 means the data has been corrected and a value of 1 means the data contains the effects of troposphere/ionosphere. The flags appear in column 33 for ionospheric correction and column 34 for tropospheric correction.
If you want to simulate measurements and then be able to toggle on and off troposphere modeling and see the effects in the residuals, then simulate measurements with troposphere enabled, producing a flag of 1 in the tracking data file. Then when filtering, you can toggle the troposphere enabled flag and see the effects in the residuals.
Tracking IDs
Satellite, facility, and receiver tracking IDs are nominally connected to ODTK by matching the integer tracking IDs contained within the measurement records to the tracking ID parameter in the scenario satellite, facility, and receiver objects. There are a couple of exceptions:
- The CCSDS TDM format uses alphanumeric IDs to identify the tracking objects. AliasMapping is required to correlate the alphanumeric tracking ID to the integer tracking ID in the applicable objects. Reference the MeasurementProcessing -> TrackingIDAlias property in the object white panels. Also reference the Tracking ID Alias.
- When processing STK Ephemeris as measurements, the satellite ID is derived from the data set name, which must be of the form *TRKID(nnnn)*.e, where nnnn is the (1 to 9 digit) tracking ID. For more description, see section 2 of the tutorial "
- When processing RINEX measurements, the optional MARKER NUMBER record in the header record nominally defines the receiver ID. However, if the MARKER NUMBER record is not present, then the receiver ID is derived from the data set name, which is of the form SATnnnn_*, where nnnn is the (1 to 9 digit) receiver ID. For more description, see section 2.2.3 of the tutorial
- When processing MDP formatted files, the GNSS receiver ID is derived from the file name, which must be of the form TRKID(nnnn)*.mdp, where nnnn is some string of digits (1-9) that matches the GNSS receiver tracking ID for the facility that the measurements belong to.
Tracking data formats
The available tracking data formats in ODTK are: