Various presentations presented at the MAPLD '04 conference, by
AGC developers and other knowledgeable folks
This section pertains to a document (E-2448) called "Users' Guide to Apollo GN&CS Major Modes and Routines", presented in several different revisions. While the document itself purports to be general purpose in nature rather than mission-specific, it was nevertheless maintained to remain current, and therefore can be roughly matched (from publication dates and internal information) particularly-relevant missions.
Regarding the Block II AGC schematics, I have heard that there is
a general attitude that they are incomplete, which is true, and
therefore inadequate for allowing one to construct a hardware
simulation of a Block II AGC, which is probably not true.
Mike Stewart, who has in fact built such a hardware simulation,
assesses the adequacy as follows (in slightly edited form):
[It depends] on what is meant by "complete". The logic and interface modules are all present, so working simulations/replicas of the *logic* of the computer, and its connections to the outside world, are certainly possible ...
That being said, there are missing pages, which make it more difficult (and less accurate/"complete") than it needs to be. All of them are in Tray B and the DSKY. [There is only one schematic page] for each -- the clock oscillator in Tray B, and the power supply for the DSKY (D7).
The missing modules are, to my knowledge:
- Analog Alarms Module (B8):
- Filtering for the AGC warning light (the three possible causes of this light were OR'd together in Tray A, then shipped here for "filtering", but I don't know what that entails)
- Voltage monitoring (announced through VFAIL)
- Oscillator monitoring (announced through OSCAL)
- Scaler module monitoring (announced through SCAFAL/2FSFAL)
- A start-up/restart signal whose exact cause I haven't yet identified (STRT2), but probably has to do with voltage stability
- Erasable Driver Module (B9-B10):
- Exactly as it sounds, took the signals generated mostly by modules A14 and A15 and drove the core memory accordingly
- Current Switch Module (B11):
- This is probably used for driving the various currents needed by the Erasable memory. In that capacity, I assume it would receive some or all of the signals ZID, SETEK, RSTKX/, RSTKY/, REX, REY, WEX, and/or WEY, while the Erasable Driver Module handles core selection with XT0E-XT7E, XB0E-XB7E, YT0E-YT7E, and YB0E-YB3E. Or maybe the Erasable Driver Module gets all of those, and has its own set of inputs to the Current Switch Module. Or vice-versa! It's bound to be something along those lines, at least.
- Module B12:
- If that's even a thing. There's a weird wiry-looking thing between modules B11 and B13 on Tray B.
- Sense Amplifier Module (B13-B14):
- Sense signals from memory, one each for fixed and erasable, and put them out on the sense amplifier lines to fill the G register. Interestingly, we've got drawings (maybe even labelled with values somewhere) of the chips used on this board, but not the board itself.
- Strand Select Module (B15):
- Rope driving stuff, although I don't know why it's separate from the Rope Driver module
- Rope Driver Module (B16-B17):
- The main rope drivers. Take signals from A14, A15, and... A6 I think? and drive the ropes
- Indicator Driver Module (D1-D6):
- Contained DSKY relay driver circuits and the relays themselvesPlus, any other ancillary information that wasn't done on a circuit board like DSKY button wiring, pinouts, backplane connections, and such that I can't put a number or name to.
I'd argue that none of this is strictly necessary for a "complete" simulation. Nobody's going to weave their own core/core rope memory anyways... there's tons of ferrite cores on ebay. I did the math. It would take years. So that immediately drops the need for B9-10 and B13-17. It's possible to implement your own versions that respond only to the signals fed directly to those modules (ie without cheating), which is how mine works. ...
The alarms module stuff can be done custom to the application, or without the filter (FLTIN connected straight to FLTOUT), or whatever.
There are enough partial drawings of the indicator driver module that you can cobble something reasonably close to the real thing together, albeit with probably different relay decoding wiring (though there's less correct answers to this than many seem to think) and component values.
THAT BEING SAID, as somebody trying to build a replica that's as accurate as possible, all of these and any other electrical/mechanical drawings are now at the top of my want-list.
This is a series of memos from the MIT Instrumentation Lab dealing with issues of Luminary software development. Of particular interest, if you're concerned with the evolution of the AGC software, many of them memos are used to document the changes of the Luminary code from one revision to the next. In theory, if you had all of them, you could use them to document the complete evolution of Luminary, or at any rate from LUMINARY 4 (memo #22) through LUMINARY 209 (memo #205).
There are over 250 known LUMINARY Memos, of which we have (or are in the process of obtaining) the majority from Don Eyles's personal collection. Here at the Virtual AGC site we are providing these memos in a convenient, readable quality, but higher-quality archival versions are available in our Virtual AGC collection at the Internet Archive. In the table below, the lines which are grayed-out are not in Don's collection at all. The remainder, if there is no hyperlink for them, simply haven't been scanned yet but will presumably appear here eventually.
There is an equivalent series of COLOSSUS and DANCE (SUNDANCE) development memos, and probably others as well, but we have none of them except where they happen to coincide with LUMINARY memos.
LUMINARY Memo #
COLOSSUS or (SUN)DANCE Memo #
Minutes of MSC LM Digital Autopilot Design Review
Synchronization of W-Matix and State Vector
LUMINARY GSOP Chapter 5 and Chapter 4 Review
Recent Changes to PINBALL Affecting DSKY Operation
Minutes of PRC Meeting 2 February 1968
RCS Jet Firings During Gyro Torquing in P52 on SUNDANCE
J. S. Miller
Inhibition of DAP Operation in SUNDANCE and LUMINARY
Hybrid Facility Procedures
Deadband Setting PCR #86
Key Release Light
AGC Time Dependent Constants
SUNDANCE Revisions 280, 281 and 282 and LUMINARY Revision 0
LUMINARY Revisions 1, 2 and 3
Jim Kernan & Schulenberg
LUMINARY Revisions 27 - 34
LUMINARY Revisions 35 - 38
Restrictions to R03 (Verb 48) Inputs
A. Laats & J. Shillingford
LUMINARY Level 3 Verification Plan
LUMINARY Program Changes Suggested at MSC/MIT Lunar Landing Co-Ordidation Meeting Held at MIT on 9/12/68
SUNDANCE Edits for DAP and for Powered Descent
Jim Kernan, Peter Volante
A Variable Time Constant Velocity-Nulling Guidance Law
Accuracy of Verb 83 (Range, Range Rate, Theta Display)
Use of V96 During State Vector / W Matrix Synchronization
Computation Cycle Timing in TPI, TPM Programs
Eugene Muller, Peter Kachmar
Affect of Radar (or the HF Ranging) AGC Interface Problem on F Mission Rendezvous Sequence
Peter Adler, Dana Densmore
Review of Reduction of Coding Approval Procedures
Bruce McCoy, George Cherry
George Cherry (attached is 8/4 Eyles/Cherry PCR 854)
David Moore, Don Eyles
Al Engel, Bruce McCoy
H Mission RTCC Compatibility Testing, Test Plan & Schedule (Preliminary)
Al Engel, Bruce McCoy
Bad Other Vehicle State Vector
Configuration Control of RTCC Digital Environment
Work-around for P32 Bomb-Outs
Peter Volanta, G. Dunbar
The New R12
Allan Klumpp, Don Eyles, Bruce McCoy
Bruce McCoy, Dana Densmore
Phyllis Rye, Peter Peck
DVTOTAL Vs. VGDISP Discrepancy in Powered Flight
Bruce McCoy, Phyllis Rye
Luminary 1D: Which One, What Kind, How Many?
"Erasable Memory Program" for a Guided RCS Burn
Effect of LSPOS "Bum Skinny" in Luminary-1D
Level 6 Testing for Apollo 14
Introduction to ZERLINA 50
LUMINARY Revisions 179 & 180
LUMINARY Revision 181
Summary of Program Change Requests Involving Astrodynamic Coordinate Systems, Ephemerides and Orientations, etc.
LUMINARY Revision 182
LUMINARY Revision 183
Inputs to LM DAP During Descent and Ascent
LUMINARY Revisions 184 & 185
Apollo 14 LM De-Orbit Test
IMU Alignments and LUMINARY 202
LUMINARY Revision 186
LUMINARY Revision 187
LUMINARY Revisions 188 - 190
LUMINARY Revision 191
APS Impulse Burn for APOLLO 14
LUMINARY Revision 192
LUMINARY Revision 193
LUMINARY Revision 194
LUMINARY Revision 195
Fixed memory hardware related constants in Luminary 1D
LUMINARY Revision 196
LUMINARY Revisions 197, 198, 199
Analysis of the Yaw Divergence at P64 Terminus
LUMINARY Revision 200
LUMINARY Revision 201 & 202
Luminary Revision 203
Craig Work, Peter Weissman
DAP performance in Apollo 14 Level 6 tests
P99 — Erasable Memory Program for a Guided RCS Burn — Luminary 1E
V. Dunbar, Peter Volante
Implementation and Testing of PCR 324, PGNCS/AGS RR Data Transfer
DOWNRUPT SEQUENCING, LOST DOWNRUPTS, AND IMPAIRED DOWNLINK INFORMATION
Luminary Revision 204
Craig Work, Peter Weissman
Guidance and Contol Stability Tests of LUMINARY 1E
Luminary Revision 205
Luminary Revisions 206, 207, 208 and 209
Attitude Error Analysis in Special FACI APS Tests
Post-FACI Luminary 1E Tests for R40, Engine-Fail Routine
Apollo 14 Descent Simulation Dispersions: Terrain Model Mismatch Aggravates Drooping Trajectories in P64 and Low Descent Rate in P66
Update to Luminary Memo 178, "Inputs to LM DAP Dusing Descent and Ascent"
Peter Volante, Bill Ostanek
Testing on Non Sign Agreement in TEPHEM in Apollo 14
"Erasable Memory Program" for a guided RCS burn (for Luminary 1E)
Effects of Delayed Tipover on Ascent Trajectories
Guidance and Control Stability Tests of LUMINARY 1E; Part 2
Luminary Test Group
Level 6 Test Description for Luminary 1E
Limitations in the Astrodynamic Orientation and Ephemeris Routines
Craig Schulenberg, Peter Weissman
Impact of PCR 1107 (Abort Bit Backup) on Apollo 15 Abort Procedures
Luminary 1E Program Notes
Apollo 15 LM De-Orbit Performance Test
Descent Abort Procedures for Apollo 15
Erasable Memory Program for LUMINARY Rev. 210 to Provide Backup for DSKY Keys
DAP performance in the Apollo 15 Level 6 Tests
Luminary Test Group
Summary of Level 6 Test Results for LUMINARY 1E
Correction to Luminary Memo #220, "Erasable Memory Program for LUMINARY Rev. 210 to Provide Backup for DSKY Keys"
Craig Schulenberg, Phyllis Rye
Revision 1 of Erasable Memory Program for Backup for DSKY Keys
Failure Protection of the PGNCS/AGS RR Data Transfer
Luminary Test Group
Level 6 Test of DSKY Keystroke Backup Erasable Progeram for LUMINARY 1E
David Moore, Peter Volante
Using P99 LM Deorbit Erasable Program in Earth Orbit (with full DPS/APS configuration)
David Moore, Craig Work, Peter Weissman
Post-FSRR (Luminary 1E) Docked DPS Burns
EFFECT ON ASCENT OF INCORRECT TIME IN AGC
Level 6 Test Description for Mission 16 (PRELIMINARY)
Low Thrust Landings
Bruce McCoy, Don Millard
EMP Control Procedures — Final Iteration
Tentative EMP for Broken CDUX
Crew Corrections for Cross Range Error due to Uncompensated Orbit Precession
EMPs to Display H and H-dot on the DSKY
Luminary Test Group
Luminary Level 6 Test Results for Mission 16
EMP for P47 Ascent
Level 6 Test Description for Mission 17 (PRELIMINARY)
Luminary Test Group
Luminary Level 6 Test Results for Mission 17
EMP to Convert a Bad HMEAS
These items are alphabetical by author, though the "author" is sometimes an organization when no individual authors are listed. A lot of the documents in this group originally came from the now-defunct AGC website of MIT's Dibner Institute for the History of Recent Science and Technology; but whenever the opportunity has arisen, those versions of the documents have been replaced by better scans, so even when the document titles are the same, these may not be the same scans found in other online sources.
The document was prepared while I was working for Al Hopkins and Ray Alonso at the Instrumentation Laboratory and describes the analysis of the crux of a proposed backup system if the AGC became overloaded during the LEM trajectory. Although the backup method described was never used, the document shows the type of analysis that went on "behind the scenes" in support of the entire mission.
Max Faget was a fanatical advocate of the optical tracker as the primary rendezvous navigation sensor. If he had had his way there would have been no rendezvous radar. This was an undocumented chapter in the Apollo program known to those of us who participated as the Rendezvous Wars. Under our tutelage, supported by extensive in-house Monte-Carlo analyses, the Astronaut Office took an uncompromising position on behalf of the radar as the primary rendezvous navigation system.
The wars continued into the Shuttle program, and were lost by our side because the FOD was able to make the case that they could support all rendezvous operations with ground-based tracking, and there was therefore no argument for autonomous on-board capability. Max got his way on the Shuttle, there was no rendezvous radar. By that time I was back in Houston working for a small company under contract to MPAD for orbital operations analysis. I got fired for refusing to lie to Draper about the availability of reference mission data to support some independent analysis they were doing for my former colleagues in SED. Thus ended my involvement in the wars, and I've always treasured those memories.
This document contains nomographs for computing the TPI and M/C maneuvers using LM boresight elevation angle measurements, and raw rendezvous radar data from the tape-meter readout. During the months prior to Apollo 11, I was able to use the GN&C analysis program in Monte-Carlo mode to construct computation tables for the CDH and CSI burns. This was done by perturbing the trajectory about the nominal, and developing power-series expansion functions for the maneuvers in terms of the resulting radar range and range-rate perturbations, obtained from measurements at fixed intervals before each burn. We wanted to be able to verify the on-board maneuver solutions independently of the ground, or in extremis do without them altogether, and still carry out the rendezvous as long as we had an operating radar. Hence our fanatical determination to have the radar as the primary rendezvous sensor.
I'm not sure these nomographic and tabular backups were known to the Instrumentation Lab. They were brute force, but they worked. Never needed, though; the IL software and systems were iron-bottomed and gold-plated... [ellipsis Clark's]
- R-649, "The Apollo Rendezvous Navigation Filter Theory, Description and Performance", Volume 1 of 2, by Eugene S. Muller, Jr., and Peter M. Cachmar, June 1970
- "Crew Procedures Orbital Guidance and Navigation Program, Navigation Section"
In this section, we provide some stuff that doesn't directly
pertain to any of the computers in Apollo or Gemini, but rather to
interesting stuff that the Instrumentation Lab had been contracted
for, and that some of the AGC developers were thus working
on. So this section pertains more to the homage we're paying
to the developers.