Ephemeris File Format (*.e)
An ephemeris file is an ASCII text file formatted for compatibility with STK that ends in a .e extension. Ephemeris files can be useful when you need to provide STK with position and velocity data for a vehicle to model certain unique circumstances. Vehicle ephemeris is a Basic property of all vehicles in STK. If you have ephemeris data, organized in a properly formatted table, in any ephemeris file, you can import it into STK using the STK External propagator.
STK uses ephemeris data to generate the position and velocity of a vehicle at whatever time values needed to support analysis and animation. When necessary, STK will interpolate between points to do, in the same coordinate frame (inertial or fixed) as the data frame.
STK ephemeris files adhere to the following conventions:
- The reference coordinate frame is specified using the
CentralBody,CoordinateSystem, andCoordinateSystemEpochkeywords. - In Julian Dates format, you can enter dates in scientific notation.
- STK-imported ephemeris files for orbiting objects are expected to have at least 90 points per complete revolution around the central body.
The first step in creating an external ephemeris file is to understand what type of ephemeris data you need. Before starting to create a file, you should ask yourself the following questions:
- How is the data formatted?
- Is it in Cartesian X, Y, Z coordinates; geodetic latitude, longitude, and altitude; or geocentric latitude, longitude, and radius?
- What coordinate system is the data in? Is it in an inertial frame? If so, which inertial frame is it? Is it a fixed frame?
Once you know the answers to these questions, you can use keywords recognized by STK to create a table that describes the position and velocity of the vehicle.
Keywords
Each ephemeris table, regardless of the type of ephemeris data in the table, contains some common elements called keywords. Keywords and their associated values must precede the specification of the ephemeris format and the actual data points.
The keywords used in ephemeris tables are not case sensitive and do not have to conform to the case scheme utilized here.
| Keyword | Required | Description |
|---|---|---|
| stk.v.<major release number>.<minor release number> | Yes |
This is the version of STK software associated with the file formatting. You can create files in this format and import them into any STK software version at this level or higher. The version stamp must be the first line in the file. Example: stk.v.11.0 A file created in and stamped with this version could be imported into STK software version 11.0 through the most recent version. |
| MessageLevel | No |
You can set this value to determine the level of message(s) you receive from STK as it attempts to read the file. The value options are:
|
| BEGIN Ephemeris END Ephemeris |
Yes | These set off the beginning and end of the ephemeris table, including all other keyword phrases and data point specification (except the version stamp). Refer to any of the sample files included in the Ephemeris Format section for examples. |
| ScenarioEpoch | No |
This is the reference epoch time for the time values of the ephemeris data in the table, where the times are represented as seconds since it's a reference epoch. Specify the scenario epoch using Gregorian UTC time ( The default is the actual scenario epoch in the STK scenario. Example:
In this case, a time of |
| CentralBody | No |
This is the central body that the ephemeris points are relative to. The keyword value that completes the phrase can be the name of any registered central body. You can find registered central bodies in the
The default is the central body for the vehicle, and that default is Earth. Example:
|
| SmoothData | No |
Including this declares that the files contain smooth data. Smoothness of data impacts sampling characteristics of STK calculations such as Access, calculation components, lighting times, etc. Non-smooth data is sampled judiciously around each time at which sharp changes may occur. Without a TrendingControl section or SmoothData keyword, STK determines smoothness of ephemeris data based on vehicle and propagator types. STK assumes that ground vehicle, ship, and aircraft objects, as well as any object with a file that declares interpolation to be based on a great arc type, have non-smooth data. Otherwise, it assumes the data to be smooth. Use the SmoothData keyword only if the TrendingControl Section does not specify a time listing. If no TrendingControl section is specified, the Smooth Data setting specifies the smoothness of the data. Valid values are Yes, No, True, False, On, and Off. The default is No. Keyword History The SmoothData keyword, with Yes and No values, was introduced in STK 10.1.0. Additional values (True, On ,False, and Off) for this keyword were introduced in STK 11.2.0. |
|
End TrendingControl |
No |
These keywords mark the beginning and end of the TrendingControl section. STK will sample the data in this section when determining trends for event detection. For example, a drastic change in motion may indicate an event (especially if the change is brief). The TrendingControl section can include either the TrendingControlTimes subsection or the TrendingControlStep. Keyword History The TrendingControl keywords were introduced in STK 11.6.0. |
|
End TrendingControlTimes |
No |
You can include a TrendingControlTimes section in the file if you do not use the TrendingControlStep keyword. This section contains a list of times (one time per line) that should be sampled for determining trends for event detection. If a TimeFormat keyword precedes this section, then this section must adhere to the format. Otherwise, the times are in seconds since the ScenarioEpoch is specified in the file. Keyword History The TrendingControlTimes keywords were introduced in STK 11.6.0. |
| TrendingControlStep | No |
You can include the TrendingControlStep keyword in the file if the TrendingControlTimes section is not used. The keyword specifies the step size, in seconds, that STK will use when sampling times in the file. STK will select samples as far apart as possible without exceeding the step size. Controlling the step size is most useful when the sample times in a file are dense. STK will sample at a lower density than the file's data, but the points will still be close enough to detect drastic changes in motion. Keyword History The TrendingControlStep keyword was introduced in STK 11.6.0. |
| CoordinateSystem | No |
AGI recommends specifying this; is the coordinate system in which the ephemeris points reside. Normally, the coordinate system is the name of a valid coordinate system for the central body specified above (see Central Body Coordinate Systems). Typically, each central body supports Fixed, J2000, ICRF, Inertial, TrueOfDate, and MeanOfDate, though certain bodies support additional systems. You can also define a new system using the Vector Geometry Tool (VGT). You can then specify the name of your new system and the name of the STK object to which it corresponds.The VGT-created system must use the keyword CoordinateSystem AWB. CoordinateSystem AWB replaces CoordinateSystem Custom as the required keyword for VGT-created systems. STK still supports the CoordinateSystem Custom keyword for backward compatibility. The default is Fixed. Examples:
Keyword History The CoordinateSystem Custom keyword was replaced with the CoordinateSystem AWB keyword in 11.5.0. The CoordinateSystem AWB keyword was introduced in 11.5.0. |
| ComputeVelocity | No |
The manner in which Cartesian velocity is computed from the Cartesian position generated from the position data in the file if rate information is not provided directly by the file. The default value is DerivativeOfInterpolatingPolynominal. Other values are:
|
| CoordinateSystemEpoch | See Note | This is the epoch time for the coordinate system in Gregorian UTC time (dd mmm yyyy hh:mm:ss.s).It is required with coordinate systems that reference an Epoch:
Example: CoordinateSystemEpoch 1 Jun 2003 12:00:00.0 |
| DistanceUnit | No |
Set the distance unit for all distance measurements in the ephemeris table. By default, STK assumes that all distance measurements in an ephemeris table are in meters and velocities are in meters/second. You can override this by setting the distance unit to be any valid STK distance unit. To see a list of all available units of measure, open the Units page of the Scenario's Basic properties by double-clicking the scenario in the Object Browser and selecting the Units page. The default for velocity is meters per second. The default for the ephemeris table is meters. Example:
|
| BlockingFactor | No |
This specifies how much memory (in terms of sets of ephemeris points) STK will allocate at a time while reading an ephemeris file. When reading large files, this can speed up the loading process by avoiding re-allocating small chunks of memory. |
| InterpolationMethod | No |
The method by which STK interpolates between ephemeris points. Valid values are:
The default is Lagrange. Examples:
Keyword History The TwoBodyBlending, J2Blending, J4Blending, and Aviator values for this keyword were introduced in 11.0. However, these four methods do not produce valid results, so AGI strongly recommends not using them. |
| InterpolationOrder | No |
This keyword has been deprecated and replaced with InterpolationSamplesM1; it has the same format and function as its replacement. |
| InterpolationSamplesM1 | No |
This is one less than the number of points used in the interpolation. For the Lagrange interpolation method, this is also the interpolation order. For the Hermitian interpolation method, the interpolation order is: The default is 5. Example:
|
| NumberOfEphemerisPoints | No |
AGI recommends specifying this to indicate the maximum number of ephemeris points to read from the file. When not specified, STK will use all ephemeris points in the file. Prior to STK 11.5, this keyword was required. Example: If you enter
STK will read up to 1000 ephemeris points. |
| NumberOfCovariancePoints | No |
AGI recommends specifying this to indicate the maximum number of covariance points to read from the file. When not specified, STK will read all covariance points in the file. Example:
STK will read up to 1000 covariance points. |
| CovarianceInterpolationMethod | No |
You can specify the method for interpolating covariance that contains both position and velocity terms. Valid values are None and TwoBodyQuadraticArithmeticBlending. The default is TwoBodyQuadraticArithmeticBlending for Satellites and None for other vehicles. TwoBodyQuadraticArithmeticBlending refers to the weighted average (with weights based on a quadratic in time polynomial) of the covariance matrices computed using two-body covariance propagation from the previous and next time samples. This is only appropriate for objects with motion dominated by two-body motion (i.e., satellites orbiting a central body). Keyword History The CovarianceInterpolationMethod keyword was introduced in STK version 11.0.0. |
| CovarianceFormat | No |
This specifies the portion of the covariance matrix that will appear in the
If you specify
If you specify
The default for CovarianceTimePos is UpperTriangular; the default for CovarianceTimePosVel is LowerTriangular. |
| StateErrorTransitionReferenceEpoch |
Not Required Default is ScenarioEpoch |
State-error transition matrices provide a linear mapping of state deviations from this time to the time of the data point. Example: StateErrorTransitionReferenceEpoch 1 Jan 2003 00:00:00.0 |
| CovarianceCoordinateSystem | No |
When you specify this keyword, STK interprets the covariance as being in either a special ephemeris-based local frame (indicated below) or the axes of the specified CoordinateSystem. When not specified, STK interprets the covariance as being in the same frame as the ephemeris (i.e., expressed in the axes associated with the CoordinateSystem). |
| CovarianceCoordinateSystemEpoch | No | The epoch time for the covariance coordinate system in Gregorian UTC time (dd mm yyy hh:mm:ss.s). You must specify this with coordinate systems that reference an Epoch:
Example: CovarianceCoordinateSystemEpoch 1 Jun 2020 12:00:00.0 |
| CovarianceProjRefCoordinateSystem | No |
This specifies the reference frame that observed the covariance matrix before its transformation into the frame specified by CovarianceCoordinateSystem, where the transformation ignored the effects of the angular velocity of CovarianceCoordinateSystem. Valid values are Inertial or Fixed. This keyword is only needed when velocity components of the covariance matrix are present and the values were created in their frame without fully accounting for the angular velocity of the frame. For example, the value should be set to Fixed when the covariance was computed in the Fixed frame. The value appears in the file using Body frame components (as specified by CovarianceCoordinateSystem) where the transformation from Fixed to Body ignored the angular velocity of the Body frame. Example CovarianceProjRefCoordinateSystem Fixed |
| CovarianceIncludeAngleVelInVelCovXfm | No |
This specifies whether the angular velocity of the frame should be included in the transformation of the covariance matrix's velocity components. Only use this when velocity components of the covariance matrix are present and CovarianceCoordinateSystem is not a local frame nor a VGT frame. Valid values: Yes, True, On, No, False, Off Default Value: Yes This setting is rarely needed. It supports situations in which the ephemeris is provided in an Inertial frame, but the covariance is provided in the Fixed frame. The angular velocity of the Fixed frame should be ignored in the Inertial-to-Fixed transformation. |
| BEGIN SegmentBoundaryTimes END SegmentBoundaryTimes |
No |
This sets off the beginning and end of a list of time values (relative to the time specified using the
Example: BEGIN SegmentBoundaryTimes 2.90998893289423e+003 7.61935679863377e+003 END SegmentBoundaryTimes |
| TimeFormat | No |
This defines the date format of time tags. If specified, each line of data in the file begins with a time in that date format; the rest of the data follows this date. Spaces are valid if the format allows (e.g., 1 Jan 2007 12:00:00.000). Quotes around time strings are invalid. The TimeFormat keyword is the time format abbreviation. For example, use EpSec for the Epoch Seconds format or JDate for the Julian Date format. For time format abbreviations, see DateTime Formats. Examples: TimeFormat DD/MM/YYYY TimeFormat GPSZ |
| TimeScale | No |
This indicates to STK that the times contained in the ephemeris and covariance sections should be interpreted as being in the TDB time scale, not TAI. If you use it, the value is TDB. Keyword History The TimeScale keyword was introduced in STK version 8.1.0. |
Local Frames
| Local Frame | Description |
|---|---|
| RIC | Radial Intrack Crosstrack frame with:
|
| NTC | Normal Tangential CrossTrack frame with:
|
| TNW |
Tangential Normal CrossTrack frame with:
|
| VNC | Velocity Normal CoNormal frame with:
|
When you use a local frame, you can specify the optional value IgnoreAngVel, indicating that the transformation from the ephmeris coordinate system's axes to the local frame should be performed without accounting for the angular velocity of the local frame itself. This is the appropriate setting if the covariance was determined in the same frame as the ephemeris, but then transformed into a local frame without accounting for the effect of the rotation of the local frame on the velocity components of the covariance matrix. If the covariance matrix only contains position components, the IgnoreAngVel setting has no effect.
Other options for specifying CovarianceCoordinateSystem are the same as those for CoordinateSystem.
When using VGT, you must specify a system, not axes, even though STK only uses the axes associated with a CoordinateSystem.
Be careful when using a VGT system (such as Body) that depends on an object's attitude, if that attitude can be modified after loading the ephemeris file. In that case, if the attitude changes, the covariance representing the uncertainty of the ephemeris will change, and it probably is not representative of the actual uncertainty of the ephemeris any longer. When using Body or other Systems that depend on attitude, AGI recommends that you set the attitude consistent with how the covariance was obtained and that you do not modify it.
Examples
CovarianceCoordinateSystem RIC IgnoreAngVel
CovarianceCoordinateSystem TrueOfDate
CovarianceCoordinateSystem AWB Body Satellite/MySatellite
Ephemeris Formats
While the sections above outline the basic format for an ephemeris table, the list below outline the formats used to specify actual data points in the ephemeris table. You must include the format keyword in the file on its own line, after the header keywords and before the actual data point array.
You must observe the following conventions when specifying data points in any format:
- Each line contains only one data point.
- The values on each line must be separated by at least one space.
- The lines must be listed in ascending order in time but do not have to be evenly spaced in time.
- You cannot have multiple points at the same time (except as described in the
SegmentBoundaryTimessection). - There must be at least as many points as specified by the
NumberOfEphemerisPointsandNumberOfCovariancePointskeywords.
To view information on a particular format, click 
that precedes the format name.
EphemerisTimePos Format
The EphemerisTimePos format is designed to import cartesian position, without velocity points, in the coordinate system specified using the CentralBody, CoordinateSystem, and CoordinateSystemEpoch keywords.
This format is commonly used for modeling ground, air, or other near-Earth objects when only position data is available.
Since no velocity data is supplied, STK automatically generates velocity data by creating the Lagrange interpolation function for the position, taking the analytical derivative of the interpolation function and evaluating it each time position data is available. The resulting velocity data is then stored along with the position data in the file. Velocity data obtained this way is not as desirable as having real velocity data in the file, but is sufficient when nothing else is available.
Individual data points following the EphemerisTimePos keyword look like this:
<TimeInSeconds> <X> <Y> <Z>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<X> <Y> <Z>
|
The vehicle position |
You must follow certain conventions when specifying data points.
By default, position values are in meters. Use the DistanceUnit keyword to change units of measure.
An ephemeris file for a launch vehicle MyLauncher that had ephemeris in a topocentric coordinate system for the launch site MyLaunchSite would be built using a custom coordinate system. In this case, the coordinate system Topocentric was built on the facility MyLaunchSite using the Vector Geometry Tool to combine the facility’s Center point and TopoCentric axes. The resulting file would look like this sample file.
Format History: The EphemerisTimePos format was introduced in STK 5.0.4.
EphemerisTimePosVel Format
The EphemerisTimePosVel format is designed to import cartesian position and velocity points in the coordinate system specified using the CentralBody, CoordinateSystem, and CoordinateSystemEpoch keywords.
Individual data points following the EphemerisTimePosVel keyword look like this:
<TimeInSeconds> <X> <Y> <Z> <xDot> <yDot> <zDot>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<X> <Y> <Z>
|
The vehicle position |
<xDot> <yDot> <zDot>
|
The vehicle velocity |
You must follow certain conventions must be followed when specifying data points.
By default, position values are in meters and velocities are in meters per second. Use the DistanceUnit keyword to change units of measure.
An ephemeris file for a satellite in a Molniya type orbit about the Earth using a fifth-order Lagrange interpolation with the ephemeris data itself expressed in J2000 coordinates, using the EphemerisTimePosVel format would look like this sample file. A similar satellite using True of Epoch coordinates and values in kilometers would look like this sample file.
An ephemeris file for a launch vehicle MyLauncher that had ephemeris in a topocentric coordinate system for the launch site MyLaunchSite would be built using a custom coordinate system. In this case, the coordinate system Topocentric was built on the facility MyLaunchSite using the Vector Geometry Tool to combine the facility’s Center point and TopoCentric axes. The resulting file would look like this sample file.
Sometimes the ephemeris that you are importing contains maneuvers or other events which are difficult to interpolate across. These times may be identified using a SegmentBoundaryTimes block within the ephemeris file. For example, an ephemeris file for a satellite that performed two maneuvers, one at 2909 seconds and one at 7619 seconds would look like this sample file.
EphemerisTimePosVelAcc Format
The EphemerisTimePosVelAcc format is designed to import cartesian position, velocity points, and acceleration values in the coordinate system specified using the CentralBody, CoordinateSystem, and CoordinateSystemEpoch keywords.
Individual data points following the EphemerisTimePosVelAcc keyword look like this:
<TimeInSeconds> <X> <Y> <Z> <xDot> <yDot> <zDot> <xDotDot> <yDotDot> <zDotDot>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<X> <Y> <Z>
|
The vehicle position |
<xDot> <yDot> <zDot>
|
The vehicle velocity |
<xDotDot> <yDotDot> <zDotDot>
|
The vehicle acceleration values |
You must follow certain conventions when specifying data points.
By default, position values are in meters, velocities are in meters per second, and acceleration values are in meters per second per second. Use the DistanceUnit keyword to change units of measure.
Here is an example of a LEO satellite with its ephemeris specified using the EphemerisTimePosVelAcc format.
Format History: The EphemerisTimePosVelAcc format was introduced in STK 7.0.0.
EphemerisLLATimePos Format
The EphemerisLLATimePos keyword is used to indicate that data points that follow are a vehicle's position in the fixed (to the central body) coordinate frame and specified using geodetic coordinates. This format is commonly used for modeling ground, air, or other near-Earth objects when only position data is available.
Since no velocity data is supplied, STK will automatically generate velocity data by creating the Lagrange interpolation function for the position, taking the analytical derivative of the interpolation function and evaluating it each time position data is available. The resulting velocity data is then stored along with the position data in the file. Velocity data obtained this way is not as desirable as having real velocity data in the file, but is sufficient when nothing else is available.
The InterpolationOrder keyword is often used in conjunction with this format to fine-tune the interpolator. When importing position data for an aircraft, you may want to set the interpolation order to one (resulting in linear interpolation) to avoid oscillations (often referred to as ringing) in the interpolated position when the input position data is very irregularly spaced in time. The ringing effect is most noticeable when the path of the aircraft changes direction.
Individual data points following the EphemerisLLATimePos keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Alt>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Alt>
|
The vehicle position defined by its geodetic latitude, longitude, and altitude in decimal degrees and meters respectively |
You must follow certain conventions when specifying data points.
An ephemeris file using the EphemerisLLATimePos format might look something like this sample file.
EphemerisLLATimePosVel Format
The EphemerisLLATimePosVel format is very similar to the EphemerisLLATimePos format, except that it also supplies the vehicle velocity. The data points that follow are a vehicle's position and velocity in the fixed (to the central body) coordinate frame specified in geodetic coordinates. This format is commonly used for modeling ground, air, or other near-Earth objects.
Irregularly spaced position data can result in oscillations.
Individual data points following the EphemerisLLATimePosVel keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Alt> <latDot> <lonDot> <altDot>
where
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Alt>
|
The vehicle position defined by its geodetic latitude, longitude, and altitude in decimal degrees and meters respectively |
<latDot> <lonDot> <altDot>
|
The vehicle velocity defined by the rate of change of the geodetic latitude, longitude, and altitude in decimal degrees/second and meters/second respectivel |
You must follow certain conventions when specifying data points.
An ephemeris file using the EphemerisLLATimePosVel format might look something like this sample file.
EphemerisMSLLLATimePos Format
The EphemerisMSLLLATimePos keyword is used to indicate that data points that follow are a vehicle's position in the fixed (to the central body) coordinate frame and specified using geodetic coordinates with respect to Mean Sea Level (MSL). This format is commonly used for modeling ground, air, or other near-Earth objects when only position data is available.
Since no velocity data is supplied, STK will automatically generate velocity data by creating the Lagrange interpolation function for the position, taking the analytical derivative of the interpolation function, and evaluating it each time position data is available. The resulting velocity data is then stored along with the position data in the file. Velocity data obtained this way is not as desirable as having real velocity data in the file, but is sufficient when nothing else is available.
The InterpolationOrder keyword is often used in conjunction with this format to fine-tune the interpolator. When importing position data for an aircraft, you may want to set the interpolation order to one (resulting in linear interpolation) to avoid oscillations (often referred to as ringing) in the interpolated position when the input position data is very irregularly spaced in time. The ringing effect is most noticeable when the path of the aircraft changes direction.
Individual data points following the EphemerisMSLLLATimePos keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Alt>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Alt>
|
The vehicle position defined by its geodetic latitude, longitude, and altitude in decimal degrees and meters respectively |
You must follow certain conventions when specifying data points.
Format History: The EphemerisMslLLATimePos format was introduced in STK 10.1.0.
EphemerisMSLLLATimePosVel Format
Irregularly spaced position data can result in oscillations.
The EphemerisMSLLLATimePosVel format is very similar to the EphemerisLLATimePos format, except that it also supplies the vehicle velocity and uses geodetic coordinates with respect to Mean Sea Level (MSL). The data points that follow are a vehicle's position and velocity in the fixed (to the central body) coordinate frame specified in geodetic coordinates. This format is commonly used for modeling ground, air, or other near-Earth objects.
Individual data points following the EphemerisLLATimePosVel keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Alt> <latDot> <lonDot> <altDot>
where
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Alt>
|
The vehicle position defined by its geodetic latitude, longitude, and altitude in decimal degrees and meters respectively |
<latDot> <lonDot> <altDot>
|
The vehicle velocity defined by the rate of change of the geodetic latitude, longitude, and altitude in decimal degrees/second and meters/second respectively |
You must follow certain conventions when specifying data points.
Format History. The EphemerisMslLLATimePosVel format was introduced in STK 10.1.0.
EphemerisTerrainLLATimePos Format
The EphemerisTerrainLLATimePos keyword is used to indicate that data points that follow are a vehicle's position in the fixed (to the central body) coordinate frame and specified using geodetic coordinates with respect to terrain. This format is commonly used for modeling ground, air, or other near-Earth objects when only position data is available.
Since no velocity data is supplied, STK will automatically generate velocity data by creating the Lagrange interpolation function for the position, taking the analytical derivative of the interpolation function and evaluating it each time position data is available. The resulting velocity data is then stored along with the position data in the file. Velocity data obtained this way is not as desirable as having real velocity data in the file, but is sufficient when nothing else is available.
The InterpolationOrder keyword is often used in conjunction with this format to fine-tune the interpolator. When importing position data for an aircraft, you may want to set the interpolation order to one (resulting in linear interpolation) to avoid oscillations (often referred to as ringing) in the interpolated position when the input position data is very irregularly spaced in time. The ringing effect is most noticeable when the path of the aircraft changes direction.
Individual data points following the EphemerisMSLLLATimePos keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Alt>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Alt>
|
The vehicle position defined by its geodetic latitude, longitude, and altitude in decimal degrees and meters respectively |
You must follow certain conventions when specifying data points.
Format History: The EphemerisTerrainLLATimePos format was introduced in STK 10.1.0.
EphemerisLLRTimePos Format
The EphemerisLLRTimePos format is similar to the EphemerisLLATimePos format, except for the following:
- Geocentric coordinates are used instead of geodetic coordinates.
- The radius values replace altitude values.
- The latitude is the geocentric latitude instead of the geodetic latitude.
Individual data points following the EphemerisLLRTimePos keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Rad>
where,
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Rad>
|
The vehicle position defined by its geocentric latitude, longitude and radius in decimal degrees and meters respectively |
You must follow certain conventions when specifying data points.
An ephemeris file using the EphemerisLLRTimePos format would then look like this sample file.
EphemerisLLRTimePosVel Format
The EphemerisLLRTimePosVel format is similar to the EphemerisLLATimePosVel format, except for the following:
- Geocentric coordinates are used instead of geodetic coordinates.
- The radius rate is used instead of the altitude rate.
- The latitude is the geocentric latitude instead of the geodetic latitude.
Individual data points following the EphemerisLLRTimePosVel keyword look like this:
<TimeInSeconds> <Lat> <Lon> <Rad> <latDot> <lonDot> <radDot>
where
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Lat> <Lon> <Alt>
|
The vehicle position defined by its geocentric latitude, longitude, and altitude in decimal degrees and meters respectively |
<latDot> <lonDot> <radDot>
|
The vehicle velocity defined by the rate of change of the geocentric latitude, longitude, and altitude in decimal degrees/second and meters/second respectively |
You must follow certain conventions when specifying data points.
An ephemeris file using the EphemerisLLRTimePosVel format might look something like this sample file.
EphemerisGeocentricLLATimePosVel Format
Often when you receive ephemeris data from another source, you may be unsure whether the latitude values are geodetic or geocentric. A general rule of thumb is to assume that if you have altitude data that the latitude is geodetic, in which case you should use the EphemerisLLATimePosVel format. If you have radius information, then assume the latitude is geocentric, so use the EphemerisLLRTimePosVel format.
In rare cases, you may have altitude data but latitude data that is geocentric. It is for this case that the EphemerisGeocentricLLATimePosVel format was designed. It is identical to the EphemerisLLATimePosVel format, except that it treats the latitude values as geocentric latitudes, not geodetic.
Format History: The EphemerisGeoCentricLLATimePosVel format was introduced in STK 10.0.0.
EphemerisGeocentricLLATimePos Format
Often when you receive ephemeris data from another source, you may be unsure whether the latitude values are geodetic or geocentric. A general rule of thumb is to assume that if you have altitude data that the latitude is geodetic, in which case you should use the EphemerisLLATimePos format. If you have radius information, then assume the latitude is geocentric, so use the EphemerisLLRTimePosVel format.
In rare cases, you may have altitude data, but the latitude data that is geocentric. It is for this case that the EphemerisGeocentricLLATimePosVel format was designed. It is identical to the EphemerisLLATimePosVel format, except that it treats the latitude values as geocentric latitudes, not geodetic.
EphemerisGeodeticLLRTimePos and EphemerisGeodeticLLRTimePosVel Format
These two formats are identical to their counterparts EphemerisLLRTimePos and EphemerisLLRTimePosVel except that latitude is treated as geodetic latitude rather than geocentric latitude.
CovarianceTimePos Format
The ephemeris file format enables you to supply covariance information in addition to position and velocity information. The CovarianceTimePos keyword is used in conjunction with one of the other ephemeris formats to indicate that data points that follow are the vehicle's position covariance in the same Cartesian coordinate system within which the ephemeris was defined. You can specify the number of covariance points using the NumberOfCovariancePoints keyword.
You must use this format in conjunction with one of the other ephemeris formats.
Typically the covariance information is obtained from an orbit determination tool as part of calculating the ephemeris for the vehicle. The position covariance matrix is a three-by-three matrix that looks like this:
Since it is diagonally symmetric, only six values are necessary to represent the matrix. You can provide the data in either lower-triangular or upper-triangular form, and you select this via the CovarianceFormat keyword. In the absence of that keyword, STK assumes the upper triangular form, to ensure backward compatibility. The data points following the keyword consist of a line per point where each line looks like the following if the upper triangular format is specified:
<Time in seconds> <CXX> <CXY> <CXZ> <CYY> <CYZ> <CZZ>
or like the following if the lower triangular format is specified:
<Time in seconds> <CXX> <CYX> <CYY> <CZX> <CZY> <CZZ>
where
<TimeInSeconds>
|
The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScenarioEpoch keyword |
<Cxx>
|
Value (in meters squared) of the corresponding element of the covariance matrix |
You must follow certain conventions when specifying data points.
An ephemeris file using the CovarianceTimePos format might look something like this sample file.
CovarianceTimePosVel Format
This format is the same as the CovarianceTimePos format, except that it gives a position/velocity covariance:
You must supply 21 matrix entries. The required unit for a matrix entry depends on whether it is a product of two positions (e.g., <x,y>), a position and a velocity (e.g., <xd,y>, <x,yd>) or two velocities (e.g., <xd,yd>):
| Entry Type | Required Unit |
|---|---|
<x,y>
|
meters^2 |
<xd,y>, <x,yd>
|
meters^2/sec |
<xd,yd>
|
(meters/sec)^2 |
If you set CovarianceFormat to LowerTriangular, data points appear as follows:
<Time in seconds> <Cx,x> <Cy,x> <Cy,y> <Cz,x> <Cz,y> <Cz,z> <Cxd,x>
<Cxd,y> <Cxd,z> <Cxd,xd> <Cyd,x> <Cyd,y> <Cyd,z> <Cyd,xd>
<Cyd,yd> <Czd,x> <Czd,y> <Czd,z> <Czd,xd> <Czd,yd> <Czd,zd>
If you set CovarianceFormat to UpperTriangular, data points appear as follows:
<Time in seconds> <Cx,x> <Cx,y> <Cx,z> <Cx,xd> <Cx,yd> <Cx,zd> <Cy,y>
<Cy,z> <Cy,xd> <Cy,yd> <Cy,zd> <Cz,z> <Cz,xd> <Cz,yd>
<Cz,zd> <Cxd,xd> <Cxd,yd> <Cxd,zd> <Cyd,yd> <Cyd,zd> <Czd,zd>
An ephemeris file using the CovarianceTimePosVel format might look something like this sample file.
StateErrorTransition Format
You must use this format in conjunction with one of the other ephemeris formats. It is possible to include an ephemeris format, a covariance format, and the state-error transition format in one file.
The ephemeris file format enables you to supply linear state-error transition matrix data in addition to position and velocity information. Use the StateErrorTransition keyword in conjunction with one of the other ephemeris formats to indicate that data points that follow are the state-error transition matrices in the same Cartesian coordinate system within which the ephemeris was defined. The number of state-error transition points is restricted to being the same as the number of ephemeris points and the times associated with the state-error transition matrices should be the same as the times associated with the ephemeris information.
The state-error transition matrices are defined to provide a linear mapping of small deviations in position and velocity. They are represented from the epoch specified via the StateErrorTransitionReferenceEpoch keyword to the time specified with the matrix. Both input and output state deviations would be expressed in the coordinate system specified for the ephemeris data. Typically, the linear state-error transition matrix is computed through the numerical integration of the variational equations during the numerical integration of the non-linear trajectory.
The data points following the keyword consist of a matrix per point. Each matrix looks like the following:
<Time in seconds> <PhiXX> <PhiXY> <PhiXZ> <PhiXXd> <PhiXYd> <PhiXZd>
<PhiYX> <PhiYY> <PhiYZ> <PhiYXd> <PhiYYd> <PhiYZd>
<PhiZX> <PhiZY> <PhiZZ> <PhiZXd> <PhiZYd> <PhiZZd>
<PhiXdX> <PhiXdY> <PhiXdZ> <PhiXdXd> <PhiXdYd> <PhiXdZd>
<PhiYdX> <PhiYdY> <PhiYdZ> <PhiYdXd> <PhiYdYd> <PhiYdZd>
<PhiZdX> <PhiZdY> <PhiZdZ> <PhiZdXd> <PhiZdYd> <PhiZdZd>
where
| Option | Description |
|---|---|
| TimeInSeconds | The time value of the point in seconds (in the format xxxx.xxx) relative to the epoch as defined by the ScnarioEpoch keyword |
| Phixy | Entry providing mapping of deviation in y coordinate at the reference epoch to the x component at the epoch indicated by TimeInSeconds |