A critical aspect of the cause of the famous 1202 and 1201 alarms reported by the Apollo Guidance Computer (AGC) during the decent of the Apollo 11 LM is that the rendezvous radar (RR) was using a "reference signal" provided by the LM which was out of sync with the signals coming from the rendezvous radar. I understand the consequences of the many interrupts caused by this situation, and how those interrupts lead to the alarms. But it's unclear to me why this phase difference matters, and why it generated so many interrupts in the first place.

Why did the Apollo 11 LM's RR and AGC being out of phase generate large numbers of interrupts?

  • $\begingroup$ (This may be a basic electronics or signal processing question, in which case feel free to propose a move.) $\endgroup$
    – orome
    Commented Jul 27, 2019 at 19:51
  • $\begingroup$ The answer to this question requires a lot of detail specific to the Apollo LM's systems and so is 100% on-topic here and most likely to receive excellent attention here as well. $\endgroup$
    – uhoh
    Commented Jul 27, 2019 at 23:44
  • $\begingroup$ Are you perhaps confusing two things? The radar split-bit problem identified in LM-5 for Apollo 11 (but fixed before launch) was a phasing issue. See section 6.4.4 page labelled 223 in ibiblio.org/apollo/hrst/archive/1029.pdf Perhaps I was wrong, but I thought that was separate from the flight problem which was due to running the RR in an unplanned way. $\endgroup$ Commented Jul 28, 2019 at 1:58
  • $\begingroup$ @BobJacobsen see space.stackexchange.com/a/37372/6944 Discussed at a very high level on page 225 of the pdf you linked in your comment. $\endgroup$ Commented Jul 28, 2019 at 15:34
  • $\begingroup$ A good explanation is given in Light Years Ahead | The 1969 Apollo Guidance Computer, after the 36 minute mark. $\endgroup$
    – Fred
    Commented Feb 11, 2023 at 10:21

1 Answer 1


This answer is based on the text @organic-marble cited in his now deleted answer and general knowledge about angular resolvers and electronics.

Apollo Guidance System

source: Don Eyles at www.klabs.org

The radar antenna of Apollo 11 was steerable to point it at the target no matter how the orientation of the LM was (within some 10° range at least). Steering happened automatically by tracking the target by its radar echo. For calculations the computer needed to know the direction of the antenna. This was measured by a common device, a so-called angle resolver. Wikipedia provides this schematic image of the device.

Angle Resolver from Wikipedia

The black bars are three coils, S1 and S2 are fixed and R is rotating with the antenna. Now an electric alternating current (28V, 800 Hz) is applied to R. Like in a transformer this induces a current in the two coils S1 and S2. The strength of this current depends on the angular position of R - if it's aligned with a coil the induced current is high, if it's perpendicular the current is 0.

The task of the coupling data unit (CDU) was to measure these currents, calculate the position and report changes to the main guidance computer (LGC). The important part is the ratio of currents in the two coils, not their absolute value. This is important as we deal with alternating currents that change constantly.

Now there is a slight complication here: The value of an alternating current is 0 1600 times per second (2x 800 Hz), no matter how high the maximum is. If measured close to this point in time, also the ratio of the two voltages can't be determined resulting in bad precision and strongly varying results. These cause the CDU to issue position update commands to the LGC which in turn has to cope with this additional load, causing the known overload error.

Why were the currents measured at the wrong point in time? Because the phase of the voltage used to drive coil R and the phase of the voltage used for timing the measurement of currents were out of sync as this was not a requirement for the design of the power supply. After switching on the systems were not in a defined phase with respect to each other, so by chance the CDU sampled the signals either at a good point (in a large region around 0° or 180° phase) or a bad point (close to 90° or 270°).

As @OrganicMarble points out, this was seen twice during testing but not seen as a major problem. First, the pointing information was still pretty accurate. Sampling the current is not an instantaneous thing, but takes some time during which the current is integrated. Hence, there is always some current to measure, never 0. Second, the increased noise due to measuring tiny currents only tends to average out over many measurements so that the accumulated position changes stored in the computers registers was usable.

Lastly, only two of the three operating modes are affected as can be seen in the schematic shown above. In "LGC" mode the reference signal would have the correct phase - and it looks like this was the intended mode of operation for most of the time and was changed only a month before Apollo 11.

  • 1
    $\begingroup$ Nice - a divide by zero problem? One quibble: the problem was found at least twice in testing, see space.stackexchange.com/a/37372/6944 $\endgroup$ Commented Jul 28, 2019 at 13:07
  • 2
    $\begingroup$ @OrganicMarble Not really. Say you have a constant measurement error of 10 units. Then calculating $\frac{1000\pm10}{1000 \pm 10}$ gives you something close to 1, but if you have $\frac{1\pm10}{1\pm10}$ you get anything between 0 and 10 (in absolute numbers). So, measure small values close to the zero-crossing in the signal gives you bad results. $\endgroup$
    – asdfex
    Commented Jul 28, 2019 at 13:11
  • 1
    $\begingroup$ This was only a problem in Slew or Auto -- because then the timing was driven by the abort guidance computer, in LGC mode the timing was driven by the LGC. Also, it didn't make a huge difference, it just pushed the time spent processing the pointing to 15% of the CPU time, which unfortunately was just a little more than was spare. $\endgroup$
    – user20636
    Commented Jul 28, 2019 at 16:11
  • 2
    $\begingroup$ @orome There is no way to update the value directly. There are just "increase" (by one step) and "decrease" flags (causing an interrupt to the CPU to make this adjustment to the stored value). With good measurements such a change happens say once a second and only if the antenna moves. With bad measurements this is constantly adjusted up and down even if the antenna doesn't move. $\endgroup$
    – asdfex
    Commented Jul 28, 2019 at 17:48
  • 1
    $\begingroup$ modest cough I pointed out that the problem was seen in testing. $\endgroup$ Commented Jul 28, 2019 at 18:00

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.