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.
Other sources referencing the erasable loads include:
TBD
The principal references for AGC electrical schematics and
mechanical drawings on this website are now the following two
pages:
See also: System Handbooks and
the other AC/Delco documents in the
"Miscellaneous" section below.
"Published to inform members of the technical staff at MIT and
Raytheon about the AGC and the Apollo G & N system",
apparently with emphasis on the electronics.
These memos primarily relate to the electrical design of the AGC.
The "LUMINARY Memos" are 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, are the many memos 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). Some of the gaps can also be filled in with SCB meeting reports, in a later section of this page. But if you're interested in such change-control issues, then anomaly reports, program-change requests (PCRs), and program-change notices (PCNs) are even more to the point. Here are the ones we know about:
- "Contents of Luminary 1E": A collection apparently kept by Russ Larson of all (as far as we know!) of the anomalies, PCRs, and PCNs addressed in moving from LUMINARY 1D (Apollo 14) to LUMINARY 1E (Apollo 15-17). Nearly 400 pages of software configuration management goodness!
- "Contents of Luminary 1D": A similar collection for LUMINARY 1D. We have not yet been able to scan this.
But back to the memos. There are over 250 known LUMINARY Memos, of which we've gotten 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 relate to memos about which we have some information but not the actual memos themselves. Following the table are many more memos of a similar nature that were not officially named as "LUMINARY Memos".
LUMINARY Memo #
COLOSSUS or (SUN)DANCE Memo #
Date
Author
Subject
1
DANCE 2
COLOSSUS 1
11/7/67
J. Rhode
2
DANCE 7
11/15/67
Steve Copps
Tiger Team
3
DANCE 8
11/13/67
George Cherry
Minutes of MSC LM Digital Autopilot Design Review
4
11/29/67
George Cherry
5
DANCE 14
11/27/67
J. Saponaro
Synchronization of W-Matix and State Vector
6
1/12/68
George Cherry
7
1/16/68
George Cherry
LUMINARY GSOP Chapter 5 and Chapter 4 Review
8
DANCE 34
1/24/68
John Vella
Recent Changes to PINBALL Affecting DSKY Operation
9
COLOSSUS ?
2/6/68
A. Martorano
Minutes of PRC Meeting 2 February 1968
10
DANCE 37
2/9/68
George Cherry
RCS Jet Firings During Gyro Torquing in P52 on SUNDANCE
11
DANCE 38
2/12/68
J. S. Miller
Inhibition of DAP Operation in SUNDANCE and LUMINARY
12
DANCE 40
2/13/68
S. Davis
Hybrid Facility Procedures
13
DANCE 45
2/26/68
George Cherry
Deadband Setting PCR #86
14
DANCE 48
3/4/68
Alex Kosmala
Key Release Light
15
3/8/68
N. Neville
SETUP504
16
COLOSSUS 41
3/14/68
Alex Kosmala
ABORT
17
DANCE 51
COLOSSUS 423/15/68
J. Saponaro
AGC Time Dependent Constants
18
3/?/68
R. Tinkham
LUMINARY Downlist
19
3/4/68
Allan Klumpp
20
DANCE 57
4/1/68
Jim Kernan
SUNDANCE Revisions 280, 281 and 282 and LUMINARY Revision 0
21
4/8/68
Craig Schulenberg
LUMINARY Revisions 1, 2 and 3
22
4/15/68
Craig Schulenberg
23
4/22/68
Craig Schulenberg
24
DANCE 69
COLOSSUS 52
4/24/68
C. Braunhardt
25
4/30/68
Craig Schulenberg
26
COLOSSUS 58
5/13/68
Don Eyles
27
5/10/68
Allan Klumpp
28
5/14/68
Craig Schulenberg
29
6/6/68
Craig Schulenberg
30
6/7/68
Jim Kernan & Schulenberg
31
6/12/68
Craig Schulenberg
32
6/24/68
Peter Weissman
33
6/24/68
George Cherry
34
7/15/68
Craig Schulenberg
35
7/30/68
George Cherry
36
DANCE 83
7/30/68
George Cherry
Computing the Lag Angles which Prevent Beginning and Supervised DAP Maneuvers
37
8/5/68
Craig Schulenberg
LUMINARY Revisions 35 - 38
38
DANCE 84
8/6/68
Craig Work
Restrictions to R03 (Verb 48) Inputs
39
8/27/68
George Cherry
Scheduling Proposed Modifications to the LUMINARY Digital Autopilot
40
9/5/68
Craig Schulenberg
41
8/28/68
A. Laats & J. Shillingford
LUMINARY Level 3 Verification Plan
42
9/12/68
George Cherry
43
9/16/68
George Cherry
44
9/19/68
Don Eyles
45
9/24/68
Don Eyles
46
10/15/68
George Cherry
LUMINARY Level IV Test Data Requirements for Pre-FACI Review
47
10/29/68
George Cherry
48
10/24/68
J. Connor
49
11/1/68
Craig Schulenberg
50
11/2/68
Craig Schulenberg
51
11/2/68
Craig Schulenberg
52
11/3/68
Craig Schulenberg
53
11/12/68
George Cherry
54
11/18/68
George Cherry
55
12/4/68
Craig Schulenberg
56
DANCE 86
12/4/68
George Cherry
57
12/9/68
George Cherry
58
12/17/68
Craig Schulenberg
59
DANCE 87
1/3/69
Craig Work
SUNDANCE Edits for DAP and for Powered Descent
60
1/9/69
Jim Kernan, Peter Volante
61
1/14/69
Craig Schulenberg
62
1/24/69
George Cherry
63
1/27/69
George Cherry
A Derivation of the Improved Lunar Landing Guidance Equations
64
2/4/69
Jim Kernan
65
2/7/69
George Cherry
66
2/12/69
George Cherry
Aborts from the Lunar Landing & Nominal Lunar Ascent Targetting
67
2/17/69
Craig Schulenberg
68
2/20/69
George Cherry
69
3/10/69
Craig Work
70
COLOSSUS 163
3/13/69
Joe Saponaro
Accuracy of Verb 83 (Range, Range Rate, Theta Display)
71
3/14/69
Peter Volante
72
COLOSSUS 167
Bill Ostanek
Use of V96 During State Vector / W Matrix Synchronization
73
3/27/69
Craig Schulenberg
74
3/31/69
Peter Adler
75
4/1/69
George Cherry
76
4/1/69
Don Eyles
77
4/3/69
George Cherry
78
4/10/69
Craig Schulenberg
79
COLOSSUS 171
4/15/69
Jane Goode
Computation Cycle Timing in TPI, TPM Programs
80
4/24/69
Don Eyles
81
4/28/69
Don Eyles
82
5/8/69
J.E. Jones
83
5/19/69
Jim Kernan
84
5/21/69
Don Eyles
85
5/21/69
Jim Kernan
86
COLOSSUS 183
5/21/69
Eugene Muller, Peter Kachmar
Affect of Radar (or the HF Ranging) AGC Interface Problem on F Mission Rendezvous Sequence
87
5/28/69
George Cherry
George Lowe's Decision at CCB Regarding LGC Radar Interface Problem
88
6/5/69
Don Eyles
89
6/23/69
Peter Adler, Dana Densmore
90
COLOSSUS 191
6/30/69
Jenny Flaherty
Memo Indexes
91
7/7/69
Craig Schulenberg
92
7/10/69
Craig Schulenberg
93
7/14/69
J.E. Jones
94
7/14/69
Bruce McCoy
95
7/9/69
Robert Covelli
96
7/14/69
Bruce McCoy
97
7/16/69
Don Eyles
98
COLOSSUS 198
7/22/69
Margaret Hamilton
Review of Reduction of Coding Approval Procedures
99
7/23/69
George Cherry
100
7/31/69
Craig Schulenberg
101
8/4/69
Bruce McCoy, George Cherry
102
8/6/69
George Cherry (attached is 8/4 Eyles/Cherry PCR 854)
Some Results of the Apollo 12 Pinpoint Lunar Landing Data Priority Meeting
103
8/6/69
Craig Schulenberg
104
8/8/69
David Moore, Don Eyles
105
COLOSSUS 209
8/14/69
Al Engel, Bruce McCoy
H Mission RTCC Compatibility Testing, Test Plan & Schedule (Preliminary)
106
COLOSSUS 210
8/14/69
Al Engel, Bruce McCoy
RTCC Compatibility Testing at MIT, Current Understanding of Scope, Responsibilities, etc.
107
8/20/69
Craig Schulenberg
108
8/22/69
Bruce McCoy
109
9/9/69
Bruce McCoy
110
COLOSSUS 213
9/10/69
Bill Ostanek
Bad Other Vehicle State Vector
111
9/19/69
Bruce McCoy
112
9/22/69
M. Albert
113
COLOSSUS 218
10/2/69
S. David
Configuration Control of RTCC Digital Environment
114
10/7/69
Russ Larson
115
10/9/69
Don Eyles
116
10/22/69
Larry Berman
117
10/24/69
George Kalan
Special Crew Procedures Necessary for Controlling the CSM-Docked Configuration with the LEM DAP
118
10/27/69
Don Eyles
119
10/30/69
Harry McOuat
120
11/5/69
Russ Larson
121
11/5/69
Bruce McCoy
122
11/6/69
Dana Densmore
123
11/18/69
Don Eyles
124
11/11/69
Dana Densmore
125
COLOSSUS 232
11/21/69
D. Reinke
Work-around for P32 Bomb-Outs
126
12/2/69
Don Eyles
127
12/3/69
Bruce McCoy
128
12/3/69
Bruce McCoy
129
12/5/69
Dana Densmore
130
12/15/69
Russ Larson
131
1/2/70
Dana Densmore
132
COLOSSUS 240
1/8/70
Ken Greene
133
1/9/70
Peter Volanta, G. Dunbar
134
1/19/70
Dana Densmore
135
1/23/70
Robert Covelli
Downrupt Losses During Periods of High Computer Activity Programs
136
1/29/70
Dana Densmore
137
1/30/70
Russ Larson
138
2/14/70
Don Eyles
139
3/3/70
Don Eyles
140
3/4/70
Allan Klumpp
141
3/10/70
Larry Berman
142
3/18/70
Dana Densmore
143
3/24/70
Allan Klumpp
144
4/6/70
Don Eyles
145
5/5/70
Dana Densmore
146
5/?/70
Robert Covelli
The New R12
147
5/5/70
Allan Klumpp, Don Eyles, Bruce McCoy
148
5/11/70
Bruce McCoy
149
5/13/70
Don Eyles
150
5/15/70
Dana Densmore
151
5/19/70
Dana Densmore
152
5/21/70
Don Eyles
153
5/26/70
Sharon Albert
154
6/1/70
Larry Berman
155
6/1/70
Bruce McCoy
156
6/9/70
Dana Densmore
157
6/10/70
Dana Densmore
158
6/18/70
Bruce McCoy, Dana Densmore
159
7/10/70
Russ Larson
160
7/16/70
David Moore
161
7/17/70
Don Eyles
162
7/20/70
Don Eyles
163
7/21/70
Don Eyles
164
7/22/70
Phyllis Rye, Peter Peck
165
7/28/70
Don Eyles
166
7/23/70
David Moore
167
8/17/70
Bruce McCoy, Phyllis Rye
167 (rev 1)
9/17/70
Bruce McCoy, Phyllis Rye
168
8/18/70
Robert Covelli
169
9/1/70
Harry McOuat
170
9/15/70
Bruce McCoy
171
9/16/70
Don Eyles
172
10/11/70
Dana Densmore
173
10/12/70
Dana Densmore
174
COLOSSUS 293
10/9/70
Bill Robertson
175
10/13/70
Dana Densmore
176
10/14/70
Dana Densmore
177
10/22/70
Don Eyles
178
10/20/70
Peter Weissman
179
10/27/70
Dana Densmore
180
12/15/70
David Moore
181
12/15/70
Don Millard
182
12/8/70
Dana Densmore
183
12/9/70
Dana Densmore
184
12/15/70
Dana Densmore
185
12/17/70
Dana Densmore
186
12/22/70
David Moore
187
12/18/70
Dana Densmore
188
12/20/70
Dana Densmore
189
12/28/70
Dana Densmore
190
12/29/70
Dana Densmore
191
1/4/71
Harry McOuat
192
1/5/71
Dana Densmore
193
1/8/71
Dana Densmore
194
1/22/71
Allan Klumpp
195
1/11/71
Dana Densmore
196
1/13/71
Dana Densmore
197
1/15/71
Dana Densmore
198
1/29/71
Craig Work, Peter Weissman
199
2/12/71
David Moore
P99 — Erasable Memory Program for a Guided RCS Burn — Luminary 1E
200
2/22/71
V. Dunbar, Peter Volante
Implementation and Testing of PCR 324, PGNCS/AGS RR Data Transfer
201
COLOSSUS 310
2/16/71
Dana Densmore
DOWNRUPT SEQUENCING, LOST DOWNRUPTS, AND IMPAIRED DOWNLINK INFORMATION
202
2/16/71
Dana Densmore
203
2/23/71
Craig Work, Peter Weissman
204
2/24/71
Dana Densmore
205
2/26/71
Dana Densmore
206
3/9/71
Peter Weissman
207
3/17/71
David Moore
208
3/16/71
Allan Klumpp
209
3/23/71
Peter Weissman
Update to Luminary Memo 178, "Inputs to LM DAP During Descent and Ascent"
210
COLOSSUS 312
3/23/71
Peter Volante, Bill Ostanek
211 (rev 1)
4/28/71
David Moore
"Erasable Memory Program" for a guided RCS burn (for Luminary 1E)
212
3/29/71
Larry Berman
213
3/31/71
Craig Work
214 (rev 1)
4/6/71
Luminary Test Group
215
COLOSSUS 316
4/20/71
William Robertson
Limitations in the Astrodynamic Orientation and Ephemeris Routines
216
4/23/71
Craig Schulenberg, Peter Weissman
Impact of PCR 1107 (Abort Bit Backup) on Apollo 15 Abort Procedures
217
5/6/71
Russ Larson
218
5/19/71
David Moore
219
5/26/71
Craig Schulenberg
220
6/4/71
Craig Schulenberg
Erasable Memory Program for LUMINARY Rev. 210 to Provide Backup for DSKY Keys
221
7/12/71
Craig Work
222
6/15/71
Luminary Test Group
223
6/17/71
Craig Schulenberg
224
6/22/71
Craig Schulenberg, Phyllis Rye
Revision 1 of Erasable Memory Program for Backup for DSKY Keys
225
7/8/71
Peter Volante
226
227
7/13/71
Luminary Test Group
Level 6 Test of DSKY Keystroke Backup Erasable Progeram for LUMINARY 1E
228
7/21/71
David Moore, Peter Volante
Using P99 LM Deorbit Erasable Program in Earth Orbit (with full DPS/APS configuration)
229
7/15/71
David Moore, Craig Work, Peter Weissman
230
9/10/71
Larry Berman
231
11/8/71
Don Millard
232
11/16/71
Don Eyles
233
COLOSSUS 326
11/23/71
Margaret Hamilton
234
COLOSSUS 327
11/30/71
Bruce McCoy, Don Millard
235 (rev 1)
2/22/72
Don Eyles
236
12/23/71
Larry Berman
Crew Corrections for Cross Range Error due to Uncompensated Orbit Precession
237
238
239
2/22/72
Don Eyles
240
3/2/72
Luminary Test Group
24X
4/14/72
Don Eyles
Latest EMP 103B
241
242
243
244
4/18/72
Don Eyles
245
246
247
9/1/72
Don Millard
248
249
250
10/20/72
Luminary Test Group
251
252
11/20/72
Don Eyles
≥ 253
This is a series of memos from the MIT Instrumentation Lab dealing with issues of Colossus software development. There are over 325 known COLOSSUS Memos, so the tiny selection we provide here is paltry indeed.
SKYLARK, if you'll recall, is the AGC software that replaced COLOSSUS (and was adapted from it) in the command modules used for the Apollo-Skylab and Apollo-Soyuz missions. We have the text of a few of the Program Change Requests (PCRs), though unfortunately as of yet, none of the Program Change Notices (PCNs), and just one of the Memos. The table of PCRs and PCNs below mostly comes from Appendix A of Section 2 of the SKYLARK GSOP. (Even so, the GSOP does not list all PCRs and PCNs, and is only current through March 1972.)
It's interesting to note that many of the changes listed in the PCRs are simply deletions of lunar code that would be unnecessary for a CM-to-Skylab mission. I think that a "normal" software-developer perspective on this would be that deletion of the working code, even if the code itself is unnecessary, represents more of a risk in terms of creating undetected breakage than simply leaving the code in place and not using it would be. However, in working with higher-reliability code — disclaimer: my only familiarity with such matters is in working with airborne code in the U.S., which is currently governed by a document called RTCA DO-178C, and thus I don't really know what they thought about it in 1970 in the space biz — there is a concept of "dead code", i.e., code that is never executed under the software requirements, and specifically never tested; the dead code must be completely removed from software beyond the absolute lowest level of criticality. The theory behind this is that if somehow that dead code actually did manage to be executed for some reason, then the result would be bad. I imagine that's the theory behind the removal in SKYLARK as well: i.e., the risk of executing bad code is worse than the risk of undetected breakage. On the other hand, I suppose the removal could be just a matter of trying to reduce the cost, by physically removing a handful of ferrite memory cores and their associated wiring. I wonder what the actual cost tradeoff would have been between lifting those cores into space vs all of the development and testing time associated with the removal?
Memo, PCR, or PCN #
Written
Approved
Author
Scope
Subject
SKYLARK Memo (unnumbered)
10/9/70 n/a
William M. Robertson
n/a
Summary of Program Change Requests Involving Astrodynamic
Coordinate Systems, Ephemerides and Orientations, etc.
PCR SL003
2/25/70
1/28/71
R. O. Nobles
Code and GSOP
Improved short-burn logic to desensitize with respect to variations in the SPS engine.
PCR SL004
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded verb 94 (cislunar tracking).
PCR SL005
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded verb 59 (optics calibration mark).
PCR SL006
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded verb 52 (offset landing site mark).
PCR SL007
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded verbs 44 and 45 (set and reset of surface flag).
PCR SL008
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded routine 57 (optics calibration routine).
PCR SL009
3/3/70
1/28/71
S. A. Gorman
GSOP only
Deletion of unneeded routine 33 (CMC-LGC clock synchronization).
PCR SL010
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded routine 05 (S-band antenna routine) and verb 64.
PCR SL011
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded programs 72-76.
PCR SL012
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded programs 65 (up control) and 66 (ballistic).
PCR SL013
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded option 4 (lunar surface alignment) from programs 52 and 54.
PCR SL014
?
?
?
Code and GSOP
Program 39 deletion.
PCR SL015
?
?
?
Code and GSOP
Program 38 deletion
PCR SL016
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded program 37 (return-to-earth).
PCR SL017
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded program 23 (cislunar midcourse navigation).
PCR SL018
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of unneeded program 22 (orbital navigation).
PCR SL019
?
?
?
Code and GSOP
Program 24 deletion.
PCR SL021
3/3/70
1/28/71
S. A. Gorman
Code and GSOP
Deletion of program 32 (CSI) due to development of new targeting procedures (probably PCR SL030 below).
PCR SL022
2/26/70
1/28/71
Bedford F. Cockrell
Code and GSOP
Change of a constant to desensitize with respect to gravitational perturbation by the moon.
PCR SL025
2/26/70
1/28/71
Bedford F. Cockrell
Code and GSOP
Extend VHF range beyond limit of 327.67 nautical miles.
PCR SL030
2/27/70
1/28/71
R. R. Regelbrugge
Code and GSOP
Addition of NCC maneuver computation capability.
PCR SL032
6/10/70
1/28/71
M. C. Contella
Code and GSOP
Incorporation of smoothing filter for VHF range rate computation and display.
PCR SL033
7/29/70
1/28/71
Bedford F. Cockrell
Code and GSOP
Use of fixed coordinate system to avoid mission-by-mission coordinate-system changes.
SKYLAB Memo 3-70
(SKYLARK Memo 23A?)
7/29/70
n/a
William M. Robertson
n/a
Detailed software-design data regarding PCR SL033.
PCR SL035
7/7/70
1/28/71
S. G. Bales
Code and GSOP
Addition of TEPHEM to telemetry downlist.
PCR SL036
7/9/70
1/28/71
C. B. Parker
Code and GSOP
New (backup) method of specifying attitude data in case of star tracker failure.
SKYLARK Memo 27
4/20/71
n/a
William Robertson
n/a
Limitations in the Astrodynamic Orientation and Ephemeris Routines PCR SL040
?
?
?
?
Skylab digital autopilot
PCR SL042
?
?
?
?
Skylab four maneuver DKI sequence
PCR SL048
?
?
?
?
Conversion of RCS DAP phase plane fixed memory constants of erasable load.
PCR SL051 REV 1
?
?
?
Code and GSOP
Skylark downlist changes
PCR SL400
?
?
?
Code and GSOP
Program 15 deletion
PCR SL402
?
?
?
Code and GSOP
Eliminate 481 day TEPHEM limitation in Lunar-Solar ephemerides routine
PCR SL405
?
?
?
?
Transform optics angles to tracking angles.
PCN SL409
?
?
?
Code and GSOP
Modification to PCR SL022
PCN SL410
?
?
?
Code and GSOP
Delete Lunar capability
PCN SL411
?
?
?
Code and GSOP
Delete HAM targetting program
PCN SL412
?
?
?
Code and GSOP
Delete ECSTEER
PCR SL413
?
?
?
?
ATM orientation determination program (P50)
PCR SL414
?
?
?
?
Docked alignment capability in P51
PCR SL415
?
?
?
?
Docked alignment capability in P52 PCR SL416
?
?
?
Code and GSOP
Add gyro trim to R50
PCN SL417
?
?
?
Code and GSOP
Deletion of 9 dimensional capability
PCN SL422
?
?
?
Code and GSOP
Initialize rendezvous navigation to update the CSM state vector
PCR SL423
?
?
?
Code and GSOP
Change conic to precision integration in all rendezvous targetting programs.
PCR SL424
?
?
?
Code and GSOP
Improve minkey gyro torquing logic
PCR SL428
?
?
?
?
Modification of Skylark Memo #14: Preliminary Skylab Rendezvous Targeting Plan for the Skylab GSOP
PCR SL431
?
?
?
?
R04 roll preference specification
PCR SL434
?
?
?
Code and GSOP
Correct αATM in P50.
PCN SL435
?
?
?
Code and GSOP
Do not automatically take VHF in P20
PCN SL436
?
?
?
Code and GSOP
Nominal use of ATM sources in P52 and P54.
PCN SL438
?
?
?
Code and GSOP
Incorrect star tracker angle in P55.
PCR SL439 REV 1
?
?
?
Code and GSOP
VHF range rate filter enable/disable by extended verb.
PCN SL442
?
?
?
Code and GSOP
Modification to R22
PCR SL448
?
?
?
?
Modification no. 4 to Skylark memo no. 14
PCR SL449
?
?
?
?
Forced firings for docked DAP auto maneuvers
PCR SL452
?
?
?
?
Precision integration for V90
PCR SL454
?
?
?
?
Docked DAP alarm codes
PCN SL455
?
?
?
Code and GSOP
Change to P35, P36 and R00 to fix anomaly ART 07
PCN SL456
?
?
?
Code and GSOP
Zeroing HOLDFLAG
PCR SL459
?
?
?
?
VHFR changes
PCR SL464
?
?
?
Code and GSOP
Set NN = 0 in P35
PCN SL467
?
?
?
Code and GSOP
Change VHFTIME to MARKTIME on the powered downlist.
The Software Control Board (or perhaps Software Change Board, or
perhaps Software Configuration Board, or even Software
Configuration Control Board ... I'm not really sure, but does it
really make a difference?) meetings were meetings held between the
MIT Instrumentation Lab and the Manned Spacecraft Center, and I
presume other parties as needed, to approve or disapprove PCRs
(Program Change Requests) and PCNs (Program Change Notices), as
well as to report the closure of such items. As such, they
can serve (for our purposes) to fill in gaps in LUMINARY Memo or
COLOSSUS Memo series in order to track AGC revision-to-revision
changes. We don't have many of these, but Don Eyles has
given us a few in order to help understand some of the changes in
Luminary 131 for Apollo 13 that weren't tracked by the LUMINARY
Memos.
Various sections above cover problem and change reports for a
variety of specific areas of implementation or responsibility
(LUMINARY, SKYLARK, SCB resolution, etc.). Reports that
don't obviously fit into any of those areas of specification are
collected in this section.
In this section, we collect documents whose primary interest for
us is that they discuss the disposition of specific AGC/DSKY
units, and/or refer to them or their constituent modules
specifically in terms of their part numbers and serial
numbers. In other words, anything that allows us to discuss
what AGC/DSKY units or their constituent parts (like software)
were used for what purposes. There are other documents which
also contain such information but which were cataloged before this
specific category of documents was invented, so it may take a
while before all such information is linked here.
These items are alphabetical by author, though the "author" is
sometimes an organization when no individual authors are listed.
John
F. McKenna, Jr., E-2462, "SIMFAM:
Description and Operation" (1970). SIMFAM is a
"braid memory" adapter used for ground testing of the AGC,
allowing you to use braid memory in place of the AGC's normal
core memory. There is a (paywalled) 1966 paper about braid
memory in the IEEE
Transactions on Electronic Computers, by Aldrich and
Alonso. "Braid memory" is apparently a term invented by
the authors of the paper. It is a form of "transformer
memory". Transformer memory, to quote the paper, "make[s]
use of magnetic coupling, linear, or nonlinear, between a set of
interrogation lines and a set of sense lines. ... The
appeal of such memories is based on the permanence of the
information, which is of advantage in control systems, and on
the intuitive feeling that it should be possible to build large
(about 106 bits), fast (about 1μs cycle time), fixed
memories at a cost substantially below that of equivalent core
storage," in spite of the fact that the cost of core memory was
"rapidly dropping" at that time. In particular, the
"braid" variety of transformer memories, based on something
called a Dimond switch, could be manufactured by being woven on
a loom in order to reduce manufacturing cost. Each "braid"
is a string of transformers, with each step of the weaving
process adding another transformer to the string, so the speed
of manufacture could be increased simply by having the loom
simultaneously operate on more braids in parallel. They
mention that a 64-string loom was in operation and that a
256-string loom was under development (see picture to the
right).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.
Note: The document scans listed in this section are now obsolete for most practical purposes, because far better scans of the documents have since been provided. Simply use the engineering-drawing search engine to find the "good" scans for most of them. (Document MH01-01380-216 is not in the search engine, but can be found by rummaging through the unindexed scans of North American Aviation Interface Revision Notices.) The material in this section (specifically, the inferior scans) has been retained anyway, but should be regarded as a last resort for trying to resolve legibility problems. I have not changed the explanations accompanying the document links below, even though they do not fully reflect the current situation. The explanations, however, do contain valuable information about how to interpret the "good" scans as well as the "bad" ones. Besides the documents listed in this section, many other documents of a similar nature exist among the engineering-drawing scans, principally though not exclusively in "aperture card" Box 431, Box 433, Box 434, Box 435, and Box 436. You are invited to browse the indices of those boxes and index-pages of all other aperture-card boxes for documents of interest that don't appear elsewhere in this document-library page. However, your searches for such documents will generally be assisted greatly by knowing the desired document number.
This is an unusual section, in that it categorizes documents according where they came from and the technique used to digitize them, rather than the contents of the documents as such. They are collected here, with an apology (in the old sense of the term) that I'm giving once (here!) because I don't care to repeat it over and over again.
In brief, a number of documents were encountered at NARA Southwest that had been converted to "microform" that were deemed significant enough to reproduce for you, but for which I personally have chosen an inferior method of digitization, due to limitations of time and money. I will say that it's better having these scans than not, in lieu of having better ones, but there's no doubt that their quality is shockingly poor. They are mostly, but not entirely, legible. With effort. Perhaps it's worth noting that all of the scans in this section are expected to be replaced by much, much higher-quality scans, probably before the end of 2021.
A fuller explanation of these microform "aperture cards" can be found on our "Documentation Quest!" page, but as a brief example, imagine a 400-page document on aperture cards. At current prices, NARA would be willing to digitize it for you for $1600, or you could go to the facility personally and make a relatively high-quality scan using NARA's equipment for about $160 (plus 12 hours of your own time), or you could go there and make a low-quality scan for free with your own flatbed scanner for $0 (plus 3 hours of your own time). Now, I have scanned many, many engineering drawings from NARA aperture cards using the mid-price option, because it's reasonably cost-effective to do so, and you can see those on the MIT/IL engineering-drawing index page. But for longer documents, for obvious reasons, I chose the free option.
Aperture cards hold photographic negatives, and the document scans I've made from them are presented as-is. I.e., as negatives. They could be easily converted to positives and post-processed with brightness and contrast adjustments that would make them easier to read, but I've chosen not to do so in most cases, because I preferred to get the scans into public view rather than hold onto them for however long it would take to work out the perfect post-processing for them. Plus, most such post-processing results in image rot that I prefer not to incur at this stage. The fact that I've not done this post-processing means that these scans will be perceived as being of even lower quality than they actually are. Perhaps you can figure out the perfect adjustments for me, and let me know how to do it the best way! But there are also true quality issues, in which portions of some scans appear blurry and out of focus, which I presently don't understand. Perhaps some pages will require rescanning in the future for legibility reasons.
Another fun feature of these documents is that rather than containing a nice, contiguous sequence of pages, we instead provide all (or all available) revisions of the document, one after the other: rev "-", followed by rev "A", followed by rev "B", and so on. Consequently, the sequence of pages will often have holes and duplications, though hopefully one could form a complete final-revision document from all of the pages if one were so inclined. If you are so inclined, I'd be happy to accept such a version from you.
Finally, since these documents are being provided only in their "raw" form, I've not attempted to turn them into nice, tidy PDFs, so at the moment, you can see these scans only in their raw forms at our Internet Archive site.
All right, enough of the apology! Here, finally, is a list of the actual documents:
See also: AGC
Electrical Schematics.
These documents relate primarily to the Saturn rockets, but one
notable feature is that chapter 2 of each document provides a
detailed mission timeline for events insofar as they relate to the
various stages of the rockets.
Note that this section doesn't include things like GSOP
documents, Operational Databooks, etc., which have their own
sections above, but is simply a catch-all for everything I haven't
already listed that's mission specific or specific to a mission
class.
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"
| Flowchart Number |
Nature of Difference |
|---|---|
| FC-2100 |
Changed |
| FC-2140 |
Changed |
| FC-2220 |
Only in 2D |
| FC-2235 |
Only in 2D |
| FC-2242 |
Changed |
| FC-2280 |
Only in 2D |
| FC-2283 |
Only in 2D |
| FC-2290 |
Changed |
| FC-2300 |
Changed |
| FC-2310 |
Only in 2C |
| FC-2363 |
Only in 2D |
| FC-2370 |
Changed |
| FC-2390 |
Changed |
| FC-2430 |
Changed |
| FC-2440 |
Changed |
| FC-2595 |
Only in 2C |
| FC-2600 |
Changed |
| FC-2631 |
Changed |
| FC-2640 |
Only in 2D |
| FC-2641 |
Only in 2D |
| FC-2642 |
Changed |
| FC-2650 |
Changed |
| FC-2670 |
Changed |
| FC-2682 |
Only in 2C |
| FC-2683 |
Changed |
| FC-2710 |
Only in 2C |
| FC-2730 |
Changed |
| FC-2760 |
Changed |
March 1962 |
July 1962 |
November 1962 |
December 1962 |
January 1963 |
February 1963 |
Revision
6 March 1963 |
Revision
7 April 1963 |
| Revision
8 May 1963 |
June 1963 |
July 1963 |
August 1963 |
Revision
12 September 1963 |
Revision
13 October 1963 |
Revision
14 November 1963 |
Revision
15 December 1963 |
| Revision
16 January 1964 |
Revision
17 February 1964 |
Revision
18 March 1964 |
Revision
19 April 1964 |
Revision
20 May 1964 |
Revision
21 June 1964 |
Revision
22 July 1964 |
Revision
23 August 1964 |
| Revision
24 September 1964 |
Revision
25 October 1964 |
Revision
26 November 1964 |
Revision
27 December 1964 |
Revision
28 January 1965 |
Revision
29 February 1965 |
Revision
30 March 1965 |
Revision
31 April 1965 |
| Revision
32 May 1965 |
June 1965 |
July 1965 |
August 1965 |
September 1965 |
October 1965 |
November 1965 |
December 1965 |
January 1966 |
February 1966 |
March 1966 |
April 1966 |
May 1966 |
June 1966 |
July 1966 |
August 1966 |
September 1966 |
January 1967 |
April 1967 |
June 1967 |
August 1967 |
October 1967 |
Revision
54 December 1967 |
February 1968 |
April 1968 |
June 1968 |
August 1968 |
October 1968 |
January 1969 |
May 1969 |
In this section, we provide some stuff that doesn't directly
pertain to any of the computers in Apollo or Gemini. But if
the original developers give me interesting and sometimes unique
material, or if I find interesting material related to them, I'd
like to present it anyway.
