See list attachedOctober 7, 196868-PA-T-215APA/Chief, Apollo Data Priority CoordinationCis-lunar spacecraft navigation for C’
We are still thrashing around trying to figure out what to do with regard to cis-lunar spacecraft navigation for the C' mission. It is not clear whether a couple of things are really necessary or not. If we could get rid of them, it would simplify things. Unfortunately, we aren't confident it is safe to delete them at this time, so they are still included. Specifically, I am speaking of:
a. Conditioning and preserving the W-matrix
b. Making star/landmark (both earth and lunar) observations as opposed to relying completely upon star/horizon measurements.
I think we have chosen the technique requiring the least diddling around by the crew which preserves the W-matrix. It is based on the following decisions:
a. The MSFN state vector will always be used for maneuver execution.
b. The MSFN state vector will always be used to reinitialize the onboard navigation state vector. That is, we don't intend to preserve the onboard computed value when new data comes from the ground.
c. The ground will only update the CMC CSM state vectors by uplinks then into the LM state vector memory locations. (This applies for all MCC's – translunar and transearth – except for the final one at EI minus two hours. In that case, the ground will send the ground state vector to the command module slots.)
It will be the standard procedure to send state vectors for whatever the spacecraft needs them (primarily MCC maneuver execution) into the LM state vector CMC memory locations since this does not effect the W-matrix. When preparing for a maneuver, the crew will transfer these MSFN state vectors into the command module state vector slots by use of programs provided specifically for that purpose. This, of course, will wipe out any state vectors that have been computed using the onboard navigation and subsequent navigation will use these state vectors transmitted from the ground as a new starting point. As the crew executes the maneuver, the guidance system will, of course, measure the maneuver and add it to the state vectors providing the best source following the maneuver. The crew should then transfer these new updated CSM state vectors back into the LM slots prior to any additional onboard navigation in order to preserve them in case of communication failure, whatever that is. Note that a small change is being made in the MCC-H/RTCC to permit automatically generating a command message to uplink the CSM state vectors into the CMC memory locations used for the LM state vectors.
Someone came up with a clever idea for comparing state vectors onboard the spacecraft. By calling up a rendezvous display of range and range rate between the LM and the command module, they are about to see the dis- placement and velocity of the state vectors – that is, the MSFN versus the onboard values. How the capability should be used is not at all clear.
Something else came up at the meeting that was rather startling and may have major impact. Namely, it may be impossible to do effective transearth navigation on a number of days in the current C' launch window. Apparently on the later days of the launch window, the sun, when viewed from the spacecraft may be too close to the earth horizon and star/horizon observa- tions by the sextant may be impossible to obtain for a substantial part of the transearth coast. MIT, MPAD, and GCD are in the process of establishing what days in the launch window are effected, based on the various systems constraints. Once this situation has been clarified, it may be necessary to make a decision as to whether it is acceptable to launch the C' mission on a day when transearth navigation capability onboard the spacecraft does not really exist. How does that grab you, “Communication Loss” fans?