See list belowMAY 29 196868-PA-T-108APA/Chief, Apollo Data Priority CoordinationSpacecraft computer program – things dealing with lunar descent and aborts from it
1. I spent an interesting morning at MIT on May 16 with George Cherry, Dan Lickly, Norm Sears, and Craig Schulenberg talking about Luminary – how it works and some things that really haven't been defined yet. It primarily dealt with lunar descent and aborts from lunar descent.
2. Powered Descent Braking Phase (P63)
There is a question in MIT's cumulative mind as to whether the x-axis override logic is consistant with the current landing radar utilization logic. Recently a PCR was approved to permit use of land- ing radar data earlier in powered descent but no changes were made in the x-axis override logic. MIT questioned if this is consistant. However, more basic than that, there is the question of whether or not any of these things should be keyed to navigated altitude as they currently are, rather than time of initiation from powered descent or simply crew choice. I believe we all are concerned that using navi- gated altitude as the system is currently designed may cause the system to be locked out from doing the right thing. Specifically, if the PGNCS has computed the wrong altitude for some reason, even though the crew may know they are getting true altitude from the landing radar, there is no way to get the PGNCS to accept it. Although this probably won't happen, the consequences are so serious that none of us could see any reason for designing the system in this inflexible way. The way the guidance system currently weight the landing radar data precludes its use above 35,000 feet based on some sort of radar specifications. Even if the navigated altitude were correct, we may be making a mistake providing this data lockout in the computer program at this early point in program development.
3. MIT would like to make a design change in the Powered Descent Landing Phase programs P65/P66/P67. As currently designed, the crew exits these final descent programs by hitting “Proceed,” which causes the LGC to do such things as storing gimbal angles and LM position, turning off average “g,” turning off the DAP, turning off the abort monitor (which prevents PGNCS recognition of an Abort and Abort Stage discrete), sets the lunar surface flag, displays LM position to the crew, etc. This procedure is enabled when the computer thinks the spacecraft is within 50 feet of the lunar surface. There are two potential problems here. First of all the crew is within one “Proceed” of catastrophy if he prematurely hits the button inadvertently. This is unlikely but is also unnecessary since there is no need to terminate that program by a single key stroke. Worse than that, if for some reason the PGNCS never realizes the altitude is less than 50 feet, there is no way for the crew to terminate the program in such a way that all those important functions are carried out. It is MIT's proposal to change the design by adding a new program (P68) which would be called in a standard way via Verb 37. This program would do all the things previously done following the “Proceed” in the final descent program and could be exited directly to any callable program crew procedures dictate such as Ascent (P12) or IMU Alignment (P57). I think it is a good idea that they do that. P68 would not be called til several minutes after the lunar landing, of course, in order to maintain the PGNCS in a state of readiness to Abort Stage from the lunar surface, if that unlikely event were necessary.
4. I learned some interesting things with regard to the APS Abort program (P71) – answers to questions noted in last week's bulletin on aborts from powered descent. Specifically, P71 does not have any so-called short burn logic. That is, if P71 is called when the duration of an APS burn required to fulfill the targeting requirements is less than four or five seconds, the PGNCS will not provide a well controlled cutoff. Actually, what it will do following Abort Stage is to turn off the APS as soon as it sees what is going on, which will be late. I asked MIT to look this over and tell us exactly what will happen in this unlikely event – for example, how big an overburn will we get? I'm sure this is an acceptable situation and the procedures we outlined in last week's memo are still okay. Of course, it may mean that RCS trimming is needed but at least the spacecraft would be in a safe orbit while it's doing it. (Incidentally, if the crew wants to do four jet RCS trimming following an abort, they will have to call up the DAP data load (R03) and reset it from the two jet logic used in preparation for powered descent.)
5. Finally, MIT people noted that there are two ways of calling up the abort programs (P70 and P71). The preferable way, of course, is through the use of the Abort and Abort Stage buttons. The alternate means is using Verb 37. They noted that program coding and testing could be carried out more efficiently if we were to delete the Verb 37 mode. None of us could think of an occasion for using Verb 37 as the primary technique. In fact, the only contingency conceivable would be to backup the abort discrete. At the time, I was inclined to think that this was unnecessary but after further reflection, I am now reluctant to see that discrete backup removed, particularly in the wake of our stage verify discussions.
6. I expect to see some PCR's or PCN's in the near future on some of the things noted above. Maybe this note will give you a little time to think about them.