Ken: big fan of your and Marc's work, would be so great if you guys could give the Ken&Marc treatment to the "Nortronics NAS-14V2 Astroinertial Navigation System", The R2-D2 unit from an SR-71. Well, here's hoping.
I'm struggling to wrap my head around manufacturing so many parts to the needed tolerances and having them work under the temperature swings and forces seen in flight. Debugging these analog computers would involve a large number of engineering disciplines!
It's not that hard. All the components here are common and well-behaved - gears, cams, bearings, shafts, mounting plates, and synchros. Only the mounting plates, shafts, and cams are fully custom. Everything else is an off the shelf part. It's like designing electronics - you use standard components, but boards are custom for the job. Design is mostly topology plus constraints to make it fit and keep vibration and backlash under control.
There are mechanical equivalents to proto boards, sort of like Lego gearing, but all metal. W.M. Berg used to be the main US maker. So you make up all the functionality on a breadboard, test with inputs and outputs, then rearrange for production.
The mechanical design is like medium duty clockmaking. Teletype machines are in roughly the same scale - the parts can be handled without tweezers and are not too fragile.
(And all custom, with far more levers than gears.) It's possible to go smaller but everything becomes more fragile and wears faster.
It's roughly the same technology as naval fire direction computers [1], but smaller and more automated.
When I was in basic research I thought that concept development and prototyping represented the hard part of the work, requiring actual brain power. Show it works and the rest is "engineering." Then, I moved to industry where products have to meet size, weight, and power restrictions, be manufacturable, testable, deployable, and usable by people who have other things to do. Aircraft usually come down so add serviceability. For most space applications, it's even more stressing.
Even within engineering disciplines there's a tendency to "throw the design over the wall to manufacturing." It usually leads to bad news.
The transition from TRL(Technology Readiness Level) 4 to TRL 7 in NASA's parlance is called the "Valley of Death" for good reason.
One big difference is that it's all in 3D. Electronics is done with off the shelf parts, physical position doesn't usually matter to the millimeter, electricity follows the wire except with RF and high voltage.
The other difference is that none of the techniques are familiar to anyone but MEs anymore. Most hackers know software, some of us can do hardware, a few can do light woodworking and 3D printing... but I've never implemented even basic logic in any mechanical way.
Plus, they had to do it all WITHOUT CAD.
Everything about it is impressive and really cool.
> The other difference is that none of the techniques are familiar to anyone but MEs anymore.
There is that. But this thing isn't that bad. All the motion is slow. There are no gyros. The precision requirements are modest. It's only 2 1/2D; it's a vertical component stack. There are no diagonal shafts or long, odd-shaped levers. It's not power-limited to the degree that a clock is. Everything is statically driven; there are no components that depend on inertia, which is appropriate for an aircraft system. It doesn't have wheel and disc integrators, which depend on friction and are touchy. This thing is all gears and cams, which are well-behaved. As the original article points out, it performs a simple computation which is a well defined function of the current inputs.
I've seen the ground-based mechanical computers that controlled a Nike missile, and those are similar technology as this but much more complex.
I've restored century-old Teletype machines, and those are more complex than this thing.
Now, those really did require mechanical genius to design. All the good Teletype machines were
designed by two people, Howard Krum and Ed Klienschmidt. It took a long time, decades, to get the core design right, and even Siemens, which built their own variation, did not redesign the core decoding mechanism. William Burroughs designed the first really reliable adding machine mechanism, and Burroughs dominated that market for decades. Burroughs had to design by scribing lines on zinc sheets; paper drawings didn't hold dimensions accurately enough. Ottmar Mergenthaler's Linotype design barely changed over a century, being better than both its predecessors and successors.
Those guys were mechanical design geniuses. This Bendix device is a good, workmanlike design, but not in that class.
The fact that they actually had to worry about the precision of drawings in addition to the actual device is amazing. It's such a foreign concept in the computer age, where you never want any information to be exclusively analog like that, you never want to directly rely on a steady hand, and drawings are just a UI on top of numbers and constraints.
I still think the Bendix is a bit outside the difficulty level of most modern tech work, but scribing lines on zinc sheets and decoding what's essentially UART without silicon is just insane. That's an amazing story right there!
Here's the actual serial data decoder, from when I was restoring a Teletype machine.[1] There's a short essay on mechanical design philosophy over there.
> It's such a foreign concept in the computer age, where you never want any information to be exclusively analog like that, you never want to directly rely on a steady hand, and drawings are just a UI on top of numbers and constraints.
Which is why AutoCAD was so successful. Engineering departments used to have huge rooms full of people at large drafting tables. Good drafting rooms had north-facing skylights. HP's old headquarters on Page Mill Road has four large buildings like that.
I feel like the designers of this would feel the same way about the current solution involving sand that has been imbued with the ability to think.
We take for granted the abstractions and mental models/tools we have to manage the complexity of the current paradigm. No doubt, the engineers who created this had their own structures for understanding the complexity at work here.
It's almost like a foreign language! I was just in another discussion the other day about how I rarely use pen and paper, and how that affects my thoughts since my "native language" for thinking about the world is "stuff that can be said on a phone call, typed on a keyboard, or made with CAD primitives".
Back in the day when everything started on paper there might have been a bigger variety of abstractions, because people were starting with a literal blank canvas and making their own tools to implement their ideas rather than most people largely just exploring the possibilities that naturally fit existing tools.
Stuff is way easier now and overall tech is so much better, but I wonder if part of the cool factor people feel about old stuff is from the lack of constraint.
It's worth noting that when this was designed, mechanical clocks and watches, which work on similar principles, were already a few centuries old, as were various types of mechanical calculators.
Moreover, I'd say that "debugging" one of these is actually easier in many ways than software --- everything can be inspected directly and manipulated.
It's impressive what the USA was capable of manufacturing from the 1940s to the 60s. My Bendix 6080 vacuum tubes were rated for use in missiles and can withstand very extreme conditions. Overkill for my application, but ensures years of reliable use in my headphone amp!
Agreed. I never thought much about fuzes but Curious Droid's video on the proximity fuze used during WW2 was eye-opening. Vacuum tubes surviving launch in an artillery shell...
The synchros run the cockpit displays. Sounds like an intuitive match. But the computed values are also used in other systems: engine control, targeting, that sort of thing. Is the signaling to these also through the synchros? Is there some kind of standard signal format for these?
The signaling is indirect. The air data computer is connected to another box, the air data converter. The air data converter is designed for a specific type of aircraft. It converts the synchro outputs from the air data computer into the formats required by the particular aircraft. These are probably synchro outputs as well, but might need to be scaled. (I don't think there is a standard.) The converter would also distribute the signals as needed, with a connector for each device that receives the data.
I'll point out that reverse engineering the CADC is not as easy as you might expect.
Well, there goes that illusion. :)
An amazing piece of work as usual, Ken. Thanks for sharing your hard-won insights on this gadget. The linear-endpoint wraparound hack was worth learning about all by itself. I'm surprised it took until 1954 before someone got around to patenting that, as it seems like a valuable general-purpose control technique. I can imagine a CORDIC-like algorithm that takes advantage of something similar to avoid clamping.
You have to find a way to power this thing up as a static demonstration piece.
Thanks! We're powering up the unit piece by piece. CuriousMarc got a vintage pitot tube vacuum simulator so we'll use that to simulate the different pressures.
I'm not sure how the devices were zeroed. This will probably be an issue when we put it back together. I think some of the gears could be loosened on the shaft so they could be rotated to the correct point. The manual defines the zero points for all the synchros, i.e. 0° means X pressure or Y temperature, so I guess you'd adjust everything to those points.
Are the synchros in this similar to what the Rosenblatt Perceptron used to adjust and show weights: "This machine was designed for image recognition: it had an array of 400 photocells, randomly connected to the "neurons". Weights were encoded in potentiometers, and weight updates during learning were performed by electric motors.[2]: 193 "
I couldn't find details on the Perceptron's motors, but I expect they were DC motors, rotating the potentiometers higher or lower as needed. The synchro is useful if you have a rotation in one location and one to match the rotation at another location. But with the Perceptron, you don't have a specific rotational angle you want, just "more" or "less".
Based on a quick search, it looks like air impedance (the mysterious air density x speed of sound calculation) affects turbine stability. So needed for engine control?
I started by searching for "turbine air impedance". Seems to be a common topic, but maybe just for design modeling? And maybe an outdated parameter to use? One of the front-page hits is a recent (2021) paper from Whittle Laboratory [1] "Modeling Turbine Acoustic Impedance" [2]. Abstract says in part
"Impedance boundary conditions are an influential yet uncertain parameter in predicting the thermoacoustic stability of gas turbine combustors...A parametric study of turbine stage designs using the analytical model shows acoustic impedance is a weak function of degree of reaction and polytropic efficiency. The design parameter with the strongest influence is flow coefficient, followed by axial velocity ratio and Mach number. We provide the combustion engineer with improved tools to predict impedance boundary conditions, and suggest thermoacoustic stability is most likely to be compromised by change in turbine flow coefficient."
Many search iterations later [5], I found a recent paper discussing "fuel flow rate fluctuations which depend upon the air side impedance at the fuel injection location" [3].
Maybe it's for controlling inlet shock waves? However, I couldn't find anything obiously linking "Air inlet control systems" to "air impedance". Here's one paper discussing such a system, with an extremely detailed transfer function [4]. Maybe it's using another term for impedence, or something close?
Edit: Considering this was cutting-edge control hardware for military equipment, I guess some lack of public details is to be expected. On the other hand, on Ebay there's a Fuel Control Unit for a J-79 engine as used in the B-58 Hustler [6].
I have a copy of "computing mechanisms and linkages" by Svoboda, MIT radiation labs press. I always wondered what functional applications cams had, and now I know (it was a library sale book, one of a huge series published at the end of ww2)
