[tccrockets] The saga of the KISS rocket \ Re: Re: Tripoli Rules 2012

  • From: David Weinshenker <daze39@xxxxxxxxxxxxx>
  • To: tccrockets@xxxxxxxxxxxxx
  • Date: Wed, 08 Feb 2012 23:39:58 -0800

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


Other related posts: