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

enter image description here

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?

  • $\begingroup$ Star sighting was used only to align the drift errors of the inertial platform. Only angle errors of attitude but no positional errors. Stars are too far away for distance measurement relative to Earth and the Moon. $\endgroup$
    – Uwe
    Commented Dec 1, 2019 at 14:12

1 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).

  • $\begingroup$ Thank you for the thorough answer! It all makes sense now. Interesting, how did Apollo 13 get away with this restriction of Lunar Module computer? $\endgroup$ Commented Dec 1, 2019 at 20:08
  • 1
    $\begingroup$ @LeoS 13 had no AGC at all for substantial portions of the trans-Earth coast, not even the LM. Tracking was provided by the ground, and the midcourse burns were done on AGS at ground instruction. I think they were given some contingency PADs but given the sorry state of their systems, if they had suffered a communication loss at any point much prior to the LM separation they probably would have been in deep trouble. $\endgroup$
    – hobbs
    Commented Dec 2, 2019 at 7:39
  • 1
    $\begingroup$ @LeoS To add to what hobbs said, I added a bit about Apollo 13 to my answer, to answer that question. $\endgroup$
    – indy91
    Commented Dec 2, 2019 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.