Steve, not sure if you saw my flight where apogee didn't work, but main deployed, and kept from making a crater as the rocket came in ballistic. It popped my chute hard enough to tear it pretty good, which is saying something on an x-type ultra.
I think your idea is a genius adaptation. I think there is always a reason for failures of deployment, and pilot error is probably the biggest number of them. I am sure those in denial say its fate... The circuit boards are generally good, and most ematch or igniter systems have less than a 2% failure rate and probably less than 1%. I think that's got me beat right there. my understanding of the barometric sensor data, is that yes, the "rate" is always calculated based on a filter where the proceeding "set time" is checked against altitude as averaged over a few readings, and then calculated to find the rate. My arts2 gives a decent rate on the screen of the data analyzer. I am pretty sure this is a post data capture calculation, however, it knows the altitude the whole time, so all it needs is the above filter. I cannot see any drawbacks other than my inability to program an altimeter. http://en.wikipedia.org/wiki/Kalman_filter you would have much better results if the nyquist rate, and frequency are adhered to in the original component design and processing. http://en.wikipedia.org/wiki/Nyquist_rate http://en.wikipedia.org/wiki/Nyquist_frequency I believe John did the Marsa with these principals in mind. Most of all the others are not offsetting there sensor data. Some have implemented sensors with integrated signal processors like featherweight which handle the nyquist frequency issue, but might not address the nyquist rate theory. I went into that because the hard thing to do, is make the function consistent. It needs to be consistent if it is going to have any use as a safety device. because there are sooo many altimeters, I find it hard to believe this would be an easy implementation. It would probably be better as an add-on chip. Something inline with the apogee igniter. you could make it the size of a dime, and use a small lipo the size of a quarter. the easiest thing to do, would be to buy an easy mini, and make your own firmware(probably just a patch in the existing firmware). This would get a solid position if it is an implementable idea and concrete data. (the part I would need outside influence) Bdale told me a cool story about some tarc participants who knew based on velocity, and environment wrote a program based on data set that knew when to fire 3 stages to achieve a prespecified altitude. They wrote the firmware use velocity to fire the motors a the correct time based on that data table. I thought that to be pretty genius, and this cant be too far off. Sorry for the bad literary skills, I have to get back to my work. Neat idea! On Tue, Jun 17, 2014 at 11:53 PM, Steven Saner <[email protected]> wrote: > I've been thinking about a possible feature to add to a dual deployment > altimeter for some time. I'm wondering if it has ever been considered > (at least by you guys) or if there are some technical difficulties that > I'm not thinking of. > > The problem that this feature would be attempting to solve is as > follows. In a dual deployment setup there is a possibility that the > apogee separation could fail. This could be due to the charge not > firing. Not a strong enough charge to cause the separation. Or maybe it > separates, but the drogue chute gets tangled up or fails in some way. If > this happens, the rocket is likely going to begin a ballistic trajectory, > or at least start descending at a higher than ideal rate. Now the main > ejection and separation may happen when it has been configured to happen, > but at this point the rocket is going to be going so fast that you are > probably going to have extensive damage. Despite the damage, maybe things > hang together well enough to slow the rocket down to a relatively safe > landing, or maybe not. > > It would, therefore, be cool if the altimeter could in some way detect > the apogee failure and trigger the main ejection early. Obviously, this > defeats the intention of the dual deployment, but I would much rather > have to hike after the rocket than for it to be destroyed and/or come in > hot and unsafe. > > The way I would envision this being implemented is for the user to > optionally be able to specify a maximum decent rate. After apogee the > altimeter would continuously calculate the decent rate, which I believe > it is doing anyway, and if that rate goes above the set threshold, the > main ejection is triggered, regardless of the current altitude. Setting > this parameter would require a bit of calculation and/or simulation by > the user to determine what the expected decent rate under drogue would > be and then you would want to leave some buffer. Some experimentation > would perhaps be necessary to provide some good guidelines. > > Do any altimeters on the market do this kind of thing that anyone knows > about? I haven't seen it, but I haven't studied every one extensively > either. Do others think this would be a useful feature, or am I alone on > that? Are there some implementation issues that I'm not thinking about? > > Anyway, I am offering this up for consideration and comment. > > Steve > > -- > -------------------------------------------------------------------------- > Steven Saner <[email protected]> KD0IJP > Andover, Kansas USA > > -- > -------------------------------------------------------------------------- > Steven Saner <[email protected]> KD0IJP > Andover, Kansas USA > _______________________________________________ > altusmetrum mailing list > [email protected] > http://lists.gag.com/mailman/listinfo/altusmetrum >
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
