Upthread: Seventh “C” Mission Rendezvous Mission Techniques meeting (Mar 13, 1968)
Downthread: Status evaluation meeting – “C” Mission Rendezvous (Apr 17, 1968)
See list belowMAR 27 196868-PA-T-69APA/Chief, Apollo Data Priority CoordinationEighth and Ninth “C” Mission Rendezvous Mission Techniques meetings
1. Most of the March 15 and 22 “C” Mission rendezvous Mission Techniques meetings were devoted to discussion of onboard rendezvous navigation with the sextant. This was brought about by the rather bad experience suffered by the 101 flight crew and a number of the flight controllers on the Kennedy Space Center mission simulator earlier in the week. What apparently happened was that whenever sextant data was used in the rendezvous naviga- tion, the resulting maneuver targeting was screwed up. In addition, the displays the crew used for working their onboard charts seemed to be erroneous too. As a result, they had all lost confidence in the capability of the sextant to do rendezvous navigation and felt that either much more reliance must be placed on ground targeting or else someone should explain why it was okay to keep on going like we are. After years of bad-mouthing the sextant, I find it difficult to suddenly start defending it. But an awful lot of analysis and simulation has been done showing the system to have some usefulness. However, it is obvious there is a serious problem somewhere, either in Sundisk, the cape simulators, the procedures, or something. Whatever it is, it has to be straightened out right away. In addition, it is evident that the operational people, Crew and Flight Control do not understand very well how the sextant navigation works and how well, so I volunteered to set up a special meeting to be devoted entirely to this subject to review the work of all organizations who have done work on this system – MIT, MPAD, GCD, MAC, FCSD, etc. I will try to get it organized for April 25, if that suits everyone – and will let you know.
2. One interesting thing that came out of our lengthy discussion was that the only real testing of the rendezvous navigation programs has been on the bit-by-bit simulators at MIT since they too have trouble with their optics in the hybrid simulator and are only able to test the program functionally. That is, they are only able to see that it runs but cannot confirm its accuracy in their hybrid. Furthermore, it also became apparent that the rendezvous navigation has never been tested under heavily dispersed initial conditions. Accordingly, at the March 15th meeting we requested FCSD and MAC to run a few rendezvous profiles on their procedures simulator starting after NSR with large errors in the spacecraft state vector.
3. On March 22 MAC/FCSD presented the results of these runs which they had already completed. What a great outfit those guys are! They had included “actual” sextant observations on our worst case and had also run the specific case which gave trouble at the MSC – a 10 mile range error, which is really bad news. These results seemed to indicate that the sextant was capable of doing a pretty good job – much better than I expected was possible. The status now is that everyone is taking a hard look at the whole situation. Simulator runs and analysis continued. On April 25, we will get everyone together with all their data and review it thoroughly and decide where to go from there.
4. The only other item we devoted much time to was the “tweak” burn between NSR and TPI. This small maneuver (less than 3 fps) was proposed by Ed Lineberry to be made only if TPI had slipped in time so much that lighting conditions during braking would be unacceptable. Lighting at braking on the “C” mission is of much greater importance than on Gemini since we have no ranging device and the SIVB does not have running lights like the Agena did to give some measure of range. Tolerable TPI time slip is said by FCSD to be ± 10 minutes which is just about what we could expect to happen due to anticipated ground control accuracy. Paul Kramer is not in favor of adding in this maneuver, primarily because it offers a chance to screw things up. It does not make the flight controller's job any easier either, although they can handle it. The flight crews, primarily Tom Stafford, are considering the pros and cons and we have agreed to go with their wishes. This is unique for the “C” mission incidentally. Ordinarily, there is insufficient time to do the burn, also this is the only CSM active rendezvous currently planned.
5. Finally, there is a procedure change that is probably worth reporting. The flight crew wants to use onboard computed REFSMMAT for all platform alignments, except retrofire (which they can't do onboard). This is brought about by the way Sundisk is coded, forcing the crew to manually set a flag bit. This is forcing us to do the job on the ground differently than planned, although that is no big deal. Instead if computing and send- ing the REFSMMAT, the MCC will now send a time within the present revolution at which the “nominal alignment” as computed onboard will give the desired platform orientation for rendezvous. Incidentally, using the onboard computed values also forces the crew to make all SPS maneuvers heads up rather than heads down, as they prefer since the Sundisk alignment program assumes that attitude when it compensates for the SPS gimbal angle trim values. This heads up turns out to be fine for rendezvous. In fact, it is rather meaningless since all of the SPS burns are nearly radial anyway. It is just the change in the REFSMMAT procedure that is a shame.