# Why don't altimeters have in-flight power-loss recovery?

### Help Support The Rocketry Forum:

#### cerving

##### Owner, Eggtimer Rocketry
TRF Supporter
Obviously, but they are dynamic, not non-volatile, no? You always go back to the initial POR state when you power on.

Anyway, I think we're beating a dead horse here.
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.

#### boatgeek

##### Well-Known Member
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.

Yes, this is good. Fixing the loss of power situation in the first place should be 80% of the effort spent and 20% should be spent on a backup to that, like you're saying.

I don't know if capacitors would be enough though. If the system can run for 5 seconds on power loss, that's 5 seconds of what, 30mA draw? 100maA? Not much. Very unlikely there's enough juice in there to fire a pyro from the capacitor. I just imagine the power loss happening right before apogee, followed by a 1s pyro signal causing a brownout/shutdown of the altimeter.

It's like, your car is leaking fuel and you keep running out of gas. Yeah, you can put a jerry can in the trunk for when you run out. Or you could just fix the leak in the tank.
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.

#### OverTheTop

##### Well-Known Member
TRF Supporter
But that’s clearly a switch problem? Get a different switch that doesn’t do that instead of inventing a new thing that could go wrong that only exists because of a different problem that wasn’t resolved.
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:

#### jderimig

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.

#### Banzai88

##### Lvl 1,Wallet....Destroyed
TRF Supporter
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
But that’s clearly a switch problem? Get a different switch that doesn’t do that instead of inventing a new thing that could go wrong that only exists because of a different problem that wasn’t resolved.

#### SparkyVTFlyer

##### Senior Member
TRF Supporter
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

Last edited:

#### jimzcatz

##### Boss, Carolina Rocket Mafia
Okay, I'm clear on the principle of building a motor mount with fins on the bench outside the body tube. I even understand the reason for doing so and how to install the completed structure inside the body tube.

A rocket kit I'm working on has three centering rings. I see no problem in applying the epoxy/glue inside the body tube for the uppermost centering ring and of course the gluing the rearmost centering ring in place is a simple matter as well.

Question: How do I get the epoxy/glue in place for the middle centering ring? Should I wait until the motor mount is installed and then add the fins (with no internal fillets on the motor tube) as I have done before? Sometimes I drilled holes in the body tube and injected epoxy fillets...my Mad Cow Frenzy comes to mind.

The kit is an 3" upscale Cherokee-H by T. VanderBurn and the scaled up Cherokee fins are rather large as you can imagine.

Seems weird building a rocket kit from a kid/guy I remember from when he was about 8 years old...I used to fly AMA Free Flight airplanes with his dad.
But that’s clearly a switch problem? Get a different switch that doesn’t do that instead of inventing a new thing that could go wrong that only exists because of a different problem that wasn’t resolved.

A perfect justification as to why I have NEVER used switches of any kind. Twist and tape. No moving parts.

#### jderimig

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.
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.

#### Banzai88

##### Lvl 1,Wallet....Destroyed
TRF Supporter
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.
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:

#### cerving

##### Owner, Eggtimer Rocketry
TRF Supporter
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
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.

#### OverTheTop

##### Well-Known Member
TRF Supporter
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.

#### Bowman

##### Well-Known Member
A perfect justification as to why I have NEVER used switches of any kind. Twist and tape. No moving parts.
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.

#### OverTheTop

##### Well-Known Member
TRF Supporter
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 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.

#### Bowman

##### Well-Known Member
Yep, might be worth a try.
The charge size is a critical piece too .
In ten years this is the first time that hapened but I want to learn from the incident and make sure it can't happen again.

#### John Beans

##### Founder, Jolly Logic
TRF Supporter
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.

#### Bowman

##### Well-Known Member
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.
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.

#### John Beans

##### Founder, Jolly Logic
TRF Supporter
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.
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.

#### SparkyVTFlyer

##### Senior Member
TRF Supporter
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:

 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

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:

 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.