These fields are all optional and need only be supplied if you would like a direct reply. Subject Your email address Your real name

You must answer this! If you don't, my spam filtering will ensure that I never see your email. What's 8 plus five (in digits only)?

Please make your changes here and then
Editing tips and layout rules.
File: TheBouncingTorpedo ''' <table width="500px"><tr><td> One of the GreybeardStories. This is the story of the bouncing torpedo. Some details have deliberately been changed, but the story as told here is broadly as it was told to me. I'd like to think it's true. ---- In the very, very early days of integrated circuits and the very first microprocessors, it was quickly realised that they could be used to solve quite complex control problems. Instead of very convoluted mechanical controllers, or specialised circuits designed from scatch, microcontrollers could be programmed with the appropriate algorithms, and then changed when necessary. One particular problem that saw an early application was in anti-submarine torpedoes. One problem with torpedoes is to stay at a fixed (or nearly fixed) depth, and this is especially a problem when firing at a submarine. When firing at a ship there's no such thing as too shallow, and in World War II sometimes torpedoes could be seen "porpoising" on their way to the target. Missing underneath was a problem, so they always set the depth to "shallow" and then it didn't matter. But that didn't work when firing at submarines. With them you could miss over as well as under, so you wanted the torpedo to run at the requested depth, not oscillate around it. The control theory problem is fairly simple, but the mechanical "computers" weren't really up to it, so when it became possible to use microelectronics, it seemed the ideal opportunity to do some real magic. I wasn't told the history of the simpler versions, I was just told about one particular trial of one particular version. You may have seen on war movies how they set the track on the torpedo before firing it. That's the angle (from North) that the torpedo should run, and it means that the firing vessel doesn't have to line up at the target before firing. Instead they set the track, fire the torpedo, and the internal gyroscopes then set the rudder to turn the torpedo onto the right track, and keep it on. This torpedo was even more clever. It could be set to run a zig-zag course so it could zig-zag through the anti-submarine and anti-torpedo nets that protected harbors and the like. And it also had sophisticated depth controls, all made possible by the onboard micro. So we skip over the development and early trials, skip over the many test firing through nets (so you can see the holes and deduce the track) and go straight to the incident in question. The torpedo is being given a final check by the technician, who finds that an area of memory isn't the expected all zero block. It's got numbers he doesn't recognise, and he's worried. He checks the documentation, he checks the manual, and everything he sees, in all the previous firings, in all the previous trials, that block is entirely zero. He thinks it's scratch memory, it should be zero. So he wipes it. Minutes later the torpedo is loaded, and fired. For reasons that will become clear (or, at least, clearer) the target in this trial is a real submarine. The torpedo in question is a test torpedo, so instead of an explosive warhead it has a flotation device that activates after the run and allows the torpedo to be recovered easily instead of sinking. So picture the sonar guy in the target submarine, some 2 miles away. He can hear the torpedo running straight and true, apparently on target, apparently at the right depth, and all seems well. Until it gets to a bit less than 1 mile away (nautical mile, 1852 meters, 6076 feet). He calls to the captain and asks: Captain - isn't the torpedo intended to turn at 1700 yds? You see, those non-zero values were the intended deviation from base track, the feature that let the torpedo run a zig-zag path and avoid anti-torpedo nets. It had been programmed to run correctly while being monitored, and then to turn off and run past. The close but non-intercepting run was to allow the submarine to monitor it more accurately. But it wasn't turning off. The submarine skipper gave orders to evade, but it was too late. With a huge *WHERRANGGGG*!!!* the torpedo rammed the submarine at about 30kts (about 35mph). The entire hull rang like a bell. Fortunately, submarines are coated with several inches (in some cases feet) of rubber to help deaden the sound they might otherwise transmit to the water, so the torpedo bounced. Unfortunately, it was mostly undamaged, regrouped, and had another go. *WHERRANGGGG*!!!* *WHERRANGGGG*!!!* *WHERRANGGGG*!!!* *WHERRANGGGG*!!!* *WHERRANGGGG*!!!* I'm told it hit the sub 5 or 8 times before finally damaging itself sufficiently to stop. At which point, perhaps unsurprisingly, the flotation device failed to activate, having been significantly damaged by the repeated impacts, and the torpedo sank. I wasn't told at what stage the technician realised what had happened, and why, but I can just picture him sitting, quietly rocking back and forth, head in hands, thinking "no, no, no, no, ..." We've all been there. We've all done what we think is right under difficult circumstances with inadequate training or documentation, only to find that it was wrong. Sometimes our mistakes are worse than this. But whenever something goes horribly wrong, I can't help but think of the torpedo, bouncing off, shaking itself vigorously, and going "Whey HEY!!" I like to think it rather enjoyed itself. ''' </td></tr></table> ---- One of the GreybeardStories.