Best way to implement an airstart

bdureau · Feb 2, 2014

Hi all
I am currently implementing an airstart function on my AltiMulti altimeter.
https://rocket.payload.free.fr/index.php?option=com_content&view=article&id=13&Itemid=11&lang=en

So far I have 2 ideas:
- implement 2 simple timer so that you do rocket separation at booster burn out with the first one and start the second stage with the other one

or

- calculate the velocity and do the booster separation when the rocket is slowing down and then a timer to start the second stage

Any though?

cerving · Feb 2, 2014

Boris: If the rocket is going fast enough, a baro sensor isn't going to be able to accurately detect burnout because of trans-mach pressure effects. I spent a lot of time and many flights trying to get it to work, it's just not workable. That's why I did it with a timer on the Eggtimer; many people use dedicated timers for airstarts and they've passed the test of time. If you have an accelerometer, you can detect burnout with reasonable accuracy, although a lot depends on the thrust curve of the motor. Burnout with motors that have a distinct thrust cutoff point are easier to pick up.

Whatever you do, think about safety... you want to eliminate any chance of the sustainer igniting on the ground.

bdureau · Feb 2, 2014

Thanks for your response
Safety is my first concern which is why I am asking around.
A timer is very easy to implement, I am going to allow all pyro output to be selectable as a timer
Have you tried a combination of timer + rocket speed?

JohnCoker · Feb 2, 2014

The way most flight computers work is to define detectable events: launch, 1st stage burnout, 2nd stage burnout, etc.
Then, you trigger an output at that event plus a set amount of time, i.e., "launch +10s" or "first stage burnout +3s".

I also agree that you should incorporate an accelerometer to get accurate launch detection, which will also give you burnout and staging detection.

DanDare · Feb 2, 2014

Hello,

Im new to this so excuse-me if anything I say is just gibberish:
What triggered me on posting a replay here is that I was thinking other day how such an airstart would work (although im really far from having multiple stages rockets).
What I think is most reliable would be (somewhat), pressure sensors on nozzles. With such accuracy, you may not spend too much velocity while deciding to ignite other stage.
The viable way of doing it I can think at the moment is some simple mechanical pressure trigger. You dont have pressure readings this way but can set a pressure trigger limit. With some loss of fuel power it may possible to deviate some pressure from nozzle to such a sensor.

Well, it sounds a good idea for experiments at least?

Rodrigo

georgegassaway · Feb 11, 2014

I know this thread is over a week old but this may be of value:

If you use the rocket slowing down as a trigger, then it very likely would trigger while the engine is still producing useful thrust.

I found years ago when doing flight sims of my shuttle model, that for a 3 second burn, the velocity peaked at either 1.5 or 2 seconds into the burn, then started to get slower. But there was still 50% to 33% of engine thrust time left.

This was when using an engine with a regressive time-thrust curve. At some point the drag from high speed overcame the thrust that was dropping so it stopped accelerating and began to slow down in mid-burn.

So, do some flight sims that graph the velocity of your specific model with the specific planned engine(s) and compare the velocity graph with the engine thrust curve.

In general, a timer would more reliable for staging than sensing the velocity.

Now, the key is in starting the timer at true liftoff. If the timer started due to a break-wire, across the nozzle, then the timer would start when the engine fired. This is usually OK for black powder motors, but for composites it could be dangerous since at best, the ignitor could fail to ignite the motor but burn the break wire, and the second stage would ignite while on the pad. At worst, the motor might chuff, leading to possibly even worst scenarios than staging while sitting on the pad.

So you need some other sensors for liftoff. I believe strongly in the good old fashioned lever switch, pressed by a rod while on the pad. It has to be mounted and assembled correctly, and the pad mount for the rod pressing the lever switch needs to be foolproof. I do know of one accident in the past, but the person who built it designed and assembled it poorly (he used a launch rod itself to press the lever arm, and had the lever arm in the middle between lugs. The rod bowed between the two lugs and left a gap to let the lever pop open. If he'd just had the lever arm just above of just below one lug, with the arm sticking up half the thickness of the rod or more, it would not have had that flaw).

Now that too could be fooled if a motor chuffed and made the model move a few inches up.

So it might be good to incorporate that with altitude indication or a G-switch that is set to a reasonable level. G-switches have a bad reputation to me, because I have heard off too many that do not sense liftoff correctly, for models that did not have the high T/W ratio that some G-switches demand (to me those failures were not due to the models but the switches being too "one size fits all" which means "does not fit most very well"). So if I ever use one I'm going to program it (Arduino based) to have a lower threshold for detecting launch, specific to the model's flight profile, without letting it be too risky. And I may very well be doing that this summer.

So I think that a break wire or lever switch, plus a reasonably set G-switch, can be done well.

For my shuttle, i had a flight computer that used two sensors for liftoff. One was a lever switch in the model, and a rod in the pad to hold that switch. The other, the engine casing was allowed to slide upwards 1/8". When it ignited and came to thrust, it moved up 1/8" and pressed a lever switch, as a "thrust sensor". So, a valid liftoff was lever switch not being pressed, plus thrust "on". The flight computer started timing when it had thrust and the liftoff sensor was not being pressed. But as a safeguard, it looked for the thrust to be sensed for 1/2 second before continuing the timing count, otherwise it would stop (an accident could be a "bump" on the pad, or a quick "chuff", that the programing could realize). If this thrust sensor was done for HPR, I'd probably make that thrust sensor duration time a lot more, at least 50% of the burn duration of the motor. That would help to make it less likely to have problems with bad chuffing that might have made the model move up enough to trigger the liftoff sensor. BTW - the engine was plugged, no ejection charge (the flight computer fired ejection 1 second after Orbiter was sepped by R/C, or 7 seconds after liftoff, whichever came first).

Later, the computer was programmed to sep the SRB's 1/2 second after burnout was detected. So, it used the "thrust" switch to detect burnout. However, due to mercury switch effect, negative G's during coast, the engine casing itself would want to stay forward, pressing the button, when it burned out. So, I added three retractable pen coil springs to provide sufficient spring force to push the engine casing back "down" when the thrust was low enough. I made sure the spring force margin of error was a little more on the side of the engine still thrusting a little bit before true burnout (maybe 1/10 to 2/10 second before), than risk trying to make it so fine that it might not actually push the engine casing back in place at burnout. As it is, the SRB sep was not till l1/2 second after burnout detect, so burnout timing was not critical.

There was also a branch in the programming to sep the SRB's at 4 seconds after liftoff, if burnout had not been detected (if springs did not push the casing back), knowing that for a typical burn the engine should burn out at about 3 seconds.

- George Gassaway

cerving · Feb 11, 2014

The Eggtimer uses both breakwire and baro altitude as airstart triggers, plus programmable timers for motor burn profile and burnout-to-ignition delay. It doesn't check the breakwire until after the baro Launch Detect Altitude (LDA) is hit; this is to protect against switch bounce on the rod/rail if you use a microswitch.

bdureau · Feb 11, 2014

georgegassaway said:
I know this thread is over a week old but this may be of value:

If you use the rocket slowing down as a trigger, then it very likely would trigger while the engine is still producing useful thrust.

I found years ago when doing flight sims of my shuttle model, that for a 3 second burn, the velocity peaked at either 1.5 or 2 seconds into the burn, then started to get slower. But there was still 50% to 33% of engine thrust time left.

This was when using an engine with a regressive time-thrust curve. At some point the drag from high speed overcame the thrust that was dropping so it stopped accelerating and began to slow down in mid-burn.

So, do some flight sims that graph the velocity of your specific model with the specific planned engine(s) and compare the velocity graph with the engine thrust curve.

In general, a timer would more reliable for staging than sensing the velocity.

Now, the key is in starting the timer at true liftoff. If the timer started due to a break-wire, across the nozzle, then the timer would start when the engine fired. This is usually OK for black powder motors, but for composites it could be dangerous since at best, the ignitor could fail to ignite the motor but burn the break wire, and the second stage would ignite while on the pad. At worst, the motor might chuff, leading to possibly even worst scenarios than staging while sitting on the pad.

So you need some other sensors for liftoff. I believe strongly in the good old fashioned lever switch, pressed by a rod while on the pad. It has to be mounted and assembled correctly, and the pad mount for the rod pressing the lever switch needs to be foolproof. I do know of one accident in the past, but the person who built it designed and assembled it poorly (he used a launch rod itself to press the lever arm, and had the lever arm in the middle between lugs. The rod bowed between the two lugs and left a gap to let the lever pop open. If he'd just had the lever arm just above of just below one lug, with the arm sticking up half the thickness of the rod or more, it would not have had that flaw).

Now that too could be fooled if a motor chuffed and made the model move a few inches up.

So it might be good to incorporate that with altitude indication or a G-switch that is set to a reasonable level. G-switches have a bad reputation to me, because I have heard off too many that do not sense liftoff correctly, for models that did not have the high T/W ratio that some G-switches demand (to me those failures were not due to the models but the switches being too "one size fits all" which means "does not fit most very well"). So if I ever use one I'm going to program it (Arduino based) to have a lower threshold for detecting launch, specific to the model's flight profile, without letting it be too risky. And I may very well be doing that this summer.

So I think that a break wire or lever switch, plus a reasonably set G-switch, can be done well.

For my shuttle, i had a flight computer that used two sensors for liftoff. One was a lever switch in the model, and a rod in the pad to hold that switch. The other, the engine casing was allowed to slide upwards 1/8". When it ignited and came to thrust, it moved up 1/8" and pressed a lever switch, as a "thrust sensor". So, a valid liftoff was lever switch not being pressed, plus thrust "on". The flight computer started timing when it had thrust and the liftoff sensor was not being pressed. But as a safeguard, it looked for the thrust to be sensed for 1/2 second before continuing the timing count, otherwise it would stop (an accident could be a "bump" on the pad, or a quick "chuff", that the programing could realize). If this thrust sensor was done for HPR, I'd probably make that thrust sensor duration time a lot more, at least 50% of the burn duration of the motor. That would help to make it less likely to have problems with bad chuffing that might have made the model move up enough to trigger the liftoff sensor. BTW - the engine was plugged, no ejection charge (the flight computer fired ejection 1 second after Orbiter was sepped by R/C, or 7 seconds after liftoff, whichever came first).

Later, the computer was programmed to sep the SRB's 1/2 second after burnout was detected. So, it used the "thrust" switch to detect burnout. However, due to mercury switch effect, negative G's during coast, the engine casing itself would want to stay forward, pressing the button, when it burned out. So, I added three retractable pen coil springs to provide sufficient spring force to push the engine casing back "down" when the thrust was low enough. I made sure the spring force margin of error was a little more on the side of the engine still thrusting a little bit before true burnout (maybe 1/10 to 2/10 second before), than risk trying to make it so fine that it might not actually push the engine casing back in place at burnout. As it is, the SRB sep was not till l1/2 second after burnout detect, so burnout timing was not critical.

There was also a branch in the programming to sep the SRB's at 4 seconds after liftoff, if burnout had not been detected (if springs did not push the casing back), knowing that for a typical burn the engine should burn out at about 3 seconds.

- George Gassaway

George
Thanks for a answering. I am a big fan of the Shuttle and I have built several, the biggest one being 1/62 scale (I have built 3 of those orbiters ).
https://rocket.bear.free.fr/index.php?option=com_content&view=article&id=18&Itemid=13&lang=en

However none of them were as complex as yours (I have seen your videos few years ago). I must admit you are one of the master out there who can build one that works like it should do... with all the booster separation I must admit I am quite impressed.

All my homemade altimeters (I have now 6 different models) which are arduino compatible boards
https://rocket.payload.free.fr/index.php?option=com_content&view=article&id=16&Itemid=13&lang=fr
are using the pressure sensor to detect lift off. Basically whenerver the rocket is 20m above ground it consider it as a lift off. This so far has worked really well with all my altimeters; note that I am also doing digital filtring with the Kalman filter code that was given to be by Cris (cerving) . What I am thinking of is starting the timer whenever lift off has been detected using the pressure sensor. However I am not going to use any break wire, I am afraid of accidently breaking the wire while the rocket is on the pad .
Don't you think that the pressure sensor is reliable enought to start the timer?
Boris

georgegassaway · Feb 11, 2014

I do not think that 20 meters off the ground is a safe margin. My introduction to altimeters was what turned out to be just a terrible trashy thing, that turned out to among other things accidentally start due to wind gusts. Except I wasn't even flying in that much wind. The solution for flying that thing was to arm it, put the model on the pad, and when it was finally ready to sense liftoff a minute later, then launch it. But it did not even have a beeper so I could not tell when it that minute or so was passed. But in any case, a good altimeter should not false detect launch when sitting on the pad, unless the winds are horrendously bad (in which case maybe it's not a good day to fly)

Anyway, you should use a higher barometric altitude than that. Approximately how high should the rocket be when it stages… ballpark number? If 400 feet, maybe use 200 feet for the barometric launch detect altitude, if 300 feet use 150 for the threshold.

I get what you are saying about a breakwire. That is why I focused more on a switch pressed by a rod on the pad. I did not literally mean a launch rod, but a rod going up inside the aft centering ring, thru aligned holes (better yet, using a tube like a launch lug to guide the rod to the switch. Although if the electronics are forward of the separation point, then an external rod wood be more practical (it is al about the design and execution it can be done safely if thought out and built properly.)

The danger is in not thinking everything through well enough, regardless of methods used.

Here's a page with info/pics on the shuttle ET I made in 2000:

https://georgesrockets.com/GRP/Scale/Shuttle-M-CD/Shutt_ET/ET_2000.htm

This pic is the liftoff sensor assembly. Lever switch with a launch lug to help guide the 1/8" rod that was mounted to the pad, going thru a 1/8" hole in the bottom of the ET Aft Dome

One other thing I'll mention is no matter what you do, use a common sense safety feature. Do not arm the thing on the pad and let it sit for many minutes until an RSO "gets around to it". Have heard of too many accidents where the battery went dead. If course there's not much excuse for a battery going dead when rockets weigh pounds and doubling the battery capacity adds grams (40 pound rocket crashed because a 1.5 ounce 9 volt crappy battery died? holy ****).

Anyway, what i like to do is have the system set up so that there are two phases of the system being powered up. One is that it is started, and it confirms it is running properly, no false detections. But I do NOT ARM the pyros until shortly before flight. On my 2-stage Orbital SkyDart, two R/C models, one piggyback boosted by the other, the Skydart's ignitor was not plugged into the cable until about a minute before flight.

Now I realize for some bigger HPR rockets, it may not be practical to do a final arm as close as 60 seconds before launch. But there is no excuse for suer long delays, it's bad safety practice for launch organizers to make models with critical electronics sit running on the pad for a very long time (even more so with an altimeter involved to sense true liftoff).

The other thing, and actually PYRO SAFETY 101, is ALWAYS treat the rocket like the pryos can go off at any instant. So, do not point the nose towards people, or let the nozzle face anyone. Or let the ejection "blast zone" face you or anyone. Eye protection is a good idea. Some of the most serious ground accidents have occurred when the rocket was not being treated like it could go off at any instant.

I'll also say that you are programming your own, program a piezo beeper to make a nice simple single beep when it is "happy" and dry for launch, and a very rapid "OMG, I'm going to FIRE soon" warning beep when it is triggered to count. So at the least, if it gets a false trigger, you can realize it and get the (blank) out of the way. I just recently programmed my own first rocket timer prototype (breadboarded), and gave it that feature, which some other commercial devices do have too, but not this small.

Maybe I'l post a video of it.

- George Gassaway

cerving · Feb 11, 2014

I've had rockets sit on the pad for nearly an hour... it happens. Your electronics shouldn't care, your baro should take occasional readings and average them into the "zero altitude AGL" reading so changes in temperature, wind, etc. don't make your rocket think it's moved. Your launch detect altitude should be at least 200 feet for any HPR rocket, unless you have some monster that will be nearing mach by that altitude. Chances are that a rocket like that won't be a two-stager anyway.

georgegassaway · Feb 12, 2014

FWIW - here's video of a simple timer prototype I made up. It will be used with black powder rockets, so the breakwire is not a big risk like it would be with composites. Though it could just as easily be a switch and not a breakwire. Also, the 9V battery is not what it will fly with, just it was handier than being hooked up via USB cable (It's still in the prototype breadboard stage)

[youtube]_H8eKyBfh2A[/youtube]

Anyway, main thing for you to look at…. is actually to listen to the different beep types depending on the mode. Unfortunately I started the recording after a test, so it was in the post-ejection beep mode 3, with a dit-dit-dah beep. But later you can hear (and see) it ready for "launch", set for mode 1, wire connected (pushbutton for testing), a 1/10 sec beep each second. Then when the wire breaks, it runs at 1/10 sec cycles, counting tenths of a second, and beeping every other tenth, which gets attention quite well. If I'm at the pad and hear that beep, I know I need to either yank the wires out from the ejection if I can, or be safely prepared for it to go off (or , try to short the "breakwire" wires together, as it will reset back to mode 1 if it gets connected again before ejection).

After the ejection, then its in mode 3 and the post-ejection beep.

It may also be used for staging a scale model, but if so then I will add another launch detect safeguard, probably a G sensor if testing goes well.

Oh, two things I am considering for the scale model staging timer. For one, a long "prep delay", so it won't arm until say 5 minutes after being turned on.

The other, a magnet switch as an abort or safety reset switch. I do not trust magnet switches for primary switches to turn the timer on and such. But it might work well for being able to STOP the timer to get back to the "prep delay" mode. Now on a non-scale rocket, I'd have external switches I could activate. But since it is scale, it can't have stuff like that visible externally.

- George Gassaway

TheAviator · Feb 12, 2014

georgegassaway said:
Oh, two things I am considering for the scale model staging timer. For one, a long "prep delay", so it won't arm until say 5 minutes after being turned on.

The other, a magnet switch as an abort or safety reset switch. I do not trust magnet switches for primary switches to turn the timer on and such. But it might work well for being able to STOP the timer to get back to the "prep delay" mode. Now on a non-scale rocket, I'd have external switches I could activate. But since it is scale, it can't have stuff like that visible externally.

- George Gassaway

As I'm sure you recall, there have been some very serious incidents regarding electronic staging at the past couple of NARAMs. We have (or should have) learned from this that electronics should never be powered up until the rocket is on the pad in flight configuration and spectators are clear. I understand the desire for scale correctness, but as your signature says, safety should be the number one priority. Now, if you can explain to me how this "5 minute arm delay" works and how it would integrate into your system, I will happily reconsider my opinion, but at first glance, it sounds somewhat unsafe.

The HPR guys have already had a serious injury due to staging electronics failure. The question isn't if, but when, a similar incident will happen at a smaller scale, as the electronics are getting smaller, cheaper, and more available. Let's learn from our near misses and try to put it off as long as possible.

Best way to implement an airstart

Help Support The Rocketry Forum:

bdureau

Well-Known Member

cerving

Owner, Eggtimer Rocketry

bdureau

Well-Known Member

JohnCoker

Well-Known Member

DanDare

Well-Known Member

georgegassaway

Well-Known Member

cerving

Owner, Eggtimer Rocketry

bdureau

Well-Known Member

georgegassaway

Well-Known Member

cerving

Owner, Eggtimer Rocketry

georgegassaway

Well-Known Member

TheAviator

Well-Known Member

Similar threads

Latest posts

Best way to implement an airstart

Help Support The Rocketry Forum:

Well-Known Member

Owner, Eggtimer Rocketry

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Owner, Eggtimer Rocketry

Well-Known Member

Well-Known Member

Owner, Eggtimer Rocketry

Well-Known Member

Well-Known Member

Similar threads

Join the conversation!

Join today and get all the highlights of this community direct to your inbox. It's FREE!