Tell me about analog naval fire control computers

This is quite long! Be forewarned. Nevertheless, if you came here, you might find it interesting.

It's "lifted", with some editing, from a thread about mechanical analog computers, and put here at the suggestion of one of the contributors to that thread. (If this de facto double post is a bad idea, Eng-Tips: Please e-mail me! The article in the thread could refer to this FAQ, instead.)

=====

This is an "anecdotal" commentary about mechanical analog naval gun fire control computers, based on the writer's extreme interest in them, as well as a tour of duty in the U.S. Navy, U.S.S. Eversole, DD-789, 1955-1958. (Pac. Fleet)

What you see here is extremely likely to apply to old land-based AA fire-control computers, although they might not have been as thoroughly mechanical as the naval ones.

As to surface fire on land, I just don't know. Being able to enter target range and altitude, along with wind data, and then have ballistic data handled automatically, would have been helpful.

Of course, a fixed gun doesn't need stabilizing, but modern tanks that fire while moving are something else, again. Of course, modern tank fire-control computers just have to be digital; I can't imagine any analog devices in them.

This was written in one long session, and of necessity, a significant amount of supporting basics was omitted. I hope to fill out the material as time goes on.

===

At FT school (Bainbridge, Md.), I really thought Heaven had come to earth when, well ahead of the class, I saw something with custom transparent-plastic covers replacing the cast-Al-alloy ones: it was the...

[Mark 1A mechanical analog computer:]

<http://dcoward.best.vwh.net/analog/ford.htm>
(Doug is traveling, and looking for work, btw! (Late March, 2004))

Those pages show the WW II version, the Mark 1. (There were different Mark 1s, designated by Mod. numbers.) The WW II versions had a mechanical resolver working backwards that didn't work too well; it sometimes needed operator help. Post-war, a design re-thinking fixed that. Result was the Mark 1A, which included other improvements.

As to Web-page specs: Current consumption is apparently worst-case, all synchro receivers locked at worst-case angle. (Educated guess). The computer, itself, ought to run easily on a 20 A. 120V 60 Hz circuit.

I have a mechanical schematic of that machine, bought from Doug, which is about 19 in. by 48 in. or so. I still understand maybe 2/3 of it.

===

[Web page]

One really-good Web page on the Mk.1 is at the DE220 Web site:
<http://tinyurl.com/ljv5>, which came from:
<http://www.de220.com/Armament/Fire%20Directors/Mk%201%20Computer/Mk%201%20Computer.htm>

I recall reading that page some time ago, and could make some comments about it, but iirc, it's solid. No silly quasi-religious nonsense about True North.

There are some splendid National Archives images of some of the innards, although not of the really interesting sections.
Chop off the right end of the full URL some, to read a lot of very good material. Thank the site's creator!

[Btw, the 1.1-inch gun mount, also described (photos, at least) at that site, has a traverse axis; apparently it doesn't develop gimbal lock when firing straight up. IIrc, its drive servos were maintenance nightmares.]

{Repairs!]

I was extremely lucky to have occasion to repair a Mark 1A; there was a fabulous two-volume set of very-detailed instructions on disassembly, field repair (iirc), and reassembly/realignment. (HELP! Does anyone remember/know the OP number?)

We took off about 15% of the top to get at the loose screw. It was a rare treat to gently exercise the individual mechanisms, clean and lube if needed, wrap them in quite-clean rags, and put them behind the fire control switchboard.

Despite their formidable complexity, these computers were remarkably reliable; they were designed and built by very capable engineers.
Disassembly was time-consuming, requiring the manuals I referred to, and reassembly was even more time-consuming, because connections between mechanisms had been broken.

For instance, if one mechanism was putting out exactly zero, the one it operated could be at any position; the connection had to be slipped and then clamped.

===

[Misinformation, elsewhere]

There's some misinformation on the Web, as well. The integrator discs were *not* an inch thick; more like 1/4 or 3/8 inch. (Also double-sided, so they could be reversed if worn.)

The original of the article, in the Annals of the History of Computing, about Ford and Newell, has an excellent photo of an integrator. However, copies of that article do simply wretched things to the gray scale on that photo.

Also, True North, mentioned in almost religious tones on one Web site, is simply bogus. Own Ships Course was a synchro input from the gyrocompass. There was no Coriolis Effect calculation, either, at least in the later mods. in WW II. The Coriolis Effect was just not important enough for the guns operated by these computers.

See also earlier comments about power consumption -- not really misinformation, just incompletely-defined info. (The high current was probably part of a spec. for determining power requirements and wiring for the worst case.)

===

[Some details]

The Mk. 1A has four 3-D arbitrary-function cams that hold the ballistic information for the gun and projectile the machine was built for.

The integrator outputs (through a chain of servos) drove the sights in the gun director to help keep it on target (aided tracking); tracking errors went through clutches and coordinate converters to position the integrator carriages.

[Mechanical resolvers]

Back then, these were called component solvers, a reasonable term.

They were basically Scotch yokes, known to steam-engine enthusiasts, but with a variable-radius crankpin.

(The Scotch yoke is a slot in a casting, probably mounted on a crosshead. Its motion is coupled directly to the piston rod. The slot is slightly longer than the diameter swept by the crankpin, and is at right angles to the sliding motion. It's a theoretically-perfect sine (or cosine) mechanism.)

Most resolvers had two "yokes", slots in Al-alloy plates with ball-bearing-roller sliding supports beyond the "crankpin". No piston rods; just racks on the edges of the plates.

The slots were carefully adjusted during manufacture to be at right angles.

The crankpin had a block (square), or possibly two, one for each slot. It was mounted on a block that slid in a wide slot in a disc. That disc set the input angle.

Radius was set by an offset cam follower, running in the spiral groove of a face cam cut into the surface of another disc. The offset permitted setting a zero radius.

A few resolvers had a crankpin-radius slot that extended over a full diameter, to permit negative-radius inputs. Radius was set on those by a leadscrew parallel to the crankpin slot.

In the Mk.1 computers of WW II, there was a resolver ("vector solver") that accepted x and y inputs to the sliding slots, and put out a radius and an angle. However, if the angle was about 180 degrees wrong, the radius went the wrong way, and the computer needed human help, losing precious seconds.

[Electromech. servos]

There's a quite-detailed description (sorry, no images) of the electromechanical position servos in the Mk.1/1A, in the YahooGroups archives on the Howthingswork list, which I have contributed a great deal of material to.
It was written roughly six months ago, I think. Sorry not to have a link, now.

Really briefly, bang-bang, tungsten contacts, reversible two-phase cap.-run motor, velocity-feedback stabilized by magnetic drag* and spring. (Think high-torque-output traditional speedometer.) Large errors were stored in intermittent gearing; null was like odometers at the all-nines/all-zeros carryover.
*PM and squirrel cage, really likely

Jitter at null was minimized by flywheels on the motor shafts, free to rotate on the shafts but coupled to them by magnetic drags.

The motors were modified squirrel-cage ball-bearing induction motors with linear torque/speed curves, just about sure. They were available from Ford Instrument Co. after WW II. (Ford, named for Hannibal C. Ford, made these computers; it was absorbed into Sperry, iirc, after WW II.)

As to servo bandwidth, I have no figures, but I do know that from "playing" with them that it might be as good as 10 Hz; that's a crude guess, though!

There were also a few with more-sophisticated stabilization (free flywheel connected to a differential inserted into the mag.-drag feedback, iirc). These had no velocity error.

===

[Photo shoot?]

I have great hopes for arranging a session (or a few) to take the covers off one of the museum-ship machines (they're too big and heavy to remove!) and take some really-good photos (scanning digital camera?) of the innards. See above for a mention...

Once done, I'd put in a few bags of dry silica gel, button it up again, maybe leave a love note to future generations, and give it a blessing.

[Materials]

Stainless steel shafts (and most gears, I assume); most of the rest, Al alloy plates. Some major mechanism support plates (Al alloy) were an inch thick, as I recall.
Housing was big Al alloy castings.

[Sounds]

The sound of these machines was distinctive and memorable. Static (powered up, nothing moving), there was a tinkle of gears now and then as the servos fixed tiny errors. A servo that was suddenly enabled, with a big error, made gear-train noises as it slewed and settled; full scale might take a few seconds.

The unforgettable sound, though, was that of the time motor starting and running. It took a few seconds to accelerate, with a hint of siren-like whine. Once at speed, an interesting escapement, cam, and contacts, combined with a jewel-bearing spur-gear differential, did what was effectively a pulse-width modulation (5 Hz?) of the AC power. The torque reversals happened twice per tick (power on, power off), and were rough on the gear reduction at the motor.

The combination of the very regular "chunk-chunk", some semi-random tooth noise, and a frosting of tinkling gears was memorable. In all, maybe 60 or so (very crude guess) meshes contributed to the sound. The cast-Al alloy covers muffled some of the sound, of course.

[Range and rangefinders]

(Off-topic, but I couldn't resist! )

Btw, before radar, range was determined by optical rangefinders. The r/f operator turned a knob to make the target seem to be the same apparent distance away as the little open lozenge-diamonds in the reticle. (These were not split-image types; those didn't work out, in practice.)

A central wide button on the knob told the computer when the rangefinder was on target.

The view through a rangefinder was stunning. Scenes miles away seemed to be like a tabletop scale-model diorama, because the sense of depth was so strong.

Those long ears that stick out of the sides of some older gun turrets and all earlier gun directors are the ends of the rangefinder.

[Hopes]

I dearly hope to write up these machines in lots more detail on a planned Web site -- <nbodley.us> is parked, for now; nothing there (end of March, 2004).

CLASSES OF M.A. F.C. COMPUTERS

[There were essentially two main classes of mechanical analog fire-control computers. One variety, such as the Mk. 8 Range Keeper, which did just fine in 1991 for battleship shore bombardment, and the Mk.1/1A, carries computational quantities from one place to another by way or rotating shafts. Typically, full scale implies many turns of a shaft.]

[These machines, called tachymetric (not "tachometric") (Greek: "tachys" = speed, iirc), effectively determined the target speed (implicitly, I'd say). That speed, combined with one angle, and rate of change of altitude, defined the target motion vector.]

(For the other class of m.a.f.c. computer, namely linkage, please scroll down; I'm not quite organized! )

[Prediction]

From that target-motion vector, along with range to the target, the computer could predict where the target would be when the shell reached it. The gun lead angles aimed the shell to that point, and the mechanical time fuze setting made the round explode at that time.

Yes, there were prediction multipliers, thin things, in a stack, iirc, of four. Big, too; maybe a foot square? Basic principle was geometrical, a model of similar triangles.

These multiplied range (adjusted distance to impact point, iirc) by the cross component of
target motion, iirc, to calculate lead angles. Other multipliers calculated wind corrections.

---

A simplifying assumption was that the target vector wouldn't change.

Assuming that the target-motion vector stayed unchanged, predictions were accurate.

[An anti-sub machine (Belock?) was built with constant radius-of-turn, as well, but that was disabled because of serious reliability problems. Don't blame Harry(?) Belock! Not his fault!]

More fun was calculating the angles required to keep the guns on target as the ship's deck tilted. Exact calculations were not possible in the Mk.1/A; there were too many terms.
The Mk 47 Computer, mentioned below, did exact calculations, using resolver chains.

Unfortunately, these tachymetric machines were not fast enough in converging to a solution when kamikazes (late-WW II suicide bombers) came in; another likely limitation was that the gun director couldn't turn fast eonugh in bearing ("sidewise").

[Grace Hopper]

RAdm. Grace Murray Hopper apparently did some of the fundamental math. for the (post-WW II redesign?) of the Mk. 1(A?). The Mk. 1 (WW II) design started in the early 1930s, I'm told.

[Evolution]

These tachymetric machines did evolve, however; the Computer Mk. 47, another magnificent machine, was an hybrid. It did multiplication with precision pots, and trig functions with electrical resolvers (similar to synchros). That computer was part of the GFCS Mk. 68, iirc. (GFCS = Gun Fire Control System) Its math. foundation was a thorough re-thinking of the fire control problem.

IIrc, it also had 3-D cams for arbitrary ballistic functions.

The Mk. 47 was built in six huge sections mounted on ball or roller slides for maintenance access. The slide movement was fore and aft, considering that ships roll much more than they pitch, and those sections weighed a lot.

Although there were shaft connections between sections, shrewd design restricted the type of data carried by those shafts. Like the output of integrator rollers, the data carried by the shafts was only in their incremental motion; absolute position was meaningless. (I realize this might need more explanation.)

Needless to say, the insides of that computer were gorgeous. I truly hope that one has been preserved, somewhere.

The whole gun director for that GFCS was gyro-stabilized in one axis; it sat in a huge yoke. Trunnions were toward and away from the target. The USS Wilkinson, DL5, had that system.

A further evolution was the Computer Mk. 100 (?), for the Terrier (? likely) ship-borne surface-to-air missile. IIrc, that computer did mostly electronically what the disk-ball-roller integrator did mechanically, to integrate one variable with respect to another variable, not necessarily explicitly with respect to time. All-electronic analog computers, afaik, can only integrate with respect to time.


THE OTHER KIND ==================
at last...

If the rotary-shaft/tachymetric variety are hard to find out about, even more obscure are the phenomenal linkage analog computers. One good look at their mechanisms, and you'll never, ever forget it.

I can only compare these to a sofa-bed linkage, or some linkages for an auto. convertible top. However, a fire control computer has more elements, and each is
by no means anywhere near to being as complicated as the two examples I cite.

I have seen two linkage computers, open to my eyes; one was in the Mk. 56 GFCS, and the other was a Librascope sonar fire control computer.

[Kamikazes and the GFCS Mk.56]

The Mk 56 Gun Fire Control System was a real masterpiece. I'm essentially sure it was a very-fast-reacting system that was developed to cope with kamikazes. There are illustrations on the Web of its critical innards, very clever, and the most not-to-scale drawings I've ever seen...
(Sorry; they're ugly, too...)

However, scale drawings of its linkage computer seem exceedingly difficult to find; that's my current viewpoint. Not the least-remarkable aspect is that the ballistic calculations were done by linkages, not 3-D cams!

The Mk. 56 system's linkage computer (it had its own Mk. no.) consisted of an upper "tray" (in a casting, iirc), maybe 4 or 5 inches deep, maybe a yard (meter) wide or a little more, and maybe 20 inches from front to back. The linkage components moved sidewise and toward and away; all pivot axes were straight up and down.

Just about sure that there were counterbalance weights in a few critical places, because rolling of the ship would put significant gravity pull on the mechanism.

At the bottom of the tray were high-precision racks and pinions for rotary mechanical input and output. A substantial space below the "tray" held servos and synchros for the I/O.

There was a remarkable 3-D mechanism ('dummy gun", loosely speaking, that had a rod pointing straight down (home position). The rod fitted into a ball with a hole through it (ball: likely).

The ball moved an x-y carriage with linear-pot pickoffs, and the whole x-y assembly rotated through a limited angle as the gun director rotated around the line of sight as the deck tilted.

The assembly was nicknamed the finger of Omar.

The system design was by Ivan Getting; oral history transcripts, iirc by the IEEE, were on the Web and probably still are. One of those transcripts has the U.S. patent number on the Mk. 56 system, although there is no mention of "Mk. 56" in the patent, which was long classified. IIrc, the patent number is in the 3,400,000..3.6M range. It contains a detailed mechanical schematic, using symbols for the multipliers you won't easily forget.

Detailed linkage design was apparently by Antonin Svoboda, one of the authors in the MIT Radiation Lab. Series.

[Sonar linkage computer]

The sonar computer, made by Librascope, was mounted on a bulkhead (wall), and linkage movement was in a vertical plane. It was smaller than that of the Mk 56 system's computer. It contained enclosed disc-ball-roller integrators; they were on the market, once, as mechanical components.

Its sine (or cosine, but not both!) mechanisms were hypocycloidal (iirc) gears, exact 2:1 ratio between a ring gear with internal teeth, and a smaller gear on a disc crankpin, so to speak.

The inner gear rotated Spirograph fashion inside the ring, but the 2:1 ratio meant that any point on its pitch circle moved in a straight line. The output was a pivot just coincident with the pitch circle.

These mechanisms were also offered commercially. They were theoretically perfect, neglecting tooth errors and backlash. (This mechanism was used on some early steam engines. Don't confuse it with another somewhat-related scheme that made several flywheel rotations for one stroke.)

For just a little taste, a computer that probably did only scaled addition and subtraction, see <http://dcoward.best.vwh.net/analog/libra.htm>. That machine converts rotary knob inputs to linear motion, and uses cascaded "whiffletree" linkages to do scaled addition and subtraction, with the results displayed on the two large pointer dials.
(Love that spare parts collection )

Linguists will see where Librascope got its name; remember the astrological sign for Libra? Balance? ("skopein" (to see?) is Greek, iirc)

If you know the IBM Selectric mechanism (a good part of it is mechanical binary!), its tilt and rotate combining linkages are the same idea; identical in principle, except for binary inputs.

Btw, steam-engine valve gears (afaik, all) are low-accuracy analog multipliers. The Baker valve gear is closest to those used in linkage computers, although physically simpler; a Baker's castings are not the easiest to understand.

As to factual reliability, this should be rather good. I try very hard to either be as correct as I can, or include some qualifying remarks (which, in other docs., I often do).

In closing, I am rather poor about replying to e-mail (I'd prefer to be different!), but one never knows. Try anyhow. If I'm not snowed under, I'll give my best.

Nicholas Bodley ("Nicabod")
Waltham, Mass. Retired