Upthread: Invitation to DPS throttling for DOI meeting (Feb 05, 1968)
See list belowFEB 20 196868-PA-T-36APA/Chief, Apollo Data Priority CoordinationSpacecraft computer programs controlling DPS throttling need more changes
1. On February 14 we had a meeting with everyone at MSC, plus MIT and Grumman, who are interested in the way the spacecraft computer program throttles the Descent Propulsion System (DPS). There has been concern that the throttling programs as currently designed are not adequate for the Descent Orbit Insertion (DOI) maneuver on a lunar landing mission, as well as being rather inflexible for DPS maneuvers on the development flights. It was the purpose of our discussion to really understand how the PNGCS is being programmed now and, by considering this subject from all aspects—DPS constraints, crew procedures, guidance accuracy, etc.— to figure out what we should do. As expected, it turned out a number of program changes are highly desirable, if not mandatory! as least for the lunar landing mission. Fortunately, it appears that those considered most necessary are expected to have little schedule impact.
2. As I understand it, this is how the general purpose DPS thrusting program (P-40) works. As currently defined for both Sundance and Luminary this program determines, prior to ignition, if the burn duration at 10% thrust will be greater or less than 95 seconds based on spacecraft weight and delta V. If it is less than 95 seconds the program will not make a throttle change throughout the maneuver, that is, it would maintain and steer the entire maneuver at 10% thrust. If the burn duration is expected to be in excess of 95 seconds it will command 10% thrust for a duration of time loaded in erasable memory and then will advance the throttle to the fixed high thrust setting of about 92½% thrust. This 10% duration, which is now in erasable memory due to a decent Program Change Request (PCR), must be long enough to permit the engine to reach fuel feed and pressurization systems stability (that is, about 5 to 10 seconds) and also to insure that adequate engine gimbal trimming would have occurred to direct the thrust vector through the cg, at least close enough to be within RCS attitude control under full thrust conditions (as much as 26 seconds).
3. The first proposed program change, which is considered mandatory, deals with how the 10% thrust trim duration is set into the computer. It is almost certain the during a lunar landing mission this quantity must be changed by the crew. For example, it will probably be set initially to some value consistent with use of the DPS as a backup to the SPS. Then it will have to be reset once in preparation for the DOI maneuver and again prior to powered descent initiation. At present these settings must be made by the crew using a universal service program for loading into an octal address. The proposed PCR is to make this quantity a standard display/ crew-input parameter in the digital autopilot (DAP) data load routine (R03). George Cherry (MIT) suggests use on a blank register available during display of DPS gimbal angles in which 10% thrust trim duration would be displayed and/or input in units of centiseconds. This parameter would be used to control the time at which the throttle would be advanced by setting it to a small value. It would also be used to insure that the throttle is never advanced by input of a time known to be in excess of the required burn duration at 10%. Rick Nobles, Floyd Bennett (FM), and Tom Price (FS) will prepare this PCR which George Cherry anticipates will create little impact.
4. A second PCR, to be prepared by those same guys, requests removal of the 95 second burn duration test described above. This PCR is also considered mandatory since the present logic would prevent an automatic throttle increase for DOI and other maneuvers of similar magnitude. For example, at 10% thrust the DOI maneuver takes about 60 seconds. Since this is less than 95 seconds, the entire maneuver would be carried out at 10% thrust.
5. The third PCR deals with crew input of the thrust level the PNCGS would automatically call for after satisfying the 10% requirement. As noted above, the program currently will only advance the throttle to the 92½% point. For a maneuver such as DOI some lower throttle setting must be used in order to provide steady state conditions for a long enough period at the high thrust level to give accurately guided cut off conditions. The proposal is to make it possible to obtain an automatic throttle setting at some intermediate value under astronaut control. It was noted that there is another blank register in the DAP data load routine (R03) display of LM and command module masses. This program change may required more time to implement than we are willing to accept and it is not considered mandatory. However, it is only possible to get along without it is we accept manual throttle control by the crew, overriding the PNGCS. The operation procedure would be to select the manual throttle mode and, after adequate time at 10% thrust, the crew would advance the throttle. It is anticipated they could hit the throttle setting desired to within about 5% which is probably okay. The computer would steer and cut off the engine properly as long as the throttle setting is left undisturbed after the initial advance. Incidentally, this procedure provides a manual throttling test during DOI which we felt might be nice prior to having to use it during the final stages of powered descent. Thus, even if the automatic mode provided by this PCR were available, it is likely we would use the manual operational mode for DOI. In addition to preparing this PCR, Rick Nobles and Floyd Bennett will attempt to determine the inaccuracies associated with the manual throttle control procedure to insure that dispersions are within acceptable bounds. Experience gained in the simulator is essential for this analysis.
6. We next discussed whether or not the three PCR's noted above should also be included in the Powered Descent DPS Thrust program (P-63). The 95 second logic is not in P-63 now so obviously there is no need to remove that. The other two program changes should be made the same as P-40 in order to standardize procedures and to permit use of common routines.
7. The only other DPS thrust program is P-70 which is used for DPS aborts. What to do with P-70 is not at all clear. For one thing, as now programmed aborts early in powered descent result in a DPS shutdown followed by an attitude change of about 160° and then a complete reignition sequence. No one likes the idea of shutting off the engine at a time like that. Furthermore there is concern that the engine should not be stopped and started again so quickly due to freezing problems. However, to fix the program to leave the engine on is a substantial change and so we're going to have to look at this one some more. Another problem associated with P-70 is that Chapters 4 and 5 of the GSOP are not in agreement and the way the program is currently coded it does not work. These are internal MIT problems. However, I expect once they figure out what to do we will get involved.
8. In summary, there are two program changes which really must be made, neither of which should impact the schedule significantly, at least on Luminary. We confirmed that there should be no problem in controlling the throttle manually during DOI and there is some advantage to doing it that way. However, an approval of a third PCR would provide the flexibility needed for automatic DPS control to lower than full thrust. Whether or not it is reasonable to turn off and then restart the DPS as currently programmed in the abort program remains to be seen. And, finally, there are some design problems in the abort program itself which MIT must resolve themselves.