- Joined
- Feb 3, 2012
- Messages
- 6,335
- Reaction score
- 5,523
We save the last flight stage along with all the other data in NV memory, in case something happens... it's helpful sometimes for post-flight analysis.
Why don't altimeters have in-flight power-loss recovery?
- Thread starter SparkyVT
- Start date
Help Support The Rocketry Forum:
boatgeek
Well-Known Member
- Joined
- Dec 27, 2014
- Messages
- 7,372
- Reaction score
- 7,876
Someone please correct me if I'm wrong, but don't altimeters normally determine ground altitude when they power up? If yours does, then you would need a fair amount of logic to (a) save the prior ground altitude before power went out and (b) go down a different logic chain on powerup for the in-flight recovery. That seems like a non-trivial software exercise with the risk of blowing charges on the ground.
I'm with the people who want the same startup every time and if you're worried about brownouts, have a more electrically robust design/installation. Also, the huge safety issue is getting the drogue out. As long as that happens, the risk of injury or death is substantially reduced (it's a lot easier to see the rocket in the air and it's coming down slower). The rocket might get damaged, but those are a lot easier to repair.
I'm with the people who want the same startup every time and if you're worried about brownouts, have a more electrically robust design/installation. Also, the huge safety issue is getting the drogue out. As long as that happens, the risk of injury or death is substantially reduced (it's a lot easier to see the rocket in the air and it's coming down slower). The rocket might get damaged, but those are a lot easier to repair.
For the case of the Raven altimeter, the capacitor only ever powers the logic. The pyros are fired directly from the battery. This way a short in a deployment charge won't cause a reset.
Usually a power loss is caused by a deployment charge directly shorting while it's on (1 second), or the shock from the deployment causing a battery or switch contact to bounce open (a few msec). If you have back-to-back deployments on all 4 Raven channels that each short out the battery while they're on, you're still covered. But obviously if the power goes away and never comes back, then you're going to have a bad day regardless of your software approach, unless you have an independently-powered backup. In that case, if the rocket is recovered intact enough to be able to download the data, you can verify the power loss based on the battery voltage and deployment charge continuity data that continues to be recorded for a few seconds after power loss. I have seen lots of customer's recorded data that looks like that, over the last 12 years that the Raven has been in the field.
Fixing the switch is an obvious solution. It has only happened on this one flight of mine after dozens of successful flights. Loss of tracking was problematic as apogee was around 37500' so visual tracking was out of the question. Deployment was redundant but not tracking.
My point is that the altimeter should be robust enough to not exacerbate the problem. With some thought and analysis the situation can be improved.
Last edited:
- Joined
- Jan 23, 2009
- Messages
- 5,972
- Reaction score
- 4,084
I think altimeters should not cover up bad practices in wiring or switch selection. Crash a few rockets and you will quickly improve your techniques. I realize that this may not be a popular opinion with the folk. 
- Joined
- Jul 15, 2015
- Messages
- 3,948
- Reaction score
- 2,684
I think altimeters should not cover up bad practices in wiring or switch selection. Crash a few rockets and you will quickly improve your techniques. I realize that this may not be a popular opinion with the folk.
I'm OK with it as a safeguard, but IF it adds complexity to an already complex item, it's a clear NO GO when adding redundancy or robustness to the simple parts of the system like battery and switches would be the cheaper, faster, and more mistake proof solution.
beeblebrox
8 C6-0, 12 D11-9, 20 D20-0, 20 E5-0, 3 Cinerocs
These switches are just perfect. Mount them so you push it from the side with the button just slightly below the surface of the body tube. With this orientation it is impossible for g-loads to accidently switch it. If a sideways g-load is high enough to switch it , you seriously had another problem... These take more than a pound of force to actuate. they are push-on push-of. The same switches that are commonly in flashlights. Since I have a whole bag of them, I will give two of them free to the first person who PM's me a message with a shipping address as an early xmas present... (Note these cost less than $10 for 20 of them...)
- Joined
- Jan 23, 2009
- Messages
- 5,972
- Reaction score
- 4,084
In my opinion it is unsafe to continually fly a latently unsound electrical package. My preference is that the altimeter brown out and the rocket crash from high altitude into a rock or pavement so the unsound package is completely destroyed and no parts can be reused again. Again I understand if the folk do not agree with my take.
I have a similar high g recessed push button switch I use in one of my test rockets for my DIY flight computer and tracker. It sits next to two key switches for my primary and backup altimeters. In 25+ flights on that rocket I have twice lost the recessed switch. The first was a fluke nose to avBay collision on main election that hit square on the switch (caught on camera) and the second just happened last weekend, when the main tangled, so we had a hard landing with no significant damage, but direct impact to the switches shut off the high g push button switch, while the key switches were fine. After that flight, I've decided to rip that push button out and replace with a key -- as I should have in the first place.
My flight computer had a few brown outs (causing resets) when I was first building it, likely due to batteries, bad connectors, or poor switches, so I added a cap that gives me a full 3.5 seconds of coverage. In the flight Saturday when the switch shut off on landing, the last transmission gave us all the flight data, GPS, etc. but said "voltage 0". So, even though it died a voltage-starved death it gave us the ground position after shutting down.
I am not using mine for deployment right now, but I would have a hard time supporting a commercial device that would shut down, restart, and then fire charges based on some series of logic and prior state when it came back online. Even with amazing logic controls, I think there is too much risk of powering up two weeks later with the altimeter connected to new charges, on the ground and in the wind. Boom. Surprise.
I wouldn't rule it out for a custom package in some extreme situations, but not for general use. That is why I fly with two altimeters. In my setup, I have bi-directional radio control, so if it did reset and was functional, I have the ability to manually put it back into any state or phase of launch.
Inappropriate use of "cool" icon. If you can improve a process, why wouldn't you? Sometimes things happen unpredictably. Your comment is like saying let's not bother with airbags since people should be able to drive properly...I think altimeters should not cover up bad practices in wiring or switch selection. Crash a few rockets and you will quickly improve your techniques. I realize that this may not be a popular opinion with the folk.
- Joined
- Jan 23, 2009
- Messages
- 5,972
- Reaction score
- 4,084
I am all for improving processes. I want all poorly selected switches and sloppy wiring crashed out of the process. ;-)
Punishment and loss is a great motivator for improvement. Old school. :wink
Agreed
- Joined
- Jun 4, 2010
- Messages
- 888
- Reaction score
- 352
Couple of thoughts, for what they are worth.
If you do program a device that can trigger a charge after waking up and detecting interruption, make sure you protect against all of the weird edge cases that can happen when the altimeter is re-powered up later:
In general be deliberate about which phases of flight are "resumable" and which are not. In general, be sure to restrict it to the boost and coast phases.
One creative fix to consider that can handle the exceptions above: add a separately powered real time clock of some type. I like Ambiq's—uses so few nanoamps that a capacitor can power them during a power blip. Then you can disallow resumption after a certain time has passed.
If that sounds like too much trouble, you could also make a poor-man's dead-switch timer with a capacitor and a discharge resistor that the MCU keeps charged up while running. Upon startup, the MCU first tests the voltage of the cap and if it's too low (in other words, it hasn't been kept charged recently enough), the MCU abandons the partial flight. Appropriate values of C and R can be set for whatever short time limit is desired.
The goal: absolutely prevent triggering after power up on the bench.
For what it's worth.
If you do program a device that can trigger a charge after waking up and detecting interruption, make sure you protect against all of the weird edge cases that can happen when the altimeter is re-powered up later:
- After a number of hours, the weather will have changed the local ambient pressure, and the altimeter will wake to a higher or lower pressure by perhaps 25 feet per hour or more
- After traveling, the local pressure will be different by many feet of altitude
In general be deliberate about which phases of flight are "resumable" and which are not. In general, be sure to restrict it to the boost and coast phases.
One creative fix to consider that can handle the exceptions above: add a separately powered real time clock of some type. I like Ambiq's—uses so few nanoamps that a capacitor can power them during a power blip. Then you can disallow resumption after a certain time has passed.
If that sounds like too much trouble, you could also make a poor-man's dead-switch timer with a capacitor and a discharge resistor that the MCU keeps charged up while running. Upon startup, the MCU first tests the voltage of the cap and if it's too low (in other words, it hasn't been kept charged recently enough), the MCU abandons the partial flight. Appropriate values of C and R can be set for whatever short time limit is desired.
The goal: absolutely prevent triggering after power up on the bench.
For what it's worth.
Great thoughts.
Many decades ago when I became a BAR the electronics were in some cases primitive and usually expensive considering inflation dollars. In the day my choice was the AltAcc priced at $160, equating to about $230 using inflation adjusted dollars. Nice unit, simple to use but today at $230 no one would make that choice. Currently I have split my altimeter choices into two groups, basic and advanced. For basic my choice is the Perfectflite CF at $60 or Misslileworks RRC3 at about the same price point. If I need GPS tracking, second stage ignition and tilt lock-out I fly a TeleMega as it's a solid unit and I see Keith or Bdale with some frequency when I have self-inflicted issues.
Where is this seemingly wandering discussion going? It's simple, opting for altimeter redundancy by spending $120 on two basic altimeters is your best option and likely much less than you likely spent on your airframe and motor you're flying. Redundant altimeters and ejection charges is a requirement at the NASA Student Launch Program and while there are still recovery issues, we have only had one instance where there airframe had complete recovery system failure and burned in. Even incident wasn't due to the failure of the flight computers.
Where is this seemingly wandering discussion going? It's simple, opting for altimeter redundancy by spending $120 on two basic altimeters is your best option and likely much less than you likely spent on your airframe and motor you're flying. Redundant altimeters and ejection charges is a requirement at the NASA Student Launch Program and while there are still recovery issues, we have only had one instance where there airframe had complete recovery system failure and burned in. Even incident wasn't due to the failure of the flight computers.
Thanks for the inputs everyone. It seems there's a lot of good reasons that the vendors don't have this feature. Many of the concerns involve safety, and the system inadvertently firing events. Having redundant altimeters, properly wired, properly configured, with a good battery is the best solution. Dead horse beaten.
However, there are some folks interested in this feature. It could be useful for the cases where only 1 altimeter will fit, or there is only 1 altimeter that is providing GPS & telemetry. There's enough concern that most people would want to be able to "opt out" and disable it in software. The default case could be "opt-out", or "opt-in with pyros disabled."
There are also some good suggestions on how this might be implemented. Here's what I'm thinking based on everyone's inputs, along with some of my own:
1) Store a few bytes in NVM that include last phase of flight and pre-flight base altitude
2) Whenever the phase of flight changes, then update the NVM. This would make EEPROM a viable candidate since the write cycles would be low. Bench tests would not change the NVM phase of flight variables.
3) If the system wakes up and the last recorded phase of flight is not "flight complete", then sound an audible alarm to the user and initiate recovery sequence.
Proposed recovery sequence logic:
1) Initiate an 8 second sample period of the barometer and accelerometer (sound audible alarm to user).
2) If during the 8 second period the sensors meet the configurations below, attempt to recover. If not, assume post-flight recovery and require a power-off reset.
Recovery Conditions:
A) Pre-flight on pad (sound audible recovery alarm and start normal boot sequence)
i) continuity on all charges
ii) positive acceleration at 1G +/-0.1G, oriented vertical within a 20 degree cone, sustained for 5 seconds, within a 0.05G range
iii) stable barometric altitude within 10ft for 5 seconds
B) Subsonic coast (re-enter normal flight operations)
i) continuity on apogee or main pyro (arm pyros if user desired, otherwise disable pyros and recover)
ii) monotonically increasing barometric altitude for at least 1 second, range difference is greater than 50ft
iii) all altitude samples greater than 300ft above base altitude
iv) All vertical-axis accelerometer values are negative
C) Inflight descending ballistic (re-enter normal flight operations)
i) continuity on apogee or main pyro (arm pyros if user desired, otherwise disable pyros and recover)
ii) Monotonically decreasing altitude for 1 second, altitude range difference greater than 50ft
iii) All altitude samples greater than 300ft above base altitude
iv) All vertical-axis accelerometer samples are negative
D) Inflight descending drogueless or under drogue (arm pyros if user desired, and re-enter normal flight operations)
i) continuity on apogee or main pyro (arm pyros, otherwise disable pyros and recover)
ii) all altitude samples greater than 300ft above base altitude
iii) average velocity <-10 ft/s for 2 seconds
E) Post-flight on ground (default if not conditions met during sample period, sound audible alarm, require hard-reset):
i) all barometric samples within 300ft of base altitude for 5 seconds
OR
i) stable barometric altitude within a 10ft range for 5 seconds
ii) accelerometer values are not 1G or outside a 20 degree vertical cone
However, there are some folks interested in this feature. It could be useful for the cases where only 1 altimeter will fit, or there is only 1 altimeter that is providing GPS & telemetry. There's enough concern that most people would want to be able to "opt out" and disable it in software. The default case could be "opt-out", or "opt-in with pyros disabled."
There are also some good suggestions on how this might be implemented. Here's what I'm thinking based on everyone's inputs, along with some of my own:
1) Store a few bytes in NVM that include last phase of flight and pre-flight base altitude
2) Whenever the phase of flight changes, then update the NVM. This would make EEPROM a viable candidate since the write cycles would be low. Bench tests would not change the NVM phase of flight variables.
3) If the system wakes up and the last recorded phase of flight is not "flight complete", then sound an audible alarm to the user and initiate recovery sequence.
Proposed recovery sequence logic:
1) Initiate an 8 second sample period of the barometer and accelerometer (sound audible alarm to user).
2) If during the 8 second period the sensors meet the configurations below, attempt to recover. If not, assume post-flight recovery and require a power-off reset.
Recovery Conditions:
A) Pre-flight on pad (sound audible recovery alarm and start normal boot sequence)
i) continuity on all charges
ii) positive acceleration at 1G +/-0.1G, oriented vertical within a 20 degree cone, sustained for 5 seconds, within a 0.05G range
iii) stable barometric altitude within 10ft for 5 seconds
B) Subsonic coast (re-enter normal flight operations)
i) continuity on apogee or main pyro (arm pyros if user desired, otherwise disable pyros and recover)
ii) monotonically increasing barometric altitude for at least 1 second, range difference is greater than 50ft
iii) all altitude samples greater than 300ft above base altitude
iv) All vertical-axis accelerometer values are negative
C) Inflight descending ballistic (re-enter normal flight operations)
i) continuity on apogee or main pyro (arm pyros if user desired, otherwise disable pyros and recover)
ii) Monotonically decreasing altitude for 1 second, altitude range difference greater than 50ft
iii) All altitude samples greater than 300ft above base altitude
iv) All vertical-axis accelerometer samples are negative
D) Inflight descending drogueless or under drogue (arm pyros if user desired, and re-enter normal flight operations)
i) continuity on apogee or main pyro (arm pyros, otherwise disable pyros and recover)
ii) all altitude samples greater than 300ft above base altitude
iii) average velocity <-10 ft/s for 2 seconds
E) Post-flight on ground (default if not conditions met during sample period, sound audible alarm, require hard-reset):
i) all barometric samples within 300ft of base altitude for 5 seconds
OR
i) stable barometric altitude within a 10ft range for 5 seconds
ii) accelerometer values are not 1G or outside a 20 degree vertical cone
Last edited:
jimzcatz
Boss, Carolina Rocket Mafia
A perfect justification as to why I have NEVER used switches of any kind. Twist and tape. No moving parts.
- Joined
- Jan 23, 2009
- Messages
- 5,972
- Reaction score
- 4,084
I think you nailed it. Perfect opportunity for someone like yourself to develop the technology for use only by you.
Commercial manufacturers need to be concerned about liability. Statistically the greatest peril of a rocket launch is preparation on the ground. An altimeter, working as designed, that increases the chance of igniting charges or ignite motors on the ground is a financial non-starter for a commercial product. At least it is for me.
- Joined
- Jul 15, 2015
- Messages
- 3,948
- Reaction score
- 2,684
Anything that increases complexity or costs more money for what is likely to be a widely unused feature is a non-starter for most of the commercial product consumer crowd. Especially a feature which, given today's relative ease of use and reliability of existing commercial products, seems to be an answer in search of a question.
Last edited:
- Joined
- Feb 3, 2012
- Messages
- 6,335
- Reaction score
- 5,523
Commercial altimeters rarely fail in flight... if they don't fire, it's virtually always "something else" that made that happen. Your efforts would best be spent eliminating the "something elses"... battery choice, wiring, connections, etc. No amount of software tweaking is going to make up for bad wiring or a loose battery connection.
KilroySmith
Well-Known Member
- Joined
- Oct 28, 2015
- Messages
- 183
- Reaction score
- 112
The last GPS module I bought had an on-board tiny supercap (something like https://www.digikey.com/en/products/detail/elna-america/DSK-3R3H224U-HL/970181) that held enough charge to power the RAM in the CPU for roughly an hour. It was used to allow the GPS to warm-start in 5 seconds if you repowered it within an hour of the last good fix, as opposed to the 45 seconds it took for a cold-start.
The same concept could apply to an altimeter design using a single battery without using EEPROM or dedicated NVRAM - you'd use the entire CPU RAM as NVRAM. Assuming the CPU didn't have a backup power input, you would power the CPU from the LiIon battery through a diode. The supercap would sit on the processor Vcc pin, and charge whenever the CPU was powered; the diode would prevent it from discharging through the pyro circuitry. When it came time to fire the pyro channel, the CPU would:
1. Prepare itself to enter a low power state then set a timer for a second or two
2. Set the GPIO to fire the pyro channel.
3. Put itself in a micro-power state (not running, clocks stopped, etc) and wait for the timer to fire.
4. On wakeup, shut off the Pyro channel GPIO.
5. Continue as if nothing had happened. All the state info, baro and accelerometer data, etc., would all be current, and the algorithms wouldn't need to be modified to deal with a "restart".
The necessary Supercap size could be experimentally determined by having the pyro channel open the battery lead using a FET or similar switch, and increasing the Supercap size until sufficient power was stored to allow the CPU to resume with sufficient margin. This is a case where you wouldn't want to drastically oversize the cap, because powering the ram for minutes to hours leads to the possibility of the CPU waking up with good RAM contents when you didn't want it to; you might even want to bypass the cap with a resistor to assure that it discharged in a known time. This also requires a ground-up design for the altimeter - it's not something that a user could reasonably add to an existing altimer.
These supercaps aren't cheap in the quantities that we'd use them ($1 each in 100 unit quantities), and would add a few bucks to the cost of an altimeter, but in the various engineering tradeoffs that the various products make, it might be useful.
The same concept could apply to an altimeter design using a single battery without using EEPROM or dedicated NVRAM - you'd use the entire CPU RAM as NVRAM. Assuming the CPU didn't have a backup power input, you would power the CPU from the LiIon battery through a diode. The supercap would sit on the processor Vcc pin, and charge whenever the CPU was powered; the diode would prevent it from discharging through the pyro circuitry. When it came time to fire the pyro channel, the CPU would:
1. Prepare itself to enter a low power state then set a timer for a second or two
2. Set the GPIO to fire the pyro channel.
3. Put itself in a micro-power state (not running, clocks stopped, etc) and wait for the timer to fire.
4. On wakeup, shut off the Pyro channel GPIO.
5. Continue as if nothing had happened. All the state info, baro and accelerometer data, etc., would all be current, and the algorithms wouldn't need to be modified to deal with a "restart".
The necessary Supercap size could be experimentally determined by having the pyro channel open the battery lead using a FET or similar switch, and increasing the Supercap size until sufficient power was stored to allow the CPU to resume with sufficient margin. This is a case where you wouldn't want to drastically oversize the cap, because powering the ram for minutes to hours leads to the possibility of the CPU waking up with good RAM contents when you didn't want it to; you might even want to bypass the cap with a resistor to assure that it discharged in a known time. This also requires a ground-up design for the altimeter - it's not something that a user could reasonably add to an existing altimer.
These supercaps aren't cheap in the quantities that we'd use them ($1 each in 100 unit quantities), and would add a few bucks to the cost of an altimeter, but in the various engineering tradeoffs that the various products make, it might be useful.
I would suggest it would be nice for any future altimeters be able to determine their status if a brownout occurs during flight. FMEAs will likely show that still allowing pyro events will be too risky, but telemetry should be resumed so effective tracking can occur. Pyro redundancy is normally achieved by separate altimeters in my rockets, but I don't normally fly redundant telemetry.
I'm in agreement. Twist Tape Tuck (I carry an un-tucker just in case).
Interesting experience last launch (near-miss I'll call it).
Batteries are zip tied to the altimeter sled. When assembled they are actually captured by the body tube as well so they can't escape. The zip ties just ensure no longitudinal movement.
I've flown this rocket for ten years.
Well.. I used a little more energetic apogee charge than I usually use.
No observable issue, nominal flight and recovery but on disassembly I realized that the ten feet of Kevlar holding the two halves together had reached its full length on deployment. I first noticed because the screw holes for the sled, which is attached to the cord were slightly elongated and when I removed the sled I noticed the batteries hanging free.
The hard stop when the cord tightened caused the batteries to shear their retention ties.
No failure or power interruption, 800' charge put the laundry out just fine. Worst case she would have landed flat and probably been undamaged.
But I am re-thinking my mounting and measuring method.
I use Velcro between the batteries and sled to take the shear forces. Cable ties just hold the batteries to the sled. You might like to try this as an improvement to cable ties only.
- Joined
- Jun 4, 2010
- Messages
- 888
- Reaction score
- 352
Kind of related: Jolly Logic products have never had switches, at least in the mechanical sense. Instead, there are buttons that are just inputs that the processor can either listen to or ignore.
The “switch” is a transistor that the processor controls. So the processor can ignore the button (e.g. during high acceleration) and even turn itself off.
For tech fans, the first car to be designed like this was the Tesla Model 3. Every single control is essentially a momentary button, and effectively everything about the car can be computer controlled.
The “switch” is a transistor that the processor controls. So the processor can ignore the button (e.g. during high acceleration) and even turn itself off.
For tech fans, the first car to be designed like this was the Tesla Model 3. Every single control is essentially a momentary button, and effectively everything about the car can be computer controlled.
How does it behave when it has a momentary power interruption?
Not trying to pick a fight, just curious if you have addressed the initial posters (and likely the rest of us) point.
BTW I did see many of your devices flying at Midwest Power with no observed failures that I know of. Kudos!
I made a career out of the fact that stuff, even the best designed stuff fails from time to time. Electrical or mechanical doesn't matter.
I take it as a certainty to the extent that I don't assume that just because the gates aren't down there is not a train.
I still stop look and listen if I can't see at least a block down the tracks.
Some failures are just too final.
- Joined
- Jun 4, 2010
- Messages
- 888
- Reaction score
- 352
Not much can be done about loss of the sole power source if you don’t have a redundant power system. Most/all altimeters have smoothing capacitors for the power supply, sometimes quite beefy, but not large enough to cover a full power outage of any significant duration.
Supercaps thus far have been too pricey to have around for rare events.
Redundancy has usually been the solution when ultimate reliability matters.
Sorry to revive a dead-thread, but I have an update on this topic. I've been working on this for a few months and finally have it dialed in. I wanted to test how the algorithms would work in the real-world, so I wrote some python code to run them against a few challenging benchmark flights. I simulated a power-loss event once per second throughout the flight by stepping through the flight at about 1500 samples per second. It required about 2 million iterations across the 4 benchmarks. Here are the test results from one of the benchmarks, a supersonic M-powered flight to about 11K feet:
Keep in mind that I'm only interested in recovering in certain phases: subsonic coast, ballistic descent, under drogue, and pre/post flight. Other flight phases are generally short lived (aka boost) or there isn't an action to take (under main).
The results show that it can be done with good accuracy, even with noisy barometers and accelerometers. I found that a barometer and accelerometer are both required. Just using barometric velocity, variance, min/max, and other metrics was insufficient to distinguish between flight phases. Thus, it will be much harder to implement on altimeters with just a barometer.
Sparky
testStartTime | detectInterval | detectTime | trueFlightPhase | recoveryPhase | actualVel | restartVel | apogeeTime | startAlt | detectAlt |
0 | 5.188611 | 5.188611 | supersonic coast | subsonic coast | 460.63 | 364.03 | 24.282651 | -0.03 | 966.48 |
1.000396 | 4.188611 | 5.188611 | supersonic coast | subsonic coast | 460.63 | 364.44 | 24.282651 | 34.56 | 966.48 |
2.000596 | 3.188611 | 5.188611 | supersonic coast | subsonic coast | 460.63 | 359.85 | 24.282651 | 140.13 | 966.48 |
22.000186 | 0.339182 | 22.339182 | subsonic coast | near apogee | 18.82 | 9.36 | 24.282651 | 3309.61 | 3315.87 |
23.000365 | 0.343779 | 23.343779 | subsonic coast | near apogee | 9.83 | 5.46 | 24.282651 | 3325.22 | 3328.08 |
24.00017 | 0.348173 | 24.348173 | apogee | near apogee | -0.87 | -1.56 | 24.282651 | 3329.9 | 3329.1 |
25.000076 | 3.19761 | 28.19761 | under drogue | inflight descending under drogue | -35.12 | -43.07 | 24.282651 | 3324.65 | 3276.18 |
162.000534 | 3.170304 | 165.170304 | main deploy | inflight descending under drogue | -9.25 | -7.05 | 24.282651 | 151.09 | 102.04 |
163.000082 | 7.717647 | 170.717647 | under main chute | post-flight on ground | -5.15 | -5.95 | 24.282651 | 118.25 | 69.44 |
Keep in mind that I'm only interested in recovering in certain phases: subsonic coast, ballistic descent, under drogue, and pre/post flight. Other flight phases are generally short lived (aka boost) or there isn't an action to take (under main).
The results show that it can be done with good accuracy, even with noisy barometers and accelerometers. I found that a barometer and accelerometer are both required. Just using barometric velocity, variance, min/max, and other metrics was insufficient to distinguish between flight phases. Thus, it will be much harder to implement on altimeters with just a barometer.
Sparky
A Featherweight Raven can lose power for half a second every second of the flight without resetting or the software state ever being affected. You could postulate a 4 second power loss any time in the flight the Raven will stay up through that event, too.
-Adrian
Similar threads
