AS-206 Spacecraft Computer Program Newsletter

See listJAN 31 196767-FM1-17FM/Deputy Chief, Mission Planning and Analysis DivisionAS-206 Spacecraft Computer Program Newsletter

We had another long AS-206 program development discussion at MIT on January-26th, and some things came up you might find interesting.

First of all, there is only one mission phase that has not been suc- cessfully run at this time – namely, the second APS maneuver. There is some feeling that this may be due to improper targeting as opposed to problems in the actual program. Completion of a satisfactory test of this mission phase will signal configuration control of the assem- bly to be maintained until the final release of the program. It is planned that verification testing to assure flight readiness will be complete on February 15th, and we've set February 17th as the date for the formal MSC review of the AS-206 program verification results. Final acceptance of the program, prior to rope manufacture, is based on this MIT presentation which will be here in Houston.

Although MIT insists that the Digital Auto Pilots are adequate for the mission, there are several program modifications under consideration in this area. In fact, MDRB's have been requested from MIT which must be acted upon very promptly if they are to be included. Briefly, they are the following:

a) As I understand it, an instability, due to fuel slosh, has been discovered making it desirable to modify the Kalman filter gains in the DPS DAP. As presently designed, when the RCS tanks get fairly empty, fuel slosh causes control to oscillate back and forth between the DPS and RCS Digital Auto Pilots. This results in inefficient use of RCS fuel, although it does provide adequate control of the vehicle. Since AS-206 does not have an RCS propellant shortage, it is not mandatory to make the change until a later mission. The primary advantage of doing it now is to get a test of the “ultimate” system.

b) At some time during the DPS maneuver, it was intended to freeze the DPS engine position, i.e., no further steering commands would be given to the DPS and all control would be carried out with the RCS. This had been proposed as an interim fix of the instability problem noted in (a), but subsequent testing at Grumman of the DAP on their digital simu- lation has shown that misalignment of the thrust vector from the space- craft cg actually results in a greater use of RCS fuel than is spent in controlling the fuel slosh induced instability. We have requested an MDRB to fix the program so that it does not freeze the engine position. (Incidentally, there is concern that engine bell ablation or erosion may cause large thrust vector misalignment, and freezing the engine deflection during the maneuver could present a significant problem in that event).

c) MIT is very much concerned that insufficient data will be collected during the AS-206 flight for adequate analysis of the Digital Auto Pilots. It has been found that the PCM data will be saturated due to the unusual platform alignment which is required on this mission. Therefore, they are anxious to obtain another source of this data which they have identified.is essential from the very beginning. One of their proposals is that the downlink be interrupted for four or five seconds during the DPS maneuver, substituting in it's place CDU data sampled every twenty milliseconds. Further, they feel it would be highly desir- able to suppress the DAP during this period in order that the data be independent of control activity. Almost surely this type of program modification will cost a lot of time even if agreement could be reached by all parties that it was an acceptable change technically.

I predict we will not make change (a) but will make change (b) since it's so simple. I really am concerned about not getting the DAP data for postflight analysis since that is one of the primary reasons for flying the mission in the first place. Resolution of whether or not to make change (c) will probably bounce all of the way up to the Spacecraft Program Manager.

MIT reported that it looks like nothing can be done in either the hard- ware or software to fix the AS-206 downrupt problem. This, you recall, is the problem resulting from higher priority computer tasks preventing the computer from servicing the downlink needs ever so often during maneuvers. This causes that data frame to be garbled on the ground. As I understand it, it is possible to unscramble this data postflight, thus it is only a real time flight control problem which we have recognized and agreed to live with on this mission.

I hear that Grumman has not yet been able to use the tees delivered to them due to problems with their own facility. I get the distinct impres- sion that we have been “had” on this. Apparently Grumman knew their facility would not be ready on schedule, and in order to salvage their incentive points, got us (MCC) to give them a waiver based on our confes- sion that the GFE computer program would not be available as promised. I guess we Texans are no match for those slick New York yankees.

That's about it. Obviously our toughest job is going to be wrenching this program out of MIT's grasp, since to them quality still comes before schedule. But that's just a little game we are playing, and I don't consider it unhealthy. I'm really not near as worried about the quality of the AS-206 program as they are, but I am very anxious to get this bunch of experienced AS-206 guys off onto the AS-278 programs as soon as possible.