Vector Reserve Pilot Chute Video

[billbooth 10]

Recently, several people have stated that the all–fabric Vector II reserve pilot chute doesn’t work as well as mesh-bottomed pilot chutes. This is simply not true. I made mesh-bottomed reserve pilot chutes for 15 years, and it is not reasonable to assume that I would put out a new product that was inferior to something I was already producing. There had to be a reason to make the change, and the reason is this:

Spring loaded, mesh-bottomed pilot chutes have a nasty habit of hesitating, and bouncing around on your back, when you deploy in a stable body position. (And who doesn’t want to deploy his reserve in a stable body position?) We learned to deal with this problem on main deployments by “sitting up” or performing other gymnastics at pull time. Problem is, because of my invention of the hand deployed pilot chute, many jumpers today have never had to deal with a spring loaded pilot chute, and don’t have a clue about how to “break the burble”.

So I set out to reduce hesitations on spring loaded reserve pilot chutes, and the all-fabric Vector II pilot chute does just that. Of course, I wouldn’t make that statement without proof, so I offer this video, made in 1986. As you will see, it actually inflates faster and hesitates a lot less than its mesh-bottomed cousin.

I would have responded to this nonsense sooner, but I was in the process of getting married, and had other things on my mind.

Watch the Video
** This is a large file, please allow the video to download before playing **
http://www.unitedparachutetechnologies.com/images/stories/videos/RPC.mp4

[Beatnik 2]

You have a nice video of the pilot chute in action but concrete proof it is not. You have your company's interests in mind and won't release a video that damages the credibility of its products. The video it self talks about your pilot chute and compares it against meshed pilot chutes. For it to be used as proof or evidence that the pilot chute works as great as is mentioned, the data concerning the other pilot chute used should be available. Also, if only one type of pilot chute was used in comparison, then it hardly makes the point that the pilot chute is better than all other designs. I have done a lot of research for many different things (many none skydiving related things but the same principles apply) and while this is a nice video it would never be considered as proof to someone who understands the statistical errors that can be made in research.

What I would like to see is an independent source evaluate pilot chutes and release what they discover. There has been some independent sources come forward previously that has brought forward results that are less than favourable and different than what others have claimed. That information I would be much more likely to believe.

I have nothing against your pilot chute and have seen a lot of information outside your company regarding it as there is another manufacturer that uses it. That said I don't have things against a lot of gear but there is some that I like better than others, which I will not mention here. I do have an issue with things like this being submitted as proof that it is better than other designs when there really isn't anything proving that.

[JohnnyMarko 1]

"A simple 'no' would have been fine, but ok"

[JohnSherman 1]

The hand is quicker than the eye. Look at the “M” in the lower corner of the altimeter; it is in meters and if you are familiar with the device, as am I, you will know it has an update rate of once per second producing a possible error of whatever the descent rate per second is. I recorded the altitude in meters from just before the reserve pilotchute became visible to a point where the slider is down. That is 660 meters down to 589 meters - a difference of 71 meters, which converted to feet equals 233 ft. The lagging update of 29 meters in a second (watch the update just before opening for this indicator), or 95 feet added to the 233 equals 328 feet. Additionally, I counted the frames for the same duration. I got 126 frames. At 30 (29.95) frames per second that is equal to 4.2 seconds. Applying Newton’s Acceleration formula of 1/2AT^2 + 2T with an initial Rate Of Descent of 20 FPS we get 322 feet.

The math indicates 322 feet and the altimeter indicates a possible 328 feet. Either way you look at it, this demo fails to meet the required 300 feet allowed for TSO certification. I’ll bet if there were a better/faster demo we would be seeing it.

Additionally, this video appears to be slightly accelerated. I am counting 24 frames per second instead of the normal 29.95 (NTSC). This is based upon the update rate of the altimeter, as it seems to be updating every 24 frames. Because video is “time accurate” we would have to advance the time lines by 25 percent to be time accurate. The test fails even without this time adjustment. But I can’t help wondering where those 5 frames per second went.

This video is but another attempt to “Bamboozle” the public. It does not answer nor does it address the nagging question of why did the Vector reserve fail on more than 3 occasions when the AAD was certified as having fired at 750+/- feet.

The military stated, upon completion of a fatality investigation, and I quote: "A drag force analysis of the [redacted] revealed that the solid nylon design; which constricts airflow through the 6-inch diameter base opening, produces minimal drag."

Here are my opposition’s pre-programmed and often-repeated answers to these facts:
“The military doesn’t know what they are talking about.”

“It just goes to show you can’t test a pilot chute in a wind tunnel.”

IMHO this is physics in the key of C

[SethInMI 146]

John,

I read your post, stepped the video through the two low-speed reserve deployments, and don't agree with what you saw.

The first deployment does start at 660m, but I see the slider down at 610m, and then the altimeter updates to 589m. I don't know exactly how the alti works, but I fail so see how you can tack on an additional 29m to the 589m value.

The second deployment starts at 600m and completes at 571m and then the alti updates to 545m.

I also don't agree with your math model. You are using a formula for constant acceleration but this is not a constant acceleration situation. The jumper will initially accelerate due to gravity, but then increasing drag from the deploying canopy will slow him back down.

I also don't agree with your math equation. Position displacement under constant accel is d = 1/2at^2 + v0t + d0. Ignoring d0 and using 20fps for v0, and 32fps^2 for accel, you get 368 ft drop in 4.2 seconds. But the velocity is now at + v0 or 155fps or 105mph. This makes no sense.

It's flare not flair, brakes not breaks, bridle not bridal, "could NOT care less" not "could care less".

[JohnSherman 1]

Seth
I am adding the 29M to compensate for the failure of the altimeter to update in real time. Splitting the hair of time, not exact but a reasonable assumption when dealing with a device that only updates once per second. By using 2 methods: counting frames or reading the Metric altimeter we can see by both your method and mine that the opening is in excess of 300 feet. I concede that your formula is more precise but I was giving the benefit of doubt. I only examined the first deployment. BTW: How do you explain the loss of 5 frames per second on the altimeter update?
John

[tdog 0]

John,

Just making sure your home is not made out of glass with stones in your own hand, can you upload video from your (or any other) container's testing showing altitude pulled and altitude deployed???

Regarding the alleged missing frames - it simply could be conversion from PAL to NTSC, compression methods used, etc.... With compression on the internet FPS (Frame Rate) is changeable, but the software knows how to play it back at the right speed...... However, it shouldn't matter how many frames are missing, if any! They all could be missing, so as long as you have the first and last frame showing the altitude and state of the container, since distance traveled, not time, is what matters...

Lastly, are you figuring that the updates on the altimeter are EXACTLY one second apart to determine "missing frames".... The altimeter manufacture could say their altimeter updates once a second in general terms, but it could update slightly quicker and thus make it appear the video was sped up... Only if that altimeter manufacture installed an internal clock, certified for measuring time before screen refreshes, can you use screen refreshes to determine time lapsed... The software for that would have to be pretty complex... First measure the altitude, calculate where it will be in a moment when the next process runs to update the screen, then update the screen exactly on the second... Why would they do that? Is this device calibrated to a precise clock?

[tdog 0]

Quote

Seth
I am adding the 29M to compensate for the failure of the altimeter to update in real time.

(forgive the fact I am going to be sloppy with physics terms. I am sleepy and making a quick post on the way to bed, but I hope the gist comes thru)

You are adding 29M to the final reading, because you assert some distance was traveled between the last refresh and the deployment.

But, have you taken into consideration the start of the cutaway sequence has some time traveled between the last refresh and the actual cutaway? And if all other variables (velocity towards earth) were the same, this error would be insignificant when a few sample jumps would be averaged out....

In other words, you can't add error correction to the ending reading without adding it to the beginning reading too!!! The cutaway happened lower than the indicated altitude, but so did the deployment!

Since the beginning reading will have increasing speed to earth due to acceleration, and the ending reading will have decreasing speed to earth due to deceleration, I bet the error correction number is rather small... I think the deceleration might even be with "more Gs", I.E. quicker than the acceleration, thus the error correction might help, not hurt, the feet/distance traveled in the calculations???

Forgive me if I missed your error calculation for the top end of the cutaway in your math....

[Sangi 0]

Ok so let me get this straight..

There were 3 fatalities (which I haven't heard of, where are they reported?) due to failed vector reserve pilot chute (unknown reasons why?), then Bill Booth steps in to say it's all BULLSHIT and then you guys complain that Booths video is BULLSHIT...

Only on DZ.com lol

Continue the drama.

"Dream as you'll live forever, live as you'll die today." James Dean

[Beatnik 2]

Quote

Regarding the alleged missing frames - it simply could be conversion from PAL to NTSC, compression methods used, etc.... With compression on the internet FPS (Frame Rate) is changeable, but the software knows how to play it back at the right speed...... However, it shouldn't matter how many frames are missing, if any! They all could be missing, so as long as you have the first and last frame showing the altitude and state of the container, since distance traveled, not time, is what matters...

I agree with you that there could be reasons why the frames are missing. I can't see why anyone would film with PAL equipment in the US. So I think that can be eliminated. You make a good point about the first and last frame but now the question is, do we have the first and last frame? I am not implying things here are that way but your post seems to try to backup the information in the video. All possibilities should be considered not just ones that favour the equipment. So lets add the frames could have been pulled out of the video to show favourable information. If there is going to be a list made, might as well put all the variables in.

Regarding your error correction post of 29m. I can't speak for anyone but it could be that number to compensate for the beginning as well. It really doesn't matter where it is factored in as long as it is in there.

29m = 95'

It isn't exactly going overboard with a correction and seems reasonable to me at least. Regarding the altimeter, before we go overboard making assumptions about it. Maybe we should get the make and model along with the specifications before making assumptions about it. It would at least bring more information to this debate rather than messing it up.

[antonija 0]

So the limit for altitude is 300 ft and the instrument used is accurate to 29 m (95 ft)? Is it just me or does this look very silly choice for measurement equipment? 30% error guaranteed?

I understand the need for conformity. Without a concise set of rules to follow we would probably all have to resort to common sense. -David Thorne

[diablopilot 2]

Quote

Ok so let me get this straight..

There were 3 fatalities (which I haven't heard of, where are they reported?) due to failed vector reserve pilot chute (unknown reasons why?), then Bill Booth steps in to say it's all BULLSHIT and then you guys complain that Booths video is BULLSHIT...

Only on DZ.com lol

Continue the drama.

Only on dz.com could you post like this to prove you don't know what you don't know.

----------------------------------------------
You're not as good as you think you are. Seriously.

[SethInMI 146]

Quote

Seth
I am adding the 29M to compensate for the failure of the altimeter to update in real time.

We can see by both your method and mine that the opening is in excess of 300 feet. I concede that your formula is more precise but I was giving the benefit of doubt. I only examined the first deployment. BTW: How do you explain the loss of 5 frames per second on the altimeter update?
John

John,

To the frames question, and math formulas: You missed my point. My point is, the formula you used was not correct for the situation. I think my formula was more correct than yours but it is also not correct for the situation, as both are for freefalling bodies, hence the note about the final velocity being 105mph (after 4.2 seconds).

To model the situation correctly, you would need to model the reserve deployment, which would involve drag force calculations, with coeffcient of drag, changing area of the reserve, etc. A method like modified Euler or Runga-Kutta would probably be used.

Without a proper math model, it does not matter how much time elapsed, as one cannot convert elapsed time to height lost without a good model. Simple as that, so frame conversions don't matter.

On the 29m: I saw several samples with the reserve deployed, that were less than the 300ft limit, so I don't think adding more distance for sample timing is required.

It's flare not flair, brakes not breaks, bridle not bridal, "could NOT care less" not "could care less".

[Beatnik 2]

I think it is silly to use an altimeter in meters when the standard in North America is feet (aviation wise). It also brings another factor into the data converting from meters to feet. That in turn creates a fudge factor where the results could be more pushed to a more or less favourable side.

The neat thing about the video is the psychological aspect of it. If you don't catch that the altimeter is in meters, most likely you would assume feet. Since there is no frame of reference to the ground there is nothing to make you think otherwise, you would think that the product in question works extremely well and far exceeds the normal parameters. The video is a great example for marketing, psychologically speaking.

[piisfish 136]

Quote

Ok so let me get this straight.....
then Bill Booth steps in to say it's all BULLSHIT and then you guys complain that Booths video is BULLSHIT...

not saying that John Sherman is right or wrong, but do you know who he is ?
He might have the background to analyse and give opinions on technical problems and solutions.
At least he has some credibility in the domain.

scissors beat paper, paper beat rock, rock beat wingsuit - KarlM

[SethInMI 146]

Jim (Beatnik):

I think you had a good point with the first post you made, that any sales video is not proof of reliability. I have helped make sales videos for my firm that involved multiple takes, so if I as an engineer saw a video for a product we wanted to use, I would not make a reliability judgment based on the video.

I think that any analysis of low-speed deployments in this video is of limited usefulness to you and John. There are two issues you are focused on are related to AAD fires:

1. Performance under high speed deployments.
2. Long term reliability/repeatability of said performance.

If this is the main concern, I suggest stop over analyzing the low speeds in that video and focus on a way to answer the two issues above.

It's flare not flair, brakes not breaks, bridle not bridal, "could NOT care less" not "could care less".

[chuckakers 370]

Looks like it's time for a CHUTE-OUT!! I say let's get these two pc's into a wind tunnel (prepped properly for flying objects, of course). 10 out of 10 launches, on video, with every high-tech whiz-bang devise y'all wanna bring to measure all the math.

Winner gets a case of beer from me. Loser jumps the winner's rig for a year.

That oughta shut someone up. The only question is who?

Chuck Akers
D-10855
Houston, TX

[tdog 0]

Quote

I think it is silly to use an altimeter in meters when the standard in North America is feet (aviation wise)....

That in turn creates a fudge factor where the results could be more pushed to a more or less favourable side.

1. Lots of instruments designed to measure with scientific accuracy are only in metric units as that is the unit of science. In the 80's, a digital altimeter with documented scientific accuracy might have been only available from the scientific market?

2. The conversion from feet to meters has zero fudge factor. You can convert with 100% accuracy of the measurement. Whatever accuracy, (significant figures/digits, in scientific terms) of the metric measurement can be converted with absolute precision to feet, as we know exactly how many feet are in a meter.

3. Last I checked, UPT (back then RWS), sold internationally, and thus had to market, test, document, and sell using both metric and English systems... Booth could have decided all testing would be in Meters for certain products, or he could have made this video for European customers and recycled it for North American, or countless other reasons...

I think it is difficult to call silly the choice of metric units without asking why first! Although I would agree, Booth and team could have, and probably should have, said the altimeter measured in meters when they showed the mirror and camcorder in the video.

[davelepka 4]

Quote

I say let's get these two pc's into a wind tunnel (prepped properly for flying objects, of course). 10 out of 10 launches, on video, with every high-tech whiz-bang devise y'all wanna bring to measure all the math.

The problem with that idea, and this whole argument, is that wind tunnels are designed for meansuring factors at constant speed in clean air, and as we all know, reserve PC launches are in anything but.

Between high speed, low speed, clean launch, or burble interference, there are a wide variety of circumstances that a reserve PC might encoutner. While one desigh might work better in one set of circumstances, the other might be the better choice for a different circumstance.

The real test for these would something on the order of 20 low speed deployments (like just after a cutaway from a stable main) and 20 deployments from terminal for each PC. This would give you a reasonable sample size from both low and high speed deployments to let the variables other then airpseed hash themselves out.

The real problem is finding someone to do the 80 test jumps rigged up with video and test equipment, and an outside video guy. So far I'm up to 160 slots, and 80 reserve pack jobs.

The up side is that the test jumper can use a chest mounted tersh resereve, and stuff a Velocity into the freebag. All were looking at is time to bag strip, so the canopy has no effect on the test, and hey, built in RDS for the swoop.

[chuckakers 370]

Quote

Quote

I say let's get these two pc's into a wind tunnel (prepped properly for flying objects, of course). 10 out of 10 launches, on video, with every high-tech whiz-bang devise y'all wanna bring to measure all the math.

The problem with that idea, and this whole argument, is that wind tunnels are designed for meansuring factors at constant speed in clean air, and as we all know, reserve PC launches are in anything but.

Between high speed, low speed, clean launch, or burble interference, there are a wide variety of circumstances that a reserve PC might encoutner. While one desigh might work better in one set of circumstances, the other might be the better choice for a different circumstance.

The real test for these would something on the order of 20 low speed deployments (like just after a cutaway from a stable main) and 20 deployments from terminal for each PC. This would give you a reasonable sample size from both low and high speed deployments to let the variables other then airpseed hash themselves out.

The real problem is finding someone to do the 80 test jumps rigged up with video and test equipment, and an outside video guy. So far I'm up to 160 slots, and 80 reserve pack jobs.

The up side is that the test jumper can use a chest mounted tersh resereve, and stuff a Velocity into the freebag. All were looking at is time to bag strip, so the canopy has no effect on the test, and hey, built in RDS for the swoop.

Either way, I'd like to see a side-by-side comparison with conditions and measuring techniques both Bill and John agree to. And I'd LOVE to see one of them diving out the door with the other's rig on.

Chuck Akers
D-10855
Houston, TX

[zoobrothertom 5]

Quote

Looks like it's time for a CHUTE-OUT!! I say let's get these two pc's into a wind tunnel (prepped properly for flying objects, of course). 10 out of 10 launches, on video, with every high-tech whiz-bang devise y'all wanna bring to measure all the math.

Winner gets a case of beer from me. Loser jumps the winner's rig for a year.

That oughta shut someone up. The only question is who?

Nice one Chucky! I'm with you!

____________________________________
I'm back in the USA!!

[phoenixlpr 0]

Quote

The real problem is finding someone to do the 80 test jumps rigged up with video and test equipment, and an outside video guy. So far I'm up to 160 slots, and 80 reserve pack jobs.

You can use a freebag on the main tray with a ripcord and a reserve PC, so no need for reserve packjobs.

I got one reserve ride with a VectorII gear. It was a low speed and I'm 100% satisfied.

[Sangi 0]

Quote

not saying that John Sherman is right or wrong, but do you know who he is ?
He might have the background to analyse and give opinions on technical problems and solutions.
At least he has some credibility in the domain.

You're right, I don't know him. My bad here.

Anyway, I have a Micron on order and since this a very disturbing topic, should I be worried about this reserve PC problem (what exactly is the problem, doesn't the PC work properly, is it prone to extreme hesitation?), if I should, any solutions you peeps could suggest?

"Dream as you'll live forever, live as you'll die today." James Dean

[davelepka 4]

Quote

You can use a freebag on the main tray with a ripcord and a reserve PC, so no need for reserve packjobs

On the low speed deployements, yes, provided you were cutting away from a stable third canopy.

For high speed tests, you need the PC leaving from the correct location, and pulling the freebag out of a container with a packed main, so you would need to use the reserve tray for those tests.

Part of the test is looking at launch, and getting the bridle stretched out, the other part is looking at the overall drag of the PC when doing it's job of extracting the freebag and getting it off the canopy.

Even with the number of reserve pack jobs cut in half, it's a big project that isn't going to happen. No manufacturer can be involved, so the whole thing would have to be funded by an impartial third party. While I imagine that a lot of people would be interested to know the outcome, unless there was some sort of action to follow the results, nobody is going to be that interested.

Who issues the TSO? The FAA? They're the ones who could pull a TSO, or call for a redesign, so they would be only ones with an interest in conducting the testing. I don't see that happening anytime soon, and I'm not even sure I want to see the FAA get that involved, it's a slippery slope.

[danielcroft 2]

Discussed at length in the other thread on this topic. http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=3833943

Cliff notes: when you do your next repack (or sooner if you're concerned) have your rigger watch you run your EPs but then they should also use the reserve PC to extract your reserve from your rig. This should be done with your main still packed and in the container.