Results of “C” Mission Rendezvous Review meeting – April 22, 1968

FA/Chairman, Apollo Software Configuration Control BoardAPR 26 196868-PA-T-88APA/Chief, Apollo Data Priority CoordinationResults of “C” Mission Rendezvous Review meeting – April 22, 1968

1. At your request, I set up a meeting on our current “C” mission rendezvous problems with participation by all organizations interested in this activity. The attached attendee list will show you they were well represented. Our basic purpose was to determine current status of the situation and to recommend where to go from here with regard to the problems which have recently been coming to light (both real and imaginative) primarily as a result of the crew training exercises at KSC.

2. In summary:

a. It is the consensus that the Sundisk program is acceptable for flight – that is, program changes and new ropes need not be made.

b. Post release Sundisk program testing is underway to further verify its flight readiness. Results to date have been highly satis- factory and no new program bugs have been found. This testing is continuing, but confidence is high that it will be completed successfully.

c. A number of open items in the crew procedures were discussed and decisions were made which will permit consistent, unified work in the future with regard to development of the crew timeline, simulation activity, program verification testing, etc.

d. A number of desirable program changes were discussed which should be incorporated in the follow-on spacecraft computer programs.

Each of these items will be amplified below.

3. Post release verification testing of programs associated with the rendezvous exercise, currently underway, falls into three categories. They are as follows:

a. Testing of the sextant rendezvous navigation. Two runs have been laid out in detail covering the period from the NSR maneuver to the terminal phase midcourse maneuver which are currently being run at MIT on their bit-by-bit simulator, their hybrid simulator, and their digital engineering simulation program. Math Physics Branch (MPAD) is designing an additional run utilizing the final crew procedures, parts of which are defined in this memorandum. MIT will also make this run. According to Flight Software Branch, these three runs are being made a part of the formal post release verification and will be well documented.

b. Twelve rendezvous targeting and burn runs covering the period between NSR and braking have been defined by MPAD and Flight Crew. Four of these tests will be run on the MIT bit-by-bit simulator and also on the North American ME-101. All twelve of these runs are being processed through the MIT engineering simulation program, the equivalent MPAD programs, and the bit-by-bit simulation here at MSC. Many of these runs have already been made and their results have been compared very favorably. In addition, the initial conditions and other data required to make these runs have been delivered to the AMS at KSC. The purpose of this is to provide test cases with which they may check out their simulator. It is not to test the Sundisk program, and as of this date, they don't intend to run these cases.

c. A completely independent test plan has been designed by TRW and reviewed by MSC defining a series of runs to be made on the local bit-by- bit simulator.

It was the consensus that successful completion of all this testing should provide adequate confidence in Sundisk for its use in the “C” mission.

4. Crew Procedures

In order that everyone may carry on using the same approach, we discussed and chose the following crew procedures which should be considered official. That is, they should not be changed without future discussion and widespread dissemination since so many organiza- tions are concerned.

a. The first and most important involved the workaround procedure for the terminal phase midcourse maneuver targeting program (P-35). It has been decided to handle this program deficiency by designating that the CSM state vector rather than the S-IVB state vector be updated based on sextant observations after TPI. Tests have shown that this technique works very well. In fact, it provides a theoretically perfect solution.

b. It was also decided that the crew would make a so-called “phony mark” after the TPI maneuver and prior to beginning navigation. This decision was made in spite of the fact that MPAD representatives did not feel this operation was necessary.

c. The consensus is that the “phony mark” is not necessary following the midcourse correction maneuver and so it will not be made at that time.

d. It was decided to set the Delta R and Delta V test parameters to zero so that after each sextant observation the crew will be forced to observe the effect of that observation on the state vector. It will also cause a program alarm to occur. The primary benefit to be gained from this procedure is that it will provide the crew with information regarding the trend of state vector changes which will be helpful in their editing process. It should be noted that this is the procedure currently in use on all simulators at MIT, KSC, MAC, etc. It was observed that after more simulator experience, it may be desirable to load values somewhat larger than zero to simplify the crew operation a little. This would be a minor modification to the procedure.

e. Based on the strong recommendation of MIT, it was decided to reinitialize the W-matrix during the second navigation period between NSR and TPI. This procedure was also adopted over the objection of MPAD personnel who intend to carry out future analysis to provide their contention that it is not necessary and perhaps that it is even damaging. There was also discussion of the values to be used for reinitialization of the W-matrix at this time. MIT currently proposes 1,000 feet and 1 fps, although it seems that values as much as three times larger may be recommended before the flight.

f. The flight crew has concern over allowing the average “G” program (P-47) to run continuously after the second midcourse correction. They are afraid that the accelerometer bias may introduce unacceptable error in the state vector. MPAD was given the action item of determining the effect of various levels of accelerometer bias acting over different periods of time on the range and range rate displays. This information should give some insight into how the system should be operated when someone establishes what accelerometer bias we should expect. As of now, they will continue to run P-47.

5. At least two program modifications should be considered for future spacecraft programs:

a. It has come to light that the Sundisk short burn SPS logic will cause a premature engine shut down amounting to about four fps as a result of some inaccurate spacecraft characteristics frozen in fixed computer memory. It is recommended that these parameters be located in erasable so that they may be loaded after true values are known.

b. There is an infuriating “Delta V residual bounce” following spacecraft maneuvers which preclude accurate maneuver execution. MIT is in the process of tracking down the cause of this. Hopefully it may be fixed in the later programs or at least maybe we will find out what it really is!

6. Finally, KSC simulator people were asked if any possible assistance not already available could be provided to help solve their problems. It was their opinion that at this time they have a number of known things that must be done which will substantially improve their facility and until these are completed, they feel no organized help from MSC or MIT would be particularly helpful.