DD Main Parachute Open Time, Hard Data

Here's the data I pulled off of my Eggtimer TRS. It shows that it took about 250 feet and 4 seconds for the main parachute to open after the charge went off. I would not have seen this data just from looking at the raw numbers. I HAD to graph the data out to see it. Hope this helps anyone trying to figure out when to open their main parachute.

How much did your rocket weigh?

13.25 pounds, launch weight. Main is a 60 inch flare parachute, folded in the Fruity Chutes style, in a nomex burrito. I should've been more specific.

I was looking at another one of your plots on Flicker and it shows almost instant decrease in velocity when main opened . Same rocket?

https://www.flickr.com/photos/bigangryscot/21111720992/in/photostream/

My X-Celerator comes in at about 16# on the pad. I started out deploying the main at 300'. After a few times of much nervousness thinking the chute wouldn't open in time, I moved it to 500'. So I can easily see it taking a good 200' to get the main fully deployed under certain conditions.

timbucktoo said:

I was looking at another one of your plots on Flicker and it shows almost instant decrease in velocity when main opened . Same rocket?

https://www.flickr.com/photos/bigangryscot/21111720992/in/photostream/

Click to expand...

Yes it was the same rocket, but the same flight. That was the backup flight computer and charge. Parachute was already out when that charge went off.

Hehehe I fly a wildman JR with no drogue and a main chute is a Recon Drogue. Mains set at 200 feet. never hits the ground hard.....

Honestly, the real variables are the type & size of chute & how you pack it (or for the real big ones, do you have a pilot?) The important take home is pack your chutes the same way and understand how long it takes to get them inflated

What is the difference between the yellow and green altitude plots? What' s up with the time units on the x axis? 10^4 seconds? Some labels/legend would help. Thanks.

I believe the time is in milliseconds, so 5000 is 5 seconds1.5x10^4 would be 15 seconds, almost 55 seconds for entire launch. Dotted lines for parachute ejection times, lower lines for filtered/unfiltered acceleration, and no idea about yellow vs green maybe velocity?

Try folding your parachute as described in this thread: https://www.rocketryforum.com/showthread.php?58403-Folding-a-Flat-Parachute&highlight=Folding

Mine are usually open well within 2 sec of charge firing, and I recently had to make a new payload section for one rocket when the chute snapped open so abruptly that it zippered the payload section. Things have been far more consistent also since I started doing it the way described in that thread.

Jeffmhopkins said:

I believe the time is in milliseconds, so 5000 is 5 seconds1.5x10^4 would be 15 seconds, almost 55 seconds for entire launch. Dotted lines for parachute ejection times, lower lines for filtered/unfiltered acceleration, and no idea about yellow vs green maybe velocity?

Click to expand...

The red/blue are velocity. The yellow/green may be barometric vs. GPS altitude (I am not sure what functions are included on the Eggtimer)???

Yellow is raw altitude, green is filtered altitude. Red is raw velocity, blue is filtered velocity. Dotted lines are charges going off. Time is in milliseconds. Apparently when I make a post at 3 a.m., I leave a lot of info out!

Cl(VII), I've used that method for a long time, and I use it on my smaller stuff, but recently had a recovery failure on a L2 attempt that made me shy away from it. I'm sure I did something wrong, but I still went to something else.

Tonimus said:

Yellow is raw altitude, green is filtered altitude. Red is raw velocity, blue is filtered velocity. Dotted lines are charges going off. Time is in milliseconds. Apparently when I make a post at 3 a.m., I leave a lot of info out!

Cl(VII), I've used that method for a long time, and I use it on my smaller stuff, but recently had a recovery failure on a L2 attempt that made me shy away from it. I'm sure I did something wrong, but I still went to something else.

Click to expand...

You should replot your data using a spreadsheet and fix up the axis units so it makes it easier to view.

If the axis output is in milliseconds, make another column and divide by 1000 to convert to seconds and format the column to xxxxx.xx (2 digits after the decimal point), and use the new column for the x-axis with time in seconds. Suggested: min = 0 seconds, max = 60 seconds, major grid unit = 10 seconds, minor axis grid = 1 second.

For the primary y-axis which is altitude suggest min = 0', max = 1500', major grid unit = 250', minor grid unit = 25'

Take the velcocity(ies) and have them use a secondary y-axis so you can expand the velocity scale to a useful range. Suggested values: min = -200 fps, max = 400 fps, major grid unit = 100 fps, minor grid unit = 10 fps. (This makes both major and minor grid line match up for both the primary and secondary y-axis.)

I'm assuming that you are averaging the y-axis points in your own spreadsheet as there is a time delay in all numbers due to the averaging. This is made worse by the options in the Eggtimer. Your up sample rate is probably 20 hz but your down sample rate is 2 hz. The down sample rate is too slow to analyze the parachute opening time. It looks like your post apogee descent rate is ~62.5 fps with a ~31' delta t and your post main descent rate is ~24 fps with a 12' delta t.

The minimum deployment time is recovery gear length in feet divided by the velocity in fps. If your gear length is 30 feet and your velocity is 60 fps your minimum deployment time is 0.5 seconds. When you are sampling at a 31' resolution rate, you can not determine the deployment time. If you increased the sampling rate to 20 Hz, the distance resolution is then reduced to 3' and you can make a good estimate of the deployment time.

The averaging routine added a 2 second phase delay to your data. When you average velocity (or altitude), you should do a symmetrical average about the sampling point to avoid any time offset.

If you have a real data file, not a plot, post it and I'll give it back in a spreadsheet.

Bob

Professor Krech graded your homework, gave you no partial credit, dismissed your conclusions, and gave you additional assignments. Aren't you glad you posted this to a hobby forum? :wink:

Anyway, I would assume the OP isn't averaging anything and just plotted the data dumped by the Eggtimer. I briefly read the user manual, and there is mention of filtered velocity and filtered altitude in the output. The filtered velocity is pretty obvious in the graph, but the need for, and method of, altitude filtering is not obvious to me when comparing the yellow and green curves.

Ouch! That's a bit harsh, but you need to know fundamental information about the rocket/motor combo and have the best available flight data to perform a detailed flight evaluation. The fundamental information includes pad weigh, motor specifications, rocket diameter and length and deployment information such as parachute diameter and shock cord length, and the weight and type of ejection charge, and a digital file of the flight parameters.

The OP is trying to identify why the deployment method required 4 seconds to deploy the main which was fired about 7.5 seconds after the apogee charge in the example case, and didn't deploy in another. You need to have the data displayed in the most illustrative manner possible so folks can look at it and assist him in his investigation on why his main deployment takes so long in this case, and didn't occur at all in another.

I do not have this altimeter so I also skimmed the manual and noticed that you can obtain a .csv file output of the flight data. The barometric data file is important as the graphics and analysis package that the altimeter comes with isn't as polished as the hardware. The digital barometric sensor is very accurate, and the rest of the hardware seem high qiuality, so I'm surprised the derived velocity data is so noisy, and when smoothed has a 2 second phase delay, but this can be fixed in a user written spreadsheet as can the graphical presentation.

Without witnessing the flight or having the digital flight data file do a more detailed what-if analysis, all one can say is that the 4 second deployment time after the main charge was fired is extremely long as ~1 to 2 second deployment time would be expected. With a 2 Hz sampling rate after apogee it's hard to note subtle velocity changes which can give useful diagnostic information.

The questions that need to be answer are:

1.) Was enough BP used in the ejection charge and was the charge ignited quickly? How was the BP confined, or was a BP substitute used? If the charge was weak it might have taken additional aerodynamic forces to pull the chute out of the airframe delaying chute extraction and inflation.

2.) Did the chute packing or excessive shock cord length inhibit deployment? Many surplus 5' flare chutes come with a Nomex D-bag. I like to fasten this D-bag to the NC so it pulls the chute out with the NC and then is pulled off the chute by the momentum of the NC. I've used this method with dual 3' flare chutes on a 5 pound 4" rocket using apogee motor ejection and obtained rapid and full chute inflation without tangling the chutes.

FWIW I know what data is required as I've performed hundreds of flight analysis using altimeter flight data, but the quality of the analysis depends on the amount and quality of the data supplied.

Bob

Bob,

I didn't take any offense to either post. The failure I referenced was due to a series of failures that compounded upon each other. Also, it was a different chute in a much smaller airframe.

1. Yes, enough BP was used. I used 2 grams of BP, with two #2 nylon shear pins. BP is confined in a 1/4 inch cardboard tube with two wraps of electrical tape over the ends, initiated with a CJ e-match.

2. 25' total recovery harness for the main, 18' between the 'chute and AV bay. I'm not using a d-bag for this parachute.

The rocket in the original graph is a Wildman Interceptor 98, pad weight of 13.5 pounds. Motor was an AT DMS J270W. I've also included the text file for a Madcow Fiberglass SuperDX3 that we flew with the same setup, same charges, virtually the same weight, same recovery gear, on an AT J350W.

I appreciate all the help.

View attachment Interceptor Primary copy.txt
View attachment DX3 Primary copy.txt

I also plan on getting at least one more launch next month on each of these rockets, gathering as much data as I can. I will increase the down sampling rate.

Personally; I'd never set my main deployment under 500 ft.
That is my flatline hard deck.
I've seen rockets main set for 250 hit hard before the main fully blossoms.
If a rocket is coming in 40-80 ft per sec, your rocket needs time to unpack itself.


JD

Safety and getting open aside.... I used to set mine for 300 or 500. I've found 1000' greatly helps in tracking.

Mine all depend on the size and type of rocket. I have a small 3" that is set to 300 ft. The larger 4" is set at 400 ft and could probably get moved to 300. The 6" is at 1000 ft and that won't go lower any time soon, if ever.

I think the biggest deciding factor is how the main chute is packed and thus how it deploys. In the smaller rockets it is folded with the shroud lines inside and put in the tube with some dog barf and a chute protector. Those mains open very quickly when they leave the tube and can be deployed at relatively low altitudes. The large 6" has a d-bag and pilot chute to pull the bag off the main. That is a much slower process and requires more altitude.

My SOP is to use the first 3 or 4 flights of any new DD rocket as calibration flights. I adjust the drogue chute size and main deployment altitude. In both cases I start off large/high and work down. YMMV.

bobkrech said:

so I'm surprised the derived velocity data is so noisy, and when smoothed has a 2 second phase delay,

Click to expand...

The noise in the velocity is inherent to numerical differentiation of the altitude. Just a little noise in altitude will be amplified in the noise in velocity.

I do not see a 2 second phase shift in velocity. Do you mean the 2 second phase shift in the down part of the altitude curves (yellow vs. green)? How can any averaging of the yellow curve result in the constantly higher green curve?

The filtering of the velocity makes sense to me, but the filtering of altitude does not. Looks more like a gain or some kind of baro vs. GPS thing. As you noted, the up vs. down sampling rate must be coming in to play also.

DizWolf said:

Safety and getting open aside.... I used to set mine for 300 or 500. I've found 1000' greatly helps in tracking.

Click to expand...

1,000' gives me time to try and spot it before it touches down! :grin:

That and I like to see big chutes open...