Creation of SPIKE /RPS2 Orbit Models
Purpose
To allow the user to determine the orbit model parameters used by the SPIKE software to
calculate the HST orbit position.
Overview
The HST is in a nearly circular low earth orbit (~580 Km altitude). The HST orbital plane
precesses in a retrograde direction at a sidereal rate of about -6.4 degrees/day. This
motion is caused mostly by the non-spherical shape of the earth. Over the range of
probable HST altitudes, this rate of precession is proportional to the semi-major axis
length.
SPIKE assumes a circular orbit for HST and does not care, in an absolute sense, about
the orbital in-track position of HST. Thus there are six orbital parameters that SPIKE
uses to determine the HST orbit: the inclination, the epoch, the right ascension of the
ascending node at the epoch, the rate of change of the ascending node, period, and the
semi major axis. (The specification of the period and the semi major axis is redundant,
see the notes section at the end of the document.) These elements are stored in a file
called a SPIKE constraint set. This file contains, in addition to the orbit information,
information about restrictions on the HST spacecraft (minimum /maximum sun angle,
maximum allowed off nominal roll, etc.). A more detailed overview on constraint sets
can be found in the <recalc constraint set> procedure. The constraint set files can be
found in /cerb/data1/operational/constraint-set/
Here is an example of orbit information in a SPIKE constraint set:
:st-information '(:inclination 28.470 ;inclination in degrees
:time-asc-node 7091.5 ;time of ascending node in truncated Julian date
:RA-asc-node 246.75 ;right ascension of ascending node in degrees
:regression-rate -6.3961 ;nodal regression rate in degrees per day
:period 96.41 ;nodal period in minutes
:semimajor-axis 6971.75) ;semi-major axis in kilometers
The truncated Julian date (TJD) is a invention for SPIKE and is given by
TJD = JD - 2444000. It is displayed in the SPSS fit report produced and used by the
fitting software.
The HST orbit slowly decays because of atmospheric drag which causes the semimajor
axis to shrink. The amount of the drag is dependent upon the air density and cross
sectional area of the telescope normal to the velocity vector. The air density decreases
with increasing radius from earth, but is also dependent upon the level of solar activity.
During times of high solar activity, the upper atmosphere is heated and expands, causing
an increase in drag and a more rapid orbital decay. As the solar activity varies then, so
does the drag on HST. Thus over long periods of time, particularly during times of high
solar activity, it is impossible to predict exactly the HST orbit radius.
This requires us to monitor the HST orbit and to update the model parameters about once
a year. As part of the normal calendar building process, each week, we receive a 10
week HST predictive ephemeris from the Flight Dynamics Facility that is fit using SPSS
software assuming constant values for the semimajor axis, inclination, and precession
rate. The fit names have the form Sxyydddvv and are stored in the PMDB.
To counter act the orbital decay, during roughly every other servicing mission, the shuttle
will raise HST into a higher orbit. This will also change the precession rate and thus
require an update to the HST orbit model.
The best time to do this is a part of the release of the latest RPS2 version.
Needs work
All of the values but three can remain constant. The inclination oscillates slightly about a
mean value of 28.469 degrees because the interaction with the moon. The period and the
semi-major axis also should remain fixed at ?? and ??. These values need to be
consistent with each other as the effects in SPIKE are unknown. There is reason for this.
The current values have been conservative for ?? f the mission. If these values are
changed to a smaller value, then any CVZ visits will need to be re-TRANSed else they
will become unschedulable. A limitation that may be fixed at a later time.
calculation of the timeframe of CVZ opportunities. The offset will cause some visits, not
necessarily just CVZ observations, to have false positives and negatives in planning.
There is no data to support how bad the problem could be. However, we should try to
keep the differences between reality and the SPIKE predictions as small as possible.
HST Orbital Semi-Major Axis
6995
Launch
6990
SM2 boost
Semi-Major Axis [Km]
6985
6980
SM1 boost
6975
6970
6965
6960
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
Year
Figure 1. The HST semi major axis as a function of time since launch to September
1999.
As can be seen in Figure 1, many times the HST semimajor axis as a function of time can
be well described by a linear or quadratic function. However, there were times during the
last solar maximum where solar activity changes induced kinks (discrete changes in the
slope) in the function. There is not much we can do about this except monitor the HST
orbit and update the orbit coefficients as needed. I doubt that the solar models used by
FDF can predict their occurrence.
During times of low solar activity (1993.001 - 1999.001), the rate of decrease in the
semimajor axis has been fairly constant and small at a value of about 1 Km/year. Since
1997 the solar activity has been increasing and the rate of decay has been increasing too.
The rate of change was ~12 Km/year. A drop of 1 km in altitude corresponds to
approximately 1.25 seconds in period reduction at this altitude.
Since launch, HST started at 6993 Km down to 6965 Km with a corresponding nodal
period range of 96.69 to 96.27 minutes. Correspondingly, over that time, the change in
the precession rate was also small and using the precession rate from the last SPSS fit
would allow a 1.5 year prediction with a maximum orbital plane position error of <1
degree. The range in the nodal regression rates has varied, historically, between –6.4464
degrees/day and -6.3813 degrees/day.
semimajor axis can be represented by a constant, linear, or quadratic function of time,
respectively. Remember that SPIKE models RACN with a linear function of time. So
the procedure is basically: fit the semimajor axis data with linear or quadratic functions of
time, use the fit coefficients to extrapolate the position of the HST orbital plane, and then
find the coefficients to use in the SPIKE model that minimizes the differences between
the extrapolated projection and the SPIKE model during the predictive interval.
Procedure
1. Log into the VMS lrp account
2.Change to the working directory
$set def [lrp.orbits]
3.Create a listing of the current low order SPSS orbit fits of the predictive 10 week data
that are in the PMDB. This report will list all available fits. The end_time argument is
used in the report to calculate the position of the ascending node (assuming a constant
precession rate) at the given end time using the epoch, initial position, and precession rate
for the listed fit. A reasonable time to input is the prediction end time you are going to be
using. The "P" qualifier will create a plot of the semimajor axis versus time. Go to the
SOGS printer and retrieve the plot. End_time format is YYYY.JJJ.
$do list_hst_orbit_fit <end_time> <mmmddyy.rpt> P
4. Typically we are interested in what has been happening since the last orbit boost. In
addition, when we are projecting the orbit into the future, we will only do it ~1.5 years
into the future. Say if we are updating the orbit model in October, just before the new
RPS2 delivery, then a good end point for the projection would be the end time of the next
cycle. So for October 99, the end point would be ~01.180 assuming cycle 9 runs from
July 1 to July 1.
Using the plot, examine the time frame from the last boost and look for abrupt changes in
the slope, as these will be good times to start the fit on. The end time of the fit can be any
time after the last data point. Do several fits (Only if you need to! You may only need
one.) to the data using different fit start times, and maybe different projected end times.
Date format is in TJD.
$do hst_orbit_ fits fit_start fit_end projection_end [p]
Each time you run the program, it will fit the data contained in the given interval using a
linear and quadratic function. Also, the program will list the derived fit parameters, the
position of the ascending node at the projection end time, and the goodness of fit (not yet
implemented, do an eyeball fit(!)). If "P" is given, the program will produce two plots.
The first plot shows the semimajor axis as a function of time with the linear and quadratic
fit to the data over the fit interval. The fit interval is shown in a solid line type, and the
projection of the fits to the projection_end are shown as a dotted line type. The second
semi-
different fits and choose the one that is better. Sometimes this is a judgment call, but the
things to be looking for are:





How well did the function fit the data?
Are there kinks in the data? How could that skew the fit results and affect the
semimajor axis predictions?
Is the sun going to become more active, (i.e. pick a reasonable fit that tends to
have the semimajor axis decreasing more) or less active?
What are the differences in the ascending node position at the end of the
projection? If the values are close to a few degrees, that is good!
What are the largest differences between the theoretical model and the SPIKE
model?
8. Once you have chosen your fit, create a new constraint set (See recalc_cv_desc
procedure for details) using the values given in the fit output. If you are updating the
model because we are starting a new cycle, then you should probably change the
planning interval in the constraint set too. Because of the way SPIKE works, the
planning-start should be no later than the start time of the earliest member of an active
(still open) link set. You can run ???? ( a non-existent report?) to find the earliest open
link set. The planning-end time should be roughly the end of the next cycle plus 6 months
(to allow for visits that must schedule after the nominal end of the cycle). The planningstart and planning-end times need to be on week boundaries (Mondays 0h UT). Do not
worry that the planning interval extends beyond the end of the predictive interval where
we attempted to minimize the ??? First, the time frame in question is nearly two years
into the future. The HST orbit parameters will be updated at least once before anything
planned in the interval will execute. The plan can change so visits planned there may be
moved for other reasons. Operational constraint sets should use the naming convention of
mmmyy.lisp. This constraint set will need to be provided to the SPIKE/RPS2 developers
for inclusion into the new RPS2 build. Finally, making the new constraint set the
operational constraint set, should be coordinated with the release of the new RPS2 and
PC activities (Some visits may become unschedulable!).
What to do after a shuttle boost?
If there has been a shuttle boost, there will be maybe one data point post-boost, so the
previous procedure will not work. be What we can do is assume a linear rate of change
in the semimajor axis, determine the rate of change (slope) for the pre-boost time, and use
the slope and the post-boost semimajor axis value to calculate the new rate to use for
spike.
Procedure
1.Fit the semimajor axis data just prior to the boost and record the slope and offset
from the linear fit.
2. From the last record listed in the report, determine the epoch t0 (TJD), the semimajor
axis (a0) , and the RA of the ascending node ( 0).
3. The values to use in the new SPIKE constraint set are given by (get out your
calculator!)
:time-asc-node = t0
:RA-asc0 + offset
:regression0+r0
0 and the end of the predictive period in days. M is the
slope from the above fit. The end time of the predictive interval (if you used it) in TJD is
given at the far right of the SPSS fit report header.
From a fit to orbit data spanning 199? To 199?, r = 0.0032?? degrees/day/Km and r0 = 23??? Degrees/day.
4. Go to step 8 in the above normal procedure to continue. The same comments about
the planning interval apply here too.
TDRS
HST uses two TDRS for communication. They are in geostationary orbits over the
Atlantic (TDRSE) and eastern Pacific (TDRSW) oceans.
SPIKE uses constant values for the TDRS orbits. Occasionally, a different TDRS is used
or one is shifted a bit. The value that would get changed is :longitude. Its value can be
obtained form STS personnel. SPIKE uses "-" for West longitude.
Does SPIKE even use these?
Notes
Tests are underway to use 14 month predictive ephemerides. If this works, the
procedure may be collapsed into ~4 lines. Request the 14 month eph, fit the eph using
??? procedure (or request STS personnel do it), run report, transfer fit results into
constraint set.
As pointed out before, specifying the semimajor axis and the period is redundant, an OPR
has been filed ? to allow entry of just one value.
In calculating the SPIKE parameters, we tried two methods in the fit program, basically a
least squares fit between the SPIKE model and the theoretical model, and minimizing the
absolute difference. The LSQ method would at times allow large differences between the
two predictions, thus it was felt we should minimize the absolute difference.