Clark Air Base, Philippines started receiving their ALQ-184 electronic warfare jamming pods in August 1989. By October, it was clear that they were in real trouble. The system had been billed as "blue-suit maintainable." It was after all just a modification of the existing ALQ-119 pod, right? Well, yeah, it did kind of use the same original shell as the 119. . . .
The problems at Clark were causing some rumbling and bad words about Raytheon, so the decision was made to send me for a month to Clark, accompanied by Clif Whaley, the genius who had designed the support equipment, who would be there for a week. It was a goodwill visit to get them on their feet, as it were.
We arrived at Clark and were met by staff sergeant Andy Walker. Andy looked exactly like the fat kid with glasses from the Far Side cartoons. So much so, I almost blurted out that "You're the kid from the Far Side!" He herded us into a chartered minibus he had requisitioned specifically to pick us up. Once the doors were closed, he turned to me and said, "So, can you really fix these devil-pods?"
The very first pod they had tried to check out was pod 0028. It was an unfortunate choice, because the pod happened to be brain-dead. The computer wouldn't boot, wouldn't talk, wouldn't come up to the point where you could even program the memory.
Using another pod, I swapped various cards, to verify that it wasn't a bad card stopping things. Air Force technicians stood around skeptically saying, "Yeah, we did that." I'm sure you did, but unless I do it, I don't know it happened. Well, it wasn't a card. I broke out the technical manual and started the troubleshooting sequence for an inoperative CPU. The problem is that the CPU is so fundamental to the operation of this thing that if it's not working, following the troubleshooting guide is already in Hail-Mary territory. I had found it next to useless before, but I had nothing else in my bag of tricks.
I checked the data lines, the latched addresses, various TTL signals. It was like the computer was trying to work, but had no software to run. And it wouldn't accept a software load from the support equipment. We verified that the support equipment wasn't malfunctioning by trying to use a memory loader/verifier, which is a rather big box we carry to the flightline to reprogram pods while they're on the plane. That didn't work either.
So I was scratching my head. Everyone else had gotten bored and wandered away. I was looking at one TTL signal call E2WDS-. That acronym stood for EEPROM Write Disable (not). The (not) meant it was active when it was low. So, let me think about this, too many double negatives, when this is low the Eeprom Write is disabled. And sure enough, it was low. What makes it high? I couldn't really tell, it traced from a programmable logic array. Basically the master processor. If that wasn't working, then the master processor must be bad. But we had already replaced the master processor.
Hell, I don't know if I'm even barking up the right tree here. I need to do something, though, because I'm not getting anywhere this way. So, wincing a bit in anticipation of all the bad things I could possibly do here, I wired a jumper from E2WDS- to a solid +5V.
I asked the support console to load software, and BAM! up it came, it immediately started talking and loading software! Yay! I was getting somewhere! Now I just needed to figure out why E2WDS- wasn't getting toggled. I shut the pod down and removed my jumper.
When I fired it up again, it came up, started talking and proceeded to load software normally. Everything was working perfectly fine. There was nothing wrong with that pod, and it continued to work perfectly fine until nine months later when it died on the belly of an F-4 whose gear wouldn't come down and crashed into the Pampang river. Both crew members ejected safely. My theory is that there was a hair of wire grounding the signal, and when I jumped it I fried the short with too much current.
Everyone gathered around to see the wonder of a pod that would actually communicate with the support console. They bowed and made obeisance to their new god, the field rep. "Praise be the tech rep! Praise be! Hey what did you do? How did you fix it?"
The one thing I learned a long time ago is that the first thing you teach somone is the thing that's going to stick with them forever. I thought about the implications of my unorthodox method of troubleshooting, and whether it was a good idea to encourage a bunch of technicians to willy-nilly jump TTL logic lines to hard voltages like that. I shrugged my shoulders and said, "I dunno, I just reseated a few cards and it started working!"
They looked at me skeptically, "You're a lyin' bastard and you're not telling us, are you?"
I just grinned and said, "Yeah."
The problems at Clark were causing some rumbling and bad words about Raytheon, so the decision was made to send me for a month to Clark, accompanied by Clif Whaley, the genius who had designed the support equipment, who would be there for a week. It was a goodwill visit to get them on their feet, as it were.
We arrived at Clark and were met by staff sergeant Andy Walker. Andy looked exactly like the fat kid with glasses from the Far Side cartoons. So much so, I almost blurted out that "You're the kid from the Far Side!" He herded us into a chartered minibus he had requisitioned specifically to pick us up. Once the doors were closed, he turned to me and said, "So, can you really fix these devil-pods?"
The very first pod they had tried to check out was pod 0028. It was an unfortunate choice, because the pod happened to be brain-dead. The computer wouldn't boot, wouldn't talk, wouldn't come up to the point where you could even program the memory.
Using another pod, I swapped various cards, to verify that it wasn't a bad card stopping things. Air Force technicians stood around skeptically saying, "Yeah, we did that." I'm sure you did, but unless I do it, I don't know it happened. Well, it wasn't a card. I broke out the technical manual and started the troubleshooting sequence for an inoperative CPU. The problem is that the CPU is so fundamental to the operation of this thing that if it's not working, following the troubleshooting guide is already in Hail-Mary territory. I had found it next to useless before, but I had nothing else in my bag of tricks.
I checked the data lines, the latched addresses, various TTL signals. It was like the computer was trying to work, but had no software to run. And it wouldn't accept a software load from the support equipment. We verified that the support equipment wasn't malfunctioning by trying to use a memory loader/verifier, which is a rather big box we carry to the flightline to reprogram pods while they're on the plane. That didn't work either.
So I was scratching my head. Everyone else had gotten bored and wandered away. I was looking at one TTL signal call E2WDS-. That acronym stood for EEPROM Write Disable (not). The (not) meant it was active when it was low. So, let me think about this, too many double negatives, when this is low the Eeprom Write is disabled. And sure enough, it was low. What makes it high? I couldn't really tell, it traced from a programmable logic array. Basically the master processor. If that wasn't working, then the master processor must be bad. But we had already replaced the master processor.
Hell, I don't know if I'm even barking up the right tree here. I need to do something, though, because I'm not getting anywhere this way. So, wincing a bit in anticipation of all the bad things I could possibly do here, I wired a jumper from E2WDS- to a solid +5V.
I asked the support console to load software, and BAM! up it came, it immediately started talking and loading software! Yay! I was getting somewhere! Now I just needed to figure out why E2WDS- wasn't getting toggled. I shut the pod down and removed my jumper.
When I fired it up again, it came up, started talking and proceeded to load software normally. Everything was working perfectly fine. There was nothing wrong with that pod, and it continued to work perfectly fine until nine months later when it died on the belly of an F-4 whose gear wouldn't come down and crashed into the Pampang river. Both crew members ejected safely. My theory is that there was a hair of wire grounding the signal, and when I jumped it I fried the short with too much current.
Everyone gathered around to see the wonder of a pod that would actually communicate with the support console. They bowed and made obeisance to their new god, the field rep. "Praise be the tech rep! Praise be! Hey what did you do? How did you fix it?"
The one thing I learned a long time ago is that the first thing you teach somone is the thing that's going to stick with them forever. I thought about the implications of my unorthodox method of troubleshooting, and whether it was a good idea to encourage a bunch of technicians to willy-nilly jump TTL logic lines to hard voltages like that. I shrugged my shoulders and said, "I dunno, I just reseated a few cards and it started working!"
They looked at me skeptically, "You're a lyin' bastard and you're not telling us, are you?"
I just grinned and said, "Yeah."
No comments:
Post a Comment