G-Wiz LCX compatibility with hybrids

[ROCKet STAR]

Hi Guys,

In a few weeks time I plan to fly a G-Wiz LCX in a rocket powered by a Skyripper J144. Given that the LCX determines launch and apogee via accelerometer, I was wondering if anybody thought there could be any compatibility issues, or if anybody had flown an LCX in a hybrid?

The LCX can be configured to use purely barometric data to function, so if I still have any doubts by the time I come to fly it, I'll just do that.

Chris

[cjl]

I don't see why there would be any problems.

[WillMarchant]

The user manual says:

NOTE: This unit has not been tested with Hybrids at this time, although it has been designed with hybrids in mind. We will post hybrid testing info when we have this data.

[WillMarchant]

I don't see why there would be any problems.

Problems have been reported with the oscillation of some hybrids causing problems in the algorithms in some accelerometer based altimeters. I applaud Chris's foresight in asking this question.

[ROCKet STAR]

Thanks Will, they are my concerns exactly. Having looked at the thrust curve for the J144 there does appear to be a fair bit of oscillation due to instability in the motor. I think maybe I'll email G-Wiz and ask them if they have any further information on compatibility with hybrids.

Chris

[cjl]

Problems have been reported with the oscillation of some hybrids causing problems in the algorithms in some accelerometer based altimeters. I applaud Chris's foresight in asking this question.

Really? Interesting - I didn't know that. I've never flown any hybrids though, so I can't claim any sort of expertise here (I may have to try one of the new Tribrids though - those look awesome).

[Adrian A]

Problems have been reported with the oscillation of some hybrids causing problems in the algorithms in some accelerometer based altimeters. I applaud Chris's foresight in asking this question.

Indeed, some (non-Featherweight) altimeters (I don't remember which ones) use a liftoff detection algorithm that is looking for a certain value of Gs for a number of consecutive samples. Hybrids typically cause occasional samples of near 0 or even negative Gs during the burn, so there have been reports of those altimeters failing to arm for hybrids.

[jderimig]

Indeed, some (non-Featherweight) altimeters (I don't remember which ones) use a liftoff detection algorithm that is looking for a certain value of Gs for a number of consecutive samples. Hybrids typically cause occasional samples of near 0 or even negative Gs during the burn, so there have been reports of those altimeters failing to arm for hybrids.

After some well publicized such failures to arm of certain altimeters in hybrid flights 6-7 years ago I can't imagine how any manafacturer would market an altimeter NOW would still be subject to that failure mode.

But it is always prudent to ask the manufacturer. If you don't get a response, move on.

[bobkrech]

Indeed, some (non-Featherweight) altimeters (I don't remember which ones) use a liftoff detection algorithm that is looking for a certain value of Gs for a number of consecutive samples. Hybrids typically cause occasional samples of near 0 or even negative Gs during the burn, so there have been reports of those altimeters failing to arm for hybrids.

In the early days of flight computers, accelerometer based altimeters used a lift-off algorithms that simply looked for an acceleration above a certain G level of a certain time period. If a single reading dropped below a certain value, the time gate window was reset.

Solids don't tend to have large pressure fluctuations so this simple method was an adequate lift-off algorithm, however hybrids, especially if the injector/nozzle sizing is not optimized will audibly buzz due to combustion instabilities, and this vibration cause large high frequency positive and negative accelerations about the mean lift-off acceleration value which retriggered the simple algorithm time counter.

The fix was simple. Look at the average acceleration value.

The probable reason why this was not done before is that earlier microcontroller chips weren't very fast so if the averaging wasn't necessary, then it wasn't done.

This is not a problem with barometric altimeters as the jump in altitude at lift-off is not effected by vibrations.

Bob

[UhClem]

The simplistic lift off detect algorithm should work even with the buzzy hybrids. The reason that it does not is because of something more fundamental: inadequate sample rate or missing pre-sample filters.

Rocket altimeters rarely include pre-sample filters to remove all or even most of the frequencies above the Nyquist limit. (one half the sample rate) The result is that high frequency content in the sensor output confuses the situation. (Bandwidth of a couple of popular accelerometers: ADXL150 - 1000Hz (obsolete), ADXL78 - 400Hz.)

This point was dramatically driven home several years ago. On one flight using a buzzy hybrid, the flier had configured his RDAS altimeter with a 50HZ sample rate. (He had extra sensors connected to the 4 extra ADC channels and wanted the recorded data to last longer than it would at 200Hz.) The result was the ugliest looking data I have ever seen.

More details on this are here. Warning: this page is nearly unreadable because of a serious formatting problem. You will have to scroll far to the right to read all of the text and to see the graphs. I have attached a sample plot so you can get an idea.

[Reinhard]

You can have it both ways. If the front end produces messed up data, like in your example, even a good algorithm will have a hard time to detect liftoff reliably. It can be impossible in extreme cases.

But the opposite can be true too. Even if you sample "fast enough", with an appropriate low pass filter before the ADC, a simplistic algorithm can fail. As an example, a criteria like "4g+ for at least 0.5s" will not be met on hybrids with strong oscillations, very fast motors like 38mm W9 or when catos happen early in the flight - unless you reduce the bandwidth to very low values (< ~1Hz).

Reinhard

[daveyfire]

More details on this are here. Warning: this page is nearly unreadable because of a serious formatting problem.

I used Readability (http://lab.arc90.com/experiments/readability/) to reformat the page on the fly and it fixed the formatting problems, making the (really cool!) article much easier to read.

On a related note, David, the LaTeX server doesn't seem to be functioning on your page (e.g., http://home.earthlink.net/~david.sch...parachute.html) I miss having the formulas available!

And kind of more on-topic, I've used a G-Wiz LC with success on hybrid (Hypertek 835cc J317 and K240) flights in the past. I've yet to put my LCX up with a hybrid, but I suspect things would probably work. The Skyrippers are significantly less buzzy than the Hyperteks.

[cjl]

You can have it both ways. If the front end produces messed up data, like in your example, even a good algorithm will have a hard time to detect liftoff reliably. It can be impossible in extreme cases.

But the opposite can be true too. Even if you sample "fast enough", with an appropriate low pass filter before the ADC, a simplistic algorithm can fail. As an example, a criteria like "4g+ for at least 0.5s" will not be met on hybrids with strong oscillations, very fast motors like 38mm W9 or when catos happen early in the flight - unless you reduce the bandwidth to very low values (< ~1Hz).

Reinhard

What about an algorithm like the Featherweight Raven, which looks for an integrated deltaV? That catches both oscillating and short-burn motors just fine.

[Reinhard]

What about an algorithm like the Featherweight Raven, which looks for an integrated deltaV? That catches both oscillating and short-burn motors just fine.

This is the best solution that I'm aware of (that doesn't mean much ) and it can be implemented very easily and efficiently.

If the deltaV threshold and the integration interval is chosen well, the algorithm is pretty immune against rough handling of the rocket and it still detects lift off reliably. As an example, the kinetic energy at 25ft/s is roughly equivalent to the potential energy of a 10ft height difference. Throwing a rocket 10ft into the air by accident (or an equivalent shock) is something that even a careless flier won't manage to do. On the other hand, this is more than sensitive enough to ensure that the altimeter is armed well before an altitude is reached where the parachute starts to make sense.

If precise timing information is desired, this algorithm needs to be extended with some kind of edge detection. Otherwise the algorithm will trigger faster on a high g flight and slower on a low g flight. But these variations are well below one second on our rockets.

Reinhard

[ROCKet STAR]

And kind of more on-topic, I've used a G-Wiz LC with success on hybrid (Hypertek 835cc J317 and K240) flights in the past. I've yet to put my LCX up with a hybrid, but I suspect things would probably work. The Skyrippers are significantly less buzzy than the Hyperteks.

Thanks for the info. In that case I'll probably go ahead and fly it then. I emailed G-Wiz, but haven't heard from them yet. Hopefully they'll confirm that all should be ok.

Edit: After posting I checked my email and had a response from Robert Briody at G-Wiz who confirmed that the LCX had sucessfully been tested with hybrids.

[UhClem]

I
On a related note, David, the LaTeX server doesn't seem to be functioning on your page (e.g., http://home.earthlink.net/~david.sch...parachute.html) I miss having the formulas available!

The Texify service is cool and it still provides drop in html for web pages. Except that now it doesn't work. I noticed this recently while working on another page but didn't go back and look for other spots I needed to fix.

The really annoying part is that while I am editing the page I check the formatting by loading it as a file before uploading it to the server. It works fine that way but breaks on the server because Texify apparently hates Earthlink. Or something.

[WillMarchant]

What about an algorithm like the Featherweight Raven, which looks for an integrated deltaV? That catches both oscillating and short-burn motors just fine.

Just a reminder that with a pure accelerometer based system you are deriving velocity from acceleration. So you had better be satisfactorily tracking the acceleration profile or you'll end up in trouble.

[cjl]

Except that with an integrated deltaV, a single low sample will not cause any problems, as the overall integral will still (on the whole) be climbing.

[WillMarchant]

Except that with an integrated deltaV, a single low sample will not cause any problems, as the overall integral will still (on the whole) be climbing.

I agree, if your algorithm is "I want X readings over Y acceleration to detect liftoff" and you get a single data point below Y and reset the counter, then you deserve the crash that you're likely to get.

On the other hand I suspect that you're never going to get a "single low sample" if you've messed up your filters and sample rates. Remember GIGO: garbage in, garbage out. You need to try and feed your algorithms decent data.

[Reinhard]

On the other hand I suspect that you're never going to get a "single low sample" if you've messed up your filters and sample rates. Remember GIGO: garbage in, garbage out. You need to try and feed your algorithms decent data.

This problem can arise when the bandwidth and sampling rate is comparable high, with the intent to accurately record transient events. Details of the thrust curve, spikes that happen during ejection etc...

A couple of altimeters are capable to operate at 200Hz. These leaves room for an analog bandwidth of 100Hz, if the altimeter is designed properly. This is enough to see at least part of the oscillations in the thrustcurve.

Now if the altimeter offers the option to record at lower rates, it is not a good idea to simply reduce the sampling rate of the ADC because this can lead to aliasing. The right way is to still sample at the full rate and filter it before downsampling.

Reinhard