I have been doing some more flight testing, and have some data from a couple of flight that convinced me to change the criteria for the default backup main deployments. Due to rocket building and prepping errors on my part, in two flights on one day I had both a flight that had a premature backup main deployment, and a main deployment at the nominal time when an earlier backup main deployment would have come in handy.
First, the premature main flight. This was on a 54mm fiberglass test rocket that I set up to fly two Blue Raven prototypes and a GPS tracker, to gather more data on inertial navigation, since I could compare the data from all 3 units. I used an av-bay that I made for a team rocket with John Wilke and Warren Musselman a million years ago, that accommodates 2 Ravens across from each other in a 54mm av-bay:
(Ravens not shown in this view, but you can sorta see the header pins on each side where they go)
I may commercialize a 54mm av-bay like this in a few months after the Blue Raven is available. This particular version was made to clamp around a 54mm coupler that was slit and glued inside a regular-sized 54mm coupler. Unfortunately, the slit in this inner coupler allowed deployment charge gas to get in, which was compounded by having inadequate vent holes for the av-bay. The result was that the pressure transducers saw a huge pressure spike at apogee:
This next plot shows all the conditions that were checked for main deployment. I zoomed the time in to the first 20 seconds of the flight:
The solid lines are the primary deployment criteria: Liftoff detected and apogee detected and the apogee output fired and altitude < AGL_1 threshold (700 feet) and burnout count > 1. The apo fired criteria goes true 1.5 seconds from the initial signal to allow deployment charge transients to be done with. This works for the primary criteria, because the altitude check only goes (falsely) high for a brief moment when the apo charge fires, but the apo_fired check doesn't go true until after that pressure transient has passed. The backup criteria are in dashes: Liftoff and total velocity < VEL1 criteria (400 ft/sec) and baro velocity less than the BVEL criteria (-200 feet/sec). Here the baro velocity check got spoofed by the deployment charge transient, and because the velocity was already low, the backup charge fired. I thought about putting a filter on the baro velocity check, but it would add quite a bit of delay to something that's pretty time-critical, and it would have a hard time filtering out the biggest pressure spikes. Instead, I'm changing the default main backup settings to wait for the apogee charge to be fired before looking for descent rate too high.
Now for the second flight, I had my rocket named "Shot" to gather data on inertial navigation for higher-G, higher-velocity flights, flying on an ancient AT H125 single use motor:
Yes, the rail is intentionally angled away from the flight line, partly to collect data on flights that start out a little non-vertical. This rocket is also dual-deploy, with 1 Blue Raven prototype and a tracker in the nose. Unfortunately, I didn't use a Featherweight 29mm av-bay for this one, and instead used another homemade av-bay of mine that had a loose connection on the apogee charge. Here you can see the apogee continuity voltage dropping out during the flight:
The time when the apogee charge should have gone off was about 20.5 seconds. But no continuity, no deployment, so the rocket had a ballistic descent until the main chute deployed:
The tracker led me right to the nosecone containing the tracker, and the ripped parachute, with a broken shock cord. The rest of the rocket was nowhere to be found. At first I didn't think to look at the recorded tracker data that I downloaded to my phone in the field to see what the GPS coordinates were when the main deployed. But after I realized that when I woke up with a start one night, I went back to the field and the location of the chute deployment coordinates, and as soon as I took a few steps toward the coordinates where I recovered the nose cone, there was the forward body tube and part of the aft tube:
Note the impressive zipper of this fiberglass body tube. I'm impressed that the chute was that strong. The velocity at deployment was 430 feet/second:
This is the scenario that the backup main deployment was supposed to avoid. The problem can be seen again with the recorded flight events for the main deployment channel:
Again, the solid lines are the primary deployment criteria, and the main fired when the altitude got down below the AGL1 criteria of 700 feet. The backup main deployment (dashed lines) was supposed to go off when the baro velocity got lower than -200 feet/second, which happened around 26 seconds into the flight. But because of being concerned about mach effects spoofing the baro sensing, I also had a check for velocity < VEL1 criteria, and with this relatively horizontal flight, the velocity was too high except for a relatively short time around apogee, and it was too high when the baro velocity backup criteria became true. With the new criteria, where i use the apo_fired rather than velocity < vel1, the backup main deployment would have happened at a survivable velocity and the apo_fired check would have prevented it from being affected by any apogee charge transient events, etc.
Time for dinner!