LM high-bit rate telemetry data is not mandatory

See list attachedNovember 17, 196969-PA-T-145APA/Chief, Apollo Data Priority CoordinationLM high-bit rate telemetry data is not mandatory

A somewhat controversial mission rule is on the books for the Apollo 12 flight dealing with LM high-bit rate data. Specifically, it indicates that it is all right to proceed with the mission (e.g., undocking, DOI, PDI, etc.) in the absence of LM high-bit rate data with an implied pro- vision that some sort of procedures would be carried out to verify the PGNCS is operating properly. On November 13 Chris Kraft, Sig Sjoberg Gene Kranz, Cliff Charlesworth, Steve Bales, and I reviewed that mission rule and concluded that it is proper and will be used on Apollo 12. I'm writing this memo at CCK's request to record that fact.

Prior to the meeting, Steve Bales prepared a rev-by-rev listing of the procedures to be followed to certify proper PGNCS operation from power-up through lunar surface operation, which showed that it is possible through use of voice communications and some special onboard procedures to check the computer, the gyros, and the accelerometers. It is obvious that these procedures impose an additional workload on both the crew and the flight controllers, which could force delay of DOI. Under no circumstances would DOI be performed prior to the satisfactory completion of the checks. The most significant impact would result from loss of command uplink capability since that would force the crew to manually input a lot of data into the computer via the DSKY, which they ordinarily do not have to pay any attention to at all. The LM state vectors (twice), RLS, and perhaps the REFSMMAT are the most significant of these. However, as I understand it, loss of high-bit rate telemetry does not necessarily mean the uplink wouldn't work; for example, it should be operational if the failure is in the high-gain antenna. And, it was agreed to use it to avoid the voice read up of the data and the crew input task. The new thing brought about by absence of high-bit rate telemetry is that it would be necessary for the crew to read out and voice down all of the data for the MCC to verify complete and accurate receipt.

Subsequent to the meeting, it was recalled that the Luminary program has the capability of computing its own Descent REFSMMAT – (P52 Option 4) – using a landing time supplied by the ground. This capability should probably be used although it may introduce other problems. Steve is checking this out.

Another item requiring further investigation deals with the erasable memory. As you know, it is standard procedure to dump erasable memory to the ground for a complete check to make sure none of the parameters loaded preflight have been lost. It is not obvious that this is a mandatory requirement since in no flight has a single parameter ever been found to be in error. Furthermore, MIT conducted a special test involving numerous off-on cycling of the LGC with a check of the E-memory on each cycle. Again, no loss of data was observed. (The test exceeded 10,000 cycles when it was terminated due to test-equipment failure.) Steve was given the action of identifying E-memory critical parameters which the crew must check if an E-memory dump cannot be performed.

Incidentally, it will be necessary forthe crew to synchronize the LGC clock without MCC assistance. They should be able to do this using the CMC as a reference to within 0.3 seconds which is considered acceptable.

In summary, the mission rule is correct as written. This meeting confirmed that but also uncovered some open items which we must have squared away before descent without high-bit rate data.