Upthread: Spacecraft computer program newsletter (Dec 18, 1967)
Downthread: Apollo spacecraft computer program newsletter (Feb 19, 1969)
See list belowMAY 24 196868-PA-T-106APA/Chief, Apollo Data Priority CoordinationSpacecraft computer program newsletter
1. I learned some things at MIT last week that seemed interesting enough to justify this note. Of course, it deals primarily with the spacecraft computer programs and their influence on the mission techniques we are developing.
2. Pete Conrad reported that during their KSC LMS simulation, they have experienced an apparent deficiency in Sundance when making a docked DPS burn. He says that the DPS engine gimbal angles do not get changed at all during that low thrust period at the beginning of the burn which was provided specifically for trimming them. MIT looked into this problem and agreed that for some reason the program does appear to work – or not work – like Pete says. Their preliminary guess as to the course of this is that with low thrust and high inertial the gimbal trim estimator may be experiencing underflow. That is, the computer is simply not able to determine that a movement of the trim gimbal is necessary as it is currently coded. Of course, the RCS jets are very active both before and after throttle up.
3. Our requirements for getting rendezvous radar (RR) data on the down- link while the LM is on the lunar surface was discussed again, and I am afraid I really blew it. MIT has resisted the program change we requested and I am beginning to think they may very well be right. That is, I am not so darn sure any more that the program as currently designed and coded is not good enough. In any case, George Cherry now proposes to look into a very simple change which can be made in the lunar surface navigation program (P22), which would substantially increase the frequency of RR data on the downlink. All that it amounts to is to remove the delay after the previous computations before the computer collects another batch of RR data. Right now this delay is 15 seconds. If we eliminate this delay and operate P22 in the “no state vector update” mode, the computer should cycle very fast. George Cherry is going to make an estimate of what this RR downlink frequency would be as well as evaluating the schedule impact for this change. I would be surprised if it is not acceptable to MSC even if it is not perfect – whatever perfect is.
4. As Colossus is currently designed, the crew is required to press the “Proceed” button during the period of maximum reentry G's to obtain a DSKY display change. A PCR had been submitted to make this procedure automatic. However, on future consideration, we are not so sure that it is a good thing to do. The initial display parameter in P65 are used in the primary go/no go logic employed by the crew in evaluating the G&N performance to decide whether to stay on it or to go with the EMS backup. It is essential that they see these parameters and an automatic “Proceed” could wipe them out before they have seen and digested them under certain circumstances. Accordingly, I suspect we should delete our request. The discussions have revealed, however, that some modification in the coding will probably be needed to make sure the system will work throughout the rest of the entry even if the crew does not provide the “Proceed” signal.
5. Here is one more note in the continuing “Stage Verify” story. Accord- ing to John Norton the lunar ascent program (P12) no longer checks stage verify. That strikes me as a real improvement in the program but it mystifies me as how it go changed without a PCR or PCN, or even letting anyone know. Norton, of course, uncovered it by going meticulously through the program listing.