Craig Klimczak <compu...@aol.com> writes: > Casey and Drew pointed out that at over 100K the exact timing of > apogee will not be that big of deal. There is not enough atmosphere to > zipper the rocket.
Yup. If you've seen a descent plot for any of these flights, it's parabolic until you get down to about 30k'-40k' and then starts to slow down. > It sounds like a good idea to have both a channel for <100K and > another with longer delay for >100K. I typically use dual matches on > the charges so if one altimeter fails, I have another firing the > charge. Likewise, I always have backup charges. I think so. I'd love to be able to program a single channel to do this, but the current *mega pyro channel configuration mechanism doesn't have any way to express it. > The delay is another consideration that I did not take into account. > It makes sense to give the rocket time for the accelerometers to > detect the change in acceleration due to gravity. That's not what we're waiting for -- we're just compensating for the inaccuracy in computing apogee based on acceleration alone. We don't have a lot of precision in measuring acceleration because we need such a large range, that means there's a significant error in each measurement, leading to (potentially) large errors in speed computation and missing apogee by many seconds. Adding a long delay ensures that the apogee pyro event happens after apogee, potentially long after apogee. > What about Drew's concern over the lack of integration over the three > axis of accel? Yeah, having a full 6dof state computation would be 'better' in some way, but we still can't get much precision in the z-axis acceleration value, so I don't know how much more accurate apogee detection would be. > Can we assume that as the rocket arc's over the change in acceleration > will become detectable and thus trigger apogee detection? Is there a > set threshold for change in acceleration for the algorithm to detect > apogee? Uh, I think you're missing something here -- there's no change in any acceleration values across apogee; the rocket trajectory is ballistic precisely because the only large force acting on it is gravity, which is constant. > If we are fairly certain of apogee detection even in an off-vertical > trajectory, then there may not be a real need for an EFU > timer. Thoughts? Apogee estimation above the baro sensor range is not precise, and can easily fail if the flight is not nominal -- a shred can easily cause things to go badly wrong. Failsafe programming that gets the laundry out if something weird happens is important, although figuring out how to avoid causing other problems is hard. > I have multiple APRS radios so it is enabled on all my TeleMegas. I > like to have the audible radio beacon as a backup measure of > confidence. In 2013 at BALLS, I had the USC team set up a remote > tracking station in the hills above the playa for the very reason of > end-fire degradation. The rocket cato'd at 5,000 feet so RF > degradation was the least of our problems then. Yeah, high performance motors are not the most reliable things in the world. -- -keith
signature.asc
Description: PGP signature
_______________________________________________ altusmetrum mailing list altusmetrum@lists.gag.com http://lists.gag.com/mailman/listinfo/altusmetrum
