df8m1

Attached are three pics of a fired blade and anvil. Anvil material is 17-4 SS at 34Rc. Blade is 440C SS at 58Rc. Also a pic of an assembly view of the finial design cutter and a pic of the body by itself.

At some point I will. With this first batch of cutters I was testing different cylinder materials, and loop hole / grommet face geometry, but the cutting aspects were the same (same blade material, hardness and geometry). For some tests, I turned the blade as much as 30 degrees off perpendicular to the loop, some the loop holes were in slightly different places / sizes, etc.. The last version (not in the video) was shaped to help with rigging. My intent was to reuse the blades, but it is too much of a PIA to get them out once they are fired lol.. The blades hold up well. If I think about it I will take a picture of a used blade. Now that I am happy with the cylinder material and, internal / external aspects, I will make more blades and cylinders based on the last design, and evaluate overall performance in a rig. I will also make more videos from different angles, put them together and up load them to YouTube. I just thought people would appreciate a sample vid.

Gotcha.. Yes, it is a single edge cutter like the Cypres and I also believe that MarS is now using a single edge cutter as well. I posted picks of my blade a few posts back. Also using a standard gas generator for power just like the other cutters out there. My cutter has some features that are different than the Cypres cutter, they are minor, but were done for a reason.. I will get more into that in time.

So far that is the only video that I was able to get bellow 1MB that showed anything lol.. What is it that you specifically want to see that this video does not show?

Finally got a chance to play with the cutter. DZ.com only allows a max of 1Mb file and I was able to shorten the video but it is really quick! 139_cut.avi

A larger diameter at the same pressure generates more force. From a failure mode aspect, if the pyro cartridge should, for some reason, not generate full pressure, or one of the seals fail, I want to have some margin built in. It will be interesting to see how low the pressure can be and still cut the loop at zero loop tension. It also allows for larger seals to be used. I am using quad rings instead of traditional 0-rings. Some of the tests will be done with only using one seal.

IIRC, the problem manifested when the closing loop did not go straight through the cutter. The blade would first strike the top (or bottom) side, causing it to tumble slightly, then jam on the opposite side because of misalignment. For Argus, the size of the hole compared to the diameter of the cutter body is not that different from Cypres and Vigil cutters. I do not recall a grommet strike being identified as an issue in any of the problematic incidents. -Mark There was another incident here in the USA where the Argus blade hit a grommet and failed to cut the loop. As I recall, there was a witness mark on the grommet that was on top of the cutter. Kirk Smith of Para Concepts did some independent tests and reproduced the blade strike failure. His report is on line somewhere.

All tests will be at zero loop tension. A consistent, clean cut is the requirement with the loop just laying in the cutter.

Make sure it is hard enough. Argus' blade was not... See the whole report (in English) here: http://mib.gov.pl/mediakomisje/archiwum/2009562RKPKBWLang.pdf . Very aware of the Argus cutters. The Argus blade design, (cylindrical), and the large hole in the cutter body allowed the grommet to drop down into the cylinder, so the blade would strike the grommet before the loop. That type of blade edge is very thin and delicate, prone to bending. My blades are made from 440C Stainless and hardened to RC 58-60. The blade design is the same as chisels which are made to cut by blunt force. One of the tests I would like to do is to thread a loop through the cutter, suspend the cutter in a container and fill it with steel shot so the cutter is buried, then fire it. I have no expectations for this test, purely curious to see if the blade will push the shot out of the way and cut the loop. This test will be conducted within a bullet proof enclosure in case things get interesting.. Safety first....

Prototype cutter blades ready to be hardened, then the cutting edge lapped. I would like to do some cutter tests later next week. Note: the blade on the right is a Cypres cutter blade for reference.

It is packed up in the reserve properly, but the loop is not through the cutter, instead the cutter is super tacked to the cutter bungie so it wont go anywhere or be able to cut the loop, but is there as a static antenna lol.. We wont go live on a jump with a real jumper until we are in Beta. Luckily there are some brave dummies who get to do the first live drops :) I am using the data collected by the actual device while packed up in a reserve so I can run it through the simulation and optimize the algorithms and settings. When we get to the Beta phase, the first units that we send out to the test jumpers will have the fire controls turned off, and cutters with a hole only in one side of the cutter, and the "blade" will be a slug so to speak. The purpose is to allow a visual inspection of the piston to see if it had fired from static, but will not allow a rigger to put the loop through the cutter. This is why I will only consider test jumpers who do not have an AAD in their rig. Once we get the wingsuit, and swoop data and validate the algorithm settings with it, and we have verified proper operation using dummy drops, we will send out units with active fire controls and real cutters... If the jumpers want to jump them at that phase that is :) If you are asking me if I have an Active AAD in my test rigs? The answer is no.

So I have a minute and thought I would post an update. We had what seems like our last really nice weekend a couple of weeks ago and I was able to get a few jumps in with the new AAD. Special thanks to Skydive Tecumseh for their indulgence and help. This was the first time a prototype has been off the bench and out in the field and it is very obvious that the interface screen will not cut it. I is very visible until it gets out in natural light lol... One of my team members said that if this is the biggest problem we have we are doing good and I agree with him.. No matter how much testing we can do on the bench, there is only one way to know what something is going to do in the air, so you have to jump it. We discovered a OS problem that showed up after the first jump. It actually would only show up after the first jump each time it was turned on, and affected the data recording process.. It was a simple fix, and is part of the validation process. I was really pleased with the data that was recorded. I am making refinements to the flight mode and firing algorithms and am very happy with how they are working. There is always room for tweaks here and there lol... I was most pleased with the altitude readings taken by the sensor in the interface. I am waiting to see what it looks like with a wingsuit, but I am leaning toward not "correcting" the altitude, from the interface anyway, as it really was a lot better than I had expected. Now the "black box" pressure varied like I expected it to, but it is not used as the primary sensor for this application. Not having to correct the altitude eliminates some complexity, and I am all for that! We will be jumping when and where we can over the winter collecting more data and dialing this thing in. We will also be pitching out dummies with a live AAD when we can. The Army wants 45 sequential successful drops using 250 lb dummies and I can't say I am looking forward to that... It is a lot of work lifting those things! lol. Oh! we also are looking to test in a vertical and horizontal wind tunnel which should be fun. That is all I have for now.

That's a phase of flight that if I recall correctly has set off AAD's of different types with no authoritative explanation why. We've sometimes heard ideas kicked around that sound plausible but who knows. In particular, the idea of the swooper losing speed during the pullout & planeout, results in a lessened burble, which equals a suddenly increasing pressure which equals a sudden drop, activating the AAD. Or it could just be the AAD reacting to a high dive speed in the middle of the swoop but taking a little while to filter & confirm the speed before popping the reserve pilot chute, which then appears when the swooper has partially planed out. Various aspects of those scenarios are debatable. But I've still never seen a good explanation of such situations. So that last hundred or few hundred feet of altitude is a bit mysterious.... Sorry for not properly addressing your comment on the AAD being turned on at another location. Your second comment on a different landing elevation is valid and not a problem. Even if the drive is up a really steep and long hill at high speed, which could cause the this AAD to stop updating the Ground Level Reference Pressure, the conditions required to put it into Airplane Mode would be, I won't say impossible because there is always someone up to the challenge lol, but it would be a Pikes Peak drive to do it. Now if the Airplane Mode requirements are not met in a period of time, then it will resume updating the Ground Level Reference Pressure, which will adjust the ground pressure to the current location. In theory all AADs should do this, but I suspect that some don't do it very well. I just do not want to say, "with this AAD you can do X which you should have been trained not to do".. The more we overcome stupidity, the dumber people get lol.. To your comment on the 100ft disarming... There is indeed something different about the last 150ft (ish) depending on temperature and humidity. We have data from a near terminal fatality and the density right of the ground is very different than say above 150. Without question, the last 50 feet is different.. That change in consistency lets call it, can really cause a change in what the AAD perceives compared to what the jumper is really doing.. I have had more time to think about why I feel the need to have a hard disarm altitude, (I have never thought about why, as it makes sense to me lol) and have found some additional benefits aside from the very challenging and inconsistent conditions that can exist during the final phase of landing. Every algorithm has to be able to be tested individually, and when nested with others to work in a phase of flight. I would have to create a new matrix just for the landing phase which would be very challenging and IMO provides no benefit to the jumper at that point in the flight. That being said, the digital testing could be developed and done, but then comes the field testing.. We use drop test dummies to test the firing algorithms in the air. We will use dummies on the front of a tandem and cut them away to simulate a cutaway at different altitudes, and pitch them out above 1250ft while rigged to fall at different rates to test out the firing altitude calculations and firing command algorithms.. We would have to do the same thing with the landing phase if the AAD were still armed at that point.. Additionally, having a well defined arm and dis-arm points makes a nice little box with limits that I can test beyond to see if something happens when it should not. I am glad I was challenged on it, and think that bringing down the disarm altitude to 100/150ft is a reasonable compromise as it still provides me what I want, and if it makes some jumpers happy, then it is a win win. There are several things that I have done based on data that we have, like the landing anomalies, that is not common knowledge. Even though I am not providing all the details as to why I am doing what, I think I can say that this level of access during the development of an AAD is unprecedented lol.. and I think it will result in a better product.. After the last conversations, I am now questioning if it should display the calibration pressure, because some nitwitch will compare it to a barometer that is not certified or has not been calibrated ever and will freak out because the two readings don't match. They wont trust that the error detection will catch a problem but will trust the $.99 dollar store barometer lol.. It is like displaying the battery voltage, causes nothing but trouble..

A zero altitude on an AAD isn't a way to tell whether the pressure sensor is reading accurately. (It could catch some errors, but not others. It could have pressure sensor problems but chose to consider that wrong value to be ground level.) But it does have some usefulness. At least helps understand what mode the AAD is in. "Does it think I'm still airborne? What about that car ride to the DZ? Has it updated recently for weather changes?" That's a issue for AADs. Mrubin.. Although the idea of displaying the altitude does make sense, the problem is it never reads 0... The only place where it could possibly read 0 is at sea level when the pressure and temperature match the standard level for each.. So then the next logical thought is, "well then display the DZ altitude".. but there is a problem with that too.. The AAD reads "Pressure Altitude" just like an altimeter does, and as the barometric pressure changes during the day, so does the "perceived" DZ altitude. That is why aircraft altimeters have an adjustment for pressure, which they are always adjusting based on what the current pressure is. So the easiest reference value is barometric pressure in Hg, which any digital barometer will display. In reality, an AAD does not care what the actual DZ altitude is, but rather what the pressure is at that location, and it uses a formula to calculate the altitude based on the change in pressure from the pressure at that location. When you off set the landing altitude, you are not actually changing an altitude value... what it does is convert the 200ft offset you entered, into the difference in pressure at 200ft from the take off pressure.. Pchapman, After the this AAD has been turned on and the modes set and yada yada... when the jumper pushes the button during the prejump gear check, it will first display the Ground Level Refference Pressure and when it was taken, then it will display the aircraft mode that it is set to, (I have not gotten into that yet), then it will display the jump mode it is in. After take off, if the button is pushed it will say "Aircraft Mode" (which one it is in), and display the current AGL altitude, then it will display the which jump mode it is in. Then it will go dark. The only option while in flight is to turn it off, after take off, you will not be able to change the aircraft or jump flight modes. I have no idea why anyone would turn on their AAD and drive to the DZ, but they do..

You bring up a good point, and that thought has gone thorugh my head, but it kept going lol... I don't want to get in to detail about how I have the logic organized and working, but the "disarming" point is not an separate subset of commands, so there would not be any saving s of any significance. Having thought about it as I was doing other things today I realized I may have some form of OCD lol.. For some reason, and I don't know why, but i feel the need to shut down functions when they are no longer useful. Now you have me analyzing myself! lol I am pretty sure you are not advocating bringing the lower full open reserve canopy altitude down from 300ft, but rather, allowing it to fire if a jumper cuts away between 300ft and the ground? That is where my OCD is kicking in lol... I am fine with allowing it to fire in the event of a cutaway bellow 300ft, there is a voice in my head that wants to disarm it at 100ft at least, and I will try to enplane why.. The algorithms are designed around canopy flight and events that can happen between the plane and the ground... Where I get uncomfortable is the touchdown aspect of the flight. I keep seeing a picture in my head of a pilot punching it out and popping way up, practically stalling, and then then taking the down elevator to the ground.. And it is not that I am "significantly" concerned about the conditions mimicking a cutaway or in some way fooling the algorithms, but that is why some hot canopy pilots are going to put it through its paces :).. To your point of not having extra code addressing unnecessary aspects, I think having to add pre-touchdown and touchdown conditions to the matrix would do just that. I will meet you 2/3 of the way and set the disarming at 100ft :). That just makes it simpler to not have to test for conditions where the reserve is worthless anyway. Does that make any sense? lol Yea... I'm thinking that there is exactly 0% chance of getting your average skydiver to do this even for just the first jump of the day. Most people don't even look at the AAD before each jump if it's hidden under a flap. If you really want to alert them to any kind of malfunction after the start-up sequence, I think emitting a sound is about the best you'll be able to do. The next step would be to send an alert via Bluetooth to their phone once your app is ready (and then you may as well have your app pull the METAR data from the nearest airport based on the user's location and compare the pressure readings automatically)

Good points! The upper target for a fully open reserve is 500ft AGL and the firing altitude is determined by the descent rate of the jumper and the TSO 3 second requirement. In reality, the reserve should be fully open above the target, which leaves some cushion for slower opening reserves and or problem with deployment as you mentioned. Lets say that the RPC hesitated bad and delayed freebag extraction for X seconds, the air between 500ft AGL and the ground is still available for the reserve to open if needed. In order for the 300ft fully open reserve altitude to be calculated, there must have been a main deployment. So there will have been something out, slowing them down some what. In the case of a bag lock (high speed) it would calculate the altitude, while falling at the current speed, necessary to have a fully open reserve by 300ft AGL. You bring up a good point about the 300ft disarm height. I can make it anything I want, and nothing is etched in stone at this point, so if an argument can me made that a lower disarming altitude would be better, then I am open to listening :). Where the 300 ft comes from is that is the PONR reserve canopy fully open by target. As you also pointed out, there needs to be some "extra runway" if the reserve is slow or there is a problem. This lower hard deck is for when the jumper is dealing with a malfunction, or to put it another way, things are not going to plan if the PONR firing altitude is calculated, and I am uneasy about reducing the cushion to be honest. If the jumper has a malfunction with a descent rate below 35M/Sec, and rides it to the ground, then it will not fire. Right now I am waiting 3 seconds from when a cutaway is detected to when I declare a cutaway, so if in the case of the jumper riding a mal with a descent rate bellow 35M/Sec down, and then chopping at 300ft, then it will fire bellow 300ft but only 3 seconds worth of descent. That is what is behind my current thinking, and I by no means think that it is perfect. It is critical that this kind of peer review takes place, because the more people thinking about all the different situations that are possible, and then challenging me with them, can only result in a better end product. Everything I do, or don't do, is based on something other than "another manufacturer does it that way". I am sure they have their reasons as well. I am interested in discussing what the "best" disarming altitude should be. I would be very interested to see how low a reserve deployment at bellow 35M/Sec can be before there is no chance of it getting out of the bag. So hypothetically, if you do an XRW jump where the canopy pilot and wingsuiter dock and then spiral down to 1,000 ft, the wingsuiter's reserve will fire, but the canopy pilot's will not? I am trying to picture what that configuration would look like.... Do you mean a wingsuiter is flying straight and level, then a canopy pilot comes in above him and settles down on top like a rodeo? Then the canopy pilot induces a turn and the wingsuit and canopy pilot spiral down to 1000ft? If so, my first thought is that is not a good idea lol... Regardless, to answer your question. Yes.. sense the wingsuiter will still be in flight configuration (the fact that someone is docked on his back does not affect that), and a main deployment has not been detected, then when they hit 1000ft, it will fire. My thoughts on this situation may seem cold, but anyone using an AAD needs to understand the conditions in which it will and will not fire. Vigil reports the current pressure reading (QFE) and you are supposed to convert and compare it against the sea-level pressure (QNH) reported by the nearest AWOS station if a calibrated barometer isn't available (Vigil Rigger Manual, p27): Note that +/-10 hPa = 0.296 inHg = 296 ft. That's a pretty big margin of error, if you ask me, which is another reason why I wonder about your choice of 300 ft. I check mine at every reserve repack and the most recent error was 30 ft. I thought it was Vigil... you have measure the pressure at the DZ. The pressure readings at different locations can vary that much, which is why they put that tolerance in there. My programmer did the same thing.. He said that the baro sensors were way off, I said what are you basing that on. He said he was using weather service pressure data or something (that was a while ago lol). I compared the sensor readings to the calibrated pressure readout that I calibrate my altimeters to and it was with in .02 HG with out being calibrated. (the soldering process stresses the membrane, so to get it dead nuts after the boards are assembled, the senors have to be calibrated). This AAD also has two barometric pressure transducers. One in the interface, and one in the ECM (black box). This allows us to compare the readings of the two and provides a back up if the primary one has a problem between exit and the ground. My point to checking the Ground Level Reference Pressure, as I call it, is to know that the AAD is adjusting for weather changes, just like we have to zero our altimeters throughout the day. In addition to displaying the Ground Level Reference Pressure that is stored and the AAD uses to identify there the ground is, it also tells you how long it has been sense it was last checked. (how old the reading is). So during the prejump gear check you push the button, and the AAD wakes up, and displays the stored pressure reading in Hg, a format that is easy compared to digital barometer, and it also tells you how old the reading is. If the reading is older than it should be, then the AAD is not updating the Reference Pressure, which could result in impacting at line stretch after an AAD fire. Or, if the pressure reading is too far off, then there is a problem, causing the potential for impacting at reserve line stretch. (if the main pressure sensor differed too much from the secondary, then it would through a fault code.) There is a tendency to try and cover every conceivable instance when there is the "potential" to do so, and that often is in conflict with keeping if from being overly complex. We are going to continue to rely on traditional training and protocols like do not turn it on at home and then drive the the DZ... Do not turn in on in the plane (this is for the sport AAD, the military one can be turned on in at altitude). If two people want to operate outside the range of "excepted best practices" then the idea that there may be some conflicts that will not end well should not be a surprise lol.. Every DZ I have been to requires wingsuiters to be in the saddle by 2K.. But I am sure any discussion about the merits of going lower will be entertaining :)

There have been a couple different case design concepts based on battery capacity / type. Here are two pics for a comparison of the current case to a Cypres 1. This case fit nicely into a standard AAD pouch. It is the batteries that dominate the physical design constraints, and my goal was to get two years / 500 jumps out of a set of batteries based on power usage estimations. It has three ER18505M cells in parallel. Only real life usage will tell how well the batteries do and how well we handle power management. When this thing is at full power, it is doing a lot of work and is going to use more power than any AAD currently available, and there is no way to get around it. You are correct that the natural evolution of hardware and design will promote more efficient designs. During the testing of the Rev-A design, we have identified several changes that we want to implement in the Rev-B design. All are related to peripheral aspects and not the business side of the AAD, which is what we are testing now. I am very excited about how this is coming together. I really want to get some jumps on the one we have packed up! The decision to self-fund has slowed the rate of progress, which is frustrating, but much less frustrating than development time being limited by deadlines set by venture capital schedules. I want to get this right and if it takes a little longer than I want, then so be it. This thing can tell if you are on the ground, or in the plane, in the plane or have exited, are in free fall or are in a wing suit, if have deployed your main or not. It calculates the firing altitude based on your speed and when the reserve should be fully open by, which is 500ft AGL if there is no main deployment, and 300ft AGL if there was a main deployment. The firing altitude window is 1250 ft to 1000 ft at a speed of 35M/Sec and faster for free fall jumpers. For a wingsuit if you enter the window and no main deployment has been detected and you are still in wing suit flight mode, then it will fire. (Each condition by itself is detectable to a very high degree of confidence; together the confidence level is even higher) Once a main deployment has been detected, the firing altitude is calculated based on a 300ft AGL fully open reserve altitude, which is what I call the Point Of No Return altitude, which is meant to delay firing the reserve as long as possible allowing either the main to open if dumped low, or the jumper to deal with a malfunction with a descent rate above 35M/Sec before firing the reserve into the mess. In reality, depending on the speed, the difference is only a few seconds, but that time could be the difference between a two out and or a double malfunction. It can detect a cutaway and if the Reserve has deployed or not. If the jumper cuts away above the upper hard deck (1250 ft AGL), then the firing altitude is calculate based on a 500ft AGL fully open reserve altitude. If the reserve has deployed before the jumper reaches the calculated firing altitude, then no fire. If however, if the Reserve has not been deployed by the time the jumper reaches the firing altitude, it will fire. If the jumper cuts away with in the window of 1250ft AGL and 300ft AGL the PONR firing altitude will be calculated, (again based on the descent rate of the jumper), and if the reserve has not deployed by the time the jumper reaches the firing altitude, then it will fire. If they are really low, it may very well beat the jumper to it. Once bellow 300ft AGL, it will not fire regardless. It can tell if you are flying a wingsuit or are under canopy, and if you are under canopy it will not fire regardless of speed or altitude. It is only after a cutaway and only above 300ft AGL that it will be able to fire once you are under a main canopy. This AAD will allow you to confirm that it is calibrated to your elevation, just like you check to be sure your altimeter is zeroed before each jump. I think every AAD should display the barometric pressure that is referencing as ground level, and that every DZ should have a calibrated digital barometric pressure readout that the jumpers can compare their AAD calibration to. I think there is already one AAD on the market now that will let you see what pressure it is calibrated to but I am not sure. It is my opinion that an AAD, regardless of type, should be checked for operation and calibration before every jump. This AAD has a Bluetooth module and we are working on an app that will allow the jumper or their rigger, if they choose to do so, to upload the results of the selftests so we can monitor for any potential problems, and alert the jumper before they become problems. Only the selftest results would be uploaded, none of the jump data would be accessed. This is what many of the auto manufactures are doing now as it allows the manufacture to monitor how the product is doing without inconveniencing the owner or waiting several years to find out there is a problem that has been present for a year. Each of these capabilities requires a lot of testing to validate that the algorithms are working as intended. It is my goal to have the alpha testing done by this spring / early summer, however that schedule is fluid. Once we have at a certain level of confidence, we will be seeking funding to bring it home and to market. We are focusing on the military version as the US Government is looking for Enhanced AADs, and they are look at ours. The military version will have some features that the sport one does not, and the sport one will have features that the military one does not, but the hardware will be the same. This AAD is a departure from the traditional AAD, and I understand that some will not be comfortable with that, or even think it necessary. There is nothing wrong with that thinking, but they are not who my team is build this AAD for. I am very curious to see if any of the other AAD manufactures add any of our capabilities into their AADs in the future. We are at the beginning of the fun part of the process and I am looking forward to the day we are ready to release our creation to the world. If anyone has any questions, please do not hesitate to ask. I will do my very best to answer them without sharing any trade secrets.

I thought I would post an update as it has been a while. The Rev-A prototype is packed up in our test rig and weather permitting I will be jumping it on the 7th. Even though I have set artificial timelines for specific phases of the development process, the determining factor has always been performance and quality, as I have said before; the AAD will determine when it is ready for release, not a date on a calendar, and I am pleased with the results of this philosophy. My team is not afraid to scrap several months of work and start over with the benefit of lessons learned. I would like to do some cutter tests later this month and will post some video afterwards. Right now I am working on the burble compensation algorithms. There are many layers to the decision making software, and we are knocking them off one at a time. We are learning as much as we can out of the Rev-A design, and have compiled quite a list of changes and improvements that we want to implement in the Rev-B design which I would like to have done by next spring. Once we are no longer identifying things that need to be addressed or could be better, we will be contacting those who have offered to help with the Beta testing. I would like to thank everyone who has offered their support and encouragement.

You are taking the list to literary.. It was to represent that there are influential aspects that can be recreated, which may or may not have a negative affect on the ability for something to do what we want it to, which may very well be different than what it was designed to do.. The actual scope of influential aspects are very unique / pacific to the actual test subject and the scope of the test. My comments were in regards to how I would hope the manufacturer of my container would react after being made aware of this situation, whether it was designed to deploy in a back to earth orientation or not, ( it is possible that it may not have been which as has been pointed out). In reality, it may very well be performing exactly to the manufacturers design intent, and if so, perhaps all it needs is a note in the user manual stating that pulling the reserve handle in any orientation grater than 20 degrees off of belly to earth may result in a lack of free bag extraction?.. But to perceivably ignore the apparently multiple examples of the same scenario (which they very well may be on top of it but has not let the market know) is not a good way to handle it IMO. But we are talking about a very specific condition in this case. I agree with you and mentioned as such in the last lines in my previous post "It is impossible to test for every conceivable scenario, however, when one is experienced in real life, I think it has to be dealt with… " Test orientation at time of reserve handle pull: back to earth... I'm not saying that the manufacture should get distracted by testing any other conditions unless they pop up as this one did. They may be well at work evaluating pilot chutes, corner construction, pack volumes, etc.. The image of it not being addressed does not look good considering that most of the world thinks we are dare devils with a death wish and have no regard for safety.. there has to be some way that a manufacturer can acknowledge their customers concern without being driven out of business... Maybe not..

If I manufactured containers, and saw a video of my system doing what yours did, the first thing I would do is say " I want that rig to test", and offer you a new one of your choice in exchange.. My goal would be to see if this "situation" could be repeated, and if so, how consistently… Considering I would already have the exact components that were involved in the original “situation” we can dispense with the canopy size, container info, etc… What I would want to know is: 1) How many days between the last repack and the handle pull? 2) What were the environmental conditions and duration of the “airing” phase of the Air and Inspect phase? (Temp / Humidity) 3) What where the environmental conditions during the actually packing of the reserve? 4) What were average environmental conditions during storage/use between the repack and handle pull? 5) Weight, build, and jumpsuit type? (to try and recreate free fall speeds) 6) Length of the reserve closing loop? 8) What patterns were used to make the container 9) What lot of material was used? 10) Who built the rig? 11) Ideally it would be nice to have the same rigger pact the reserve for the tests, but I could see how that could be touchy, so experiments in bulk distribution would have to be done to try to “encourage” the “situation” by creating a worse case scenario. I’m sure more specifics will come to mind later, but these are the ones that come to my mind right now.. The last thing we want is to have the FAA get involved IMO.. They do not have the time to deal with us, and I can see them saying “If the FAA is going to be responsible for overseeing the operational functionality of all skydiving gear, then we are going to ground every rig until such time is available as is necessary to properly carry out the requirement”.. This is also a very touchy area with container manufactures, as if something like this is able to be reproduced consistently, and the specific causes identified, then at that point, how the manufacturer handles it will be critical.. and if there has been a fatality in the past associated with the problem area, then that is a whole new world.. However, I feel that life is more important, and safety should always be the deciding factor. Even if there was a problem that was later identified, that was not during the TSO tests because the TSO tests did not create the conditions that are required for the “situation” to occur, that “may” not mean the manufacture was negligent or liable for any fatalities. However, could it be shown that the manufacturer was aware of “similar situations” in the past, and they made no effort to first inform users of those rigs that there “may” be a problem, and at least make an attempt to resolve the issue, then there may be a problem for the manufacturer.. As the saying goes,, “You can’t put the shit back in the horse” I can see why manufacturers could not really want to know how the “variations” of the original TSOed rigs perform in the real world.. I’m not saying that they don’t, it is just a delicate subject as a whole.. Aside from a couple of manufactures, most are in reality micro companies, and would not be able to survive a storm.. That being said, ones size does not absolve one from being proactive when “situations” present themselves.. I have had several discussions with my business partners and other manufactures about performing independent tests, as we have design and built data collection systems that the USDA Forest Smoke Jumpers and BLM use to aid in the development, evaluation, and refinement of their gear. There is an “learning period” where one has to get past what they “know” to be true and let the data show them what is really happening.. The problem, as was pointed out, is a financial one.. I have reserve pins that I want to do some bend tests on, but the problem is, I have bills to pay, and the time it will take to properly design, build, and calibrate the test protocol and fixtures is not billable to anyone, and my investors do not like that, as I could have been working on actual billable work.. Add to that, that the manufactures are really not keen on anyone looking for skeletons in their closet, and it is a non starter.. So the issue becomes, how do we as a self-governing body, deal with “ performance situations” when all there is, is a voluntarily group made up of competing manufactures, who are all fighting for the same limited market? Add to that the “politics” of the landscape and the hill quickly turns into a wall.. If every time there is a “situation” like this, where gear did not perform as one would like, (which may not be required in a TSO speck), the complete rig was acquired and kept for testing and put in a safe pace, eventually there would be several rigs from different manufactures in the safe that can be physical compared side by side.. I mean if my rig did that once, I sure as hell would never give it the chance to do it again.. So instead of it sitting in my closet or burning it, I would think it would be better used as a test subject to help our gear evolve.. It is impossible to test for every conceivable scenario, however, when one is experienced in real life, I think it has to be dealt with… The question then comes down to, does the FAA deal with it, or does the manufacture?

Try cutting a wire or cable with a pair of side cutters and the try to cut Cypres loop with side cutters.. I do not know of many people that have reserve closing loops made out of wire or cable lol... I just mean although cutting cable looks impressive, it is not a good test for a cutters ability to cut a closing loop.

That test standard is for the cutter and reserve container opening interaction, not the "black box" operation. What I am talking about is a method to confirm that an AAD fires (performs) as the manufacturer states in thier user manual or any published materials. For example, if the manufacturer states the the AAD firing window is from 1000 ft AGL to 750 ft AGL at or above a descent rate of 78 MPH, and in reality it fires within that window up to 100 MPH, but starts to fire deeper as as the descent rate is increased above 100 MPH (this is just at hypothetical)... Other things to test for are consistency between units, Automatic barometric pressure calibration updates between jumps, Accuracy of the data the AAD records, (for example the AAD said it fired at 1000 ft, but in reality it fired at 1200 ft or 800 ft) which relates to incident investigations (are the AAD fired and impact at reserve line stretch caused by an accuracy issue?). Keep in mind that the AAD manufacture would be allowed to make the AAD do what ever they want it to, and as long as any performance variations are noted in the manuals, all would be good. It is about the end user knowing the idiosyncrasies of their equipment and making informed buying choices. I doubt any independent process will be implemented voluntarily, but that is how we validate our AADs, and is just a suggestion for consideration and discussion.

I hope you don't take offence to what we have said. Keep in mind that we all need to look out for each other's safety, and it takes some time to earn the trust so to speak. If you have any questions that I can answer or be of any assistance please do not hesitate to contact me. I agree that limiting advancement of technology to a very select few stifles the evolutionally process that has gotten us to where we are today. That being said, it is the way one goes about trying to advance technology that can make people nervous, which is evident in some of the previous posts. I agree that a standard performance validation process would be good. One that would validate that an AAD can/will fire, won't fire as advrotized. That means each manufacturer can have their AAD do what ever, when ever, so we are not limited to only the functionality that is in a standard. This standard performance validation process would provide an independent means to verify that the AAD did fire at the advertised altitude and speed, or did not if it was not supposed to. For example, the AAD that we are working on guards against firing in the aircraft regardless of altitude or aircraft descent rate. The performance validation process would provide a test standard that would independently validate that in the tested conditions, the AAD fired or did not providing more than just the data from the AAD or the manufactures claims. This is what the Army is doing with our Static Line AAD. They have our SLAAD fire into their data recorder so they have an independent data source that will record if and when our AAD fires and the conditions at that time; The data from the SLAAD and their Data recorder should match, if they do not, then there is a problem. This type of validation testing would help identify if an AAD fires deeper than advertised if the descent rate exceeds a threshold, which could be fine as long as the jumper knows that is a characteristic of that AAD. Maybe this kind of testing would be more in line with how consumers reports tests cars?

I agree. However, whenever I have been doing any test jumps, I have never had anyone on the load stand down. Something about human nature, Jerry Baumchen No one wants to be the only one that did not see a spectacular failure lol... The thing about entertainment is it is better to be entertained than it is to be the entertainment! :) Its kind of like watching a student's first clear and pull... every now and then there is one that makes you say "OOO... that is going to leave a mark!! " lol.. Personally, when I am doing "risky" stuff I usually need help on board, and I only allow people that I know can handle themselves if things go sideways. One time at Eloy we were dropping out at Area 51 and I was so focused on the set up and my partners gear that he had to remind me to put my goggles on lol...

OP, I don't mean to give you a hard time about this, I am just puzzled as to your approach. If you can not decompile the algorithms that make the AAD work, then you are limited to your development process in an attempt to discover the same process that Astra, Airtec, Vigil, and M2 have developed to make a one or possibly 4 channel AAD work. I totally understand and agree with your statement about only trusting what you make, but keep in mind what Lee was hinting at, which is, one often doesn't know they don't know something until it is to late. Personally, knowing what I do now after 10 years of working on AAD algorithms, I would never attempt to make one using only barometric, or even just barometric and an accelerometer. I am truly impressed with what Cypres, Vigil, and M2 have been able to do with so little data. But they also have a, (IMO), large actual altitude indication deviation depending on jumper orientation. My target range total is 75ft, as apposed to 125 to 200+ ft. I think I can do better than 75ft, but I think that is a reasonable bench mark to start with. If you are like me, you will really enjoy working with the algorithms and seeing how a change in one place to address an issue has an affect, sometimes a negative one, on another part that was just fine before the change lol.. I also get the impression from your statement that you will only trust your AAD, that you intend on putting it in your reserve and jumping it... I really can not stress this enough that doing so would really be a bad idea. Not to be a prick or come from an "Only I can do that" position, but I am coming from a position of having spend thousands of hours analyzing data and developing algorithms to achieve the desired performance and reliability expectations. Another thing I want to mention is if you are going to jump your altered AAD in a "live" state, meaning it can cut the reserve loop, then it is critical that the aircraft owner and pilot know you have an experimental AAD that is live and does not have any safety override mechanism to prevent an unintended deployment at any point during the fight. It is also critical that no other jumpers be in the aircraft with you when you are jumping your AAD. That may seem like a no brainier, but test jumping or dropping something is not a "regular skydive". There needs to be safeties in place to prevent unintended deployment until you are clear from the aircraft. You should also have accounted for any deviations from the standard emergence procedures that your set up may require, should something go wrong. I am starting to think that being as open as I have been about what we are doing might be encouraging jumpers to put themselves and others at risk as Lee mentioned. We have become complacent from the advanced equipment that is used now and do not have a fear that the pioneers had when they were sorting out what worked and what did not. I would hate to see people get hurt because someone repeated some bad history.