Now It Can Be Told

Testing Trident Ballistic Missiles

Note: I have never held a security clearance. The information below is 40 years old; it predates GPS. I'm reasonably sure it's all completely obsolete.

Introduction

I began my working career in the Santa Barbara, CA area, where the small tech community is occasionally called "Silicon Beach". During the Bummer Summer of '76 (so-called because El Niño conditions kept it cool and foggy), I worked assembling the world's first digitally frequency-synthesized dual-band ham radio, the Comcraft CST-50. In December of that year I got a similar circuit board assembly job at Sonatech, a local maker of underwater equipment.

At Sonatech I discovered "high tech". I worked there for a few years and continued summers and Christmas breaks when I went back to school. During this time, around 1980, Sonatech picked up an important contract called STS, "Sonar Tracking System". I began working on STS after I graduated UC Santa Barbara in 1982 and continued working on it for the next couple of years.

STS

The goal of STS was to build a single instance of a system that provided range and bearing to a "cooperative" underwater target from a nearby ship. STS was installed on AGDS-2, the USS Point Loma. The Point Loma was the Launch Area Support Ship (LASS) for the Pacific Missile Test Range. It was tasked to be on the scene when a submarine launched the then-new Trident I ballistic missile, now known as the UGM-96. In short, the purposes of STS was provide information that would allow other shipboard equipment to know exactly where the missile was going to pop out of the water. In particular, shipborne antennas could guarantee instant acquisition by being correctly aligned prior to launch. The shielded antennas are visible here and in more detail here as the "golf balls" near the bow.

How did STS work? Well, the "cooperative target", a Trident missile submarine, carried a pinger during the test which responded when interrogated by the ship. So the system needed only to ping and measure the response time from the pinger (to establish range) on two or more receivers with known spacing (to establish bearing). Given that Sonatech and its sister company International Transducer were experts at building sonar transmitters and receivers, it sounds pretty straightforward, right?

It wasn't. Nothing about the physics of sound in the ocean is simple. This is particularly true at the "head end' of the test range, the Eastern Pacific somewhere offshore from San Diego. This part of the world's oceans is known for maintaining an extreme thermocline, or temperature layering. The effect of the thermocline on sound transmission is so extreme that a ship may not be able to ping a target at a shallow depth (e.g. a submarine about to launch a missile on the test range) even if it's just a few miles away. The temperature layer creates a sort of channel that carries the sound away horizontally with no vertical penetration.

To address this, the system used a third component: a towed, manta-ray shaped fiberglass "fish" containing a transducer (the audio "speaker" of a sonar system). The fish was deployed on several hundred feet of cable to a position below the thermocline (and below the launch depth of the submarine). The fish pinged upward at the target through cooler, denser water.

The ship needed to know the exact location and orientation of the fish in order to resolve the range and bearing to the target. Of course the fish, hundreds of feet down, wasn't visible from the surface. So the ship tracked the fish by pinging it, which was possible despite the thermocline because of the sharp angle downward to the fish. The fish tracked the target. And the shipboard system was expected to compute the direct path from ship to target, the third side of the ship-fish-submarine triangle.

Both ship and fish were of course subject to yaw, pitch, and roll. Small errors in angle on both paths from the tracking sonar to the target are magnified by distance into large errors of range or bearing. So in addition to the sonar transducer, the fish contained yaw, pitch, and roll sensors...which were unfortunately sensitive to acceleration; so accelerometers were added with the intent of correcting data from the primary sensors. The shipborne equipment, too, had three-axis sensors and accelerometers, in order to correct the range and bearing from ship to fish.

Sounds a little more complicated now, doesn't it? And the whole thing had to be implemented in a shipborne 19" rack-mount box with early 1980s computer technology.

The Computers

The system was required to produce range and bearing output at a fixed rate, once every few seconds. The STS architects (not me!) designed a distributed computing system with (5) 8085-based front-end data collectors and a single Q-Bus based LSI-11 for the data processing.

The 8085 was an 8-bit CPU with 16-bit addresses. It executed perhaps 500,000 instructions per second at a clock rate of 3MHz. The 8085 boards designed for STS included the 8273 HDLC controller, a complex VLSI peripheral device; HDLC is a now-obsolete serial link communications protocol. These 5 8-bit processors were connected by HDLC to each other, and were connected (somehow...I don't remember) to the LSI-11 to provide the sonar and sensor data to the compute engine.

The 8273 HDLC controller was riddled with bugs. Sonatech eventually obtained an errata sheet (really booklet) perhaps a quarter of an inch think. My understanding is that the device was originally implemented for a specific contract in which Intel supplied IBM with controllers for IBM's proprietary version of HDLC, called SDLC. The devices were used in IBM point-of-sale (POS) terminals, after which Intel marketed them as general purpose HDLC controllers. Apparently not much testing had been done to ensure conformity with the non-proprietary HDLC protocol, which an intergalactic standard back in its day. Getting these devices to work cost the project several months.

In practice, the 8085s spent most of their compute cycles executing the custom HDLC communications software which Sonatech called CLIP (Communications Link for Interface Processors?). Written in a combination of PL/M and assembly language, the CLIP protocol code was expensive for these tiny processors. It barely left them cycles to perform their real function, which was collecting, bounding, and scaling data from the sonar and the various sensors. Floating point arithmetic, which had to be done completely in software (and in 8-bit chunks) on the 8085, was pretty much out of the question. The end result was that much of that work was pushed back on the LSI-11 based compute engine.

The LSI-11 was the VLSI-based low end of the Digital Equipment's venerable PDP-11 computer family. It was implemented as four 40-pin ICs and an optional fifth 40-pin math processor device, microcode customizations of Western Digital's MCP-1600 chip set. Digital didn't supply chips for board-level designers; all users bought systems or CPU boards designed and constructed by Digital. This implied some sort of board level connection bus, and Digital specified Q-Bus, a 16-bit wide interconnect. The Q-Bus was "open"; third parties could (and did) implement various boards for use in Q-Bus systems.

Sonatech integrated a Q-Bus system for STS. The LSI-11 was programmed in a combination of Digital FORTRAN and PDP-11 assembly language. Development was done on a small PDP-11 running RT-11. The code took the raw sonar and sensor readings, bounded, scaled, and translated them (since the 8085s couldn't), and estimated the position of the "cooperative target". The estimation code had been written by a skilled mathematician. It was very sophisticated: it used a Kalman Filter to maintain an estimate of the target's range and bearing.

Testing STS

I made three one-week trips to sea as "contractor personnel" on the USS Point Loma. I am prone to seasickness and wore scopolamine patches, which makes the memory of the three trips pretty weird ... in large doses, scopolamine is a sort of nightmare psychedelic. The first of the three trips occurred during the severe Pacific storms of the November 1982 El Niño. I was on the stern of the Point Loma, with a lifeline and life jacket, operating a winch to recover the "fish" around the occurrence of the lowest barometric pressure ever recorded in the Eastern Pacific. The Point Loma was big. 30 feet up on the wave, 30 feet down into the trough.

The system didn't work very well. The prime contractor, which I believe was Sperry Gyroscope, was not happy. It didn't work much better the second time I went out, either, although the weather was better. Each of these shakedown cruises cost millions of dollars - the cost of operating a US Navy ship at sea for a week. I'm sure we didn't have the only troubled piece of the entire Trident missile test system, but we had a budding project disaster on our hands.

My Contribution

I was straight out of school when I joined this project. I had some work experience, even experience in tech; but I'd never stepped up to taking responsibility for the outcome of a project. It took me about 6 months to get my feet on the ground, stop nibbling around the edges of the code, and try to get a grip on it.

The system architects had done one thing very well: all the sensor data arriving at the LSI-11 was recorded on a 9-track reel to reel tape. The tape could be played back in the lab at Sonatech, providing a bit for bit and second for second identical simulation against which we could run updated versions of the compute engine software.

The mathematical part of the code was very difficult, and I was loath to touch it. But I did come to understand the code's structure. It had an outer loop which ran forever. The outer loop initialized the filter and entered the inner loop. The inner loop began periodically calling subroutine DSCALE, which prepared the latest sensor readings, and then calling the filter code. If serious errors occurred, like the loss of sensor data for a long time, the code was supposed to break the inner loop and reinitialize the filter.

I said "...break the inner loop", but the compute software was written in FORTRAN IV with numeric labels and GOTO statements. There was no structured control flow. The initialization code was labeled 240. The inner loop, which iteratively called the Kalman filter with the latest data, was labeled 250.

Playing back the tape, it was easy to show that the system didn't work very well. It just made inaccurate predictions. We didn't know why.

One day, as I was looking at the code, I noticed that the bottom of the inner loop said GOTO 240. I'd probably read it several times before. "240", I thought. GOTO 240. Wasn't 240 the location of the initialization code? It was. Shouldn't that have said GOTO 250? It  should have. The filter had never been filtering: it had been reinitializing itself on every iteration. Two shakedown cruises. Millions of dollars. And a filter that didn't filter.

I showed it to my boss, one of the architects. His eyes bugged out. It was unspoken: we fix this. We don't talk about it.

The next trip out, my third and last, the Sperry representative (who was an ex-Navy sort and quite technical) was all smiles. "I've never seen the system work like this", he said.

I'm sorry, John. We just couldn't tell you.

I don't know what happened to STS. Around that time I was a player in a minor security leak; a representative of Sperry divulged the proposed date of an actual Trident launch, assuming I had the proper clearance. I did not, and I assume the Sperry guy was seriously pissed when he found out. I believe my management quietly slid me off the project and on to others, which was fine with me: I hated going out on that ship. I left Sonatech in early 1984. I don't know if STS was successfully delivered, cancelled, what.

I understand that in previous submarine missile tests, the Polaris and Poseidon missile test programs, the submarine had carried a mast with a radar reflector that stuck out of the water from launch depth. This made things easier for the ubiquitous Russian "trawlers" (spy ships). For the Trident program, they tried to avoid this with STS, which allowed them to orient the antennas without the radar mast. Maybe STS was successful. Maybe they went back to the radar mast. To this day I have no idea. I'm sure I never will.