Open Rocket Optimal Delay, how accurate?

The Rocketry Forum

Help Support The Rocketry Forum:

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

jb62

Well-Known Member
Joined
Dec 26, 2010
Messages
70
Reaction score
0
Hi, I am getting ready to fly my 4" Madcow Phoenix this weekend on an AT H250G. After simulating the flight on Open Rocket, I get ~1140 ft. altitude, with an optimal delay reading of ~7.32 seconds. Assuming I have the rocket and simulation model entered accurately, should I go with a 6 second delay or an 8 second delay?

For some reason, It seems like 7.32 seconds is a bit long for a rocket only going to 1142 ft. I would just like to know if, in your experience, OpenRocket is accurate on the optimal delay reading and when not, is it usually less or greater than what it should be?

As of right now I would choose 8 seconds, because 7.32 is closer to 8 than to 6 unless the wind is strong and I don't like the way a rocket looks when the 'chute opens up while the rocket is still climbing ;).

Just for fun, if you are bored, I am using the Rocksim file found on Apogee's site, with the motor tube out the aft of the rocket 3/4", with a mass of 1900g, and a CG (no motor) at 20" from nose cone. It has rail buttons and I launch off of a 6' rail.

Note: I havn't done many simulations so i'm a bit nervous about trusting the software lol. I know it works from what others have said but i'm still a tad timid.
 
I have the 4" Madcow Torrent and it's OR simulations have similar long optimum delays. I have found them to be pretty good based on altitude and velocities recorded on my RRC3. I use CTI motors and tend to round the optimum delay up to the next longer delay.
 
I would go with a 7 sec delay. it is better to be a triffle early than late(OR puts deployment at about 6mph). it takes about a half sec for the chute to start opening.
Rex
 
Not sure how accurate OR is, but I was always told it is better to go over the "perfect" delay time than under. It's better to go "over the hump" and then deploy, than to deploy while still going up. But honestly, I can't explain why these people say it's better.
 
I ran a sim on RS with all your info, I get 1,198 ft. optimal delay of 7.51. Go with 8. I also go with over rather than under with my delays.
 
I'll agree with Rex about being a triffle early than late. There are many variables in the sim program that can affect the calculated delay. Accurate coefficient in drag (cd) ? Launch site MSL ? Air pressure ? Winds aloft ? Round down is what I usually do.
 
remember the simulations assume that ejection/chute deployment occurs Instantaneously, when in fact it can take up to a 1/10 of a second to get the laundry out.
Rex
 
The minimum allowable uncertainty in a deal is +/- 1.5 seconds, and +/-20% from 7.5 to 15 second, and within +/-3 seconds for anything longer, so if your recovery system can't handle a +/3 second inaccuracy in the apogee time, you have built your rocket too light.......

Sky divers have gear that survives a 180 mph free fall, which is equivalent to +/- 9 seconds (but they have a dual deployment or reefing system for free fall jumps.

Bob
 
Reasons for biasing early:
It's closer to optimal in the case of weathercocking.

Reasons for biasing late:
If you really want that peak altitude.
More kinetic energy goes away (to potential energy and to drag) during the x seconds before apogee than the x seconds after apogee, so the deployment velocity is theoretically lower after than before (given the same time error in either direction). It's not a big effect though, unless your time error is something horrible.
The rocket is more likely to be falling backwards in a tailstand after apogee, giving a gentler deployment than the abrupt direction reversal of a deployment before apogee.


I personally bias early rather than late, because weathercocking does happen and it's a bigger effect than any of the other arguments I gave.
 
Thank you all for the replies; a lot of good things to think about. I think the rocket will do well with anything 6-8 seconds. I do not know what I will adjust it too, it will depend on the weather... and of course you never know how accurate the Aerotech delay is anyway. Who knows.
 
Thank you all for the replies; a lot of good things to think about. I think the rocket will do well with anything 6-8 seconds. I do not know what I will adjust it too, it will depend on the weather... and of course you never know how accurate the Aerotech delay is anyway. Who knows.

Exactly. Now you got it. The weather and motor variation will wreak havoc on even the most beautiful simulation. 6 or 8 seconds - no difference, really.

Personally, I would go with 6 seconds. The rocket will likely be a little more draggy and weathercocked than your simulation, resulting in a lower agogee.

On the other hand, if you go with a really long motor delay, then the method is called "Hillbilly Dual Deploy!"
 
Where do you find or calculate the optimal delay in OpenRocket? I've always just simulated the delays available for single-use motors with set delay times, or I've plugged in a couple of different delays for adjustable delay motors. Then I pick the best one based on the sims. Is there an Optimal Delay feature?
 
version 14.06 simulations results between 'velocity at deployment' and 'max velocity'.
Rex
 
version 14.06 simulations results between 'velocity at deployment' and 'max velocity'.
Rex

Ah, ok. There it is. I just downloaded 14.06 earlier today and didn't see that feature. That's actually a pretty cool new feature. Thanks!
 
I've always gone by which ever deployment velocity was lower, the one that puts the least strain on the recovery system. If they are close then looking at whether the rocket is likely to weathercock becomes the deciding factor.


Richard
 
I have the same Madcow Phoenix, it weighs right at 67 oz (1900g) without motor. On an H250G or an H242T (38mm), 6 seconds has been almost dead-on every time. When using Rocksim, a Cd of 0.67 results in excellent matches (within about 50 ft) of actual flight results.
 
Jumping in a little late on this one but I have always gone with the longer delay, rounded past the OR sim. I think on all but one of my rockets it seems to be a little too long. I would round down if I were you. What Rex said.


Sent from my iPhone using Rocketry Forum
 
I've always gone by which ever deployment velocity was lower, the one that puts the least strain on the recovery system. If they are close then looking at whether the rocket is likely to weathercock becomes the deciding factor.


Richard

+1.

OpenRocket has always been about spot on with the recommended delay in my experience.
 
That was a great recommendation! This will be great for picking motors that have set delays, and even better for the ones with adjustable delays.

Hmm, I am surprised this is a new feature in OR. Optimal Delay is a pretty standard output from simulators.

The basic results I need from a simulation: is the launch velocity sufficient, how high does it go, what delay to choose.
 
The minimum allowable uncertainty in a deal is +/- 1.5 seconds, and +/-20% from 7.5 to 15 second, and within +/-3 seconds for anything longer, so if your recovery system can't handle a +/3 second inaccuracy in the apogee time, you have built your rocket too light.......
So there is significant error in the delay mechanism itself (since we are essentially using the smoke charge as a fuse). There is also error in the simulation because we make large assumptions about forces, particularly drag.

This is the main reason electronics are better: they deploy at the actual apogee by measuring pressure and/or acceleration, which makes them independent of variations in motor performance and launch conditions.
 
Back
Top