Search Exo Cruiser

Oct 30, 2011

Horten H IX (or Ho 229 or Gotha Go 229) Construction Details and Story

The Horten Ho 229 V.3 is Currently been Restored and Preserved

Horten Ho 229 (IX) V.3, June 2011

"Early in June 2011, staff of the Paul E. Garber Preservation, Restoration and Storage Facility slowly and carefully moved the center section of the Horten H IX V.3 all-wing jet fighter from storage into the restoration and preservation shop." /4/


"The H IX was a single seat fighter bomber of 16 m span with twin jet engines, being a further development of the H V and H VII designs. The following figure is a general arrangement drawing made from a wooden model found at Gottingen 1945 (Gotha, Friedrichroda), where the first two of the type were built." /6/

Avro Canada CF-105 Arrow

"The Avro Canada CF-105 Arrow was a delta-winged interceptor aircraft, designed and built by Avro Aircraft Limited (Canada) in Malton, Ontario, Canada, as the culmination of a design study that began in 1953. Considered to be both an advanced technical and aerodynamic achievement for the Canadian aviation industry, the CF-105 held the promise of Mach 2 speeds at altitudes exceeding 50,000 ft (15,000 m), and was intended to serve as the Royal Canadian Air Force's (RCAF) primary interceptor in the 1960s and beyond." /1/

Here is a YouTube video about the AVRO Arrow concept.



* * *

Oct 29, 2011

Small "Solar" Turbines

An interesting Solar turbine T62 (usually an APU) and its use in a small helicopter. /1/

Solar T62-16B 75 hp Turbine

T62-32 only 142 Ibs / 65 kg (dry)

T62-32 in a helicopter

T62-32 in a helicopter (160shp/61,091 rpm/sea level)




* * *

Oct 20, 2011

Launch Date Today; Galileo IOV 2 First Satellites

Galileo IOV (In Orbit Validation) 2 first satellites should be launched today or tomorrow in Guiana Space Centre, French Guiana using Russian Soyuz ST-B launcher with Fregat-MT upper stage. /1/

Galileo IOV Satellite

These 2 satellites are the first two satellites of the actual Galileo system consisting of 30 satellites. Until now different tests have been going on with preliminary type Galileo satellites.

Satellites waiting on a Soyuz launch vehicle to be launched

Soyuz - Galileo IOV launch delayed

At the moment: 20 October 2011, following an anomaly detected during fueling of the Soyuz launcher’s third stage, the final countdown has been interrupted. Soyuz and its two Galileo IOV satellites, along with the launch facility, have been placed in a safe mode. A new launch date will be announced later today. /2/

And here it goes

Here is more about the Galileo and factors affecting its accuracy.




* * *

Oct 15, 2011

Saturn Fly-through

"The following video is not some CGI or 3D models but the real space how it is, only Cassini photographs used." /1/

"The above captivating natural color view was created from images collected shortly after Cassini began its extended Equinox Mission in July 2008. It can be contrasted with earlier images from the spacecraft's four-year prime mission that show the shadow of Saturn's rings first draped high over the planet's northern hemisphere, then shifting southward as northern summer changed to spring (see PIA06606 and PIA09793). During this time, the colors of the northern hemisphere have evolved from azure blue to a multitude of muted-colored bands." /2/

Cassini's position 15.10.2011 (CGI image). Launch date was 15.10.1997 (exactly 14 years before this position)

More about the source:





* * *

Oct 14, 2011

Yuneec 81 hp (60 kW) Direct Drive Brushless DC Motor (and Some Testing)

With low rpm (2400 1/min) this is an interesting direct propeller drive motor for the next generation fully electric aircraft. On top of all you get the whole power pack from the same company, including motors, controllers, chargers and batteries.

Here is more information:

Here is an interesting video about a kit been tested in an old VW.

and an other controller driving 3-phase AC motor from DC.

in an airplane application you might not want to have any shutdown circuits even if the drive might be getting hot .. you just slow down so much that the circuit cools down and give a warning light.

* * *

English Electric Canberra

E. E. Canberra is a bomber and spy plane with an exceptionally long service history.

"Evidence of the importance of Kapustin Yar (V-2 test site in Soviet Union) was obtained by Western intelligence through debriefing of returning German scientists and spy flights. The first such flight reportedly took place in mid-1953 using a high flying Canberra aircraft of the RAF. Numerous circumstantial reports suggest this flight took place, using either a Canberra B2 or a PR3, but the UK Government has never admitted such a flight took place nor have any of the supposed participants provided direct evidence" /1/

Here is some information about the airplane.



* * *

Oct 12, 2011

Apollo Guidance Computer (AGC) Software

"By 1963, designers determined that the Apollo computer software would have a long list of capabilities." /1/

Tasks of LEM's AGC

"The software should act as backup to the Saturn booster (Saturn had its own computer, the Saturn Launch Vehicle Digital Computer [LVDC], and software), controll aborts, target, do all navigation and flight control tasks, attitude determination and control, digital autopilot tasks, and eventually all maneuvers involving velocity changes. Programs for these tasks had to fit in the memories of two small computers, one in the CM and one in the LEM. Designers developed the programs using a Honeywell 1800 computer and later an IBM 36O, but never with the actual flight hardware which was only used for testing in some simulated environments. The development computers generated binary object code and a listing. The tape containing the object code would be tested and eventually released for core rope manufacture. The listing served as documentation of the code." /1/

Honeywell 1800 (1960's)

"Defining requirements is the single most difficult part of the software development cycle. The specification is the customer's statement of what the software product is to do. Improperly prepared or poorly defined requirements mean that the resulting software will likely be incomplete and unusable. Depending on the type of project, the customer may have little or a lot to do with the preparation of the specification. In most cases, a team from the software developers works with the customer." /1/

IBM 360 (1964...)

"MIT worked closely with NASA in preparing the Guidance and Navigation System Operations Plan (GSOP), which served as the requirements document for each mission. NASA's Mission Planning and Analysis Division (MPAD) at the Manned Spacecraft Center provided detailed guidance requirements right down to the equation level." /1/

Johnson Manned Spacecraft Center

"Often these requirements were in the form of flow charts to show detailed logic. The division fashioned these requirements into a controlled document that contained specific mission requirements, preliminary mission profile, preliminary reference trajectory, and operational requirements for spacecraft guidance and navigation. NASA planned to review the GSOP at launch minus 18 months, 16 months, 14 months and then to baseline or "freeze" it at 13.5 months before launch. The actual programs were to be finished at launch minus 10.5 months and tested until 8 months ahead, when they were released to the manufacturer, with tapes also kept at MIT and sent to Houston, North American (CM manufacturer), and Grumman (LEM manufacturer) for use in simulations. At launch minus 4 months the core ropes were to be completed and used throughout the mission." /1/

A video from the Mission Planning and Analysis Division of the Manned Spacecraft Center in Houston, Texas (now the Johnson Space Center [JSP]).

"Even during the early 1960s, the cycle of requirements definition, design, coding, testing, and maintenance was followed, if not fully appreciated, by software developers. The main point of the Bellcomm report (and the thrust of software engineering) was that software can be treated the same way as hardware, and the same engineering principles can apply." /1/

David G. Hoag, technical design director at the MIT laboratory, examines the IMU (Inertial Measuring Unit) of Apollo.

"However, NASA was more used to hardware development than to large-scale software and, thus, initially failed adequately to control the software development. MIT, which concentrated on the overall guidance system, similarly treated software as a secondary occupation. This was so even though MIT manager A.L. Hopkins had written early in the program that "upon its execution rests the efficiency and flexibility of the Apollo Guidance and Navigation System". Combined with NASA's inexperience, MIT's non-engineering approach to software caused serious development problems that were overcome only with great effort and expense. In the end NASA and MIT produced quality software, primarily because of the small-group nature of development at MIT and the overall dedication shown by nearly everyone associated with the Apollo program." /1/

A video from the Mission Planning and Analysis Division of the Manned Spacecraft Center in Houston, Texas (now the Johnson Space Center [JSP]).

"In the Apollo program, with an outside organization developing the software, NASA had to provide for quality control of the product. One method was a set of standing committees; the other was the acceptance cycle." /1/

Dr. Von Braun, Dr. J.P. Kuettner and Warren J. Northleft at the NASA Manned Spacecraft Center, now the Johnson Space Center (Oct.14.1964)

"Three boards contributed directly to the control of the Apollo software and hardware development. The Apollo Spacecraft Configuration Control Board monitored and evaluated changes requested in the design and construction of the spacecraft itself, including the guidance and control system, of which the computer was a part. The Procedures Change Control Board, chaired by Chief Astronaut Donald K. Slayton, inspected items that would affect the design of the user interfaces. Most important was the Software Configuration Control Board, established in 1967 in response to continuing problems and chaired for a long period by Christopher Kraft. It controlled the modifications made to the on-board software. All changes in the existing specification had to be routed through this board for resolution. NASA's Stan Mann commented that MIT "could not change a single bit without permission"." /1/

Dr. Von Braun looking computer consoles (Oct.14.1964)

"NASA also developed a specific set of review points that paralleled the software development cycle. The Critical Design Review (CDR) resulted in acceptance of specifications and requirements for a given mission and placed them under configuration control. It followed the preparation of the requirements definition, guidance equation development, and engineering simulations of the equations. Next came a First Article Configuration Inspection (FACI). Following the coding and testing of programs and the production of a validation plan, it marked the completion of the development stage and placed the software code under configuration control. After testing was completed, the Customer Acceptance Readiness Review (CARR) certified that the validation process resulted in correct software. After the CARR, the code would be released for core rope manufacture. Finally the Flight Readiness Review (FRR) was the last step in clearing the software for flight. The acceptance process was mandatory for each mission, providing for consistent evaluation of the software and ensuring reliability." /1/

"With respect to units, the LGC was eclectic. Inside the computer we used metric units, at least in the case of powered-flight navigation and guidance. At the operational level NASA, and especially the astronauts, preferred English units. This meant that before being displayed, altitude and altitude-rate (for example) were calculated from the metric state vector maintained by navigation, and then were converted to feet and ft/sec. It would have felt weird to speak of spacecraft altitude in meters, and both thrust and mass were commonly expressed in pounds. Because part of the point of this paper is to show how things were called in this era of spaceflight, I shall usually express quantities in the units that it would have felt natural to use at the time." (Don Eyles) /3/

"In software engineering practice today, the specification document is followed by a design document, from which the coding is done. Theoretically, the two together would enable any competent programmer to code the program. The GSOPs contained characteristics of both a specification and design document. But, as one of the designers of the Apollo and Shuttle software has said, "I don't think I could give you the requirements for Apollo and have you build the flight software". In fact, the plans varied both in what they included and in the level of detail requirements. This variety gave MIT considerable latitude when actually developing the flight software, thus reducing the chance that it would be easily verified and validated." /1/

The AGC Operating System

"The AGC was a priority-interrupt system capable of handling several jobs at one time. This type of system is quite different from a round-robin executive. In the latter programs have a fixed amount of time in which to run before being suspended while the computer moves on to the remaining pending jobs, thus giving each job the same amount of attention. A priority-interrupt system is always executing the one job with the highest priority; it then moves on to others of equal or lower priority in its queue." /1/


"The Apollo control programs included two related to job scheduling: the Executive and the Waitlist. The Executive could handle up to seven jobs at once while the Waitlist had a limit of nine short tasks. Waitlist tasks had execution times of 4 milliseconds or less. If a task ran longer than that, it would be promoted by the Waitlist to "job" status and moved to the Executive's queue. The Executive checked every 20 milliseconds for jobs or tasks with higher priorities than the current ones. It also managed the DSKY displays88. If the Executive checked the priority list and found no other jobs waiting, it executed a program called DUMMY JOB continuously until another job came into the queue." /1/

AGC's placement in the LM

"The Executive had other duties as part of controlling jobs. One solution to the tight memory in the AGC was the concept of time-sharing the erasable memory. No job had permanent claim to any registers in the erasable store. When a job was being executed, the Executive would assign it a "coreset" of 12 erasable memory locations. Also, when interpretive jobs were being ran (the Interpreter is explained below), an additional 43 cells were allocated for vector accumulation (VAC). The final lunar landing programs had eight coresets in the LEM computer and just seven in the CM. Both had five VACs. Moreover, memory locations were given multiple assignments where it was assured that the owning processes would never execute at the same time. This approach caused innumerable problems in testing as software evolved and memory conflicts were created due to the changes." /1/

Programming Tools

"The AGCs in the LM and CM were programmed in two languages. The one we called "Basic", but more properly "Yul", was an assembler language of about 40 operations, authored by Hugh Blair-Smith. "Interpretive" was a list-processing interpretive language (essentially a set of subroutines) designed to facilitate guidance and navigation calculations involving double precision (30-bit fixed-point) vectors and matrices — at the cost of being very slow. The Interpreter was written by Charles Muntz." /3/

"The memory-cycle time for the AGC was 11.7 microseconds. A single-precision addition in the assembler language took two memory cycles. A double-precision vector cross-product programmed in Interpretive took about 5 milliseconds. One of the challenges in programming the AGC was juggling the two languages to obtain the best blend of speed and compactness for the given situation." /3/

"The interpreter got a starting location in memory, retrieved the data in that location, and interpreted the data as though it were an instruction. Instead of having only the 11 instructions available in assembler, up to 128 pseudo instructions were defined. The larger number of instructions in the interpreter meant that equations did not have to be broken down excessively. This increased the speed and accuracy of the coding." /1/

Some of the MIT staff /3/

"The MIT staff gave the resulting computer programs a variety of imaginative names. Many, such as SUNDISK, SUNBURST, and SUNDIAL, related to the sun because Apollo was the god of the sun in the classical period. But the two major lunar flight programs were called COLOSSUS and LUMINARY. The former was chosen because it began with "C" like the CM, and the latter because it began with "L" like the LEM97. Correspondence between NASA and MIT often shortened these program names and appended numbers. For example, SOLRUM55 was the 55th revision of SOLARIUM for the AS501 and 502 missions. BURST116 was the 116th revision of SUNBURST98. Although these programs had many similarities, COLOSSUS and LUMINARY were the only ones capable of navigating a flight to the moon. On August 9, 1968, planners decided to put the first released version of COLOSSUS on Apollo 8, which made the first circumlunar flight possible on that mission." /1/

Restart Protection

"An Apollo restart transferred control to a specified address, where a program would begin that consulted phase tables to see which jobs to schedule first. These jobs would then be directed to pick up from the last restart point. The restart point addresses were kept in a restart table. Programmers had to ensure that the restart table entries and phase table entries were kept up to date by the software as it executed. The restart program also cleared all output channels, such as control jet commands, warning lights, and engine on and off commands, so that nothing dangerous would take place outside of computer control ." /1/

"A software failure causing restarts occurred during the Apollo 11 lunar landing. The software was designed to give counter increment requests priority over instructions. This meant that if some item of hardware needed to increment the count in a memory register, its request to do so would cause the operating system to interrupt current jobs, process the request, and then pick up the suspended routines. It had been projected that if 85,000 increments arrived in a second, the effect would be to completely stop all other work in the system. Even a smaller number of requests would slow the software down to the point at which a restart might occur. During the descent of Apollo 11 to the moon, the rendezvous radar made so many increment requests that about 15% of the computer systems resources were tied up in responding. The time spent handling the interrupts meant that the interrupted jobs did not have enough computer time to complete before they were scheduled to begin again. This situation caused restarts to occur, three of which happened in a 40-second period while program P64 of LUMINARY ran during descent106. The restarts caused a series of warnings to be displayed both in the spacecraft and in Mission Control. Steven G. Bales and John R. Garman, monitoring the computer from Mission Control, recognized the origin of the problem. After consultation, Bales, reporting to the Flight Director, called the system GO for landing. They were right, and the restart software successfully handled the situation. The solution to this particular problem was to correct a switch position on the rendezvous radar which, through an arcane series of circuitry, had caused the analog-to-digital conversion circuitry to race up and down. This incident proved the need for and effectiveness of built-in software recovery for unknown or unanticipated error conditions in flight software-a philosophy that has appeared deeply embedded in all NASA manned spaceflight software since then." /1/

"Cut to a time about a year before Apollo 11, when we software engineers, who thought we already had enough to do, were requested to write the lunar landing software in such a way that the computer could literally be turned off and back on without interrupting the landing or any other vital maneuver! This was called "restart protection". Other factors than power transients also caused restarts. A restart was triggered if the hardware thought the software was in an endless loop, or if there were a parity failure when reading fixed memory, or for several other reasons. Restart protection was done by registering way points at suitable points during the operation of the software such that if processing happened to jump back to the last way point, no error would be introduced." /3/

"Following a restart, such computations could be reconstructed. For each job, processing would commence at the last registered waypoint. If multiple copies of the same job were in the queue, only the most recent was restarted. Certain other computations that were not considered vital were not restart-protected. These would simply disappear if there were a restart." /3/

"Restart protection worked very well. On the control panel of our real-time "hybrid" simulator in Cambridge was a pushbutton that caused the AGC to restart. During simulations we sometimes pushed the button randomly, almost hoping for a failure that might lead us to one more bug. Invariably, once we got the restart protection working, operation continued seamlessly." /3/

SDS 9300 digital computer and a COMCOR CI 5000 analog computer

"The hybrid simulator in Cambridge combined SDS 9300 digital and Beckman 21331 analog computers with a real AGC and realistic LM and CM cockpits."/3/


"NASA did successfully land a man on the moon using programs certifiably adequate for the purpose. No one doubted the quality of the software eventually produced by MIT nor the dedication and ability of the programmers and managers at the Instrumentation Lab. It was the process used in software development that caused great concern, and NASA helped to improve it143. The lessons of this endeavor were the same learned by almost every other large system development team of the 1960s: (a) documentation is crucial, (b) verification must proceed through several levels, (c) requirements must be clearly defined and carefully managed, (d) good development plans should be created and [53] executed, and (e) more programmers do not mean faster development. Fortunately, no software disasters occurred as a result of the rush to the moon, which is more a tribute to the ability of the individuals doing the work than to the quality of the tools they used." /1/






* * *

Oct 9, 2011

ACES II Ejection Seat

"The ACES II (Advanced Concept Ejection Seat) is considered a smart seat since it senses the conditions of the ejection and selects the proper deployment of the drogue and main parachutes to minimize the forces on the occupant. The seat is a derivative of the Douglas Escapac seat. Removal from the aircraft is by a three part pyrotechnic sequence. A gun catapult provides the initial removal of the seat from the aircraft. A rocket sustainer provides zero/zero capability to the seat. To prevent the seat from tumbling when the aircraft is in a roll maneuver or there is a center of gravity imbalance, another (smaller) rocket called a STAPAC is attached to a gyroscope. This senses the motion and attempts to keep the seat from spinning by automatically providing a correcting force.

F-16 ejection sequences

Once clear of the aircraft, the pitot - static system on the seat measures the conditions and selects one of three operating modes depending on the conditions present at egress."

"Mode 1 - Low speed (<250 knots) and low altitude (<15 000 feet) operation. The main parachute deploys as the seat clears the rails. Drogue parachute remains undeployed to prevent line tangle."

"Mode 2 - Moderate speed (250-650 knots) and low altitude (<15 000 feet) operation. Drogue parachute deploys as the seat leaves the rails. Main parachute deploys 0.8 to 1.0 seconds after the drogue. Drogue chute is then released to prevent line tangle."

"Mode 3 - High speed (250-650 knots) and high altitude (>15 000 feet) operation. Drogue parachute deploys as the seat leaves the rails. The pitot - static system senses the conditions and delays the main parachute until mode 2 conditions are met. Then the main parachute deploys after 0.8 to 1.0 seconds. Drogue chute is then released to prevent line tangle. " /3/

ACES II parts and controls

"The Advanced Concept Ejection Seat (ACES) Was developed to provide a standard Ejection seat to be utilized in all United States Air Force jets from the mid-1970s. It was first flown in a A-10 Thunderbolt II from the Fairchild Republic Co. at the Farmingdale Long Island (N.Y.) plant in April 1978. The driving reasons for the development of the ACES II were to standardize on one type of ejection seat*- this would lead to reduction in training of both mechanics and pilots, also the design was intended to provide better performance in low altitude/adverse attitude conditions as well as to improve high speed seat stablity. It also allowed the government to purchase larger lots of spare parts." /1/

"The ACES-II ejection seat produced by McDonnell Douglas Aerospace is the seat installed in the F-16. The same seat is also used in the F-15, F-22, F-117 and A-10 but has small differences, mainly because the F-16 has the flightstick located at the right side, while the other aircraft have the stick located at the center, between the pilot's legs." /2/

"The ACES-II is a Zero-Zero seat. That means that the seat is still capable of ejecting the pilot at a 0 kts speed. The seat has the following parts: the case itself, the control-electronics, the parachute container that holds the pilot's parachute, the survival kit assembly according to the area of operation, the emergency oxygen assembly and the ejection mechanism itself." /2/

"The seat is installed in the cockpit in a 30 deg. angle. This position allows the pilot a better resistance to pulled G's as the position is not completely vertical." /2/






* * *

Apollo Guidance Computer (AGC), Its Emulators (ISAGC) and Space Environment Simulators

Apollo AGC

"Early in the development of the Apollo simulators, a problem arose that would have had critical consequences if not solved. The importance of the on-board computer to the guidance and navigation of a moon-bound spacecraft was obvious. Crews interacted with the computer thousands of times in a typical mission; its keyboards contained the most used switches in the spacecraft." /1/

Eldon C. Hall with an Apollo Guidance Computer

"In August 1961, NASA contracted the MIT Instrumentation Laboratory (later called the Charled Stark Draper Laboratory) to develop the Apollo guidacnce, navigation and control system. Eldon C. Hall (shown above) was selected to lead the development team, and astronaut David Scott was chosen as the interface between the designers and the users." /8/

David Scott

"Between 1963 and 1969, Raytheon Corporation churned out approximately 75 rectangular chunks of metal, plastic, and silicon. Bigger than a breadbox but significantly smaller than a UNIVAC, the Apollo Guidance Computer had been designed by the MIT Instrumentation Laboratory to safely guide the Apollo astronauts and spacecraft to the Moon and back." /7/

AGC and DSKY (Display and Keyboard)

"Initially, the Apollo Guidance Computer (AGC) for both the command module and the lunar module were simulated functionally, just like the rest of the spacecraft hardware. This meant that the major components of the Apollo modules existed as software in a DDP-224 rather than in their physical form in the simulator." /1/

"The Apollo Guidance Computer (AGC) provided onboard computation and control for guidance, navigation, and control of the Command Module (CM) and Lunar Module (LM) spacecraft of the Apollo program. It is notable for having been one of the first IC-based computers." /2/


MIT DSKY (pronounced "Diskey")

3C (Honeywell) DDP-224

"As a result of a study and the continued concern of the Apollo Spacecraft Project Office, W. B. Goeckler of the Systems Engineering Division of the program asked James L. Raney of Computational Analysis to do a feasibility study of using a Honeywell DDP-224 to simulate the AGC. Goeckler thought it might be possible to make the Honeywell computer think it was the MIT computer and execute the MIT code, thus eliminating the need for rewriting the programs and solving the time problem." /1/

"In 1966 3C (Computer Control Company) was sold to Honeywell, Inc. As the Computer Controls division of Honeywell, it introduced further DDP-series computers, including DDP-224." /3/

3C DDP-24 Computer (Later Honeywell)

3C (Computer Control Company) card rack 1964.

"Raney suggested both hardware and software modifications to the DDP-224. He specified a switch to disable the machine's floating-point capability. Instructions were added to enable more efficient table searching and other operations that the AGC did well. To handle the different word sizes, Raney let the right-most 14 bits of the DDP word be the value of a corresponding AGC word. The left-most bit was always set to zero to indicate that it was an Apollo word, and the intervening bits matched the sign bit of the original word. Words that could not be translated (i.e., executed one for one), had to be executed by interpretive subroutines written for the purpose and stored in the lower part of the Honeywell memory. Raney figured that since the DDP had a 10-to-1 advantage in execution speed over the AGC, several instructions could be used to do one Apollo instruction without slowing down the program. He used the index registers in the Honeywell DDP to act as the Fixed Bank Register, which kept track of which core rope memory module the AGC was currently using, as well as the address of the next instruction. Finally, to store the AGC code, the flight program was put in the upper half of the 64K words of core, with the interpreter used in the AGC to execute its own instructions in an area in lower core. The contents of the AGC's 2K erasable memory and the 8K of common core addressable by all the simulator computers also was in lower core, along with Raney's interpretive subroutines24." /1/

Video of the CM Computer Human Interface

"Despite Raney's careful evaluation of the situation and proposed solution, many Apollo project personnel opposed it, simply feeling it was unworkable. In desperation, NASA approved the attempt at an interpretive simulator and bought the modified computers. In the end, the simulation within a simulation was spectacularly successful. Even though Raney and his team took care to time the subroutines so that they matched execution of the actual Apollo code, the simulated computer was faster than the real article. Following the Apollo 9 earth-orbiting mission that tested the command module and lunar module rendezvous techniques, pilot Dave Scott complained that he had up to 12 seconds less time to react when the computer signaled for a maneuver to begin. This was adjusted for later flights." /1/

Video: NASA Computers 1960's

"The sidelight in here that I want to talk about is this Software Development Laboratory. There really wasn’t such a thing in Apollo. They had the computers that did simulation mainframes, they did their assembly language assembling on big machines. The crew trainer for Apollo, you know, the simulators that the astronauts train in, actually ran an interpretively simulated Apollo guidance computer. ISAGC it was called. A fellow named Jim [James L.] Raney, who was around for a long time, I think he’s still around somewhere, created that, ended up working all the way through Station, in fact, on onboard software." (John R. "Jack" Garman) /4/

Lunar Module AGC or LGC was located at the aft of LM

"I'd become so embedded in the Station Program that they sent some of that work with me, particularly the SSE project, and that gave me the opportunity to grab a couple of other people. One of them that would be very worthwhile chatting with is Jim [James L.] Raney. Jim was the guy that built the ISAGC, the Interpretively Simulated Apollo Guidance Computer." (John R. "Jack" Garman) /4/

DSKY was located in the middle of the front section

"Developing the interpretively simulated AGC had several impacts on the program. MIT could use the simulator as a field test of its code before flight. Since MIT used tape rather than core rope to send the programs to Houston and the Cape, errors discovered could be corrected and then the corrections tested in a "real" situation. Crews could react to the way the software worked with them. Also, the simulator cost just $4.6 million, compared to an estimated $18 million for functionally simulating the programs." /1/

DSKY in the lower middle

"Actually, the Apollo Mission Simulators were the last of their type in that the analog environment of the spacecraft that dictated hybrid and functional simulations changed to a digital environment that lent itself to full digital simulations for the Shuttle program. Evolution to full digital simulation, including digital imaging of window scenes, meant even more dependence on digital computers. Making the Shuttle a more autonomous and thus more complex spacecraft contributed to a massive increase in the size of the computer systems needed to support simulations." /1/

The AGC in the LM controlled almost everything simultaneously

AGC In-flight Use

"Shortly after liftoff of Apollo 12, two lightning bolts struck the spacecraft. The current passed through the command module and induced temporary power failure in the fuel cells supplying power to the AGC. During the incident the voltage fail circuits in the computer detected a series of power trenches and triggered several restarts. The computer withstood these without interruption of the mission programs or loss of data." /10/

Apollo 12 Struck by Lightning

"The Apollo 11 overload (1202 alarm) resulted from the rendezvous radar being set in the wrong mode during the lunar landing phase (?pilot in the loop?), waisting computer memory cycles and overloading it. The AGC operating system was responding to overloads as designed (lower priority tasks were delayed)." /10/

CM Simulator

"The Command/Service Module simulator (CSM) consists of a generalpurpose digital computer (SDS 9300) with 32K words of memory: two analog computer consoles (Beckman 21331, interface equipment (40 A/D, 56 D/A channels) and a complement of flight hardware (real and special-purpose simulators). The heart of the flight hardware is the on-board guidance computer (CMC) which contains the programs for guidance, navigation, and control of the spacecraft. In the simulator, a real CMC is used, but the fixed memory is replaced by a core rope simulator (which operates with the CMC and has all erasable memory). This allows modification of the flight programs before they are manufactured into modules. The entire contents of the fixed memory is recorded onto magnetic tape and can be loaded into the core rope simulator in a few minutes. Individual memory locations may be altered or monitored as well. This simulator also allows control of the CMC, by providing address stop, step-by-step operation, etc." /11/

SDS 9300 digital computer and a COMCOR CI 5000 analog computer

"The inertial measurment unit (IMU) is simulated by two devices, the gimbal angle simulator and the accelerometer simulator (PIPA simulator). The gimbal angle simulator accepts three dc inputs corresponding to the three gimbal angles (which relate the inertial axes to spacecraft orientation) and by means of three servos, positions the gimbal resolvers. These resolvers are interfaced to the coupling data units (CDU), as in the flight system, which digitize the gimbal angle information for the CMC. Each CDU also has a D/A section for converting CMC output to. either 800-cps or dc voltages for use in the system, e.g. to position the SPS engine, display attitude errors, position optics, etc. The accelerometers are simulated by a special purpose device which generates pulses to the CMC as a function of the applied input voltage (dc). This device interfaces directly with the CMC." /11/

Beckman EASE 2133

"The down-telemetry output and up-telemetry input of the CMC are interfaced through special purpose devices to the SDS 9300. For down telemetry, the device converts serial data to the parallel format which is acceptable to the SDS and these data are stored for later processing. The up-telemetry is generated in the SDS and serial pulses are sent to the CMC in the appropriate format. The uplink is used to intialize the CMC prior to a simulation." /11/

"Both the flight hardware and the hybrid computer are interfaced with a cockpit mockup which contains displays and controls. Many of the discrete input signals to the CMC originate in the cockpit, e.g. mode control, attitude and translation control, etc. In addition, the lower equipment bay of the cockpit contains the optics simulators and controls which provide star fields for navigation and alignment of the TMU. These optics simulators interface with the CMC through the CDU's." /11/

LM Simulator

"The Lunar Module (LM) simulator consists of essentially the same complement of equipment with certain other special-purpose devices added and the deletion of the optics simulator. In particular, rendezvous radar and landing radar simulators are used to generate radar data to the guidance computer (LGC) with the rendezvous radar angle data interfacing through the CDU. There is also a LM Visual Display device which projects a lunar landscape to the left window or the LM cockpit and which is driven by the SDS/Beckman computer. This device allows simulation of a manually controlled lunar landing maneuver with a realistic display of the scene as would be seen from the vehicle." /11/

Modern ISAGC

Here is a link to the virtual AGC which is a modern version of the original ISAGC.

"Virtual AGC is a computer model of the AGC. It does not try to mimic the superficial behavioral characteristics of the AGC, but rather to model the AGC's inner workings. The result is a computer model of the AGC which is itself capable of executing the original Apollo software on (for example) a desktop PC. In computer terms, Virtual AGC is an emulator. Virtual AGC also provides an emulated AGS and (in the planning stages) an emulated LVDC. "Virtual AGC" is a catch-all term that comprises all of these." /5/

Modern AGC's

John Pultorak has constructed an AGC out of 74LS-series low-power Schottky TTL devices. Here is more about that.

John Pultorak's AGC

There are also other AGC's running today. Here are some links.
"The AGC is the most interesting early computer because: a) it flew the first men to the moon; and b) it's the world's first integrated circuit (IC, or microchip) computer. It also has interesting architectural features." (John Pultorak)

Apollo Guidance System Documents

You'll find more information here.


/1/ Computers in Spaceflight: The NASA Experience, Chapter Nine, Making New Reality: Computers in Simulations and Image Processing











* * *

Apollo Simulators

Apollo simulators and their associated computer systems were crucial to the success of the Apollo program. No less than 15 simulators trained crews during the Apollo Program.

Among the plethora of simulators, use of the Command Module Simulators and Lunar Module Simulators nonetheless occupied 80% of the Apollo training time of 29,967 hours.

Here are couple of interesting stories of that time and area.

And some videos:

Some more recent test videos.

* * *