AS-258 RTCC Retrofire Time Computation

FA/Director of Flight OperationsMAR 20 196767-FM1-22FM/Deputy Chief, Mission Planning & Analysis DivisionAS-258 RTCC Retrofire Time Computation

One step taken in an attempt to alleviate the RTCC program development problem has been to make major reductions in the area of retrofire time computations. Since these deletions have an impact on the Retrofire Controller's capability and mode of operation, I felt it desirable to report these things in a memorandum devoted solely to that subject.

Retrofire time computations to be used when the guidance system is up and operating are done with precision, as are those for non-G&N reentries wherein there is time to make proper adjustments in the inputs to the RTCC program. However, I would like to emphasize from the start that in certain contingency situations – namely those reentries which must be performed on an emergency basis and without the guidance system – the retrofire time computation may be in error as a result of our having eliminated one of the modes for computing retrofire time. Recognizing that almost all cuts in the RTCC programs involve a calculated risk, this one seemed to be as reasonable as any to me. I base this opinion on the knowledge that there are many other equally large error sources contributing to the landing point dispersion for non-G&N emergency reentries. Also, it must be recognized that an error in the retrofire time computation does not affect our knowledge of where the spacecraft will ultimately land.

In order to understand the reductions that have been made in the retro- fire time computations, it is necessary to describe in some detail the options which originally were to be available. These options are made up of any combination of the following elements, which I will describe individually:

1. Type of reentry, with 4 options – no change. 2. Attitude hold mode during retrofire, with 2 options – reduced to 1. 3. Choice of propulsion system, with 4 options – no change. 4. Choice of retrofire attitude iteration, with 3 options – reduced to 1. 5. Orientation of the spacecraft, with 4 options – changed, but only in the manner in which it is specified. 6. Manner in which the maneuver magnitude is to be specified, with 2 options – no change. 7. Real time adjustment of a number of other parameters – probably increased by one.

Type of Reentry:

There are four basic types of reentry for which we are able to compute the retrofire maneuver:

1. Retrofire only followed by guided reentry. 2. Retrofire preceded by a pre-retrofire maneuver and followed by a guided reentry. 3. Retrofire only followed by ballistic reentry. 4. Retrofire preceded by a pre-retrofire maneuver and followed by a ballistic reentry.

Since there is a reasonable high probability of having to carry out any of these four basic types of retrofire maneuvers, we haven't attempted to decrease this capability.

Attitude Hold Mode:

When making a guided retrofire maneuver, it is intended to hold inertial attitude. This is also the case when using the SPS engines in conjunc- tion with the SCS control system. However, if the SPS, G&N and SCS have all failed, the procedure is to maintain orbit rate torquing during a long RCS maneuver, and this option was available to provide a more precise retrofire time computation in that instance. Considering the low proba- bility of making this sort of maneuver, along with the large probable error associated with one of that type, it would seem unnecessary to pro- vide this extra precision in the computation of the retrofire time itself. Accordingly, all retrofire time computation will now only be based on the assumption that the attitude during the maneuver will be maintained iner- tially constant.

Choice of Propulsion Systems:

Retrofire time computations can be based on either using the SPS engines or the service module RCS. Two options are provided for the SPS mode, depending on whether 4-jet or 2-jet ullage is to be used. It is also possible to specify either 2-jet or 4-jet RCS retrofire, although it has been stated that a 2-jet RCS retrofire maneuver is not operationally feasible. If this option is considered unnecessary, some computer time could be saved by eliminating checkout of it.

It should be pointed out that retrofire time computations can also be carried out if the command module RCS propulsion system is to be used. However, this is done by manipulation of the input parameters and not through provision of special RTCC computer program logic.

Selection of Retrofire Attitude Iteration:

The original retrofire time program was designed to provide three basical- ly different retrofire attitude options. In fact, it is the provision of these three options which contributed most to expanding this particular task out of reasonable bounds. It is the deletion of two of these which constitute the most substantial savings. The three options are as follows:

1. Retrofire attitude is selected external to the RTCC program and manually input to it. This was the mode used in Gemini where is was possi- ble to change the retrofire attitude but the value was selected based on some logic external to the computer program, usually preflight. This retrofire attitude is referenced to the local spacecraft horizontal and the orbital plane at the time of retrofire initiation. The program then iterates for the retrofire time based on the assumption the retrofire maneuver will be executed in the attitude specified. It is this single option which we shall retain in the system, since it gives the greatest flexibility.

2. The second retrofire attitude iteration logic was introduced new for Apollo and, in fact, became the prime mode of operation. For some reason, it was felt necessary that the retrofire maneuver be made with a reference line on the spacecraft window aligned precisely with the earth's horizon at the time of retrofire initiation. Therefore, special computer logic was provided wherein the program would iterate not only for the retrofire time but also for the attitude to be used. As a result, it was not known what the spacecraft retrofire attitude would be until the final retrofire time computation was carried out.

It is understand than most non-G&N retrofire maneuvers will be carried out with the spacecraft orientation this option provides. However, considering the inaccuracies associated with a non-G&N retrofire and re- entry, the small additional error incurred in the retrofire time computa- tion itself seems acceptable. The error would result from using an attitude close to, but perhaps not precisely on, the visual horizon in the time-to- fire computation. Of course, the maneuver would most likely be performed at the horizon attitude to within the crew's ability to hold it. It must be emphasized again that deletion of this mode is implicit acceptance of a somewhat inaccurate retrofire time computation, but with the understanding that the knowledge of what the crew will do is not jeopardized in any way. Further, it should be pointed out it is not at all difficult to determine the retrofire attitude referenced to the horizontal which would provide the visual horizon reference within whatever precision is required. That is, the only time the error will result is non-G&N retrofires occurring on an emergency, immediate basis.

3. For some reason, it was concluded that the attitude to be used during an RCS retrofire must be aligned along the velocity vector rather than horizontal, and the third special mode had been provided to compute this attitude in real time. First of all, the difference between the velocity vector and horizontal seldom exceeds 2°, even for highly ellip- tic earth orbits. This is a rather trivial error even if it were not compensated for, as it could be quite easily. There was agreement that this mode could be deleted without hurting anybody.

Orientation of the Spacecraft:

Provision has been made for computing retrofire maneuvers in any combi- nation of heads-up or heads down and posigrade or retrograde [can you believe posigrade?]. We have not reduced this capability, but it is my understanding that, in order to provide consistency with inorbit maneuvers, the spacecraft orientation will be specified by pitch, roll and yaw as opposed to those quantities noted above.

Maneuver Magnitude Control:

The magnitude of the maneuver may be specified either in terms of ΔV or duration of burn.

Other Controls:

Just to be complete, I might list the other input parameters which control the retrofire time computation:

1. Revolution number, recovery area and landing point latitude and longitude. 2. Duration of the ullage burn. 3. Nominal reentry bank angle. 4. REFSMMAT is to be used to compute IMU gimbal angles. 5. g level at which rolling is to be initiated for ballistic reentries. 6. The bank angle it is intended to hold between retrofire and that g level.

In summary, it seems to me that the retrofire time processor still provides all the flexibility and accuracy required to carry out our missions. Sev- eral limitations have been made which should considerably reduce the systems test time. As you can guess from the length of the various discussions given above, the only real area of contention had to do with how reasonable it was to provide special retrofire iteration modes beyond that available on Gemini. Agreement by the Flight Controllers on this matter was only possible assuming acceptability of somewhat erroneous retrofire time computations in the case of non-G&N reentries performed on an emer- gency basis.