See list attachedAugust 29, 196969-PA-T-116APA/Chief, Apollo Data Priority CoordinationA lengthy status report on lunar point landing including some remarks about CSM DOI
It is clear that lunar point landing capability is absolutely necessary if we are to support the exploration program the scientists want. That is, mission success intrinsically depends upon it. (The current definition of “point landing” is for the LM to touchdown on the lunar surface within 1 kilometer of a point referenced to specific features on the moon which have been selected preflight.)
For Apollo 12 we have made a number of Mission Techniques improvements which should reduce landing point dispersion significantly. However, we were constrained to implementing only those changes which have small impact on the MCC and crew timelines due to the imminence of the flight.
A primary goal of Apollo 13 is to demonstrate a real, honest-to-goodness point landing capability and various groups have been working on ways of doing that job as well as possible without the minimum timeline impact constraint. This work has been going on for several months now and has led to a number of proposals for changes in the Apollo 12 procedures, software, and hardware. On August 22 and 25 we reviewed these proposals in an attempt to evaluate and incorporate them – and anything else that came up – into the Mission Techniques to be used on Apollo 13. It is the purpose of this memo to present the current status of all that, including items being worked on, and hardware and software changes needed.
It was interesting and encouraging to observe that we really did not come up with any radical changes from the Apollo 12 baseline. In fact, there were only two basic changes involved in the plan we are all now concentrating on. They are:
a. Schedule the LM/CSM undocking about one revolution earlier – that is at about 2¼ revolutions before PDI. (This does not mean an extra two hours in the timeline; some activities can be moved from before undocking to after undocking.)
b. Achieve the pre-descent orbit (i.e., 8 x 60 n.m.) on “LOI day” rather than on “descent day.” This, of course, means getting into that orbit with the CSM PS and makes descent the only burn to be done by the DPS.
Each of these individually is beneficial; however, the second probably is not possible without the first. They both require a lot of work to prove feasibility and desirability and – assuming that is proven – to produce the final procedures, plans, and rules to support a flight.
So much for the introduction!
One way of slicing the point landing pie is like this:
a. The MCC must supply accurate state vectors and targeting (i.e., where the LM is and where it's supposed to go to) to initialize the LM guidance system (PGNCS) for descent. Any inconsistency in these parameters will result in an equivalent position error when the crew takes over during the last several thousand feet.
b. The PGNCS must be adjusted and operated during descent as accurately as possible for the same reason. This includes things like pre-descent tuning and optimum utilization of the landing radar data.
c. The crew must be provided with as much terminal descent maneuver capability and control as possible.
Most of this memo deals with the first of these, although a great deal of attention is being given all three.
How can we obtain accurate state vectors and targeting for descent? First of all, experience has shown that the MSFN orbit determination system works best when utilizing tracking data obtained on two successive revolutions. We have also found that the results are better when the LM and CSM are separated. This leads to the first proposal, which Dave Reed (FDB/FCD) has been pushing for a long time, in spite of our ignorance. Namely, undock one rev earlier so that we can get two complete MSFN tracking passes on the LM alone. Although the primary purpose of this is to assure getting the best possible MSFN determination of the LM orbit, some other benefits spin off. For example, the LM crew would be able to perform two PGNCS alignments (P52's) two or more hours apart to get a decent IMU drift check and perhaps even allow the MCC to determine and uplink improved gyro compensation coefficients. We couldn't do that before. It also means the landing site tracking with the CSM optics is done undocked. The significance of this is that undocked tracking is necessary to make the early “DOI” with the CSM possible. More about that later. Anyway, Bob Lindsay (FCSD) and others are busy assembling a revised flight plan to reflect this change and I'm sure all the ramifications are not apparent yet. Hopefully, they will be able to reshuffle the LM activation and checkout activities so that we do not require much increase in the crew work period. Certainly it should be less than a complete rev (i.e., two hours).
The other thing we concentrated on to improve the state vectors was to reduce as much as possible any perturbations to the LM trajectory caused by onboard activity during these last two revs before PDI. And, the importance of these things cannot be too strongly emphasized, particularly to the crews themselves since they are the best and final policemen. The Apollo 12 changes caught most of these (see memo 69-PA-T-114A, dated August l, 1969); undocking earlier eliminates all the rest of the known ones except that darned LM water boiler venting (we must leave fixing this to the CCB) and the DOI burn itself, which is the next subject.
Doing the DOI burn with the CSM SPS is not a new idea. It was proposed several months ago by MPAD primarily to save LM DPS propellant. (It can save as much as 70 fps which is equivalent to about 14 seconds of hover.) It also eliminates the wear and tear of the low thrust DOI burn on the DPS engine – particularly throat erosion. The big question is – when should this CSM DOI burn be performed? After several false starts we have finally concluded the only place it can be done in the timeline is on LOI day since on descent day the crew timeline and/or the descent targeting was rent asunder by it – usually both. On the other hand, doing it on LOI day – perhaps combined with LOI₂ into a single maneuver – probably improves the targeting. This is because the MCC/RTCC is given about ten revolutions of stable orbit tracking to psych out exactly what that crazy lunar potential is doing to us and to compensate for it; also there is no last minute DOI maneuver to introduce unknown ΔV errors. Of course, the accuracy of the CSM landmark tracking of the landing site must not be degraded too much or this advantage can be lost.
Actually, it appears right now that finding a way to do landmark tracking is the key to whether or not we can do the CSM DOI. First of all I'd like to make clear that this tracking is mandatory for point landing. Many people have expressed surprise at this but it is a fact. Accordingly, it would be ridiculous to launch a mission on which point landing is equivalent to mission success if we are not confident the tracking can be done. Our problem, of course, is having done the DOI burn with the CSM, we must either do the landmark tracking in the low orbit or we must raise the CSM's orbit at least l½ revolutions before PDI to track from the higher orbit in time to target the LM. Unfortunately there is no simulator on earth with which we can develop confidence in the low orbit tracking operation. And, certainly the benefits of CSM DOI are not sufficiently great that we would be willing to try low orbit tracking on Apollo 13 for the first time thereby jeopardizing the entire point landing demonstration objective of that flight. That leaves early circularization as our only remaining possibility. On the surface it appears feasible but we'll have to get into the details before we'll know.
There are some other things about which we must satisfy ourselves regarding CSM DOI. For example:
a. Can LOI₂ and DOI be combined? Is there a solution to targeting such a burn? (Incidentally, an RTCC program change would probably be required for this.)
b. How do you monitor this maneuver where one second overburn results in lunar impact? And, what is the contingency recovery plan?
c. Is the post-DOI orbit safe or does it get too low sometime before PDI?
d. How large will the PDI dispersions be (primarily Δh)? Can the descent guidance handle them? Are there any crew or MCC monitoring impli- cations? If the PDI dispersions may be too large, must a trim burn be scheduled and when?
e. Is it possible to include a landing radar test a rev or two before PDI which traces out the descent approach terrain signature for us? If so, how do we use it (e.g., real time slope determination and LGC coefficient update, RLS altitude update, part of the real time landing radar enable decision during descent, etc.)?
f . When does the CSM circularize (at 60 n.m., I suppose)? And how are the current abort targeting programs and procedures affected?
Although this memo is already too long, I'm afraid it can't be complete without a comment on the proposal for pre-PDI landmark tracking by the LM to tune up the descent targeting. Attempts to include this and the associated activity into the timeline have been very frustrating. On the other hand, estimates of its benefit have been decreasing to a point where some of us even feel it is more likely to foul things up than to help. Accordingly, it is my recommendation that it be dropped completely from Apollo, including related computer program changes and any premission photographic requirements. I will write another note to document the reasons for this negative recommendation.
In summary, I guess it's obvious but the fact is we really don't know how much benefit we'll get from any of these things we're talking about doing. Our approach actually has been to dream up anything that might help and see if it can be applied without too much strain. It is based on the assumption that the task is almost impossible and so we've got to do everything we can, no matter how little each item contributes. What is our chance of success? Hopeful is my guess. The kind of things proposed here plus optimization of the descent trajectory to squeeze out the last millisecond of hover time on the DPS plus some intelligent handling of the LR data (requiring computer program changes, no doubt) just might do the trick.