When the Hardware Is the Algorithm: Resolvers and the B-52's Electromechanical Trig Computer

Ken Shirriff has been systematically dismantling computing history for years. He has reverse-engineered the Apollo Guidance Computer’s core rope memory, traced signals through the IBM 1401’s discrete transistor logic, and decoded the die layout of early Intel processors. His latest teardown is the electromechanical angle computer buried inside the B-52 bomber’s star tracker, and it is one of the more striking pieces of engineering he has covered. Not because it is complex in the way a modern chip is complex, but because it is so thoroughly alien to the way we think about computation today.

The B-52 Stratofortress entered service in 1952. Inertial navigation systems existed, but they drifted. The gyroscopes and accelerometers of the period accumulated error at rates that mattered over an eight-hour intercontinental mission. A bomber carrying nuclear weapons needed to know where it was with accuracy measured in fractions of a nautical mile, not the several miles that INS drift could produce over a long flight. GPS was decades away. The solution was celestial navigation: track a known star, measure its angular position relative to the aircraft, compare that with where the star should be given your assumed location and the current time, and use the difference to correct your position.

The star tracker itself is an optical instrument mounted on a gyro-stabilized platform. It can acquire and track stars even during daylight at high altitude by filtering for the narrow band of light around a specific star. The tracker outputs two angles: azimuth and elevation in the aircraft’s body frame. Those angles are mechanically meaningful but navigationally useless on their own. What you need to know is how those measured angles relate to the star’s known position in celestial coordinates, which means you need to transform through several coordinate frames in sequence.

Coordinate Frames and the Transformation Chain

A star’s position is published in astronomical catalogs as right ascension and declination, which are coordinates in the celestial equatorial frame. They are fixed (ignoring precession, which is slow enough to tabulate). To predict where that star should appear from a given point on Earth at a given time, you have to convert:

From celestial equatorial coordinates to the horizon frame at your location, accounting for your latitude and the current sidereal time
From the horizon frame (altitude and azimuth relative to north and the horizontal plane) to the aircraft body frame, accounting for heading, pitch, and roll

Each of those conversions is a 3D rotation. The math is spherical trigonometry, and the result is that you need to evaluate expressions full of sines and cosines of several angles simultaneously. In 1950s computing terms, that was not something you could do digitally at the speed and precision required. Digital computers of the era were large, slow, and fragile. The angle computer in the star tracker does all of this mechanically.

What a Resolver Actually Does

The core component is the resolver, which looks like a small electric motor but functions as an analog trig computer. A resolver has a rotor winding and two stator windings arranged at 90 degrees to each other. Apply an AC voltage to the rotor and rotate the shaft to angle θ; the two stator outputs are proportional to sin(θ) and cos(θ) of that shaft position. The relationship is exact within manufacturing tolerances. The device is not approximating anything. It is doing what wound copper and rotating geometry do.

You can also run the computation in the other direction. Apply voltages representing a vector (x, y) to the two stator windings and drive the shaft to angle θ, and the rotor output is x·cos(θ) + y·sin(θ). That is the dot product of the input vector with the unit vector at angle θ. Geometrically it is projection; algebraically it is one row of a 2D rotation matrix.

Chain two resolvers together so that the output of the first feeds the input of the second, and you have composed two rotations. The math falls out of the physics. You do not program this. You wire it.

A complete 3D coordinate transformation requires three successive 2D rotations (Euler angles). Three resolvers in series, with their shafts set to heading, pitch, and roll respectively, transform a vector from the aircraft body frame to the local horizon frame continuously and in real time. Add another stage for latitude and sidereal time and you have the full transformation from body frame to celestial equatorial coordinates.

The Sidereal Time Problem

One of the inputs to this chain is Greenwich Mean Sidereal Time, which advances at a rate of one full rotation every 23 hours, 56 minutes, and 4 seconds. The system cannot look that up; it has to track it continuously. This was done with a precision servo motor driven from a stable oscillator, its shaft position representing the accumulated sidereal time since a known epoch. The motor turns, the shaft rotates, the resolver computes. Time literally advances mechanically.

The latitude and longitude inputs came from the aircraft’s inertial navigation system, fed as shaft positions through servo loops. As the INS updated its position estimate, the resolver shafts tracked those updates, and the coordinate transformation stayed current.

Once you have the expected direction to the star in aircraft body coordinates (from the resolver chain, starting with the star’s published RA and Dec and transforming through the full chain), you compare it with the actual measured direction from the star tracker gimbals. The difference in those angles is the angular error. Projected back through the geometry, that error corresponds to a position error on the ground.

The comparison was done electrically. The resolver outputs for expected position and the tracker gimbal signals for actual position fed into a differential resolver, producing an error voltage. That voltage drove servos that updated the navigation solution. The whole system ran as a continuous servo loop: tracking the star, computing where it should be, measuring where it is, feeding back the difference.

There was no sampling. No ADC. No processor scheduling. The computation ran at the frequency of the AC excitation signal, typically 400 Hz in aircraft electrical systems, which was fine because the star was not moving that fast.

What This Architecture Actually Means

Modern software engineers will sometimes reach for the phrase “hardware acceleration” when talking about GPUs or FPGAs doing math faster than a CPU. The resolver computer inverts that framing entirely. There is no general-purpose substrate being directed toward a specific computation. The hardware is the algorithm. The physical arrangement of the windings, the gearing ratios, and the wiring topology directly implement spherical trigonometry. To change the computation you would have to change the machine.

This carries costs. The system could not be reprogrammed. If the navigation equations changed, someone had to redesign physical components. Adding a new coordinate transformation meant adding new hardware. The inflexibility was total.

But it also carried properties that digital systems do not get for free. The computation had no quantization error. A resolver does not represent sin(θ) as a floating-point number; it is a continuous voltage that varies smoothly with shaft position. The accuracy is limited by manufacturing tolerance and electrical noise, not by word length. There is no accumulation of rounding error across stages in the same way digital computation has. And the system had zero latency in the signal-processing sense: the output updated instantly with the input, with no pipeline stages, no clock cycles, no scheduler.

Shinriff’s teardown shows the physical hardware in detail: the compact stacks of resolver units, the synchro transmitters that carried angular information electrically between parts of the system, and the mechanical dials and servo indicators that made the computation legible to the crew. It is the kind of artifact that rewards close reading. The engineering density per cubic inch is remarkable, and the design constraints were severe: it had to survive vibration, temperature swings, and altitude changes while computing continuously for hours.

Why This Still Matters

The B-52 still flies, though its navigation suite has been updated. Modern versions use GPS integrated with inertial navigation, which is simpler to maintain and more accurate in most conditions. The resolver-based angle computer is a museum piece.

But the underlying ideas are not. Resolver-based position sensing is still common in industrial servo systems and aerospace applications where digital encoders would be unreliable. Synchros still appear in heavy industrial equipment. And the broader principle, that continuous physical systems can compute, shows up in analog neural networks, optical computing research, and the nascent field of physical computing, which asks what computations can be embedded in the physics of materials and structures rather than simulated on a digital substrate.

The star tracker angle computer is not an early attempt at something we now do better. It is a different thing. Understanding it means sitting with a model of computation that does not center software, does not center digital representation, and does not center the von Neumann architecture. The physics does the work. The engineer’s job was to arrange the physics correctly.