"The AGC wan't powerful enough"

[Everett]

A pretty common (but strangely never elaborated on... ) HB claim is that the Apollo Guidance Computer wasn't powerful enough. Reading (on years old threads, so I can't actually post) some HB say "it had the power of a pocket calculator" makes me want to scream "WHAT DO YOU THINK A GUIDANCE COMPUTER IS! IT'S A GLORIFIED CALCULATOR HOOKED UP TO AN AUTOPILOT!"
Excuse me there, wanted to get that out. Aham. Anyway, it seems (presumably younger) people think everything has to be done with a computer. Some prominent HB (the kind with a book/DVD to sell) called it "just enough to change to the spin cycle on the washing machine." Oddly enough, while my washer has a lot of computer options built into it (which ironically makes it more complicated to use), my dryer from the 80's can change cycles all by itself, and it doesn't have computer in it. It's also far more reliable, and has outlasted, two consecutive computer-containing washers.People seem to forget (or really were born far after) what you can do without any computer at all. Somebody on the DI forum claimed 2kb RAM and 32kb isn't enough to run a string of neon lights. Well, I'm a bit of a historian in a bunch of fields, and I'm pretty sure they had big blinking/etc neon lights in the 50's, and I don't think those used computers...

If anything, it's more powerful than it needs to be. The alignment procedure to correct gyro drift had (IIRC) the computer orient the ship to where it's current gyro alignment thought a star should be, then the sextet was used to correct for where it actually was. Really, as long as there were attitude display counters with enough digits, there's no reason it couldn't be manually maneuvered to the correct attitude an astronaut looked up from a sheet of paper, figure out the deviation, then manually enter the actual attitude into the computer. The math also actually isn't as complex as I thought it was; I'd always assumed it was calculus, but looking at BobB's site showed it's only (dense) algebra. It's worth pointing out that on Apollo 11 simply running the rendezvous raider during descent actually exceeded the AGC's capacity. It's also worth pointing out that it was not programmable, all the programs were hardwired in (literally!) when they were made. (This would probably be a good place to show a photograph of the "programs" (the core rope memory cores.)) As for the digital autopilot part, my response in more along the lines "cool, you made a digital one." Completely analog electro-mechanical autopilots capable of doing basically the same job had been standard issue in airliner cockpits for two decades by that point.

Since most people don't know about it (probably since most people who used them firsthand are dead by now), it's actually somewhat surprising what analog electro-mechanical computers can do. I've flown (in flight simulator, but full system accuracy) an 1947-vintage airliner from just after takeoff in New York all the way to final approach in Paris using a 1947-vintage autopilot. All it does it pitch hold, heading hold, altitude hold, and it can also make perfectly coordinated turns. (Better than I can.) You can use the turn handle to change heading and then it'll hold that, you can adjust the pitch it's supposed to hold to climb or descend (along with manual control of engine power), and if you're at the altitude you want you can set it to hold it. (The navigation didn't involve said autopilot.) 0kb RAM, 0kb memory. And that's really all you need. Heck, the Soyuz capsule didn't get any digital computer until the 21st century! And it was more automated (cam timer systems) than US craft of the same vintage.

Just going by what was in widespread use, analog computers can be a lot more capable than people think. For example of what an analog computer could do all the way back in 1935, check out this page:
http://www.navweaps.com/index_tech/tech-056.php
Basically, a mechanical computer that handled fire control calculations for anti aircraft fire (and surface fire) in all 3 axis to automatically aim the guns so that the shell would arrive where the aircraft will be at the time the shell arrives. It has a gyro to correct for ship roll and such, takes into account wind speed and direction and gun wear (inputted manually) and even compensates for the Coriolis effect! Radars elsewhere on the ship were capable of generating inputs themselves which would feed directly into the fire control computer, which could aim the guns all on its own, no human intervention required. And it's not the size of a room either; it's 3ft x 4ft x 6ft.

[Obviousman]

These are the range / fire control computers from the USS Alabama and the USS Drum, both WW2-vintage vessels.

Even in the mid-1980s, when I did my Navigator training, we were still using the Ground Position Indicator Mark 7 (GPI Mk7). This was a mechanical computer that gave you wind velocity (manual wind or via doppler), true air speed (TAS), ground speed, position along & across planned track, or just plain latitude / longitude. Hook that up to an autopilot and you had a complete navigation system, so what is so strange about the AGC?

(As an aside, the mechanical GPI Mk7 used a spherical resolver to account for latitude changes. Since pretty much all navigation sorties went in / out on the 360 radial until 50 nm from East Sale, the resolvers (think a metal ball, something like a golf ball but smooth) ended up getting a groove in the resolver. This mean it was not unusual to be approaching the 360 at 50 when all of a sudden the GPI would 'jump' to the 360 radial!)

And if you have a penchant for 50s / 60s British nav and bombing systems, you'll enjoy this... and should let her know what an outstanding job she has done:

http://www.tatjavanvark.nl/tvve/dduck0.html

[Abaddon]

A pretty common (but strangely never elaborated on... ) HB claim is that the Apollo Guidance Computer wasn't powerful enough. Reading (on years old threads, so I can't actually post) some HB say "it had the power of a pocket calculator" makes me want to scream "WHAT DO YOU THINK A GUIDANCE COMPUTER IS! IT'S A GLORIFIED CALCULATOR HOOKED UP TO AN AUTOPILOT!"
<respectful snip for brevity>

Functionally, it was exactly a calculator. It was never designed to add up ones taxes, or do ones math homework, it was designed to operate a CSM/Lunar module to achieve a Lunar landing. That is a very different task.

Add to that the simple fact that there exists a gaggle of people out there that have reconstructed that very same AGC to perform exactly as specified just for the sheer hell of it.

Hell, I will admit that I harbour a desire to do likewise. Alas there is never the time. While I lack the time to do it, many have already done it and demonstrated that it does exactly what it says on the tin.

Bottom line is that this is a classic argument from ignorance. "If I can't figure it out, then nobody else can". Oh really? I think not. Well, that's a lie. I know not.

[MBDK]

Add to that the simple fact that there exists a gaggle of people out there that have reconstructed that very same AGC to perform exactly as specified just for the sheer hell of it.

Indeed.  I forget how/where I acquired this link (may have even gotten it from one of this board's members), but here is a page where you can see the step-by-step process of how one group did it, and how to build your own, if you are able (money, time, tools, etc.) and so inclined.  There are also links to programming guides for it on that page.

https://www.instructables.com/id/Open-Apollo-Guidance-Computer-DSKY/

Edit:  Forgot to include the link.  *sheepish grin*

[smartcooky]

Just going by what was in widespread use, analog computers can be a lot more capable than people think. For example of what an analog computer could do all the way back in 1935, check out this page:
http://www.navweaps.com/index_tech/tech-056.php
Basically, a mechanical computer that handled fire control calculations for anti aircraft fire (and surface fire) in all 3 axis to automatically aim the guns so that the shell would arrive where the aircraft will be at the time the shell arrives. It has a gyro to correct for ship roll and such, takes into account wind speed and direction and gun wear (inputted manually) and even compensates for the Coriolis effect! Radars elsewhere on the ship were capable of generating inputs themselves which would feed directly into the fire control computer, which could aim the guns all on its own, no human intervention required. And it's not the size of a room either; it's 3ft x 4ft x 6ft.

Back in the dim dark ages of the early 1970's, one of the systems I use to service and repair was something called an "Air Position and Mileage System". It was fitted to De Havilland Devon and Heron aircraft, the Bristol Freighter and the English Electric Canberra. This was a devilishly clever bit of kit - in effect an electro-mechanical computer that solved the dead-reckoning navigation formula and provided the aircrew with an approximate latitude and longitude. This was from before the days of inertial navigation, and when GPS stood for General Purpose Shelter

It consisted of two major parts

1. The Air Mileage Unit used an artificial "pitot balance pressure" produced by a motor-driven fan and compared it with the pressure from the pitot head. By varying the speed of the fan motor to balance the two pressures against each other, the average speed of the fan motor provided an electrical value for the true airspeed at any altitude within the aircraft's operational parameters.

2. The Air Position Unit sat below the navigator's table, and drove the Air Position Indication (located on the Nav's instrument panel).  On take-off, it would be set to the known Lat & Long, and thereafter, took the electrical pitot input, combined it with electrical signals from the gyrocompass, and fed the result via bowden cables to the API to drive latitude and longitude counters. The system was reasonably accurate (later models were able to account for drift angle caused by wind). The counters could be re-set manually when definite visual or other fixes were obtained.

All of this was achieved with a combination, of gears, synchros and electric motors... not a computer chip in sight!

[raven]

One thing of note is, at least from my fairly cursory examination of the material, the early moon landing conspiracy claims don't mention a lack of computing power as being  a showstopper.
It's only later, as home computers and similar devices got more and more powerful (I have a pretty out of date smart phone, a Samsung Galaxy S5, and it still has far more computing power than everything involved in the whole Apollo program combined), that this claim started to crop up. To those who say "But a simulation of the lunar landing takes X power, yet they only had Y!" I say, reality has its own  weight. How much computation does it take to simulate dropping a rubber ball? How much does it take to drop a ball? Infinitely less than the former.
Really, the whole thing can be debunked by a high school drop out, namely myself, so it's definitely scraping the barrel.

[smartcooky]

One thing of note is, at least from my fairly cursory examination of the material, the early moon landing conspiracy claims don't mention a lack of computing power as being  a showstopper.
It's only later, as home computers and similar devices got more and more powerful (I have a pretty out of date smart phone, a Samsung Galaxy S5, and it still has far more computing power than everything involved in the whole Apollo program combined), that this claim started to crop up. To those who say "But a simulation of the lunar landing takes X power, yet they only had Y!" I say, reality has its own  weight. How much computation does it take to simulate dropping a rubber ball? How much does it take to drop a ball? Infinitely less than the former.
Really, the whole thing can be debunked by a high school drop out, namely myself, so it's definitely scraping the barrel.

Its probably the case that it would have taken more "computer power" to fake the moon landings in 1969 that it did to actually go there.

[JayUtah]

You can never bore me by talking about electromechanical computers.  I think I was a preteen the first time I encountered one, an elevation computer in a derelict WWII tank.  There's something viscerally pleasing about turning knobs and watching dials magically move back and forth in response.  Then recently I had the pleasure of engaging with one of the docents aboard USS Iowa who happened to have been an operator for the fire control computers during his active service.  There's nothing more exciting to me than to see these old guys' eyes light up when they realize you understand how their machinery worked, and when you can work through the trigonometry with them, and also roll up your sleeves and get into the guts of the mechanisms.

I think there's a Clavius page that explains why simulating something is actually more computationally intensive than just coping with the inputs nature provides you.  And yes, the modern desktop computer running a game-type simulation also has to make the graphics to simulate the things that simply exist as physical objects in the actual LM and mind their own business.  For some middle ground, try the old Lunar Lander game.  Those were electronic, to be sure, but did not use general-purpose programmable CPUs.  Most of those games were simple state machines implemented with TTL logic.  The "program" was soldered onto the board.  I bring this up because the AGC, as a stored-program computer, was already more sophisticated than that.

My software guys are adapting code originally intended for an embedded device to run on general-purpose computers.  When I hear a groan from their cubicles, it's usually because they've run across yet another programming construct that presumes the program is running in real-time mode on a dedicated CPU, and they'll have to make risky architectural changes to get it to run on a time-sharing system.  This factors into the comparison because the AGC software could rightly presume it was the only software running on the hardware.

[Abaddon]

You can never bore me by talking about electromechanical computers.  I think I was a preteen the first time I encountered one, an elevation computer in a derelict WWII tank.  There's something viscerally pleasing about turning knobs and watching dials magically move back and forth in response.  Then recently I had the pleasure of engaging with one of the docents aboard USS Iowa who happened to have been an operator for the fire control computers during his active service.  There's nothing more exciting to me than to see these old guys' eyes light up when they realize you understand how their machinery worked, and when you can work through the trigonometry with them, and also roll up your sleeves and get into the guts of the mechanisms.

I think there's a Clavius page that explains why simulating something is actually more computationally intensive than just coping with the inputs nature provides you.  And yes, the modern desktop computer running a game-type simulation also has to make the graphics to simulate the things that simply exist as physical objects in the actual LM and mind their own business.  For some middle ground, try the old Lunar Lander game.  Those were electronic, to be sure, but did not use general-purpose programmable CPUs.  Most of those games were simple state machines implemented with TTL logic.  The "program" was soldered onto the board.  I bring this up because the AGC, as a stored-program computer, was already more sophisticated than that.

My software guys are adapting code originally intended for an embedded device to run on general-purpose computers.  When I hear a groan from their cubicles, it's usually because they've run across yet another programming construct that presumes the program is running in real-time mode on a dedicated CPU, and they'll have to make risky architectural changes to get it to run on a time-sharing system.  This factors into the comparison because the AGC software could rightly presume it was the only software running on the hardware.

Yup. Early PCs for example had a problem with IRQ conflicts. The AGC avoids such things because there is nothing else to generate an IRQ.

[smartcooky]

For some middle ground, try the old Lunar Lander game.  Those were electronic, to be sure, but did not use general-purpose programmable CPUs.  Most of those games were simple state machines implemented with TTL logic.  The "program" was soldered onto the board.  I bring this up because the AGC, as a stored-program computer, was already more sophisticated than that.

I had a Lunar Lander Game that could be programmed into my old HP25C programmable calculator. IIRC, you had to punch in about 40 lines of code, and then play the game by repeatedly deciding how long to burn the decent engine (0 = engine off)

There were no graphics, of course, you had to work out what was happening by interpreting the red numeric LED display which, IIRC, showed the velocity, altitude and fuel remaining.

I'll bet that program used craploads more "computing power" than actually letting the LM fall out of the lunar sky to land at Tranquillity Base!

[ka9q]

My software guys are adapting code originally intended for an embedded device to run on general-purpose computers.  When I hear a groan from their cubicles, it's usually because they've run across yet another programming construct that presumes the program is running in real-time mode on a dedicated CPU, and they'll have to make risky architectural changes to get it to run on a time-sharing system.  This factors into the comparison because the AGC software could rightly presume it was the only software running on the hardware.

I could ask why you're doing this, given the low cost and ubiquity of microcontrollers and small microprocessors you could dedicate to the task, thus avoiding the real-time challenges just as the original did...

[smartcooky]

You can never bore me by talking about electromechanical computers.  I think I was a preteen the first time I encountered one, an elevation computer in a derelict WWII tank.  There's something viscerally pleasing about turning knobs and watching dials magically move back and forth in response.  Then recently I had the pleasure of engaging with one of the docents aboard USS Iowa who happened to have been an operator for the fire control computers during his active service.  There's nothing more exciting to me than to see these old guys' eyes light up when they realize you understand how their machinery worked, and when you can work through the trigonometry with them, and also roll up your sleeves and get into the guts of the mechanisms.

I think there's a Clavius page that explains why simulating something is actually more computationally intensive than just coping with the inputs nature provides you.  And yes, the modern desktop computer running a game-type simulation also has to make the graphics to simulate the things that simply exist as physical objects in the actual LM and mind their own business.  For some middle ground, try the old Lunar Lander game.  Those were electronic, to be sure, but did not use general-purpose programmable CPUs.  Most of those games were simple state machines implemented with TTL logic.  The "program" was soldered onto the board.  I bring this up because the AGC, as a stored-program computer, was already more sophisticated than that.

My software guys are adapting code originally intended for an embedded device to run on general-purpose computers.  When I hear a groan from their cubicles, it's usually because they've run across yet another programming construct that presumes the program is running in real-time mode on a dedicated CPU, and they'll have to make risky architectural changes to get it to run on a time-sharing system.  This factors into the comparison because the AGC software could rightly presume it was the only software running on the hardware.

Yup. Early PCs for example had a problem with IRQ conflicts. The AGC avoids such things because there is nothing else to generate an IRQ.

Nonetheless, you could overload the core memory by giving it too much to do, e.g. hence  1201 & 1202

[Abaddon]

You can never bore me by talking about electromechanical computers.  I think I was a preteen the first time I encountered one, an elevation computer in a derelict WWII tank.  There's something viscerally pleasing about turning knobs and watching dials magically move back and forth in response.  Then recently I had the pleasure of engaging with one of the docents aboard USS Iowa who happened to have been an operator for the fire control computers during his active service.  There's nothing more exciting to me than to see these old guys' eyes light up when they realize you understand how their machinery worked, and when you can work through the trigonometry with them, and also roll up your sleeves and get into the guts of the mechanisms.

I think there's a Clavius page that explains why simulating something is actually more computationally intensive than just coping with the inputs nature provides you.  And yes, the modern desktop computer running a game-type simulation also has to make the graphics to simulate the things that simply exist as physical objects in the actual LM and mind their own business.  For some middle ground, try the old Lunar Lander game.  Those were electronic, to be sure, but did not use general-purpose programmable CPUs.  Most of those games were simple state machines implemented with TTL logic.  The "program" was soldered onto the board.  I bring this up because the AGC, as a stored-program computer, was already more sophisticated than that.

My software guys are adapting code originally intended for an embedded device to run on general-purpose computers.  When I hear a groan from their cubicles, it's usually because they've run across yet another programming construct that presumes the program is running in real-time mode on a dedicated CPU, and they'll have to make risky architectural changes to get it to run on a time-sharing system.  This factors into the comparison because the AGC software could rightly presume it was the only software running on the hardware.

Yup. Early PCs for example had a problem with IRQ conflicts. The AGC avoids such things because there is nothing else to generate an IRQ.

Nonetheless, you could overload the core memory by giving it too much to do, e.g. hence  1201 & 1202

Sure, but that is a hardware limitation, not a code limitation. Which was, ironically, implemented by interrupts.

[rocketman]

So how much power do they think is required?

Boeing 747s flew before the moon landing, so I guess the state of computing power at the time was adequate for a large jet airliner, but inadequate for a spacecraft.  Unless Boeing 747s are fake too.

Much of the computing power used in a lot of modern applications is for a high resolution graphics interface.  If you don't have that, it's a lot easier.

[Zakalwe]

No discussion of this can be complete without acknowledging Charles "Doc" Draper and his work on inertial navigation systems. He developed autopilots that allowed a bomber to fly from Boston to California with no input from the pilot in 1953.

https://www.lindahall.org/charles-stark-draper/




“Doc, can you design a guidance system that will take men to the moon and back safely?”

“Yes.”

“Well, when will it be ready?”

“It will be ready when you need it, Mr. Webb.”

“Well, how will I know that it'll work?”

“I'll go along with it.”


Don Eyles' book "Sunburst and Luminary" is a fascinating source of info on how the navigation systems were developed. Also, Digital Apollo