[tccrockets] Re: The saga of the KISS rocket \ Re: Re: Tripoli Rules 2012
- From: James Dougherty <jafrado@xxxxxxxxx>
- To: "tccrockets@xxxxxxxxxxxxx" <tccrockets@xxxxxxxxxxxxx>
- Date: Thu, 9 Feb 2012 14:32:16 -0800
David
Thanks, that's a great problem, its off topic since we don't fly peroxide
motors at TCC (the rules are regarding HPR), and the discussion is on IGNITION
systems. However, I have some experience in this area and as it pertains to
commercial electronics and harmonics there are quite a few things to check out!
In electrical engineering the slang word we use for Electromagnetic (EM)
phenomena is "cross-talk", it occurs when a resonant frequency interferes with
a carrier or main signal frequency. This can happen when oscillations within
the bay (eg metal on metal) interfere with circuitry on the system board or
create noise in the power supply. A common example of this (in RC aircraft)
occurs when a poorly mounted RF receiver vibrates with engine /blade noise and
creates "servo chatter". Mounting the electronics securely with rubber grommets
will usually alleviate this problem.
Next is whether one of the solder joints failed on the electronics circuit
board or there were issues with the mounting. Did you pot the PCB?
This is an easy (but irreversible) procedure but can prevent this (and also act
as a band-pass filter for low frequency noise).
On the wreckage I would have X-rayed the PCB if it was intact, most assembly
houses can do that for you, I can recommend someone if you want but that would
have ruled out PCB damage during flight.
Regarding the firmware and how it can fail with harmonic oscillations and
sensor data, the "Nyquist rate" is the rate in digital signal processing which
is the upper bound for how much information you can process on a bandwidth
limited channel. The nyquist rate is 2x the true data rate.
Nyquist says that if you want 100 samples/second you should actually
Be sampling 200 samples/second.
We kind of know that intuitively when we fly altimeters and crank up the sample
rate as it gives us better graphs
As to how the flight computers all operate with sensor data
(Barometers,Accelerometers, IMU's, etc) a rough example of what could be
happening is that if the A/D samples 50hz, and you oscillate at 20hz, your
effective sampling rate is 1/2 50hz (25hz) and half the Nyquist rate is 12.5hz,
the firmware (as it loses efficiency in sensor data) effectively "slows down"
and apogee may never be seen!
This is an evil side effect of vibrations with noisy sensors driven over A/D,
and is solved with a Kalman filter. The Marsa54 supports Kalman filtering.
The other issue with harmonics on circuit boards which occurs during A/D
conversion is the sensor data forms a hysteresis around a band or harmonic
frequency, effectively locking out A/D data. You solve this with a "low-pass"
or "band gap" filter and most Accelerometers do not do this. However, You can
mount your electronics in an otter box and solve this problem by insulating or
"masking out" harmonics which confuse A/D data from the flight computer.
Did you use solid copper wire? I wouldn't use yellow shooters wire For anything
besides e-matches. Use stranded wire for switches and power and always check
for cold solder joints. The V2 rockets started to fail at the end of WW2
because stranded wire was not available as the factories were all bombed and
destroyed. harmonic oscillations from the ethanol rocket motor caused lots of
vibration and cracked the wire to various control systems.
I agree your setup has lots of complicated failure modes as Hybrid motors
create a lot of vibration. But, I would be looking at a G-wiz HCX 200g, a
Marsa54, or a Raven and being extra cautious how that baby gets mounted.
When will you fly your rocket again? I think I can get your flight computers
to work. Do you come to TCC launches?
Thanks,
-James
Sent from my iPhone
On Feb 8, 2012, at 11:39 PM, David Weinshenker <daze39@xxxxxxxxxxxxx> wrote:
> 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:
