Saturn V Instrument Ring

[smartcooky]

For those who are familiar with Destin Sandlin's YouTube channel "Smarter Every Day", he has a second channel to which he posts longer, more in-depth and detailed videos.

In this video, Destin he teams up with Linus Sebastian from Linus Tech Tips to go to the US Space & Rocket Center in Huntsville, Alabama for a visit with Luke Talley, one of the IBM computer engineers who worked on the Saturn V.

This is a really fascinating look into the functionality and detail of the Launch Vehicle Digital Computer and other parts of the instrument ring, with a guy who knows every little detail of how it all worked. Its a 45 minute video, but if you are at all interested in the nitty-gritty of electronics, computers and spaceflight (or at least as interested as I am) you will feel at the end that it wasn't long enough... and I've just added another place to my bucket list for my US visit when the current Covid-19 crisis is over.

Enjoy...
 

[JayUtah]

Oh, yeah, I remember that video.  I agree, it's great.

[smartcooky]

When I began my training in Avionics in 1973 (it was called Aircraft Electronics back then) it was less than six months after Apollo 17, so all that style of technology; discrete components, ULDs and monolithic RTL integrated circuits similar to those used in the Apollo Guidance Computer was all the stuff I cut my teeth on. When Luke Talley talked about two-second loops with interrupts and shorter loops running within them, I knew exactly what he was talking about. For our digital logic final exam, we were given a theoretical two/three  lane "X" intersection and had to design a digital controller to operate the traffic lights, complete with pedestrian crossings and green-arrow free turns. Interrupts and loops galore, and it was a lot more difficult that you might think.     

[bknight]

When I began my training in Avionics in 1973 (it was called Aircraft Electronics back then) it was less than six months after Apollo 17, so all that style of technology; discrete components, ULDs and monolithic RTL integrated circuits similar to those used in the Apollo Guidance Computer was all the stuff I cut my teeth on. When Luke Talley talked about two-second loops with interrupts and shorter loops running within them, I knew exactly what he was talking about. For our digital logic final exam, we were given a theoretical two/three  lane "X" intersection and had to design a digital controller to operate the traffic lights, complete with pedestrian crossings and green-arrow free turns. Interrupts and loops galore, and it was a lot more difficult that you might think.  

Of course, if it were easy anyone could do it. 

[Obviousman]

That video was outstanding! Even I could grasp some of it. Everyone should have a squizz at it.

[jfb]

There's a companion video on Destin's second channel that has more material with Luke abusing Linus ("those are called wires"), and it's a blast.  I had a few flashbacks when he described combing through octal dumps for a couple of weeks to troubleshoot a particular issue, only to discover that wasn't the problem after all; I've done a variation on that dance more than once. 

I also like how it quietly refutes the whole "we didn't have the technology to go to the Moon in 1969" nonsense.  You don't need 64-bit general-purpose CPUs and gigabytes of memory to guide a rocket or spacecraft.  What we had at the time was heavy, power-hungry, and labor-intensive to build, but it was adequate for the task. 

[JayUtah]

In a class once I guided a discussion about what it would take to have a guidance system.  Or rather, the processor portion of it.  It was an exercise in requirements analysis.  We started off with a COTS solution, then pared it down to needing only six registers and some custom arithmetic hardware.  I honestly think those guys back then had an easier time thinking outside the box because back then there wasn't as much of a box yet.

But also with the hex dumps -- I've been there too.  My first computer stuff as an engineer was done on the IBM 370 mainframes.  You could always tell whether your program worked by the thickness of the printout.  A thin printout meant your program ran and produced results.  A thick one meant it crashed and OS/MVS (or whatever it was back then) dumped all 256 kB of core as hex.  The Michigan Terminal System, which ran on the same hardware, used EBCDIC 'a' (0x81) as a "core constant."  Before bringing your program into memory, it filled your entire memory space with that value.  And then when the inevitable dumps happened, it "cleverly" omitted those from the dump as untouched.