Descent Data Select procedures are finalized

See list attachedJuly 11, 196969-PA-T-106APA/Chief, Apollo Data Priority CoordinationDescent Data Select procedures are finalized

On July 7 and 8 we held a final review of the Data Select procedures and Flight Controller interface during the Descent phase of the lunar landing mission. This lengthy memo is to describe briefly some of the items discussed, all of which are being thoroughly documented before the flight.

On F, as you know, John Young did not track the center of the Land- ing Site 2 landmark – a crater designated “130” – but rather used a much smaller crater on the rim of 130. He did this primarily because it was much easier to do and, he thought, would improve the accuracy. It is planned to use this smaller crater, which has been called “130 Prime,” on the G mission also, and the RTCC is set up to do so. How- ever, it was emphasized that we must also be prepared to use the old “130” if for some reason lighting makes it impossible for Mike Collins to acquire “130 Prime.”

It was strongly emphasized by the Data Select people that they should be in the high-speed mode for Lear filter initialization and condition- ing at least four minutes before PDI. If for some reason they are delayed past this point, their confidence in the system will be degraded. In fact if initialization is delayed until 20 seconds before PDI – the drop- dead point – they feel they will have no confidence in the system through- out descent at all.

Analysis of the F flight data has revealed that the Lear processor for some reason gives best results when using three tracking stations rather than four, which it was originally set up to use. Accordingly, it will be operated in the mode where the fourth station's data are available but are excluded from the solution. If one of the three active sites fails during descent, the Data Select people will immediately replace it with the previously excluded site. If it is concluded that the failed site will not be restored quickly, another site will be called up immediately to provide backup for a second failure. It is to be emphasized that bringing up this new station is to provide a backup and an opportunity to observe its data. It will not be actively used unless another site breaks down or the performance of the Lear processor unexpectedly becomes degraded in a manner consistent with poor station location geometry which the new station could help correct.

The Data Select people reviewed their real-time procedures for declaring the “Lear filter is go” as follows:

a. During the free-flight processing after going into the high- speed mode at PDI minus four minutes, they plot and compare Lear results with their best estimate of radius and altitude rate based on previous MSFN tracking and a confirmed DOI maneuver. If these parameters differ by more than 3,000 feet and 13 fps, respectively, the Lear is considered uncertain.

b. During powered descent they have doppler comparison plots for each of the individual MSFN sites vs. the PGNCS. These are used to sort out a bad station.

c. They monitor Lear output plots of altitude, altitude rate, pitch, and LM mass rate of change looking for discontinuities, internal incompa- tibilities, smoothness, etc.

d. The Lear filter displays an estimate of its own performance – residuals, rate biases, and so forth. A particularly strong indicator of performance is the residuals of the fourth (excluded) site, which is not included in the solution.

During the Descent briefing to the management people, a week or so ago, Chris Kraft proposed that some sort of inflight lunar orbit checkout be made of the Lear Processor prior to Descent. After lengthy and some- times emotional discussion, we have concluded that it is most advantageous to use the same tracking stations and communication lines as during descent. To do this we must perform the test on either the first or second lunar orbits before the Madrid station is lost due to earth's rotation. It was also concluded that to perform this test in the on-line RTCC computers with the active third floor MOCR was too risky. Accordingly, the pro- posal is as follows. Configure the network stations to transmit high- speed data for a period of 15 minutes during the first lunar rev when the spacecraft is more-or-less over the landing site. Log the data in the control center and then play it through a third, off-line computer utilizing the second floor MOCR display system. Since no compatible G&N telemetry will be available at this time, it will be impossible to operate some of the displays such as the guidance officer strip charts. It will be possible however to make a realistic, useful comparison of the Lear output with the other MSFN processing to see that this system is working properly end-to-end – from spacecraft to display system in the MCC. Mike Conway (FSD) is responsible for assigning personnel to do this and for getting the control center configured for the test. He also intends,if possible, to get some simulated data and practice this test before the flight. I think the consensus is that this test is like airline flight insurance – a small waste of resources with very little chance of gain; however, it can pay off real big, if we're lucky!

Another question answered was, What spacecraft position should be used for initialization of the Lear Processor in preparation of the T₂ lift- off? (“T₂,” you recall, is the delayed abort time shortly after landing associated with the second stay/no-stay decision.) The problem here is that very little time is available to assess the descent tracking and telemetry data in order to select the best estimate of the actual land- ing site location. We finally concluded that the best solution was to use the preflight nominal value – the one computed from the F mission tracking.

One very significant item resulting from our meeting dealt with reconfig- uring the MSFN tracking network after a T₂ stay decision. It had been planned to keep all stations in the same configuration as during descent in order to support a lift-off one rev later (T₃) if that turned out to be necessary. Unfortunately this leaves only two tracking stations with very little geometry on the command module which produces two substantial disadvantages. First, the command module state vector hasn't been updated since before DOI and it's getting kinda worn out and yet it is the one which would have to be used in support of a T₃ launch and rendezvous. Probably more significant is the effect on the nominal mission, namely it is intended for the CSM to track the LM with the sextant at the end of that first rev. It is anticipated that this data will provide the best estimate of LM position on the lunar surface in support of nominal ascent targeting as well as post-flight analysis. In fact, we intend to use this RLS determination in preference to any of the other RLS sources unless there is some reason to suspect it is screwed up. However, for the sextant data to be useful we must have an accurate CSM state vector to reference the sextant data too. This requires better MSFN tracking than had been planned. Accordingly, it was decided that immediately after a T₂ stay decision, the Ascension station would be reconfigured for CSM tracking on the remainder of the descent rev and for the next rev too. It will only be switched back to the LM in the event of a T₃ no-stay decision.

The problem of determining LM position (RLS) to support a T₃ launch is a tough nut to crack. Our choices are based on powered flight navigation by the PGNCS, AGS, and Lear adjusted after touchdown with an improved estimate of LM position at PDI. It is anticipated that the LM's AOT/ gravity alignment data will not be available in time to support the Ascent targeting although if everything goes just right it might be. The point is that none of these data sources have ever been used before and each has its own potential problems that could foul it up badly. This makes its unreasonable to assign hard and fast priorities to these sources today, although everyone agrees that the Lear should probably be the best. The point is, determination of RLS for T₃ is being left open to real-time judgment of the experts who will include whatever bits of intelligence are available during the flight to select the best value. As noted before, the CSM state vector and sextant tracking will normally be used for the nominal ascent, but it obviously won't be available for a T₃ launch.

We discussed the PGNCS reinitialization required if PDI is delayed one rev. It was finally decided that virtually under no circumstance would the state vectors in the PGNCS be updated even though later tracking data is available. The values of RLS will be updated by applying addi- tional propagation biases to account for the extra rev. The exact pro- cedure for doing this is too complicated to put in this memo but I believe it is understood by everybody involved.

And that's that!