Various presentations presented at the MAPLD '04 conference, by
AGC developers and other knowledgeable folks
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
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.
[Jay,] I can't let you get away with saying that you weren't a key contributor to the manned lunar mission software. The AS 501/502 and 206 software provided the foundation for the subsequent manned mission software development. — Peter Volante, AGC developer[Jay is] one of the top system and software heroes of the Apollo software. — Ed Copps, AGC developer
[And from Jay himself:] Here’s my history on Apollo. I was interpreting and writing Block I code at GM’s AC Spark Plug in Milwaukee (they built the IMU and needed to understand and write AGC code for testing) when I was transferred to MIT/IL in mid-1966. MIT was seriously falling behind schedule on the lunar mission software, so NASA instructed MIT to allow some outside contractor/support persons to come in and relieve MIT of the burden of unmanned mission software and to also help them with lunar mission and test software. I was one of about 100 non-MIT people who worked out of IL-7 and IL-11, and I may have been the only one involved with the unmanned mission software. When I got there, Ed Copps assigned me to work on the AS-501, identical AS-502, and AS-206 flights. The first two were Block I computers/software that flew on the Big Saturn-V for its first two unmanned flights. Besides testing the new Saturn-V to boost the vehicle into a high trajectory path and come streaming back into the earth’s atmosphere at lunar-return speed, the mission also tested the ability of the AGC software and heat shield to survive the plunge into the ocean. AS-501/502 were a slight rework of the AS-202 software that was to be astronauted until the tragic fire. So, I worked under Dan Lickly, who was the official rope mother for that flight combination. I made the 202→501 software mods, extensively tested (e.g., simulated) the mission(s), and supported the AS-501 flight at NASA.Then for the AS-206 (LM-1) flight (Block II, the first unmanned LM descent/ascent engine tests in earth orbit), I worked under Jim Miller (rope mother) and solely made mods to the first Block II code (I think AS-204), tested, and supported it. I wrote several MIT/IL docs.So, in a nut-shell, I was not a very key contributor to MIT/IL’s manned lunar mission software, other than to relieve MIT people of the burden for modifying/testing/etc. less-important mission software.During my one-year at MIT/IL, I got familiar with their all-digital simulations on their Honeywell mainframe. When I returned to GM, I took advantage of that familiarity and friendship developed at MIT to create a “Two-Machine” simulator that interfaced an actual AGC to a mini-based, almost real-time digital simulation of GN&C hardware, spacecraft dynamics, and environmental interactions. Using “recipes” of accelerometer and gimbal rates, I was able to quickly satisfy the AGC’s read requests without significantly having to stop the AGC to wait much. This simulator allowed GM to better support the later Apollo and Skylab missions from the IMU and NASA standpoints. For instance, we could serve as an independent site to test emergency Apollo procedures (like cold-starting the AGC, asking the LM to “push-burn” the CSM, etc.)
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"