Altimeter feature request: safety main deployment

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

CarVac

Well-Known Member
Joined
Feb 12, 2012
Messages
5,704
Reaction score
37
Is there a dual deploy altimeter which will fire the main charges in the case that the rocket is descending too quickly after apogee? I'm talking about a 60 ft/s or so threshold four seconds after apogee (where a ballistic falling rocket would be descending at 120 ft/s (32 ft/s/s)). My supposition is that a somewhat late deployment would be better than one at the main altitude where the rocket would be moving much faster.

Is this a realistic idea without incurring too many false positives? I would definitely buy an altimeter with this feature.
 
Last edited:
Is there a dual deploy altimeter which will fire the main charges in the case that the rocket is descending too quickly after apogee? I'm talking about a 60 ft/s or so threshold four seconds after apogee (where a ballistic falling rocket would be descending at 120 ft/s (32 ft/s/s)). My supposition is that a somewhat late deployment would be better than one at the main altitude where the rocket would be moving much faster.

Is this a realistic idea without incurring too many false positives? I would definitely buy an altimeter with this feature.

I think that the Raven would be capable of doing this if Adrian were to permit you to program the unit with if statements.
 
I think that the Raven would be capable of doing this if Adrian were to permit you to program the unit with if statements.

The velocity value doesn't work when descending.

Edit: I don't even need the time delay or anything. If the downward speed exceeds the threshold, assume the drogue didn't work/the airframe didn't separate.
 
Last edited:
Good idea. I will see if I can program that. (Marsa54L).
 
Good idea. I will see if I can program that. (Marsa54L).

I look forward to seeing if it works out.

I would like it to be a configurable threshold so that on a rocket with a slow drogue descent rate (say 30 ft/s) you can tighten up the safety deployment to happen at 40 ft/s, such as might be desirable for a larger project which couldn't survive a higher speed deployment. Or the reverse: with a minimum diameter rocket you could tell it to not panic unless it hits a higher threshold like 120 fps.
 
I look forward to seeing if it works out.

I would like it to be a configurable threshold so that on a rocket with a slow drogue descent rate (say 30 ft/s) you can tighten up the safety deployment to happen at 40 ft/s, such as might be desirable for a larger project which couldn't survive a higher speed deployment. Or the reverse: with a minimum diameter rocket you could tell it to not panic unless it hits a higher threshold like 120 fps.

There may be better ways to detect a ballistic return than descent velocity alone. For instance if the accelerometer is reading near 0 for an extended time after the supposed apogee event then that could be the trigger.
 
Is there a dual deploy altimeter which will fire the main charges in the case that the rocket is descending too quickly after apogee?
The German SALT 3 altimeter (out of production) had this feature. You could enable three thresholds (minimum altitude, maximum descent rate and time after liftoff) and whichever criteria was met first, triggered the second pyro channel. I never needed it, but it was certainly a nice feature while I had it (the altimeter is now retired after a rather wet landing).

There may be better ways to detect a ballistic return than descent velocity alone. For instance if the accelerometer is reading near 0 for an extended time after the supposed apogee event then that could be the trigger.
Sometimes, rockets (or at least the e-bay) come down nearly horizontally, which can fool the altimeter - but these cases are usually survivable when the main deploys at its regular altitude.

Reinhard
 
The German SALT 3 altimeter (out of production) had this feature. You could enable three thresholds (minimum altitude, maximum descent rate and time after liftoff) and whichever criteria was met first, triggered the second pyro channel. I never needed it, but it was certainly a nice feature while I had it (the altimeter is now retired after a rather wet landing).


Sometimes, rockets (or at least the e-bay) come down nearly horizontally, which can fool the altimeter - but these cases are usually survivable when the main deploys at its regular altitude.

Reinhard

Perhaps he refers to the lack of deployment shock.
 
CarVac -

The RRC3 has this capability via its Aux programmability.
It's only capable however of comparing velocities of either -100fps or -200fps (due to the comparator granularity of "x 100").
One could trigger this operation after a user determined "post drogue" event timer.
 
Why not use an altimeter with multiple output channels per event, like the Raven, Telemega, etc, etc, Then program one of the channels to apogee + x seconds as a backup. If the drogue chute is already out, then the charge wont harm anything, but if it isnt out, it will be very soon.
 
Why not use an altimeter with multiple output channels per event, like the Raven, Telemega, etc, etc, Then program one of the channels to apogee + x seconds as a backup. If the drogue chute is already out, then the charge wont harm anything, but if it isnt out, it will be very soon.

Because I don't feel like using an additional charge that'll do nothing. Plus, in my currently-in-design rocket, it'd be harder (read: heavier) to do that.

Also, at my school's USLI attempt a few years ago, they horribly zippered the rocket because somehow both apogee charges failed, but the main came out right on time at the prescribed altitude. Redundant charges didn't help there, but this deployment option would have.
 
You can do it with a TeleMega, if you don't want use a third charge , just put 2 ematch in the main charge

tele.jpg
 
Funny I'm sitting here trying to finish up the Sparrow firmware and decided to look at RF to see what is happening... I'll talk to Adrian about a 'Exceeds Descent Rate' deployment option. The firmware on the Raven is pretty tight on space but it might be possible in the current version or a future version. What I myself need is a "If drogue charge too much, suck the main chute back in" option... (I have been known to deploy the main with a powerful drogue charge...)
 
Funny I'm sitting here trying to finish up the Sparrow firmware and decided to look at RF to see what is happening... I'll talk to Adrian about a 'Exceeds Descent Rate' deployment option. The firmware on the Raven is pretty tight on space but it might be possible in the current version or a future version. What I myself need is a "If drogue charge too much, suck the main chute back in" option... (I have been known to deploy the main with a powerful drogue charge...)

Awesome. I hope, for the sake of the hobby's safety, that it might become a standard feature on altimeters much as Kalman filters have become.
 
Why not use an altimeter with multiple output channels per event, like the Raven, Telemega, etc, etc, Then program one of the channels to apogee + x seconds as a backup. If the drogue chute is already out, then the charge wont harm anything, but if it isnt out, it will be very soon.

Ummmmm,

He was inquiring about blowing the Main not a drogue backup. I think it would be an interesting feature though I believe the use would be limited for flights under
"X" number of feet. What's "X"? Well if one uses the "backup main" event and the rocket is at 20,000 feet, will be a long drive for recovery. If the expected flight is 3000 feet, an apogee failure followed by the "backup main" situation might not be that bad of a deal for recovery. I like the idea and it wouldn't entail using extra electronics or an extra ematch/charge necessarily if the event could be programmed to the main chute channel. If not, then a two ematch charge would be needed like Gerard suggests. One to the "standard Main event" and one to the "backup Main" channel.

The only trick would be choosing the "triggering" rate of descent (or whatever parameter). Might be hard to discern with a drogueless descent. Choose too low and would see the main when everything might have been nominal at apogee. Still, wouldn't be a big deal if the expected flight wasn't going to a horrendously hight elevation. Kurt
 
The only trick would be choosing the "triggering" rate of descent (or whatever parameter). Might be hard to discern with a drogueless descent. Choose too low and would see the main when everything might have been nominal at apogee. Still, wouldn't be a big deal if the expected flight wasn't going to a horrendously hight elevation. Kurt

Ideally it would be set to roughly 1.5x the drogue descent speed.

Another restriction requiring configurability would be on extremely high flights. Not 20k, but rather 50k, where the air is thin and the drogue descent speed is higher than at ground level. You would end up having to disable it entirely for flights at e.g. 100k since rockets can break Mach even under drogue.
 
Yes, I think the request is like this... your altimeter fires the drogue and then waits, but it then notices that it is accelerating ... fast... ballistic FAST... it starts to scream "oh God, OH GOD!, We're going to DIE - Fire the Main!, FIRE THE MAIN!" at which point it realizes it can do this itself - and does - fire the main.... :)
 
Ideally it would be set to roughly 1.5x the drogue descent speed.

Another restriction requiring configurability would be on extremely high flights. Not 20k, but rather 50k, where the air is thin and the drogue descent speed is higher than at ground level. You would end up having to disable it entirely for flights at e.g. 100k since rockets can break Mach even under drogue.

Admittedly, the altimeter knows what the density of the air is, and can automatically decide to give up at high altitudes...not that that's particularly reassuring when you've got Death from Above coming down ballistic.
 
Last edited:
Just wire the ematch to both channels, or use two ematches in the same ejection charge.

Do negative velocities work properly?


And furthermore, would it be possible on my only-two-channel EasyMini?
 
Is there a dual deploy altimeter which will fire the main charges in the case that the rocket is descending too quickly after apogee? I'm talking about a 60 ft/s or so threshold four seconds after apogee (where a ballistic falling rocket would be descending at 120 ft/s (32 ft/s/s)). My supposition is that a somewhat late deployment would be better than one at the main altitude where the rocket would be moving much faster.

Is this a realistic idea without incurring too many false positives? I would definitely buy an altimeter with this feature.

I understand the motivation. In most ways I like this better than dedicating a separate charge to a backup apogee deployment. The hard part is selecting an appropriate too-fast descent threshold speed. When I'm doing a drogueless descent with a high performance composite rocket, the descent speed is on the order of 100 feet/second, and I'm fine with that. At very high altitudes, it can be even faster. But a lot of rockets would zipper or worse with that for the main deployment speed. So I don't see a way to put this feature in as a default without making a significant number of customers very irritated. The Raven is designed with deployment settings that are appropriate for almost anyone to have a successful flight right out of the box, and wide range of customers do just that. But as a user-selectable option with a selectable descent speed, it could be good.
 
Do negative velocities work properly?


And furthermore, would it be possible on my only-two-channel EasyMini?

Yes, negative values indicate that you're heading towards the ground. EasyMini (and TeleMetrum) don't have programmable pyro events in the stock firmware, although changing that would be a fairly simple matter of programming...
 
I understand the motivation. In most ways I like this better than dedicating a separate charge to a backup apogee deployment. The hard part is selecting an appropriate too-fast descent threshold speed. When I'm doing a drogueless descent with a high performance composite rocket, the descent speed is on the order of 100 feet/second, and I'm fine with that. At very high altitudes, it can be even faster. But a lot of rockets would zipper or worse with that for the main deployment speed. So I don't see a way to put this feature in as a default without making a significant number of customers very irritated. The Raven is designed with deployment settings that are appropriate for almost anyone to have a successful flight right out of the box, and wide range of customers do just that. But as a user-selectable option with a selectable descent speed, it could be good.

Very valid points but as one who's had the apogee blow on ascent (defective product not failure to set mach delay) and had the subsequent
main deployment set the remains down softly. Plus forgetting to clip the shockcord to the upper bay, I like seeing some prospect of main
deployment to bring some of the remnants back safely, perhaps with no damage so as to be able to fly again. A controlled "Main after Apogee"
could lead to that prospect in an admittedly rare situation as long as the apogee doesn't outstrip the launchsite size. Kurt
 
Sometimes, rockets (or at least the e-bay) come down nearly horizontally, which can fool the altimeter - but these cases are usually survivable when the main deploys at its regular altitude.

Reinhard

Good point. I still think a "ballistic mode detector" based on a fusion of baro and accelerometer readings may be possible with a good detection and false positive ratio. My brain can instantly tell if an apogee event has occurred just by looking at a plot of accelerometer and baro data of a flight. The question is how hard is it to replicate the brains processing of that information in a reasonable algorithm in firmware.
 
Hanging out for this feature on the raven. I'm thinking of trying an experimental recovery method so would actually use a normal drogue as a backup. I want to be able to check my decent rate to see how effectively recovery is working, otherwise it could get pretty messy.
 
I really like this idea as a failsafe. It's better to chase a rocket down (or possibly lose it) than put it into the ground at high speed. I'd rather separate a rocket and strip a chute (this should happen with the main anyways); but the likelihood of this is less with lower velocity.

Food for thought:
==========
Drogueless recovery is rather violent with semi-random tumbling. -- There should be some noise in all 3 axes. (Baro usually shows a little noise also.)
Drogue recovery should be much calmer once the drogue reaches a certain size. (The fincan below the drogue and upper section.) -- Relatively stable in all 3 axes. (Baro with little noise.)
Drogue separation failure will almost always come down nose first. -- Downward portion of motion should mirror the upward portion (after burnout).

It almost seems that checking for the ballistic reentry via either baro or accelerometer would be the most reliable. Possibly offer a "emergency main ejection" option and a "increase main altitude" to either put the laundry out as soon as a problem is detected or to separate the rocket higher to let aerodynamic forces slow it down more before impact.

I'm guessing that a check on deviation from ballistic is the best plan of attack. If As mentioned, accounting for low drag at high altitudes would be more complex.
 
I like the idea of this, but I wonder about the velocities?

I'm typically seeing 110 fps under drogue (at high altitude) that slows down to ~80 fps shortly before main deployment.


All the best, James
 
Could this be programmed to use baro data such that if the rocket descends X feet from apogee (point of pressure increasing) within T seconds, fire the main? Most backup drogue logic already has the time after apogee. It would be a matter of checking the drop in altitude at the time out and activating the main if the drop is greater than X feet.
 
Back
Top