67-PA-T-127A.md

layout	title	date	from	serial	subject
tindallgram	67-PA-T-127A	Dec 26 1967	PA/Chief, Apollo Data Priority Coordination	67-PA-T-127A	LM rendezvous radar during Ascent is about to go over the brink.

1. It turns out providing justification for obtaining LM rendezvous radar data during Ascent from the lunar surface is as difficult as getting the data itself. This memorandum is to let you know that unless some sharp cookie comes along with sufficient justification we ain't gonna get it!

2. There have been numerous memoranda and discussions in which the requirement for the use of the LM rendezvous radar during powered ascent was stated primarily as a data source to evaluate the performance of the ACS and the PNGCS both by the crew onboard the spacecraft and on the ground. In addition, intuition supported this idea and so a good deal of work has proceded based on the assumption that the rendezvous radar data would be available. However, due to a series of circumstances still beyond my comprehension, the LM spacecraft computer program - Luminary - does not provide the capability for obtaining this data. In fact, as far as I can tell it is deficient in two respects. First, no automatic radar acquisition capability is provided during ascent which would be mandatory since radar lock can only be acquired after the big pitch maneuver at approximately lift off plus 10 seconds. And, second, once it's locked on no provision has been made for getting the radar data onto the telemetry downlink. Luminary change requests are in the mill to add these capabilities. However, it is anticipated that the schedule impact will be substantial, and since the current program delivery schedule is only marginally acceptable, modifications to it have to be in the mandatory category. In order to establish this justification we discussed this subject in detail during the December 21 Ascent Phase Data Priority meeting. Much to my amazement, mandatory justification does not appear to exist. The rationale for this statement is the subject of the following paragraph. The point to be made here is that unless a much stronger story can be put together, these proposed program changes will probably be rejected and rendezvous radar data will not be available either during powered ascent or immediately after insertion into lunar orbit.

3. It had been proposed that rendezvous radar data was essential to permit the MCC to monitor ascent and advise the crew of the necessity to switch from the PNGCS to the AGS. How this would be done is thoroughly documented elsewhere but basically it was intended to determine the range rate of the LM with respect to the command module utilizing the PNGCS LM state vector and the AGS LM state vector separately, and then to compare these values with that actually measured utilizing the rendezvous radar. This information would be displayed on analog plots in the control center. The same comparison process would simultaneously be carried out with the range rate as computed and measured along the line of sight between the LM and on an MSFN tracking station. In each case, the rendezvous radar and the MSFN provide an independent data source upon which to evaluate performance of the PNGCS and the AGS. Studies to date indicate that in most cases of guidance system malfunction, comparison against only the MSFN is adquate to identify the errant system.

4. The most significant exception is certain accelerometer scale factor or bias cases perpendicular to the line of sight between the LM and the MSFN station. That is, the MSFN comparison is always capable of determining unacceptable dispersions in flight path angle, but sometimes is not able to provide an independent measurement of the velocity magnitude particularly when inserting into lunar orbit from a centrally located landing site. The result is, if throughout ascent both the AGS and the PNGCS appear to be operating properly based on all data available but at insertion the PNGCS shuts down the APS engine producing conditions which the AGS indicates to be suborbital, it will be impossible to determine which guidance system is correct without rendezvous radar data. Accordingly, it would be necessary to reinitiate thrusting immediately probably using the RCS in order to provide safe orbital conditions based on the AGS readout. Subsequently, MSFN tracking and/or rendezvous radar measurements obtained as soon as possible will reveal whether it was the AGS or the PNGCS which was in error. If it truly was the PNGCS at fault creating an underburn at insertion the proper action will have been taken. On the other hand, if the AGS was in error the situation will be: the rendezvous catch up rate will have been decreased to a point where an extra revolution or so will probably be necessary, probably a lot of APS/RCS fuel will have been expended and, based on the (good) PNGCS and MSFN the situation will have to be sorted out and handled on a contingency basis. This particular set of circumstances is extremely unlikely. The action taken is undesirable but not catastrophic. It would probably require use of the command module to assist in the rendezvous but RCS is being provided for that specific situation. Rendezvous radar data during ascent and immediately following insertion would have prevented it from happening but it does not appear to be mandatory. So unless the analysis now underway disproves the above rationale, someone else comes alone with a good reason or if the Luminary program delivery impact turns out to be small, I expect these requested changes will not be made in the first version of Luminary, and maybe never. At this time I don't expect any of those things to turn out favorably. Furthermore, if we can't get this data we probably ought to simplify the RTCC programs and MCC displays to be compatible.

5. Finally, if we can't prove we need rendezvous radar data for Ascent, it's about certain we won't be able to for Descent either. But we do have to have it on T/M while the LM is on the lunar surface for "launch site" position determination and Ascent targeting. This data must be at a high update rate (10 to 30 samples per minute) and preferably without "improving" the spacecraft state vectors in the LM computer.