Really cool vid on Apollo Re-entry

[Bacterius]

The FAR mod did/does in principal allow some control over lift of the pod, but i never got around to trying that. Last time i tried FAR and DR didn't play nice together.

I know, right? Screaming through the lower atmosphere at over 2.5km/s tends to burn away the heatshield pretty quickly

[Krupski]

Ikr. Didn't the LM have less computing power than a modern calculator? They did all their work the old fashioned way: with a paper and a pencil and a few logic gates. It truly is amazing.

Well, the idea of computing "power" really doesn't figure into a comparison like that. The AGC was more of a microcontroller than a computer.

Think of, say, a university student robot project.

The robot may have motors for movement (analogous to rocket engines), steering servos to control direction (like RCS), optical or ultrasonic sensors to detect obstacles and steer around them (CM rendezvous radar or LM landing radar), a gyro or GPS for position knowledge (inertial platform), etc...

To build a robot like that, you wouldn't want or use a "powerful PC", you would use a relatively simple microcontroller board like an Arduino or PIC or Motorola EVBU, wire up all the sensors, motors, etc... and then write simple, custom software to read sensors, control motors, decide when to drive, where to steer, etc...

A little microcontroller (like an Arduino) could have probably run the LM and CM quite nicely, but alas they didn't have those back then.

Another REALLY great innovation in the AGC software was the priority interrupt driven executive. As an "OS", it puts even Windows, MacOS or Linux to shame. Various tasks were given different priorities, and if the computer got overloaded, it delayed running low priority routines.

For example, the code to read the inertial platform and calculate range, range rate, velocity, etc and control RCS and DPS (in the LM during landing) was a LOT more important than, say, updating the DSKY display to tell how fast they were going.

That was the famous "1201" and "1202" program alarms. There was no software error. The computer simply said "I'm a bit busy here, I'm not going to update the Delta-H display right now, sorry".

And the reason for those errors is terribly mis-documented in most literature.

Some sources say "The rendezvous radar was mistakenly left on". Wrong, It was supposed to be on. Since it used a vacuum tube to generate the radar, it needed to be warmed up in case of an abort.

Others say it was because the computer was too slow. Wrong again.

The real reason was that the LM ran on 400 hz, 3 phase AC power. The inverters were supposed to be frequency locked (they were), but also PHASE locked (they weren't). So the resolvers in the rendezvous radar dish actuators produced random antenna position data instead of clean data and that caused the routine which locked the radar on the CSM to go wild searching for a target that SEEMED to be jumping all over the sky.

This sucked up about 15% of the total computer time and the executive said "forget this, I have to watch the LANDING radar" and issued the 1201 and 1202 overflow errors.

The problem was never caught in ground sims because thay all ran on one power supply (which was obviously phase locked to itself).

So, the AGC didn't fail. Instead, it did PRECISELY what it was supposed to do and it saved the Apollo 11 landing from an abort. Thank God they weren't running Windorw!!! Can you imagine a blue screen crash 1500 feet above the lunar surface???

We owe a big thanks to the Apollo program for all the goodies of technology we have today (like monolithic integrated circuits that make up the CPU and every other chip in our PC's)... those were invented by Dr. Robert Noyce and first mass produced by Fairchild Semiconductor for use in the Apollo AGC.

Our super-duper Core-whatever processors are just improved versions of the first "chips".