**Consolidated Laser Ranging Prediction Format (V0.97)**

R. Ricklefs

The University of Texas at Ausin/ Center for Space Research

ricklefs@csr.utexas.edu

for the ILRS Prediction Format Study Group

of the ILRS Data Format and Procedures Workling Group

7 September 2004

**Abstract**

The International Laser Ranging Service (ILRS) Predictions Formats Study
Group was created at the 12th International Workshop on Laser Ranging
and tasked with creating a consolidated laser ranging prediction format
that could accurately predict positions and ranges for a much wider
variety of laser ranging targets than had been previously possible.
While several complications arise in creating and implementing a format
for such divergent targets, the opportunities for ranging exotic targets
from ordinary ranging stations should compensate for any inconveniences.

**Introduction**

The satellite laser ranging (SLR) community of about 40 laser ranging
stations has used the standard \"Tuned IRV\" prediction format for up to
20 years. This format consists of a satellite state vector (x,y,and z
positions and velocities at a given time plus other parameters, one set
per day per satellite) tuned to specific field integrator software and
gravity field to provide maximum accuracy over the integration period.
The format can be found at:
ftp://cddisa.gsfc.nasa.gov/pub/formats/tirv.format.

The ranging stations in the lunar laser ranging (LLR) community (2
stations routinely gathering data, at least 3 others lunar-capable, and
3 several retired) have historically either developed their own
prediction software or have ported others\'. The software has used one
of about 3 lunar and planetary ephemeris packages, each containing a
multi-year ephemeris.

Thus, the SLR community has generally used standard integrator software
and gravity field models with predictions supplied on a weekly or (now)
daily basis. The lunar community has used a standard multi-year
ephemeris, a mix of interpolation software, and weekly earth orientation
parameter predictions.

Lunar ranging has been restricted to a few stations due in large part to
the low return signal strengths involved. The distance to the moon (R),
combined with the 1/R^4^ scaling of the return signal strength to that
transmitted, means only a few photo-electrons per minute are seen by
current ranging systems using available technology.

This state of affairs has existed since the 1970s. There are now,
however, the possibility of several new missions that could change
everything. For instance, CRL would like to put a laser transponder on
the moon. Groups at NASA are proposing transponders combined with
altimeters for future planetary and asteroid missions. Transponders have
a laser transmitter at both ends of the ranging link. The receive signal
strength therefore is proportional to 1/R^2^ times the transmit energy.
Because of this, the downlink energy is high enough for most existing
SLR stations (including SLR2000) to detect. This implies that there must
soon be prediction procedures and formats in place for the moon, other
solar system bodies, and transponders in transit.

This document represents the results of an effort to combine the
prediction requirements of these various ranging techniques into a
single laser ranging prediction format. The format presented is
preliminary and will undoubtedly undergo some adjustments before it
reaches the ranging stations.

**Format Features**

1.  No Euclidean Space Assumptions

> The range to the environs of the moon and beyond cannot be simply
> calculated from the square root of the sum of the squares of the
> reflector\'s topocentric x, y, and z coordinates. The movement of the
> earth and moon during the approximately 2.5 second round trip is large
> enough that the range must be computed as the sum of the iteratively
> determined lengths of the outbound and inbound legs. Because of the
> distances and masses involved, there is also a non-negligible
> relativistic correction. The difference between the true range and the
> Euclidean distance gives a range error for the moon of a few to
> hundreds of microseconds. Omitting the relativistic correction causes
> a range error of about 50 nsec. Stellar aberration effects on pointing
> need to be considered since the aberration is a second or two of arc
> at the moon, 30 or more arcseconds for Mars and asteroids, and
> possibly more for close in spacecraft in transmit.
>
> The orbits of the moon and other major solar system objects can not be
> integrated easily on site as those for small earth satellites can.
> However, one can readily interpolate tables of geocentric coordinates
> for these and the other laser targets. The tabular format also
> benefits lower earth satellite ranging by removing the need to tune
> the predictions to a particular integrator. In addition, other
> non-integrable functions such as the drag can be included with a
> tabular format.

2.  Multiple records

> The tabular format will need to include at least x, y, z and a
> corresponding time for each ephemeris entry. This and other
> specialized information will be spread over several records, the
> number and type depending on target class. The time between each entry
> will normally be constant and will be small enough to meet any
> reasonable precision requirements using the supplied interpolation
> software. The time should be large enough to avoid excessive file
> size. Typical values are 1 minute for low earth satellites, 15 minutes
> at the moon, and hours to a day for the planets. See the section
> **Interpolator Definition** below for more information.
>
> Record pairs like position 10, direction 1 and 2, and corrections 30,
> directions 1 and 2 should be treated as sets. For a transponder or any
> other target for which the time between entries is less than the
> round-trip light time, records 10 directions 1 and 2, etc. must be
> grouped so that the fire and receive legs are right after each other.
> In other the words the records are not in strict time order. See the
> transponder example in Appendix B.

3.  Variable entry spacing

> To accomodate high eccentricity satellites like LRE, variable entry
> spacing is a possibility that is allowed for in the format and the
> recommended interpolator.

4.  Line length limits and method of transmission

> The length of each prediction record will normally be less than 80
> character to allow for easy email transmission without line wrap or
> truncation. \"Deep space\" targets may require position records longer
> than this. No mode of distribution is assumed, so email, ftp, and scp
> should be useable.

5.  Free format read, fixed format write

> Due to the large dynamic range in the target positions and velocities,
> the non-header data should be read in free format. The prediction
> providers should write with a fixed format so that all fields line up
> for a given satellite. Doing so will allow easy visual reading of the
> files for debugging. White space between fields removes ambiguity of
> field boundary from visual software reading.
>
> The format in appendix A show width and significant digits for each
> field. For the free format records, this represents typical width for
> planning purposes.

6.  True body fixed system of date and earth rotation parameters

> The coordinate system used in the TIRV's is pseudo-body-fixed. The new
> format is usually presented in the true-body-fixed of date system. In
> this reference system, the earth's pole positions have been included
> in the predicted positions. Earth Orientation Parameters (EOP's),
> x-pole and y-pole, were included in the TIRV files to allow rotation
> from pseudo-body-fixed to true-body-fixed system to be computed at the
> individual ranging stations. This was done when prediction sets were
> often created up to a year in advance for use in ranging systems at
> remote locations. Since fresh EOP's are now easily available to the
> prediction suppliers and since the predictions are usually supplied
> daily via the internet, there is no need to apply the EOP information
> on site, nor to back out values that may have been used in the
> predictions. In addition, the excess length of day was rarely used at
> the ranging stations. Earth orientation information will only be
> supplied in the case of predictions that are presented in the inertial
> (space-fixed) reference system.

7.  Multiple days per file

> As with current IRVs, the prediction file for a particular satellite
> will contain several days worth of data. This should help
> interpolating over day boundaries, which could otherwise cause
> problems. Header records appears only once per file.

8.  Integration past end of file

> Current IRVs permit integration well past the epoch of the last IRV in
> a prediction set. This benefits stations that are cut off from a
> supply of IRVs for a moderate period of time. The predictions show
> steadily increasing runoff, but can still allow data to be taken,
> especially with higher satellites. In addition, it is also possible to
> extend the integrations several months into the future for the purpose
> of scheduling. The latter use has fairly low accuracy requirements. It
> should be possible for the site to integrate the last state vector in
> a prediction file for some time into the future. (Targets on or
> orbitting the moon and planets can not be handled in this way.)
> Software could be written to convert the last state vector into a TIV
> file, which then could be input to the existing scheduling software.
> This will not help with other targets, however, and the lack of tuning
> in the CPF state vectors will reduce the accuracy of the
> extrapolation. Given that the extrapolation is only used for
> scheduling, this should not be a serious problem.

9.  Elimination of drag message

> Since the drag information can be built into the tabular state
> vectors, there should be no need for separate drag messages. Drag
> could not be easily incorporated into tuned IRVs.

10. Compression

> Common compression software such as compress, gnu zip, and others
> could reduce the files size. If file size is still too onerous, it is
> possible to create smart compression software based on numerical
> difference between successive file entries as is done with RINEX data.

11. File naming conventions

> While there appears to be a wide range of file naming conventions
> used, the following is suggested for the new prediction format, based
> on conventions used on the ILRS and prediction center websites:
>
> aaa_cpf_yymmdd\[\_n\].bbb
>
> where
>
> aaa is the satellite name, any reasonable number of characters;
>
> \"cpf\" is a literal indicating the new prediction format;
>
> yy is 2-digit year;
>
> mm is 2 digit-month;
>
> dd is 2-digit day of month;
>
> n is optional and refers to the sequential number of predictions set
> for this date, starting with 0; and
>
> bbb is the prediction center identifier, any reasonable number of
> characters.

**Format Field Comments**

1.  SIC, NORAD and COSPAR ID\'s

> SIC, COSPAR, and NORAD IDs will be included in the prediction headers
> as a convenient cross reference.

2.  Estimated accuracy

> These records give an estimate of the expected accuracy (peak-to-peak)
> at certain points during the day. This will be based on the experience
> of the prediction provider. The intention is to use this information
> to suggest or automatically set a station\'s range gate. This will be
> especially valuable to automated stations so that excessive time is
> not spent in searching for an optimal range gate and tracking
> settings.

3.  Leap second

> Application of leap seconds has always been a source of some
> confusion. In the new format, each ephemeris record contains a leap
> second value. In prediction files spanning the date of a leap second,
> those records having leap second applied will have this flag set to
> the number of leap seconds (always \'1\' so far, but standards allow
> for -1). In other words, a 3-day file starting the day before a leap
> second is introduced will have the leap second flag set to \'0\' for
> the first 24 hour segment and \'1\' in the last 48 hours. If the leap
> second is not applied by the supplier, then the flag is \'0\' for all
> records.
>
> Predictions starting at 0 hours immediately after the leap second has
> been introduced will have the leap second flag set to \'0\'.

4.  Position and velocity fields

> The signs of corresponding elements in the outgoing and incoming
> positions fields will have opposite signs. The same is true with the
> velocities.

5.  Correction fields

> As noted above, several complications arise in predicting ranges and
> point angles of solar system targets. These are essentially relativity
> and aberration. The aberration can be broken into light-time
> aberration which applies to all targets and stellar aberration which
> applies to those targets (such as moon and planets) which are computed
> from solar system ephemerides. Near-earth artificial satellites are
> usually computed in the geocentric system and do not require the
> so-called stellar aberration. Light time aberration is already applied
> implicitly in the state vectors supplied in the new format. Stellar
> aberration corrections are applied in computing point angles on site,
> while the relativistic corrections are applied to the ranges. ESAA, pp
> 127-130.
>
> The in-bound and out-bound relativistic corrections are due to
> geodesic curvature. The time-scale correction converts a solar system
> barycentric range (elapsed time) into an elapsed time which would be
> observed at a station. This correction can be 200 m for a round trip
> range to Mars and is necessary because the vectors are computed in the
> solar system barycentric frame using a solar system ephemeris. The
> former is included in the format while the later is site-dependent and
> is computed in the sample on-site code. See ESAA.
>
> If there are outgoing and incoming correction records, the
> corresponding aberration and relativity fields will have opposite
> signs. If there is only one correction record, it will be the \'30\'
> record with direction = \'1\', and the software will have to sense
> this and compute the incoming aberration values as negative of
> outgoing ones. For point angle computations, the aberration values are
> added to the corresponding velocity values, and the result is
> converted to topocentric coordinates.
>
> The relativistic corrections are both positive, scalar values. These
> are added to the range based on the vector distances calculated from
> the outgoing and incoming positions. Again, if there is only one
> correction record, the relativistic correction will need to be doubled
> for the round trip range to be correct. An additional 0.27 nsec can be
> added to the round-trip range as an earth-moon geodesic curvature
> correction. The resulting range with relativistic corrections is then
> scaled from proper to coordinate time.

6.  Lunar fields

> Lunar predictions may include lunar features for offset pointing.
> These features do not have SIC or COSPAR IDs since they are not
> ranging targets. The ID for these objects will be given bogus IDs,
> perhaps negative numbers. A list of targets, names, and IDs will be
> supplied.
>
> The libration vector (Euler angles φ,θ,ψ) and Greenwich apparent solar
> time are available in the \"rotation angles \"record type 60 for the
> center of the moon file (SIC = 0099). This allows a station to compute
> point angles to any arbitrary lunar surface feature whose
> selenocentric coordinates they supply. Stations without arcsecond
> level pointing accuracy may need this as a basis for offset pointing
> to the reflectors. Ranges computed in this way will not be accurate
> enough for ranging.
>
> To determine the pointing angle, the center of moon to center of earth
> vector is translated to the laser station coordinates using light time
> iteration. The aberration corrections are then added to this vector.
> The new aberrated body fixed coordinates are then rotated through the
> negative of the Greenwich apparent sidereal time. To this is added the
> result of creating the libration matrix from the rotation vector of
> (φ,θ,ψ ) (Skip Newhall, private correspondence; see sample code) and
> premultiplying it by the station coordinate vector (x,y,z). This gives
> the inertial coordinates of the lunar feature. This vector is then
> rotated through the Greenwich apparent sidereal time to give the body
> fixed station to feature vector of date vector, which can then be
> converted to RA/Dec, then HA/Dec, and then azimuth/elevation. If the
> lunar positions and velocities are supplied in inertial coodinates
> (reference frame = 1), the first rotation, through -GAST, is unneeded.

7.  Transponder fields

> Transponders can either be synchronous or asynchronous. Synchronous
> transponders fire when a laser pulse has been received from a ground
> station. The delay between receiving and transmitting the return pulse
> must be accounted for in both the prediction and data flow.
> Asynchronous transponders fire continuously for some period of time,
> as does the ground station. Both the spacecraft and ground station
> record transmit and receive time based on a local clock, which must be
> tied with an offset and rate to a master clock.
>
> Transponders need various time, frequency and range rate fields in the
> format. With the exception of the oscillator relativity correction,
> these are slowly changing with time, so they can be included in the
> data header records. (Alternatively, some quantities could be
> distributed in separate files.) These fields are as follows.

-   Pulse Repetition Frequency (PRF) - 1x10^-5^ to 1x10^6^ Hz

```{=html}
<!-- -->
```
-   Asynchronous transponders only.

```{=html}
<!-- -->
```
-   Transponder transmit delay - 10sec to 1 msec

```{=html}
<!-- -->
```
-   Synchronous transponders: delay between receive and fire

```{=html}
<!-- -->
```
-   Asynchronous transponders: delay between fire command and fire

```{=html}
<!-- -->
```
-   Transponder UTC offset - 10 nsec to 1 second

```{=html}
<!-- -->
```
-   Asynchronous transponders only

```{=html}
<!-- -->
```
-   Oscillator Frequency Drift - 1 part in 10^12^ -10^15^/day

```{=html}
<!-- -->
```
-   Asynchronous Transponders orbitting a solar system body

```{=html}
<!-- -->
```
-   Corrects for the drift of the satellite\'s on-board oscillator.

```{=html}
<!-- -->
```
-   Relativity Correction to Satellite Oscillator Time Scale for 1 Way
    Range Rates - 1.5m/sec - 1cm/sec (5 nsec/sec - 0.03 nsec/sec)

```{=html}
<!-- -->
```
-   Asynchronous Transponder orbitting a solar system body

```{=html}
<!-- -->
```
-   Corrects for range rate change due to satellite orbitting in a
    different gravitational field.

```{=html}
<!-- -->
```
-   Range rate is also needed to an estimated accuracy of 15 cm/sec, but
    this is computable from positions and/or velocities given a small
    enough time between vectors (5-10 sec).

> As with lunar ranging, it may be necessary to compute point angles and
> range based on rotation angles of a planet or moon. While it is
> convenient and very accurate to use Euler angles for the moon, the
> universal system adopted by the IAU/IAG/COSPAR Working Group on
> Cartographic Coordinates and Rotational Elements of the Planets and
> Satellites uses the right ascension and declination of the body\'s
> pole as well as the position of the body\'s prime meridian (a~0~,
> d~0~, and W ). See Davies or the ESAA for more details. These
> quantities also have a place in the new prediction format as do x, y,
> and z offsets from the center of the main body (e.g., a planet).

**Interpolator Definition**

The baseline for interpolation of the new format predictions will be an
8 point Lagrange interpolation scheme that allows for variably spaced
grid point times. A suggested interpolator has been written to accompany
the new format. Recent investigations of study group members show the
following record spacing to be reasonable, using position (X, Y, and Z)
only. Note that the MGS (Mars Global Surveyor) results are identical
with the step size of the Integration of the satellite\'s orbit. If the
target had been on Mars, the interval would have been much larger.

Satellite Interval (min)

Degree 7 Degree 9

(8 point) (10 point)

CHAMP (LEO) 2 3

GFO-1 3 4

TOPEX 4 5

LAGEOS 5 10

GPS 15 30

Moon 30 60

MGS at Mars - 0.3

It is anticipated that the ranging stations will use a variety of
interpolation schemes, preferrably Lagrange. (Splines are strongly
discouraged.) However, the baseline is the 8 point Lagrange
interpolation and a maximum error due to production and interpolation of
the predicted ephemeris of less than 1 nsec in range. Any alternate
interpolation scheme must provide 1 nsec agreement using a grid no
narrower than the above. Interpolation must always be done in Cartesian
(X, Y, Z) space and not in range/point angles for acceptable accuracy.
The interpolation time must be between the middle 2 points of the
interpolation series for maximum accuracy (i.e., between the 4^th^ and
5^th^ points of an 8 point interpolator). See Abramowitz and Stegun for
details.

**Sample code**

Sample station implementation code incorporating the new interpolator is
being developed and will be supplied in FORTRAN and C. This computer
software handles the computation of topocentric ranging predictions
rigorously, meaning that it can be used for artificial satellites near
or distant, the moon, and other solar system bodies.

**Constants**

The speed of light used by both prediction centers and stations should
be the IERS Convention 20003 standard of 299792458 m/sec. Site
coordinates should be in the International Terrestrial Reference Frame
(ITRF). Although JPL's DE-403 ephemeris is not, the differences are not
significant for predictions and normalpoint formation. Lunar reflector
coordinates are usually supplied by the creators of the ephemeris and
are the result of fitting the ranging data. For example, there is one
set of coordinates that one should use with the JPL DE-403 ephemeris,
but which may not provide as good results with DE-405 or the MIT PEP
ephemeris.

**Conclusion**

The requirements established for this study group for improved
prediction accuracy and inclusion of exotic targets is met through the
ILRS tabular prediction format. The new format covers 4 different target
types in one prediction format and sample software set. It opens up
opportunities for most stations to range a wider variety of targets and
will naturally solve several difficulties in current SLR predictions.
The format will come at the expense of some software retooling and
larger file transfers. It will, however, provide a flexible platform for
laser ranging predictions into the foreseeable future.

**Study Group**

This format is the result of combined efforts by the study group
members:

-   R. Ricklefs, chair, University of Texas/McDonald Observatory, and
    CSR

-   J. McGarry, co-chair, NASA/Goddard Space Flight Center

-   G. Appleby, NERC Space Geodesy Facility

-   G. Bianco, Agenzia Spaziale Italiano

-   C. Clarke, Honeywell Technology Solutions, Inc.

-   R. Eanes, University of Texas, Center for Space Research

-   W. Gurtner, Astronomical Institute University of Bern

-   J. Horvath, Honeywell Technology Solutions, Inc.

-   J. Luck, Electro Optic Systems

-   D. McClure, Honeywell Technology Solutions, Inc.

-   C. Moore, Electro Optic Systems

-   J. Mueller, University of Hannover

-   D. Rowlands, NASA/Goddard Space Flight Center

-   U. Schreiber, Technical University of Munich

-   R. Wood, NERC Space Geodesy Facility

-   W. Wu, Yunnan Observatory, Chinese Academy of Sciences

-   T. Yoshino, Communications Research Laboratory

**References**

Abramowitz, M. And Stegun, I. A., [Handbook of Mathematical Functions
with Formulas, Graphs, and Mathematical Tables]{.underline}, National
Bureau of Standards, Washington, 1964, p. 878.

Davies, M. E., et al (1991) \"Report of the IAU/IAG/COSPAR Working Group
on Cartographic Coordinates and Rotational Elements of the Planets and
Satellites: 1991,\" Celestial Mechanics, 53, 377-397.

Seidelmann, P.K., ed. [Explanatory Supplement to the Astronomical
Almanac]{.underline}, University Science Books, Mill Valley, 1992.

Appendix A. Prediction Format Version 0.97

1\) Data headers

> Header type 1 Basic information - 1 (required)
>
> 1-2 A2 Record Type (= \"H1\")
>
> 4-6 A3 \"CPF\"
>
> 8-9 I2 Format Version
>
> 11-14 A4 Ephemeris Source (e.g., \"HTSI \", \"UTX \")
>
> 16-19 I4 Year of ephemeris production
>
> 21-22 I2 Month of ephemeris production
>
> 24-25 I2 Day of ephermeris production
>
> 27-28 I2 Hour of ephemeris production (UTC)
>
> 30-34 I5 Ephemeris Sequence number
>
> 36-45 A10 Notes (e.g., \"041202\",\"DE-403\")
>
> Header type 2 Basic information - 2 (required)
>
> 1-2 A2 Record Type (= \"H2\")
>
> 4-11 I8 COSPAR ID
>
> 13-16 I4 SIC
>
> 18-25 I8 NORAD ID
>
> 27-30 I4 Starting Year
>
> 32-33 I2 Starting Month
>
> 35-36 I2 Staring Day
>
> 38-39 I2 Starting Hour (UTC)
>
> 41-42 I2 Starting Minute (UTC)
>
> 44-45 I2 Starting Second (UTC)
>
> 47-50 I4 Ending Year
>
> 52-53 I2 Ending Month
>
> 55-56 I2 Ending Day
>
> 58-59 I2 Ending Hour (UTC)
>
> 61-62 I2 Ending Minute (UTC)
>
> 64-65 I2 Ending Second (UTC)
>
> 67-71 I5 Time between table entries (UTC seconds)(=0 if variable)
>
> 73 I1 Compatibility with TIVs = 1 (=\> integratable, geocentric
> ephemeris)
>
> 75 I1 Target type
>
> 1=passive artificial satellite
>
> 2=passive lunar reflector
>
> 3=synchronous transponder
>
> 4=asynchronous transponder
>
> 77-78 I2 Reference frame
>
> 0 =geocentric true body fixed (default)
>
> 1=geocentric space fixed (i.e. Inertial) (True of Date)
>
> 2=geocentric space fixed (Mean of Date J2000)
>
> 80 I1 Rotational angle type
>
> 0= Not Applicable
>
> 1= Lunar Euler angles: φ, θ, and ψ
>
> 2 = North pole Right Ascension and Declination, and angle to prime
> meridian (α~0~, δ~0~, and W)
>
> Header type 3 Expected accuracy
>
> 1-2 A2 Record Type(=\"H3\")
>
> 4-8 I5 Along-track run-off after 0 hours (meters)
>
> 10-14 I5 Cross-track run-off after 0 hours (meters)
>
> 16-20 I5 Radial run-off after 0 hours (meters)
>
> 22-26 I5 Along-track run-off after 6 hours (meters)
>
> 28-32 I5 Cross-track run-off after 6 hours (meters)
>
> 34-38 I5 Radial run-off after 6 hours (meters)
>
> 40-44 I5 Along-track run-off after 24 hours (meters)
>
> 46-50 I5 Cross-track run-off after 24 hours (meters)
>
> 52-56 I5 Radial run-off after 24 hours (meters)
>
> Header type 4 Transponder information
>
> 1-2 A2 Record Type (= \"H4\")
>
> 4-15 F12.5 Pulse Repetition Frequency (PRF) in Hz
>
> 17-26 F10.4 Transponder transmit delay in microseconds
>
> 28-38 F11.2 Transponder UTC offset in microseconds
>
> 40-50 F11.2 Tranponder Oscillator Drift in parts in 10^15^
>
> Header type 9 End of header (Last header record)
>
> 1-2 A2 Record Type (= \"H9\")

2)  Ephemeris entry (repeat as needed)

> NOTE: ALL fields MUST be separated by spaces, since these records are
> read free format. The field widths (e.g., I5, f12.5) are suggestions,
> and should be sized according to the target\'s needs.
>
> Record type 10 Position (transmit required for all targets; receive
> for distant targets and transponders. )
>
> 1-2 A2 Record Type (= \"10\")
>
> I1 Direction flag (transmit = 1; receive = 2)
>
> I5 Modified Julian Date (MJD)
>
> F13.6 Seconds of Day (UTC) (Transmit or receive)
>
> I2 Leap second flag (= 0 or the value of the new leap second)
>
> F17.3 Geocentric X position in meters
>
> F17.3 Geocentric Y position in meters
>
> F17.3 Geocentric Z position in meters
>
> Record type 20 Velocity (tranmit required for all targets; receive for
> distant targets and transponders)
>
> 1-2 A2 Record Type (= \"20\")
>
> I1 Direction flag (transmit = 1; receive = 2)
>
> F19.6 Geocentric X velocity in meters/second
>
> F19.6 Geocentric Y velocity in meters/second
>
> F19.6 Geocentric Z velocity in meters/second
>
> Record type 30 Corrections (All targets computed from a solar system
> ephemeris)
>
> 1-2 A2 Record Type (= \"30\")
>
> A1 Direction flag (transmit = 1; receive = 2)
>
> F18.6 X stellar aberration correction in meters
>
> F18.6 Y stellar aberration correction in meters
>
> F18.6 Z stellar aberration correction in meters
>
> F5.1 Relativistic range correction in nsec (positive number)
>
> Record type 40 Transponder specific (Transponders)
>
> 1-2 A1 Record Type (= \"40\")
>
> F6.3 Oscillator relativity correction in meters/second
>
> Record type 5 Offset from center of main body (Surface features and
> satellites)
>
> 1-2 A2 Record Type (= \"50\")
>
> I1 Direction flag (bounce=0; transmit = 1; receive = 2)
>
> I5 Modified Julian Date (MJD)
>
> f13.6 Seconds of Day (UTC)
>
> a10 Name of target (no spaces in middle)
>
> f17.3 X position offset in meters
>
> f17.3 Y position offset in meters
>
> f17.3 Z position offset in meters
>
> Record type 60 Rotation angle of offset (Surface features)
>
> (See Rotation Angle Type in header record 2.)
>
> 1-2 A2 Record Type (= \"60\")
>
> I5 Modified Julian Date (MJD)
>
> F13.6 Seconds of Day (UTC)
>
> F17.12 Rotation angle 1 in degrees (For moon: φ )
>
> F17.12 Rotation angle 2 in degrees (For moon: θ )
>
> F17.12 Rotation angle 3 in degrees (For moon: ψ)
>
> F17.12 Greenwich Apparent Sidereal Time in hours
>
> Record type 70 Earth orientation (For space-fixed mode,
>
> as needed, typically once a day)
>
> 1-2 A2 Record Type (= \"70\")
>
> I5 Modified Julian Date (MJD)
>
> I6 Seconds of Day (UTC)
>
> F8.5 X pole (arcseconds)
>
> F8.5 Y pole (arcseconds)
>
> F10.6 dUTC (seconds)
>
> Record type 99 Ephemeris Trailer (last record in ephemeris)
>
> 1-2 A2 Record Type (= \"99\")
>
> 3\) Comments
>
> 1-2 A2 Record Type (= \"00\")
>
> 3-80 A Free format comments

Appendix B - Sample Prediction Configurations

Note: the number after the hyphen in the typical configurations below
refer to the direction indicator, 1 for outbound, 2 for inbound.

**1. Most earth-orbitting artificial satellites**

A typical record configuration for most satellite is the following. Very
high satellites may benefit from the return leg position, record 12.

> H1 H2 H3 H9 10-1 10-1 10-1 \... 99

Example:

H1 CPF 01 UTX 2004 4 14 0 1 note

H2 7603901 1155 8820 2004 4 14 0 0 0 2004 4 15 0 0 0 60 1 1 0 0

H3 0 0 0 1 0 0 5 1 1

H9

10 1 53109 0.0 0 -1967933.511 8589721.713 -8528048.288

10 1 53109 60.0 0 -1818076.487 8835879.123 -8308987.294

10 1 53109 120.0 0 -1664722.064 9074010.401 -8083461.630

10 1 53109 180.0 0 -1508058.026 9303907.214 -7851648.543

10 1 53109 240.0 0 -1348276.392 9525369.235 -7613730.082

10 1 53109 300.0 0 -1185573.192 9738204.335 -7369892.949

10 1 53109 360.0 0 -1020148.237 9942228.760 -7120328.334

10 1 53109 420.0 0 -852204.905 10137267.286 -6865231.781

\...

99

**2. Lunar reflectors or distant earth satellites (beyond GPS, etc)**

For lunar reflectors, a typical sequence of records would be as follows.
Note that the \'32\' record is not really needed for the moon. The
aberration corrections are not needed unless the orbit is cormputed
relative to a solar system ephemeris, as the moon is.

> H1 H2 H3 H9 10-1 10-2 30-1 30-2 10-1 10-2 30-1 30-2 10-1 10-2 30-1
> 30-2 \... 99

Example:

H1 CPF 1 UTX 2004 8 15 0 1 jpl_de-403

H2 103 103 0 2004 8 15 0 0 0 2004 8 16 0 0 0 900 0 2 0 0

H3 0 0 0 1 0 0 5 1 1

H9

10 1 53232 0.0 0 -362786142.485 59990545.228 152815200.590

10 2 53232 0.0 0 362778404.086 -59986805.884 -152790318.761

30 1 9820. 35713. 9128. 25.8

10 1 53232 900.0 0 -358331953.237 82843971.704 152569272.444

10 2 53232 900.0 0 358324620.631 -82839783.181 -152544389.028

30 1 12070. 35024. 9164. 25.8

10 1 53232 1800.0 0 -352439337.910 105374409.819 152322569.282

10 2 53232 1800.0 0 352432436.162 -105369808.673 -152297684.282

30 1 14271. 34193. 9200. 25.8

10 1 53232 2700.0 0 -345131301.581 127491397.709 152075091.995

10 2 53232 2700.0 0 345124852.743 -127486421.820 -152050205.415

30 1 16416. 33224. 9235. 25.8

\...

99

For the center of the moon, the libration information needs to be
carried along.

> H1 H2 H3 H9 10-1 10-2 30-1 30-2 60 10-1 10-2 30-1 30-2 60 10-1 10-2
> 30-1 30-2 60 \... 90
>
> Example:
>
> H1 CPF 1 UTX 2004 8 15 0 1 jpl_de-403
>
> H2 99 99 0 2004 8 15 0 0 0 2004 8 16 0 0 0 900 0 2 0 1
>
> H3 0 0 0 1 0 0 5 1 1
>
> H9
>
> 10 1 53232 0.0 0 -364451976.619 60353106.303 152490438.335
>
> 10 2 53232 0.0 0 364444139.573 -60349677.212 -152465465.976
>
> 30 1 9820. 35713. 9128. 25.8
>
> 60 53232 0.0 -0.042278188066 0.387449359548 2952.323425637165 5.6
>
> 50461729274
>
> 10 1 53232 900.0 0 -359971209.607 83311513.516 152243440.204
>
> 10 2 53232 900.0 0 359963759.425 -83307628.423 -152218466.246
>
> 30 1 12070. 35024. 9164. 25.8
>
> 60 53232 900.0 -0.042277885694 0.387449864896 2952.325820966946 5.7
>
> 16090758825
>
> 10 1 53232 1800.0 0 -354045407.436 105945020.582 151995664.855
>
> 10 2 53232 1800.0 0 354038369.650 -105940714.887 -151970689.302
>
> 30 1 14271. 34193. 9200. 25.8
>
> 60 53232 1800.0 -0.042277578121 0.387450370753 2952.328216291734 5.7
>
> 81719788331
>
> \...
>
> 99

or (for inertial systems)

> H1 H2 H3 H9 10-1 10-2 30-1 30-2 50 60 10-1 10-2 30-1 30-2 50 60 10-1
> 10-2 30-1 30-2 50 60 \... 99

**3. Asynchronous Transponders**

A typical record sequence would be the folowing.

> H1 H2 H3 H4 H9 10-1 10-2 30-1 30-2 40 10-1 10-2 30-1 30-2 40 10-1 10-2
> 30-1 30-2 40\... 99

Example:

H1 CPF 1 GSFC 2004 03 30 1

H2 99999999 9999 99999999 2004 04 04 00 00 00 2004 04 04 05 00 00 10 0 4
0 0

H3 0 0 0 1 0 0 5 1 1

H4 1999.91715 273.1500 2004.93 15.30

H9

10 1 53098 84449.02096 -125015785900.315 -238593151366.328
113777817699.433

10 2 53099 0.00000 -157578821821.085 -218511517400.466 113800334257.752

20 1 -4900.351123 27002.440493 -11504.716991

20 2 -1033.856498 27424.269894 -11503.554375

30 1 14960874.918060 -6906109.317657 1955191.986389 19356.3

30 2 -13838706.981995 8961558.044586 -1956244.853897 19361.8

40 0.1000

10 1 53098 84459.01980 -125189460917.443 -238502228781.030
113777934456.549

10 2 53099 10.00000 -157737908754.342 -218396877560.796 113800451035.803

20 1 -4880.719560 27005.997166 -11504.711036

20 2 -1013.916777 27425.015665 -11503.548412

30 1 14955868.474579 -6917009.332855 1955188.391006 19356.3

30 2 -13832201.994965 8971645.220612 -1956241.253082 19361.8

40 0.1000

10 1 53098 84469.01863 -125363069927.043 -238411179620.121
113778051444.382

10 2 53099 20.00000 -157896912383.972 -218282121726.361 113800568044.534

20 1 -4861.085417 27009.539567 -11504.705081

20 2 -993.976518 27425.746937 -11503.542448

30 1 14950854.096252 -6927905.739502 1955184.780594 19356.3

30 2 -13825689.658722 8981727.696381 -1956237.637238 19361.9

40 0.1000

\...

99

**4. Synchronous Transponders**

A typical record sequence would be:

> H1 H2 H3 H4 H9 10-1 10-2 30-1 30-2 10-1 10-2 30-1 30-2 10-1 10-2 30-1
> 30-2 \... 99
>
> Example:

H1 CPF 1 GSFC 2004 03 30 1

H2 99999999 9999 99999999 2004 04 04 00 00 00 2004 04 04 05 00 00 10 0 3
0 0

H3 0 0 0 1 0 0 5 1 1

H4 0.00000 273.1500 0.00 0.00

H9

10 1 53098 84449.02096 -125015785900.315 -238593151366.328
113777817699.433

10 2 53099 0.00000 -157578821821.085 -218511517400.466 113800334257.752

20 1 -4900.351123 27002.440493 -11504.716991

20 2 -1033.856498 27424.269894 -11503.554375

30 1 14960874.918060 -6906109.317657 1955191.986389 19356.3

30 2 -13838706.981995 8961558.044586 -1956244.853897 19361.8

10 1 53098 84459.01980 -125189460917.443 -238502228781.030
113777934456.549

10 2 53099 10.00000 -157737908754.342 -218396877560.796 113800451035.803

20 1 -4880.719560 27005.997166 -11504.711036

20 2 -1013.916777 27425.015665 -11503.548412

30 1 14955868.474579 -6917009.332855 1955188.391006 19356.3

30 2 -13832201.994965 8971645.220612 -1956241.253082 19361.8

10 1 53098 84469.01863 -125363069927.043 -238411179620.121
113778051444.382

10 2 53099 20.00000 -157896912383.972 -218282121726.361 113800568044.534

20 1 -4861.085417 27009.539567 -11504.705081

20 2 -993.976518 27425.746937 -11503.542448

30 1 14950854.096252 -6927905.739502 1955184.780594 19356.3

30 2 -13825689.658722 8981727.696381 -1956237.637238 19361.9

\...

99

Appendix C - Prediction Processing Requirements and Suggestions -
Prediction Producers

1)  Don\'t tune the state vectors.

2)  Include drag, time bias, and earth orientation parameters (EOP).
    Re-issue low satellite predictions when drag gets stale, perhaps
    several times a day.

3)  When interpolated with an 8 point Lagrange interpolator, a CPF file
    must duplicate the output of the prediction model to ± 0.5
    nanoseconds in range. See **Interpolator Definition** above.

4)  Accuracy: See **Estimated Accuracy** above.

5)  Fill all fields in the records you write. Headers are fixed format.
    Body records are free format (after the 2 digit record
    identification) with spaces between fields. For a specific target,
    the fields in the body records should line up, for easy reading by
    humans.

6)  Time on prediction is fire time for outleg and return time for
    backleg. These are kept in one file with the outleg/backleg doubles
    remaining together in fire time order.

7)  Backleg is required for the moon and beyond, and can be helpful for
    high satellites.

8)  Vector elements have opposite signs on outleg and backleg records.
    Relativistic corrections are always positive and additive.

Appendix D - Prediction Requirement and Suggestions - Prediction Users

Cookbook

1)  Read predictions

2)  Decide how to handle (See aAppendix B for sample configuraions.)

```{=html}
<!-- -->
```
1.  Single cartesian coordinate record per time, for most of slr targets

2.  Dual cartesian coordinate records per time, for very high satellite,
    the moon, and beyond.

3.  Dual cartesian coordinate records per time and echo transponder
    delay

4.  Dual cartesian coordinate records per time and async transponder
    fields

```{=html}
<!-- -->
```
3)  Rotate body-fixed vector into inertial space. Make whatever
    simplifications that are desired (like ignoring dUT1) but be sure to
    so the same when rotating back.

4)  Interpolate to desired time

5)  Apply rotion angles or add in body-centric coordinates of any
    features (for reflectors, transponders on another solar system
    body).

6)  apply along-, cross-track and radial corrections

7)  Rotate back to body-fixed system

8)  Translate to topocenteric coordinates (using light time iteration)

9)  Convert to point angles and range (using included aberration
    corrections, and refraction corrections using your favorite model).

General comments

1)  Interpolate in Cartesian coordinates (body-fixed or inertial) and
    not in point angles and range, for acceptable precision. The results
    from interpolating in point angle and range can be quite poor,
    especially for normalpoint creation. If you need to interpolate in
    point angle and range, interpolate in Cartesian coordinates before
    hand to produce a very fine mesh. In the latter case, it is best not
    to use spline interpolation.

2)  Interpolated time must between the 4^th^ and 5^th^ points in an 8
    point interpolator, or precision will be degraded.

3)  Due to rule 2), the interpolator needs order/2 extra records at the
    beginning and end of a pass to maintain full prediction accuracy.
    The sample interpolator will stop if there are not enough records
    centered on the time of interpolation.

4)  Do not assume that the prediction file starts at 0 hours UTC.

5)  It is a good practice to read all fields in as ascii strings before
    converting to integers or floating point. With added checks, this
    will prevent software crashes when misformed or blank fields are
    encountered.