Hi Keith, Thanks for the response. I'm probably saying to much but Rasaero and OpenRocket put the apogee far enough above 100k' that I expect it to be an issue.
> What we've learned is that the firmware will often think that apogee > happens before the actual apogee, so a fairly long delay can avoid > putting the chute out early. Yea, that's what I'm trying to avoid, hence all the questions. So to confirm, you're recommending using the primary Apogee channel and then add to that a 10 second delay in the "Configure Flight Computer" window in the "Apogee Delay (s)" field? I think what concerns me is that from looking at the sim the rocket reaches 100k' AGL at ~47 seconds into the flight, but apogee isn't reached until roughly 83 seconds after ignition. So wouldn't it make sense to plug in a 36 second delay on the "Apogee Delay" instead of 10? And given the length of that delay and the fact that we're basically trying to program around early deploy issues with delays is the main reason why I thought it might be simpler and more accurate to just configure the Apogee deployment event as a pure timer event with some logic to ensure the rocket is well above ground before allowing the channel to fire. I was hoping given the superior sensor package in the *Mega boards there might be some configuration that would mitigate both baro ineffectiveness above 100k' plus accelerometer only deployment events which seem quite prone to drift and accumulated errors over time issues. I could easily be wrong, as my great uncle used to say, "It takes two of me to make one idiot". Thanks again for the prompt response. Regards, Andrew On Thu, Aug 30, 2018 at 1:10 PM, Keith Packard <[email protected]> wrote: > Plugger Lockett <[email protected]> writes: > > > Any advice in this area would be much appreciated folks. > > How high is the flight expected to be? For flights "close" to 100k', you > can use EasyMega pretty much as-is -- the kalman filter will use both > baro and accel data up to the limits of the baro sensor (about 30km, or > 100k'), and above that it switches to using only the accelerometer. > > What we've learned is that the firmware will often think that apogee > happens before the actual apogee, so a fairly long delay can avoid > putting the chute out early. Because the air density is so low, you can > use a pretty long delay without any risk -- you'll be ballistic for a > long time, even if the ejection system has deployed. At 130k', I've used > 10 seconds several times. > > Of course, if you have a non-nominal flight that has apogee below 100k', > you may not want this delay. There's no way, save changing the firmware, > to do this from a single channel. However, you can wire up two channels > in parallel and have one fire with no delay if height < 100k', and the > other fire with a delay at any height. > > If you will be flying well above 100k', I don't have any great > suggestions. What would be cool is to predict apogee by the speed > estimate from below 100k' when the baro sensor is still working and the > kalman filter is generating more accurate speed data. Divide the speed > by 9.8m/s to get seconds until apogee. I should do some analysis of the > recorded flight data I have here to see if this might be a reasonable > plan... > > -- > -keith >
_______________________________________________ altusmetrum mailing list [email protected] http://lists.gag.com/mailman/listinfo/altusmetrum
