Switch Reliability Test
I have used most of the types of switches common in hobby rocketry, from simple audio jacks to key switches, for controlling power to on-board electronics. I've never actually had one fail, but others have and some make strong claims for one kind or other. Well, it seemed like something that should be tested!
I had at various times thought about how to do the testing, but it wasn't until early 2008 that the idea came off the back burner. The spark was a class at the TechShop on AVR microcontroller uses given by Windell Oskay, where I realized that the test electronics would be a perfect introductory project for learning embedded systems development.
The primary things that affect switches are acceleration during powered flight, vibration and various shocks during recovery and landing. To test switches, they should be flown in a high-performance rocket with electronics that sample their state at a relatively high rate and record any unexpected changes.
The primary thing to test is whether any of the switches momentarily open during any part of the flight. To do this, the sampling rate must be high enough to detect any brown-out that could affect typical rocket flight computers. Since almost all flight computers have some capactors in the power circuit, short switch opens would probably not have an affect, but I still wanted to detect them for comparison purposes. I decided that a 1ms open would be considered a failure and any open shorter than 1µs would be considered a pass. That meant that I needed to sample the state of the switches at or above 1MHz (1 million times a second).
Since the board would be flown in a typical high-power rocket, I wanted it to work like a normal rocket flight computer. That meant that it must be self-contained to easily go for rides in any available vehicle. Since the focus was on high-performance flights, I wanted it also to fit into a minimum diameter 38 or 54mm rocket.
The board should be capable of testing several switches at once, as well recording the acceleration. Opens of 1µs or longer should be recorded for each switch in a way that can be correlated with the acceleration profile. It should also monitor at least one "control" unswitched connection as a self-test.
To use, one or more external switches would be connected to the board using the most reliable method (probably soldering to a through-hole pad on the board itself). The switches would be turned on and the unit flown in a rocket. After the flight, LEDs would indicate the failure of any switches connected. The acceleration curve and any points of failure could also be downloaded to a laptop in the field.
For now this is just some random notes, but will be fleshed out as the design proceeds.
The board should have all components directly soldered so that vibration and acceleration don't affect the circuit itself. (This means that the board must support in-circuit programming of the microcontroller.)
The board should record state using a ring buffer as soon as power is applied. When the start of testing is detected (lift-off), the unit should keep the prior 2s of data and stop recording if the buffer runs out (since the most important data is probably from early in the flight).
In addition to the acceleration sensor, there should be a break-wire or other way to start the test process. This would allow the unit to be used with a shaker table or other ground-based torture device. A secure switch (jumper?) should be used to select between acceleration sensor and break-wire triggering.
Given that high-performance rockets routinely exceed 30Gs during powered flight, the acceleration sensors may be costly. 3 axes of acceleration would be ideal, but if the data rate is too high, we can probably go with a single axis. Note that the most interesting axis is along the board's length.
NVRAM memory constraints will not allow us to record the raw accleration data and raw switch states for a flight of 5m or more, so we will have to use an external SD card or some clever compression. The most obvious compression for the switch state is to record changes and times, but even this will require some damping to avoid a switch that is vibration sensitive using up all the buffer. An SD card clearly has enough space to store all the raw data, but the interface to it is unlikely to support even 2MBps (8-bit acceleration plus mask of 8 switch states at 1MHz). Luckily, it is not necessary to store the acceration at 1MHz since the sensors won't produce unique readings at nearly that rate.