OpenRocket optimum delay - request for comments

Hi,

Based on the feedback on this forum Kevin has taken a shot at implementing the optimum delay column in OpenRocket. There's been a rather long debate on the developer mailing list on whether the column should display the optimum delay (time from motor burnout to apogee) or difference from optimum delay (time from recovery device deployment to apogee).

Please provide your input.

If you're for the difference from optimum delay, please comment on which way do you think it should be informed: Does "+0.7s" mean I have to add 0.7s to the delay to make it optimal, or is the delay 0.7s too long?

(And just to be clear, the result of this poll is not binding. The final say comes from the one coding it.

Cheers,
Sampo N.

IMHO, I think it should be delay from burnout to lowest velocity in the flight. It would be nice because we can just read that number and use it to find our delay, instead of doing an extra calculation.


We already manually do it, so having a computer do it shouldn't be too hard... :rofl:

my vote is for optimum delay. the number it spits out is the number I want to match to the motor delay. the whole point is to eliminate the maths!

Derek said:

my vote is for optimum delay. the number it spits out is the number I want to match to the motor delay. the whole point is to eliminate the maths!

Click to expand...

Yup. That was my vote too.

Optimum delay would be the most useful number for the user (time from burnout to optimum deployment, I.e. Apogee or minimum velocity or whatever).


Sent from my iPhone using Rocketry Forum

blackbrandt said:

IMHO, I think it should be delay from burnout to lowest velocity in the flight.

Click to expand...

That's a good point. But are there any cases where lowest velocity is significantly different from apogee?

On normal flights I could imagine air resistance slowing down the rocket still a bit after apogee before gravity really kicks in, but I'd doubt it to be more than some tenths of a second. For high altitude flights the air resistance should be even less.

Cheers,
Sampo N.

There are rockets (forward facing one shot cameras (Camroc, Astrocam 110, Snapshot, etc.)) that are designed to arc over before the laundry is deployed, and others (modified Astrocam 110's, etc.) that need to deploy before the rocket arcs over. Knowing what the trajectory of say each Estes C6-X motors would be extremely cool.

I voted, then wrote a short note. Decided that the short note would open a heated discussion and deleted it.
I don't mind using my brain to figure out that I need to change my delay time a second or 2.....

I voted for optimum delay. Any delta from optimum assumes the motor's delay is actually what the rated value is....which isn't always true (unless actual delays from cert data are in the motor files rather than the one given in the motor's designation).

I guess I don't get the distinction from lowest velocity in flight (which should be zero unless the recovery system is deployed before apogee) and apogee.

+1 for "Optimum Delay". I believe that is what I asked for in the other thread.

BTW: Kevin sent me a beta version of the software with this feature implemented last week. I've been playing around with it on a bunch of different designs and it works great.

If you wanna send it to me, I would love to help test.

bass matt f at gmail dot com

Would the program known the delay times on the reload? Will it then state to use electronic deployment if you're time to apogee is above the highest delay?

Just curious.

I vote time from motor burnout, but I think I clicked wrong one & it wouldnt let me go back.

I voted both, but really want "Time from motor burnout to apogee (optimum delay for motor): " as a first choice...

Time from motor burn out to apogee.

My goal with motor ejection is to pick the correct delay, or to drill the correct amount to achieve ejection at or very near apogee.

When I sim a motor with a longer delay than needed, it's easy to look at the Plot (vertical motion vs. time) and see what the optimum delay would be.

This is not really possible when the delay is too short. That's where the "Optimum Delay" column is really valuable.

HOWEVER... If I'm at the launch site and I need to drill a delay, The DIFFERENCE (-2 seconds for example) is really what I want. That's the big advantage there. Hey, it's a computer, it should just tell me what I want to know.

I really like the idea of an "Optimum Delay" column.

I also want to see it say "Delay too long, Drill -2.0 sec" or "Warning delay too short, minimum recommended delay = 8.43 sec"

Yeah - sorry, I want it all - thanks for asking for input - that's really the best thing!

I vote optimum delay. A plus/minus readout would cause trouble if you forget what stock delays you ran the sim on if you're in the field w/o a printout.

Optimum delay for me please.

+1 for optimum delay, please.

First of all, "Thank You!" for attempting this.

I voted for optimal delay.

Greg