How would the state vector be updated in the Apollo Guidance Computer during coasting to/from the moon if communication with Earth was lost entirely?

Question

This source https://www.hq.nasa.gov/alsj/alsj-average_g.html states that:

From time to time, Houston could update the onboard SV using tracking and other available date; [sic] but, generally, it was the AGC's job to update the SV at about two second intervals

Although highly unlikely, let's imagine that communication with MCC disappeared entirely.

During powered flight, the Average-G Routine was used in solving the equations of motion using (1)integrations of three-component dynamic acceleration provided by IMU Pulsed Integrating Pendulous Accelerometers (PIPAs) and (2) three-component values of gravitational acceleration.

During coasting flight, with the engines off, the AGC used the Coasting Integration Routine (Section 5.2 in the GSOP) to update the SV.  Although Earth was the dominant gravitational influence in earth orbit and, likewise the Moon in lunar orbit, the effects of both had to be included to update the SV with sufficient accuracy.  The spacecraft orbit was similar to a Keplerian ellipse, but not quite identical.  The Coasting Integration Routine made use of a venerable, 19th-century perturbation technique called Encke's Method.

Now, the Apollo Guidance Navigation and Control, R-567, section 5, p.5.2-11 (http://www.ibiblio.org/apollo/NARA-SW/R-567-sec5-rev8-5.1-5.2.pdf) has an interesting remark regarding the Coasting Integration Routine:

The LGC Coasting Integration Routine is restricted to earth or lunar orbit and is not to be used in cislunar-midcource space

Question: How was the state vector to be updated in this unfortunate case (no communications with earth and coasting to/from the moon)? Or am I missing something obvious here (i.e. it must've been planned, perhaps, to keep updating it somehow between MCC uploads anyway)?

Bonus question: As for any numerical integration, AGC would inevitably accumulate errors; was there a star sighting procedure, similar to P52 (IMU align), but for obtaining precise state vector from the stars (or any other procedure), without MCC uploading it?

Answer 1

The restrictions you are quoting only apply to the LGC, the computer in the Lunar Module. The Command Module Computer does not have these restrictions (compare the section about the Coasting Integration Routine you quote with the same passage from the document about the CMC: https://www.ibiblio.org/apollo/Documents/R-577-Colossus2-Martin-5.2.pdf). The CMC coasting integration routine does have the necessary data (ephemerides for the Moon and Sun) to provide accurate coasting integration in the midcourse phase of a mission, between Earth and Moon.

To answer the bonus question, the CMC software has a program called Cislunar-Midcourse Navigation (Program 23), which uses the sextant to take horizon/star sightings or landmark/star sightings. The same document I linked above has the equations for that program as well. This was practiced a bit on each mission and would be used if communication is lost with the ground, to have an onboard method of updating the state vector. Another onboard program, the Return-to-Earth program (P37) could then be used to calculate course correction burns to achieve the trajectory for reentry. The LGC does not have this program, it does not have a sextant (only a telescope for IMU alignments) and not the accurate ephemerides necessary for navigating back home to Earth accurately enough.

For Apollo 13 this restriction of course added some additional challenges. The first burn the LM did was under LGC control, a few hours before flying past the Moon. To quote the Mission Operations Report (https://history.nasa.gov/afj/ap13fj/pdf/a13-mission-ops-report-19700428.pdf), PDF page 127:

The LGC is unable to navigate in cislunar space, and how to handle state vectors and target loads became our biggest concern. It was decided to make sure that the RTCC vectors were in the earth sphere of influence, and that the state vectors uplinked to the LGC would be timetagged at TIG - 30, which is the time the LGC would have to integrate the vectors in any burn program.

What that means is that the uplinked state vector was valid at 30 seconds before time of ignition. So any coasting integration by the LGC back and forth wouldn't introduce significant errors, the state vector would be accurate at the time of ignition despite the limitations (but probably not very accurate some time before or after TIG).