Jack Garibaldi wrote: > Not sure why you are using timers for deployment charges other than it is > cheaper but not accurate unless your sim is right on at apogee that’s why all > the electronics commercially available work with Hybrids for Apogee and Main > chute plus other features like motor burn out, programmable functions adding > time, delaying time etc and if you use a timer to air start motors with a > G-switch you will have to be sure you pull the G’s that is the down fall > if you have some big low and slow bird but that just means you have to step > up to some better electronic that will work in your situation, I know the > Public Missile timers I have are the only timers that sense motor burn out > and if you need more well then yes a G-Wiz LCX, G-Wiz HCX, Marsa 54, Raven > all are programmable and will be better than a straight timer any way for > deployment charges and any other functions you need. Hi, Jack - I'm not disputing your point in general, but I did once run into a situation with a liquid propellant (hydrogen peroxide) rocket that had a lot of high-frequency noise. (This seems to be a characteristic of a peroxide mono-propellant chamber with a short straight flow passage from the tank to the catalyst - they tend to run a fair bit smoother on a thrust stand with a flex hose in the feed line.) This all happened with the "KISS" (keep it simple, sir!) rocket that the ERPS group launched a few times (down at Mojave) in 2002. (Some folks may remember the "beta" configuration that was launched at Fresno a few times.) Anyway, there was enough high-frequency component in the signal coming through the accelerometer chips to confuse the snot out of HPR-style flight computers that depend on that data to implement flight sequence functions. On the first peroxide flight, neither of the two altimeters (a G-wiz and a Black Sky AltAcc, both tested and reliable on solid-propelled "beta" flights of the same recovery configuration) fired its charge; the e-matches were later retrieved intact from the wreckage. (There wasn't enough left of the AltAcc to recover any data from.) On the second iteration, I used a Missile Works RRC2 pure-baro altimeter, with an R-DAS as backup (with breakwire startup and timer-mode recovery on the R-DAS, since I didn't trust anything G-based at this point) - this worked (at least on the first time we ran it); the baro charge popped at apogee and the timed charge a few seconds later, as expected. When I downloaded the R-DAS data and looked at the acceleration trace, I saw that it was an aliased mess of a signal that appeared to have major "AC" content at frequencies higher than the sample rate. (I think the R-DAS sampled at 200 Hz; I'm pretty sure we had "combustion acoustics" with frequency components well past that, up into the audio range, from the sound of the running engine - and these were evidently well-coupled through the airframe into the accelerometer chip.) So we flew a few times that day, and everything seemed OK - but the next time we went down there with the same rocket (similar recovery setup; some enhancements to the propulsion plumbing) we found that the vibrations were even messing with the baro altimeter: the first try had the baro fire early; in the end we got a successful flight by disabling the baro and just using the R-DAS timer, programmed with an estimated delay that turned out to be pretty reasonable.) One thing I will point out is that I had a safe-arm system on that bird, completely supplementary to the flight computers' sequence logic - this was based on a 3-position switch, connected directly in series with the firing circuit. Center position was "off"; to one side was the "armed" setting that completed a low-resistance circuit. The third position of the switch was the "test" position, which put a high-brightness LED and enough resistance to limit the current to about 50 mA (less than the rated "no-fire" current of the e-match, and within the continuous current rating of the LED). In this position, the flight computers could get continuity, but would be unable to actually fire anything. So I could power things up, switch to the test position, and confirm that everything was initialized and the continuity check was OK, before actually arming anything. (The power and on-off-test switches were accessible by putting a tool through the altimeter vent ports in the electronics bay - electronics arming was the last thing, once the rocket was erected on the launch rail.) Yes, the potential hazard here was rather less drastic than unexpected ignition of a large motor; I doubt I would have taken much injury from the powder squibs down inside the fiberglass airframe. However, a premature ejection while I was trying to start up the electronics might well have startled me enough that I fell off the ladder; that's the part that would have hurt... I certainly couldn't imagine doing upper stages or airstart motors without SOME sort of safe/test/arm switch in the system - the idea of having live power on any e-match circuits (whatever the eventual triggering logic) while setting up the rocket on the launcher just seems like something best avoided. -dave w