Electronic systems and computer software are pretty straight-forward and work great under lab conditions where everything is sanitary, clean, and as expected.
You may recall that, in honor of my days testing Aircraft-Stores Compatibility, I installed weapon systems on the Combat Bearhawk. After turning the Master Switch to ARM, pulling the trigger switch played machine gun sounds through the intercom, and pressing the pickle button played the sound of a dropping, whistling bomb followed by an explosion. (Of course, bombs only whistle in the movies, but, hey, go with what they expect.)
[Sidebar: It always seemed to me that the "bomb" didn't fall very far. The sound clip plays for 3.85 seconds before the explosion. Simple math from 12th grade Physics (assuming a low drag delivery) says that the distance of fall would be about 238 feet. If you account for time for the sound waves to travel back to the cockpit, that reduces the release altitude to about 200 feet. That's really low-level bombing! At 122 KTAS that may not be enough time to reach safe escape distance.]
Over the years, the sound module that hosted the bomb sound stopped working reliably. As the module had been sold through Radio Shack, and Radio Shack had since adopted a business policy of being "defunct", the module had become what the logistics experts refer to as "unsupportable".
Needing a new approach, in 2019 I replaced the whole system with a Raspberry Pi computer. I wrote the software in Python so that the Raspberry Pi would boot upon power up, then cycle through a constant loop continuously until receiving a command to do something. Now the Master Arm switch was no longer in the power circuit (the Rasp Pi takes about a minute to fully boot up), but was in the command circuit. The gun sound was set up to play as long as the command was present (as long as the trigger was pulled). The bomb sound was set up to run to completion after receiving a momentary command, caused by grounding one of the pins.
The problem was that even with the Master Arm switch in SAFE, momentary voltage spikes to the Rasp Pi would be interpreted as a bomb release command. Random bombs were falling on the airport and all around the Antelope Valley, all to the unknown disapproval of the Valley residents. With the assistance of Randy "Kanard" Kelly, I tried a hardware solution of attaching a capacitor to the bomb release command line to try to tame the voltage spikes. This approach was chosen because it could be done without removing the system from the airplane. This fix reduced the number of uncommanded bomb releases, but there were still an unacceptable number of uncommanded bomb releases.
During the 2021 condition inspection, I pulled the Rasp Pi out of the airplane and took it home for reprogramming. The software solution was to "debounce" the bomb release command. In the new software, a bomb release command starts a delay loop of about 0.5 seconds. If at any time during the delay loop the bomb release command is removed, the delay loop exits. If the bomb release command is still present at the completion of the delay loop, the bomb sound is played. The Rasp Pi with the new software was re-installed in the airplane.
It is tough to determine if a fix to make something "not" happen is successful, because we don't think about the thing when it doesn't happen. Since I have not had any uncommanded bomb releases in the last 1.75 years, I think it is time to declare the fix successful.
Dealing with the uncertainty of the real world is a real wakeup call to young engineers and computer scientists.
- Russ Erb