**Consolidated Laser Ranging Prediction Format**

**Version 1.00**

R. L. 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

28 November 2005

**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://cddis.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
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 is the result of an effort to combine the prediction
requirements of these various ranging techniques into a single laser
ranging prediction format. The format presented is the standard for
laser ranging as of mid-2006. It will undoubtedly undergo some changes
ove the years as we gain experience with some of the more exotic
targets.

**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 transit.
>
> The orbits of the moon and other major solar system objects can not be
> integrated easily on site in the way artificial 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 drag and orbital maneuvres 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 altitude and 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 or longer 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 follow each other in the
> file. In other the words the records are not in strict time order. See
> the transponder example in Appendix B.

3.  Variable entry spacing

> To accommodate high eccentricity satellites like LRE, variable entry
> spacing is a possibility that is permitted in the format and the
> sample interpolator.

4.  Line length limits and method of transmission

> The file headers have a maximum length at this time of 82 characters.
> \"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 (at least one space) is required
> between fields to clearly separate them.
>
> 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. (We
> also use the term International Terrestrial Reference Frame -- ITRF).
> 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 distribution practices, 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 and maneuvre messages

> 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.
>
> Maneuvres will also be built into the CPF files. Therefore, maneuvre
> messages will only be needed to warn stations of the event.

10. Compression

> Common compression software such as compress, gnu zip, and others
> could be used to reduce the CPF files sizes for distribution. Thus
> far, the files have been of a manageable size and have not required
> compression even with email distribution.

11. File naming conventions

> While there appears to be a wide range of file naming conventions
> used, the following is required for the new prediction format:
>
> satellite_cpf_yymmdd_nnnv.src
>
> where the fields are as follows:
>
> \- satellite:

-   Official satellite name (See table in Appendix C.)

-   hyphens are allowed, but no blank spaces

-   variable length, maximum 10 characters

> \- nnn:

-   ephemeris version number. This is day of year + 500 to distinguish
    CPFs from TIVs in time bias and other messages. The "500" can be
    dropped when TIVs are discontinued. This field is three digits with
    zero leading fill.

> \- v:

-   version within the day. This is one digit, starting with \'1\'.

> \- src:

-   prediction provider code, 3 characters long.

**Format Field Comments**

1.  SIC, NORAD and COSPAR ID\'s and satellite name

> SIC, COSPAR, and NORAD IDs and satellite name will be included in the
> prediction headers as a convenient cross reference. Satellite names
> should be taken from the standard list in Appendix C.

2.  Center of mass to reflector offset

> The position vectors of spherical satellites always refer to the
> satellite\'s center of mass. An optional record H5 can indicate the
> range correction from the center of mass to the refector reference
> radius. If H5 is given the stations can correct the interpolated
> two-way range station-satellite station from the center of mass to the
> reflectors by subtracting twice this correction.
>
> Position vectors of non-spherical, attitude-controlled satellites can
> either be given for the center of mass (center of mass correction flag
> in header record H2 set to \'0\') or the reflector reference point
> (correction flag set to \'1\'). As the stations usually do not know
> the attitude of the satellites no action is required in either case.
>
> As GNSS satellites (GPS, GLONASS, Galileo) are seen from the Earth\'s
> surface within a small angle only, reflector corrections could be
> given as an approximate radial correction in header record H5 if the
> given positions refer to the center of mass.

3.  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.

4.  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 after the leap second 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.
>
> Even though the flag is non-zero, the leap second is not applied to
> the cpf times or positions. The station software needs to detect the
> leap second flag and handle the time argument to the interpolater
> appropriately.
>
> Prediction files starting at 0 hours immediately after the leap second
> has been introduced will have the leap second flag set to \'0\'.
>
> Normally, the leap second field will be set to \'0\'.

5.  Position and velocity fields

> Artificial earth satellites will not include light time iteration
> corrections. These 10-0 records give the position vector corresponding
> to the same (common) epoch at the geocenter and satellite. For any CPF
> computed using a solar systme ephemeris (e.g. DE-403), the 10-1 and
> 10-2 recors are used and contain the light time iteration. For these
> the vector spans fire time at the geocenter to bounce time at the
> target(10-1) and from boune time to return time at the geocenter
> (10-2).
>
> The signs of corresponding elements in the outgoing and incoming
> positions fields will have opposite signs. The same is true with the
> velocities.

6.  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
> geodesic correction is included in the format while the time-scale
> correction 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 must sense this and
> set 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. (Aberration must not be added to the position
> as part of the range computation!)
>
> 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. 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.

7.  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 (some station-dependent corrections have been left
> out).
>
> To determine the pointing angles using the lunar euler angles, 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 ranging station to feature vector of date, 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.

8.  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 a
10 point (9^th^ order) Lagrange interpolation algorithm that allows for
variably spaced record times. A sample 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 could use a variety of
interpolation schemes, preferrably Lagrange. (Splines are strongly
discouraged.) However, the baseline is the 10 point Lagrange
interpolation and a maximum error due to production and interpolation of
the predicted ephemeris of less than 1 nsec in range. To be
conservative, prediction providers should use the intervals above for
the 8 point interpolation. 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 5^th^ and 6^th^ points of a 10 point
interpolator). See Abramowitz and Stegun for details.

**Sample code**

Sample station implementation code incorporating the new interpolator
has been developed and will be supplied in FORTRAN and C. This computer
software handles the computation of topocentric ranging predictions
rigorously for artificial satellites near or distant, the moon, and
other solar system bodies. Targets computed from a geocentric ephemeris
and those computed using a solar system barycentric ephemeris (moon,
planets, satellites of either) must be handled differently, but the
software package will call those routines necessary based on target. See
appendix D for more details.

**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.

**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 1.00

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
>
> 12-14 A3 Ephemeris Source (e.g., \"HON\", \"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)
>
> 31-34 I4 Ephemeris Sequence number
>
> 36-45 A10 Target name (e.g. lageos1)
>
> 47-56 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 (retro-reflector) artificial satellite
>
> 2=passive (retro-reflector) 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)
>
> 82 I1 Center of mass correction
>
> 0= None applied. Prediction is for center of mass of target
>
> 1= Applied. Prediction is for retro-reflector array
>
> 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 5 Spherical satellite center of mass correction
>
> 1-2 A2 Record Type (= \"H5\")
>
> 4-10 F7.4 Approximate center of mass to reflector offset in meters
> (always positive)
>
> 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 (common epoch^\*^ = 0; 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 (transmit required for all targets; receive
> for distant targets and transponders)
>
> 1-2 A2 Record Type (= \"20\")
>
> I1 Direction flag (common epoch^\*^ = 0;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 (common epoch^\*^ = 0;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 50 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 UT1-UTC (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
>
> ^\*^ Common epoch: instantaneous vector between geocenter and target,
> without light-time iteration.

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-0 10-0 10-0 \... 99

Mandatory records: H1, H2, H9, 10-0, 99.

Example:

H1 CPF 1 AIU 2005 11 16 4 8201 gps35

H2 9305401 3535 22779 2005 11 15 23 59 47 2005 11 20 23 29 47 900 1 1 0
0 0

H9

10 0 53689 86387.000000 0 -13785362.868 -12150743.695 19043830.747

10 0 53690 887.000000 0 -13656536.158 -14288496.731 17628980.237

10 0 53690 1787.000000 0 -13618594.073 -16250413.260 15908160.431

10 0 53690 2687.000000 0 -13647177.924 -18001187.561 13911910.138

10 0 53690 3587.000000 0 -13712868.344 -19511986.614 11675401.577

10 0 53690 4487.000000 0 -13782475.931 -20761369.576 9237779.852

\...

99

**2. Lunar reflectors**

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

Mandatory records: H1, H2, H9, 10-1, 10-2, 30-1, 99.

Example:

H1 CPF 1 UTX 2005 11 16 14 8201 apollo15 jpl_de-403

H2 103 103 0 2005 11 17 0 0 0 2005 11 21 23 45 0 900 0 2 0 0 0

H9

10 1 53691 0.0 0 343226579.261 46543054.740 166061912.378

10 2 53691 0.0 0 -343237287.411 -46403753.013 -166044491.398

30 1 -7566. 36724. 5545. 25.5

10 1 53691 900.0 0 345427390.701 24820813.890 166269371.365

10 2 53691 900.0 0 -345429119.195 -24681112.863 -166251952.876

30 1 -5221. 37124. 5504. 25.5

10 1 53691 1800.0 0 346255366.913 3006463.995 166475893.820

10 2 53691 1800.0 0 -346248108.749 -2866942.040 -166458477.824

30 1 -2855. 37375. 5463. 25.5

\...

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

Mandatory records: H1, H2, H9, 10-1, 10-2, 30-1, 60, 99.

> Example:
>
> H1 CPF 1 UTX 2005 11 16 14 8201 luncenter jpl_de-403
>
> H2 99 99 0 2005 11 17 0 0 0 2005 11 21 23 45 0 900 0 2 0 1 0
>
> H9
>
> 10 1 53691 0.0 0 344918986.877 46883148.021 165882903.645
>
> 10 2 53691 0.0 0 -344929799.893 -46742993.132 -165865415.671
>
> 30 1 -7566. 36724. 5545. 25.5
>
> 60 53691 0.0 -0.762524039740 21.927815073381 242.085911540111
> 3.743252931977
>
> 10 1 53691 900.0 0 347138025.698 25052846.263 166090930.914
>
> 10 2 53691 900.0 0 -347139804.259 -24912287.206 -166073445.455
>
> 30 1 -5221. 37124. 5504. 25.5
>
> 60 53691 900.0 -0.762477162557 21.927762020202 242.223125654342
> 3.993937427448
>
> 10 1 53691 1800.0 0 347977335.938 3129493.252 166298018.604
>
> 10 2 53691 1800.0 0 -347970072.850 -2989111.915 -166280535.662
>
> 30 1 -2855. 37375. 5463. 25.5
>
> 60 53691 1800.0 -0.762430689795 21.927708977647 242.360340162630
> 4.244621923024
>
> \...
>
> 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

Mandatory records: H1, H2, H4, H9, 10-1, 10-2, 30-1, 30-2, 40, 99.

Example:

H1 CPF 1 GSC 2004 03 30 12 901 lro

H2 99999999 9999 99999999 2004 04 04 00 00 00 2004 04 04 05 00 00 10 0 4
0 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

Mandatory records: H1, H2, H4, H9, 10-1, 10-2, 30-1, 30-2, 99.

> Example:

H1 CPF 1 GSC 2004 03 30 12 901 xponder1

H2 99999999 9999 99999999 2004 04 04 00 00 00 2004 04 04 05 00 00 10 0 3
0 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 - How to Create Consolidated Prediction Format Files: A
> Cookbook
>
> At the Laser Workshop in Eastbourne in October, 2005 the ILRS
> Governing Board set the goal of converting all stations from the Tuned
> Inter-range Vectors (TIVs) to the new Consolidated Predictions Format
> (CPF) by June 31, 2006. All prediction centers are expected to start
> providing the CDDIS and EDC with CPF files on a routine basis by the
> end of 2005. This conversion is the culmination of 5 years of work by
> the ILRS Prediction Format Study Group. The new format promises to
> provide better prediction accuracy for artificial satellites,
> especially LEOs, as well as providing a common system that will
> include lunar retro-reflectors and transponders in lunar orbit and
> beyond.
>
> This short document summarizes the main requirements for producing CPF
> files. There is a more complete and extensive document that discusses
> philosophy and format details. It can be found at the addresses listed
> in the **Resources** section.

**SLR Predictions (Non-transponders)**

1)  CPF predictions are tabulated satellites state vectors in the
    geocentric earth-fixed coordinate system of date known as ITRF
    (International Terrestrial Reference Frame).

2)  The state vectors are generated from predicted orbits based on the
    best possible force models (gravity field, air drag, solar pressure,
    \...) and predicted earth rotation parameters. No tuning is
    performed.

3)  CPF files are generated at least on a daily basis, containing a data
    span of five days. The prediction center should re-issue prediction
    files for low satellites several times per day, if necessary.

4)  When interpolated with an 10 point Lagrange interpolator, a CPF file
    must duplicate the output of the prediction orbit to ± 0.5
    nanoseconds in range. Separations of tabular records for various
    altitudes of satellites are included below.

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 at least 1 space between fields. For a specific
    target, the fields in the body records should line up, for easy
    reading by humans.

6)  Required records: Headers H1, H2, and H9. Header H3 is optional.
    Header H4 is for use with spherical satellites only. Data record 10
    with direction \'0\' (instantaneous vector between geocenter and
    satellite at fire time) and 99 are required. None of the rest
    pertain.

7)  The interpolator must always interpolate in the center interval of a
    10 point span. Therefore, include at least 5 points prior to file
    generation/distribution time to prevent stations from trying to
    interpolate outside the optimal interval.

8)  Each ephemeris record contains a leap second value. In prediction
    files spanning the date of a leap second, those records after the
    time of the leap second 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.

> Even though the flag is non-zero, the leap second is not applied to
> the cpf times or positions. The station software needs to detect the
> leap second flag and handle the time argument for the interpolator
> appropriately.
>
> Prediction files starting at 0 hours immediately after the leap second
> has been introduced will have the leap second flag set to \'0\'.
>
> Normally, the leap second flag will be set to \'0\'.

10) CPF files should be named in accordance with the following format:

satellite_cpf_yymmdd_nnnv.src

where:

\- satellite:

= Official satellite name (See table below.)

= hyphens are allowed, but no blank spaces

= variable length, maximum 10 characters

\- nnn:

= ephemeris version number. Day of year + 500 to distinguish CPF from
TIV in

time bias and other messages. The "500" can be dropped when TIVs

are discontinued. This field is three digits with zero leading fill.

\- v:

= version within the day. One digit, starting with \'1\'.

\- src:

= prediction provider code. Three characters.

11) If predictions are emailed, the subject line should read:

> Subject: satname DAILY CPFS center,
>
> e.g., SUBJECT: ICESAT DAILY CPFS UTX .

The file should be mailed as embedded text, not as an attachment.

12) Maneuvers messages are no longer needed except to alert operators.

```{=html}
<!-- -->
```
13) CPF files should normally be ftp-ed to EDC or CDDIS for
    distribution, as detailed in their instructions.

14) There is a sample software program called cpf_chk that can be used
    to test the CPF files\' format. Using this program could save a
    great deal of time in hand-checking the prediction files. The code
    is provided as-is, and any bug fixes or improvements will be
    gratefully accepted.

**Moon and Most Transponder Predictions**

1)  Follow the same procedures as for "SLR Predictions" with the
    following differences.

2)  The out-bound and in-bound leg vectors (records 10-1 and 10-2) are
    corrected for light time. In other words, for record 10-1, the
    vector spans from the geocenter at fire time to target position at
    bounce time. Similarly, for record 10-2, the vectors spans from the
    target at bounce time to the geocenter at return time.

3)  For the moon and transponders, time of prediction is fire time for
    the outbound leg and return time for in-bound leg. The latter is for
    reference only. For rotation records (30), the time is bounce time
    (i.e., firing time + out-bound leg length). Out- and in-bound leg
    and rotation records remain together in fire time order.

4)  The in-bound leg is required for ranging to the moon and beyond or
    any other orbit that has been computed using a solar system
    ephemeris.

5)  Position, velocity, and aberration vector elements have opposite
    signs on out-bound and in-bound leg records. Relativistic
    corrections are always positive and additive. When there is only one
    corrections record (type 30) for each outbound/inbound leg pair, the
    relativistic correction must be one-way, as it will be added twice.

6)  Include the following records:

-   Lunar reflectors: H1, H2, H9, 10-1, 10-2, 30-1, 99

-   Center of moon: H1, H2, H9, 10-1, 10-2, 30-1, 60, 99

-   Asynchronous transponders: H1, H2, H4, H9, 10-1, 10-2, 20-1, 20-2,
    30-1, 30-2, 40, 99

-   Synchronous transponders: H1, H2, H4, H9, 10-1, 10-2, 30-1, 30-2, 99

[**Resources**]()

1)  [Standard Satellite Prediction Spacing]()

Satellite class Interval (min)

CHAMP (LEO) 2

GFO-1 3

TOPEX 4

LAGEOS 5

GPS 15

Moon 30

2)  [Standard Laser Target Names]()

[SLR Targets:]()

> [adeos\
> adeos2\
> ajisai\
> beaconc\
> champ\
> diadem1c\
> diadem1d\
> envisat\
> ers1\
> ers2\
> etalon1\
> etalon2\
> fizeau\
> geos3\
> gfo1\
> gfz1\
> glonass## (where \## is the 2-digit GLONASS satellite number)\
> gpb\
> gps35\
> gps36\
> gracea\
> graceb\
> icesat\
> jason1\
> lageos1\
> lageos2\
> larets\
> lre\
> meteor3\
> meteor3m msti\
> reflector\
> resurs\
> starlette\
> starshine2\
> starshine3\
> stella\
> sunsat\
> tips\
> topex\
> westpac\
> zeia]()

[LLR Targets:]()

[apollo-11]()

[apollo-14]()

[apollo-15]()

[luna-17]()

[luna-21]()

[An up-to-date list will be maintained at:]()
<http://ilrs.gsfc.nasa.gov/products_formats_procedures/satellite_names.html>

[2. Full documentation](../cpf_0.99_provider_cookbook.doc)

> http://ilrs.gsfc.nasa.gov/products_formats_procedures/predictions/cpf.html

3.  Sample Software

> http://ilrs.gsfc.nasa.gov/products_formats_procedures/predictions/cpf.html
>
> 4\. EDC and CDDIS upload instructions
>
> Contact Carey Noll at <carey.noll@nasa.gov> or Wolfgang Seemueller at
>
> <seemuell@dgfi.badw-muenchen.de> .
>
> 5\. For reference, CPF files can be found at:
>
> <ftp://cddis.gsfc.nasa.gov/pub/slr/cpf_predicts> or
>
> ftp://www.dgfi.badw-muenchen.de/slr/cpf_predicts.
>
> [or contact Carey Noll (]()<carey.noll@nasa.gov>) to be added to the
> email exploder.
>
> §

6.  CPF email exploder:

> Contact Wolfgang Seemeuller (<seemuell@dgfi.badw.de>) or check the
> ILRS web page.

Appendix D - Consolidated Prediction Format User\'s Guide

> At the Laser Workshop in Eastbourne in October, 2005 the ILRS
> Governing Board set the goal of converting all stations from the Tuned
> Inter-range Vectors (TIVs) to the new Consolidated Predictions Format
> (CPF) by June 31, 2006. All prediction centers are expected to start
> providing the CDDIS and EDC with CPF files on a routine basis by the
> end of 2005. This conversion is the culmination of 5 years of work by
> the ILRS Prediction Format Study Group. The new format promises to
> provide better prediction accuracy for artificial satellites,
> especially LEOs, as well as providing a common system that will
> include lunar retro-reflectors and transponders in lunar orbit and
> beyond.
>
> This short document tries to summarize the main requirements for using
> CPF files. There is a more complete and extensive document that
> discusses philosophy and format details. It can be found at the
> addresses listed in the **Resources** section.

**General comments**

1)  Sample software is provided at the address given at the end of this
    document. There are \'c\' and FORTRAN versions of the CPF file
    reading and interpolation software (with test programs and "readme"
    files), a more advanced program for SLR-type predictions
    (CPF_INTER), and a more advanced program for lunar and transponder
    predictions (CPFPRED). In addition there is a CPF file format
    checker (cpf_chk). It is expected that all this code will be
    supported. Note that bug fixes and improvements will be gratefully
    accepted. Treat this as an open source project where everyone making
    changes to the software contributes the improvement of the final
    product.

> Finally there is a suite of software to split a CPF file into shorter
> single pass files for a particular station and produce a schedule
> file. The latter software is for demonstration purposes only, and
> active maintenance is not anticipated.

Test input and output are supplied with all programs.

2)  For acceptable precision, interpolate in Cartesian coordinates
    (body-fixed or inertial) and not in point angles and range. There is
    sample code to read and interpolate the CPF files, so you do not
    need to \"re-invent the wheel.\"

3)  Interpolated time must between the 5^th^ and 6^th^ points for 10
    point interpolation, or precision will be degraded.

4)  Due to rule 3), the interpolator needs 5 extra records at the
    beginning and end of a pass to maintain full prediction accuracy.
    The sample interpolator will produce a warning message and give the
    best results it can if there are not enough records to center on the
    time of interpolation.

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

6)  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 mis-formed or blank fields are
    encountered.

[**Resources**](../cpf_0.99_station_cookbook.doc)

[1. Full documentation](../cpf_0.99_station_cookbook.doc)

> http://ilrs.gsfc.nasa.gov/products_formats_procedures/predictions/cpf.html

2.  Sample Software

> The software is organized as follows;
>
> FORTRAN, C, and C++ directories with the following subdirectories
>
> cpf - Interpolation (basic and complete packages)
>
> common - basic routines
>
> include - .inc and .h files
>
> slr - slr code
>
> llr - for llr and transponders at the moon and beyond
>
> combined - handles all targets; a combination of slr and llr code
>
> cpf_split - split CPF files into passes and creates schedules
>
> cpf_chk - CPF file format checker
>
> Note that not all programs and routines are available in all
> languages. As of version 1.00 there are no C++ routines.
>
> Maintenance priorities will be: cpf, cpf_chk, and cpf_split. Cpf_split
> is for reference and probably will not be maintained.
>
> Find the code at:
>
> http://ilrs.gsfc.nasa.gov/products_formats_procedures/predictions/cpf.html
>
> 3\. CPF files can be found at:
>
> [ftp://cddis.gsfc.nasa.gov/pub/slr/cpf_predicts,](ftp://cddis.gsfc.nasa.gov/pub/slr/cpf_predicts)
> [or]()
>
> <ftp://www.dgfi.badw-muenchen.de/slr/cpf_predicts>[,]()
>
> [or contact Carey Noll (]()<carey.noll@nasa.gov>) to be added to the
> email exploder.
>
> §

Appendix E -- Maximum Predictions Grid Spacings

**MAXIMUM PREDICTIONS GRID SPACINGS**

to achieve RSS due to INTERPOLATION ONLY of:

1 ns, and 10 ps, in RANGE

1 second of arc, in AZIMUTH and ELEVATION

*J.McK. Luck*

*Research Fellow*

*Electro Optic Systems Pty.Ltd.*

**Table 1**: Prediction Intervals giving nominated Interpolation Errors

+------------+-----+------+-----------+-------------+------+--------+
| **S        | **M |      |           |             | *    |        |
| atellite** | axi |      |           |             | *CPF |        |
|            | mum |      |           |             | Reco |        |
|            | G   |      |           |             | mmen |        |
|            | rid |      |           |             | dati |        |
|            | Sp  |      |           |             | on** |        |
|            | aci |      |           |             |      |        |
|            | ngs |      |           |             |      |        |
|            | (s  |      |           |             |      |        |
|            | eco |      |           |             |      |        |
|            | nds |      |           |             |      |        |
|            | )** |      |           |             |      |        |
|            |     |      |           |             |      |        |
|            | w   |      |           |             |      |        |
|            | hen |      |           |             |      |        |
|            | us  |      |           |             |      |        |
|            | ing |      |           |             |      |        |
|            | 8^  |      |           |             |      |        |
|            | th^ |      |           |             |      |        |
|            | -or |      |           |             |      |        |
|            | der |      |           |             |      |        |
|            | La  |      |           |             |      |        |
|            | gra |      |           |             |      |        |
|            | nge |      |           |             |      |        |
|            | I   |      |           |             |      |        |
|            | nte |      |           |             |      |        |
|            | rpo |      |           |             |      |        |
|            | lat |      |           |             |      |        |
|            | ion |      |           |             |      |        |
+------------+-----+------+-----------+-------------+------+--------+
|            | **R |      | **        | **          | Deg  | Deg 9  |
|            | ANG |      | AZIMUTH** | ELEVATION** | 7    |        |
|            | E** |      |           |             |      |        |
+------------+-----+------+-----------+-------------+------+--------+
|            | **1 | **10 | **1       | **1         |      |        |
|            | n   | ps** | arcsec**  | arcsec**    |      |        |
|            | s** |      |           |             |      |        |
+------------+-----+------+-----------+-------------+------+--------+
| CHAMP      | 234 | 127  | 441       | 456         | 120  | 180    |
+------------+-----+------+-----------+-------------+------+--------+
| STARLETTE  | 240 | 127  | 466       | 519         | 180  | 240    |
+------------+-----+------+-----------+-------------+------+--------+
| AJISAI     | 310 | 170  | 617       | 628         | 240  | 300    |
+------------+-----+------+-----------+-------------+------+--------+
| LAGEOS     | 501 | 280  | 1097      | 1118        | 300  | 600    |
+------------+-----+------+-----------+-------------+------+--------+
| GPS35      | 1   | 763  | 2970      | 3160        | 900  | 1800   |
|            | 360 |      |           |             |      |        |
+------------+-----+------+-----------+-------------+------+--------+

**EXPLANATION**

Files of predictions for each satellite chosen were kindly provided by
Chris Moore. They were generated in the "Inertial" reference frame
(True-of-date) at 1-second intervals, as geocentric Cartesian X,Y,Z
coordinates They are labeled "I"

The "I" coordinates were then transformed to body-fixed Greenwich
coordinates, labeled "G", by rotating through Greenwich Mean Sidereal
Time. These coordinates are those proposed for the ILRS Consolidated
Prediction Format (CPF). In this study, UT1-UTC and polar motion were
ignored.

The "G" coordinates were then transformed to the relative topocentric
Cartesian coordinates (East, North, Up) at the Mount Stromlo SLR
station, labeled "T", by rotating through longitude and latitude.

Finally, the "T" coordinates were transformed to Range, Azimuth and
Elevation, labeled "P" (for Polar), by the usual formulae.

These four data sets were considered to be "truth". They each covered
about a day of predictions.

Interpolation errors were examined for a variety of circumstances:

-   Grid spacings of 15, 30, 60, 120, 240, 480 or 960 seconds, with
    tabular points ("nodes") selected from the "true" data;

-   Interpolation orders 4, 6, 8, 10, 12 (degrees one less than these);

-   Interpolating into the I, G, T or P reference frames, at every
    second. When interpolating using tabular points in the first three
    systems, the interpolation results were transformed to range,
    azimuth and elevation .

Each circumstance was characterized by its "RSS", i.e. the square root
of the average square of the deviates "interpolated - truth", over all
the 1-second points. The various RSSs were plotted on log-log graphs
against grid spacing; and the grid spacings for the nominated values of
RSS, shown in Table 1, were then obtained by inverse logarithmic
interpolation. The relevant graphs for LAGEOS are shown in Figures 1 and
2.

**OUTCOMES**

![](media/image1.wmf){width="4.079166666666667in"
height="2.015972222222222in"}

![](media/image2.wmf){width="4.079166666666667in"
height="1.9326388888888888in"}

![](media/image3.wmf){width="4.0993055555555555in"
height="1.9756944444444444in"}

**Figure 1**: Log-log graphs of Range, Azimuth and Elevation
Interpolation Errors using an 8^th^-order interpolator in Inertial XYZ
(I), Greenwich XYZ (G), Topocentric ENU (T) and local Az/El/R (P)
systems.

From Figure 1 it is seen that the results are virtually identical when
interpolating with an 8^th^-order interpolator on any of the Cartesian
systems (I,G,T), but much worse when interpolating directly in range,
azimuth and elevation (P). This general result holds for all satellites
tested and for all interpolator orders used, although their graphs

are not shown here.

Both sets of figures also show that, after a "floor" due to subtraction
of nearly equal large numbers, the log-log relationships are linear,
consistent with the theoretical behaviour of interpolation errors. This,
too, is a general result.

![](media/image4.wmf){width="4.079166666666667in" height="2.0375in"}

![](media/image5.wmf){width="4.0993055555555555in"
height="1.9541666666666666in"}

![](media/image6.wmf){width="4.111111111111111in"
height="1.9645833333333333in"}

**Figure 2**: Log-log graphs of Range, Azimuth and Elevation
Interpolation Errors using interpolators of order 4, 6, 8, 10 and 12 in
the Greenwich XYZ (G) system. .

**CONCLUSIONS**

From the point of view of interpolation error, the grid spacings
proposed for the ILRS Consolidated Prediction Format are adequate for
producing better than 1 ns accuracy in range, and 1 arcsec accuracy in
azimuth and elevation, provided that an 8^th^-order interpolator (or
higher) is used on Cartesian coordinates. They are not adequate for
producing ranges with 10 ps accuracy (if anybody would ever want such
accuracy in predictions).

They are grossly inadequate for interpolating directly into tables of
range, azimuth and elevation!

**CAUTIONS**

Transforming from an inertial (or quasi-inertial) reference frame to the
Greenwich (body-fixed) frame involves application of sidereal time,
which in turn requires the Julian Date (JD). Now, a typical satellite
range rate is 5 km/sec, or 1 ns (2-way) per 30 μs. If the formula for
GMST given, for example, on page B6 of "*The Astronomical Almanac 2005*"
is followed blindly at an arbitrary time, then about 17 decimal places
are required for the JD to reach the 30 μs resolution needed. My
Windows-based 32-bit computer only gives about 14 decimal places in
Fortran double precision, so the rounding error is highly significant -
it caused a 30 ns saw-tooth during my experiments. A simple remedy is to
calculate GMST for exactly 0h UTC on the required day, reduce it modulo
86400^s^, then add \[UTC + (UT1-UTC)\] multiplied by the sidereal
conversion factor 1.00273781191135448 ("*IERS Conventions (2003)"*,
p.38). Or simply increase the precision of calculations.....

\[*Confession*: I have always known about this, but forgot. The reminder
came when the interpolation errors on "G" were much larger than on "I",
which was hard to understand since the transformation between them is
essentially extremely smooth. There's no fool like an old fool.\]

It was also humbling to have to take several goes at getting the
azimuths strictly continuous before their interpolations, because the
ATAN2 function only returns values in the range ![](media/image7.wmf).
Failures showed up as ridiculously large interpolation RSSs, e.g. 10^5^
seconds of arc. \[The old fool does still remember to do simple, yet
comprehensive, sanity checks on all his software.....\]