Sensitivity of baro altimeters to ejection pressures

[JordanT]

How sensitive to pressure spikes are most barometric sensors? (I currently have the Raven series, fwiw)

Is there normally a lockout period between apogee and main on modern altimeters to prevent transients from apogee charges from tripping the sensor?

 

[troj]

Your av bay should be sealed, and the sensor shouldn't be seeing those transients.

That said, it's hard to get a perfect seal, and there is some oomph behind a typical charge, so you'll often see a small spike (shown as an altitude drop), but it's not an issue. Where you'll see more scrambling of readings is on the accelerometer.

-Kevin

 

[cerving]

If properly sealed you shouldn't have any ejection blowback into the AV bay, which will definitely show up as a high-pressure (low altitude) spike. However the jerking of the payload bay at ejection may show up as an up-down spike in your altitude graph, since by Bernoulli's principle the air pressure in the bay will drop for a moment and then go back to ambient as the bay is accelerated forward and then stops.

 

[mikec]

Is there normally a lockout period between apogee and main on modern altimeters to prevent transients from apogee charges from tripping the sensor?

Not for the Raven, no. The channels are completely independent. If your bay is very leaky you can fool a Raven into deploying main at apogee with the normal settings, though it takes a significant leak to get past its noise filtering.

I'm not sure if other altimeters use lockout logic, but it would make a certain amount of sense to do so.

 

[Larry Curcio]

Your av bay should be sealed, and the sensor shouldn't be seeing those transients.

That said, it's hard to get a perfect seal, and there is some oomph behind a typical charge, so you'll often see a small spike (shown as an altitude drop), but it's not an issue. Where you'll see more scrambling of readings is on the accelerometer.

-Kevin

Actually... both the altimeter and the accelerometer respond to the abrupt acceleration of the ejection event - no matter how well sealed the chamber is. If the accelerometer isn't pegged in the process, and if its response isn't "nonlinear" (i.e.; if it registers correctly) then the accelerometer reading is meaningful. It's not just a scramble.

 

[cvanc]

Not for the Raven, no. The channels are completely independent. If your bay is very leaky you can fool a Raven into deploying main at apogee with the normal settings, though it takes a significant leak to get past its noise filtering.

I can confirm this with my Raven 3s. It was a pretty significant leak - the apogee charge pressurized the AV bay - and it was enough to trigger the main/700' channels. I do not know if there is any filtering in the firmware, but for sure at some point any filtering that may exist can be swamped if the leak is big enough.

I wonder about a timed lockout of 'x' (one second or so?) on the lower altitude channels triggered by the firing of any apogee channel. Assuming you are flying well above the lower altitude threshold that sounds like an interesting approach to me.

 

[mikec]

I wonder about a timed lockout of 'x' (one second or so?) on the lower altitude channels triggered by the firing of any apogee channel.

There was a discussion with Adrian on some online forum about this. One issue is that the Raven microcontroller doesn't have any space left for more logic. Another problem is how you would configure this in general and what failure modes there might be. But it would make things more tolerant to leaks.

It would be interesting to know if any altimeters are doing some form of apogee lockout. For a simple dual-deploy altimeter with minimal configurability it would be trivial to add it.

 

[keithp]

How sensitive to pressure spikes are most barometric sensors?

There are two separate effects in play here:

1. "Blow-by" causing pressure increases inside the av-bay. These appear as sharp (and short) pressure increases. With a suitably vented bay, they'll dissapate within a few pressure sample periods, and of course can be minimized by sealing things well. And, you want to seal things anyways as the combustion gasses are quite corrosive and will damage the electronics.

2. Mechanical stress. The barometric sensor is actually mechanical inside -- it has a sealed vacuum chamber with a membrane over the top. Pressure changes on the top of the membrane flex it up and down, those motions are measured to figure out the air pressure. Sharp acceleration can also move things around though, and often the ejection charge will cause a fairly large apparant change in pressure, both up and down as the device recovers from the ejection charge and shock cord jerks.

I stuck the analog MP3H6115A in a barometric testing chamber with a shake table to characterize the vibration noise it generated which was used to set the Kalman filter parameters for TeleMetrum. I haven't done the same with the newer digital M5607 yet, but just flying them in the same airframe makes it pretty clear that the MS5607 is less sensitive to vibration.

Is there normally a lockout period between apogee and main on modern altimeters to prevent transients from apogee charges from tripping the sensor?

You need a filter of some kind to reduce the effect of noise on the altimeter or you won't be able to detect apogee anywhere near the right place. A simple IIR filter with a 1/2 second (or more) time constant will still detect apogee (and main altitude) just fine, while essentially eliminating all of the noise from quick changes in measurements. A Kalman filter will also tell you when the sensors are completely nuts, allowing you to track 'good' data closely while discarding 'bad' data.

I've never seen a flight that would require any kind of 'ejection lockout', and because we fly redundant electronics much of the time, you really wouldn't want to count on that in any case -- when the other altimeter fires ejection charges, you still want to behave reasonably.

 

[JordanT]

All good info - thanks for all the input.

The reason I ask is that I'm considering a dual-deploy configuration for rockets with very short payload areas and large nosecones (like the 5" Jart). The configuration, however, would expose the payload bay to the apogee charge. Note: I'm trying NOT to build a custom AV setup for every single rocket I own, and partial exposure would allow me to share a single AV bay setup between no less than 4 rockets.

I suspect there are ways to program the Raven with the logic to avoid an early main deploy (with a time limit...I'll have to look). I went back and re-read the Adept data sheet, and there is a 2 second lockout after the first charge fires. .

 

[cvanc]

The configuration, however, would expose the payload bay to the apogee charge.

Do you mean the circuit board(s) would be directly exposed to ejection charge gasses? If so, that's really not a good idea. Those gasses are both electrically conductive and highly corrosive.

 

[JordanT]

No, it would be a vented AV bay located in the apogee compartment with a single vent hole exposing it to the bay. I'm considering a set of tests which would give me a base line for the pressure differentials experienced, using cloth filters in front of the port to buffer the spike and further reduce any debris that might find its way into the bay.

 

[mikec]

I suspect there are ways to program the Raven with the logic to avoid an early main deploy (with a time limit...I'll have to look).

I don't think there is. The time delays apply after the deploy condition is met, they don't cause a re-evaluation of the condition itself. If you have a leak larger enough to get past the filter that looks like it's below the main deploy altitude, it's going to fire. The only way around that I know of is to not use altitude at all for main deployment (just use a pure timer) but there are also limits on the maximum time delay.

If somebody knows a way around this I'd be very interested.

 

[mikec]

The reason I ask is that I'm considering a dual-deploy configuration for rockets with very short payload areas and large nosecones (like the 5" Jart). The configuration, however, would expose the payload bay to the apogee charge.

I'm currently working on something like this does doesn't expose the altimeter to the apogee charge, and that would be a better configuration if at all possible.

 

[JordanT]

My first inclination was to use a break-away tube to connect to an external static port, but that complicates things quite a bit.

 

[mikec]

If somebody knows a way around this I'd be very interested.

Come to think of it, if your time to apogee is less than 51.2 seconds from liftoff, you could add a tval> condition to your main deploy and that should lock out anything at apogee -- just use your time to apogee plus some margin.

 

[troj]

No, it would be a vented AV bay located in the apogee compartment with a single vent hole exposing it to the bay. I'm considering a set of tests which would give me a base line for the pressure differentials experienced, using cloth filters in front of the port to buffer the spike and further reduce any debris that might find its way into the bay.

You want to vent the av bay to the area that's pressurized inside the airframe? If so, I would suggest against that -- you want the altimeter to sense ambient outside air pressure, not the pressure inside the airframe.

The avbay needs to be vented to the outside, so that the pressure transducer can sense the rocket's altitude -- that way, it knows the air pressure on the pad, and at apogee, allowing it to determine when it has reached the desired altitude for firing the main.

-Kevin

 

[JordanT]

You want to vent the av bay to the area that's pressurized inside the airframe?

Oh, no - I'm going to vent the airframe, just as I would to prevent pressure separation. This allows me to put the vent holes further away from the nose transition. In both rockets I'm considering using this, there are only 1-2 diameters between the NC and the top of fins and/or motor casing. Not that it would matter much on the Raven, as I almost always use accel for apogee. I suppose a perfect seal would solve the main deploy issue, since the criteria for main is xxx' and increasing pressure - but perfect is for mathematicians, not engineers. ;-)

There's a possibility of reversing the system - capturing the altimeter in the body rather than the nose - and adding an additional bulkhead. This would be closer to Adrian Adamson's single bulkplate deploy idea, but at least on paper it adds some complexity and is a bit more complex to assemble.

 

[mikec]

This allows me to put the vent holes further away from the nose transition.

The design I'm working on -- a 38mm MD -- has the Raven in the nose cone with an aft-facing chute cannon. The vent hole is just below the nose cone seam and is sealed from the apogee side. I wasn't expecting the barometric to be right given the vent location and am going to use accel apogee detection. I'm going to try flying it this weekend and if it works I'll post photos -- if it doesn't work, it won't be useful except as an example of what not to do

 

[JordanT]

Experience is what you get when you don't get what you want.:lol:

FWIW, there was a post on one of the high altitude flights (Carmack prize?) that said the accelerometer apogee was short of the actual apogee by a percent or so. Probably a limitation of the discrete sampling rate. I can't remember all of the details, just that it would have cut the flight short at 99xxx' had the relied solely on it.

None of the designs I'm working on are high-performance flights, and I doubt I'll be flying any of them more than a mile up. It's mostly for fun, and to work on new stuff (for me) like airstarts and clustering without having to spend most of my launch-day time walking.

Good luck with your flight!

 

[Rocketjunkie]

In my upscale Goblin, the avbay is in the base of the nose cone. It vents into the main body which is vented to the outside. The altimeter sees the full apogee ejection pressure spike. (The charge is about 3 feet away from the avbay so the pressure is from clean air.) I use a Perfectflite altimeter which I know ignores the short pressure spike (as much as equivalent to 9000' altitude drop). How I built the Goblin is at https://www.rocketryforum.com/showthread.php?8709-Almost-a-Goblin

 

[UhClem]

FWIW, there was a post on one of the high altitude flights (Carmack prize?) that said the accelerometer apogee was short of the actual apogee by a percent or so. Probably a limitation of the discrete sampling rate.

The problem is the sensor and micro-controller and it was much worse than a percent or so.

The two sustainer Raven units showed accelerometer-based apogee at 15 and 25 seconds in advance of baro apogee, respectively. This further confirmed to us that the Raven's accelerometer is not suitable for apogee detection.

page 61 Note that this a a test flight to ~33,000'.

Operating a 5V sensor at 3.3V is rarely a good idea. While the data sheet claims it is functional at that voltage it says absolutely nothing about how well it works. Specifications apply only when at the recommended operating voltage.

When I looked up the specifications of the ADC on the Z8 micro-controller I was shocked at just how bad they are.

 

[JordanT]

In my upscale Goblin, the avbay is in the base of the nose cone. It vents into the main body which is vented to the outside. The altimeter sees the full apogee ejection...

Thanks for the link! That's close to what I'm planning, the only difference is putting a 3" tube into the nose of both my 4" Sea Wolf and my 5" jart, then using my 3" dark star AV bay instead of custom building an AV bay for each bird. The same bay should also work in my PML AMRAAM.

I'll still probably run a couple of tests single deploy and likely just take data (or go timer only) on the first couple of flights.

 

[cerving]

Virtually all of the integrated baro sensors are rated to about 30,000' or so CALIBRATED. Above that, you're out of the manufacturer's spec so all bets are off. If you need a high altitude baro, you have to use a separate analog sensor and ADC, and very carefully calibrate it. It really doesn't matter what MCU you use, the sensor is much slower than any MCU, even an ATTINY at 1 MHz.

+1 on the 3.3v part running at 5v. I'm a little suspicious of "5v-tolerant" parts rated at 3.3v nominal. Most high-G accel chips are 5v parts but everything else on the board probably runs at 3.3v. You need level-shifting circuitry to make them talk to each other, or if the accel chip is analog you can trim it down with an op amp and still retain full scale.

[Soapbox alert...] My personal belief is the baro-only flight computers are fine for DD with MPR/L1 rockets and lower power/weight L2 rockets since they rarely hit Mach 1 and generally fly under 10,000'. The reality is that this represents 90% of the flights that most hobbyists attempt. Supersonic flights are best done with a computer using a high-G accel chip to lockout deployments until near-apogee. Once you get there, the baro will be just fine for the descent, assuming that you haven't exceeded its pressure range.

The problem is the sensor and micro-controller and it was much worse than a percent or so.


page 61 Note that this a a test flight to ~33,000'.

Operating a 5V sensor at 3.3V is rarely a good idea. While the data sheet claims it is functional at that voltage it says absolutely nothing about how well it works. Specifications apply only when at the recommended operating voltage.

When I looked up the specifications of the ADC on the Z8 micro-controller I was shocked at just how bad they are.

 

[bobkrech]

In the past the MEMS pressure chips used in most altimeters were a 1970s era industry standard analog MEMS sensor with an integrated amplifier. While the sensor was good to over 100 KFT the internal analog amplifer design was poor and limited the altitude to ~35 KFT.

An exception was Adept who used the sensor element only version and their own custom amplifier so many of their unitis are calibrated and operated properly to 100 KFT.

Over the past several years many altimeter manufacturers started using modern digital pressure sensor chips that are entirely different and will function properly at altitudes to 100 KFT. The real problem now is the accuracy of the conversion of a pressure reading to an altitude.

At 30 KFT a pressure derived altitude measurement could be off by +/-300 ft or 1% and still be within the calibrated acceptable range and the errors increase with altitude. GPS and radar are more accurate so these methods are used for precision altitude measurem at these altitudes.

Bob

 

[cerving]

It' kinda funny that NAR only certifies baro-only computers for contests and records. No GPS units are certified yet. I guess that's why you have to break an existing record by at least 2%, they figure that it covers the error band in the two readings.

1% error is certainly acceptable for deployments, especially for sub-mach and relatively low-altitude (under 10,000') flights. I'd be looking real hard at a GPS/accel unit for a L3 flight, though. Once you're into that kind of money, a few hundred dollars more for the flight computers doesn't amount to a hill of beans.

 

[bobkrech]

It' kinda funny that NAR only certifies baro-only computers for contests and records. No GPS units are certified yet. I guess that's why you have to break an existing record by at least 2%, they figure that it covers the error band in the two readings.

Not really. Most of NAR's existing records are for model rockets and there isn't a model rocket that will exceed 30 kft however it is easy to build a calibration facility for barometric altimeters to over 100 KFT.

There is no easy way to calibrate a GPS altimeter inexpensively that I am aware of.

1% error is certainly acceptable for deployments, especially for sub-Mach and relatively low-altitude (under 10,000') flights. I'd be looking real hard at a GPS/accel unit for a L3 flight, though. Once you're into that kind of money, a few hundred dollars more for the flight computers doesn't amount to a hill of beans.

You are confusing precision and accuracy. The digital barometric pressure gauges are extremely precise and accurate however the conversion of pressure to density altitude to actual altitude is subject to a lot of natural variation as it is sensitive to both base level atmospheric pressure and temperature, the temperature gradient with altitude, humidity, and weather fronts. GPS is not effected by any of these natural phenomenon however it is very sensitive to the internal almanac data, the relative position of satellites, RF atmospheric propagation, time and acceleration. Any random GPS fix is good to about +/-5 meters in altitude if you have 6 satellites with 1 overhead. Without 1 over head the accuracy will drop to about +/-50 meters.

A barometric altimeter will correctly deploy at apogee if the programing algorithms are properly written since apogee is only determine by the minimum pressure observed. The assignment of altitude corresponding to that pressure can be in error by 1% or more depending on the atmospheric model and temperature measurements employed in the conversion algorithm.

The best apogee detection systems today below 100 kft are still barometric based.

Bob

 

[ClayD]

I see pressure increase from apogee charges often (not always), because, the seperation point of the rocket, and the vent holes are in close proximity. So for that millisecond in time, when the avbay is separating from the booster section, there is a pressure increase that no matter how well the bay is sealed, the pressure sensor will sense the charge-to be precise, the "pressure increase" from separation.

Directly exposing you sensor to ejection charge pressure is not something i would do... unless its something i wanted to measure... I would probably get a 100psi transducer for that, not a flight computer...

 

[cerving]

All of the integrated baro sensors are relatively precise, typically 20-24 bits. The accuracy is of course what is in question; since you're taking readings while the rocket is moving at a pretty good clip while going upwards there IS going to be some error, no matter what the precision may be. When the accuracy error exceeds the precision of the sensor, the precision no longer matters. It's like truncating to significant digits; your final value is only as good as the least accurate data element used in computation.

Going down you're not moving very fast, so the baro error is much less. As I have stated, the best high-altitude baro systems use separate sensors and ADCs, but not many of us have the means to launch something up to 100kft so the cheaper baro systems work fine for most sport launches.

As far as determining apogee, yes, all you have to do is look for the lowest pressure and wait a second or so to make sure that it's not going any lower. Once you get there, you can pop the drogue. It's actually harder to do with accel because the rocket kinda floats around near apogee compared to ascent/descent, the G's drop to a small negative number then they might to slightly positive as the rocket noses over, but it's kind of a crapshoot because you don't have any way of knowing which way your rocket was pointing at the time. If your rocket was overstable and had significant horizontal component near apogee it becomes tougher. The trick is figuring out where the transition likes, which is where Kalmann filters and the like come into play. I can see somebody using a gyro chip in the near future along with an accel to figure out very accurately when the rocket starts moving downward, regardless of forward velocity.

Not really. Most of NAR's existing records are for model rockets and there isn't a model rocket that will exceed 30 kft however it is easy to build a calibration facility for barometric altimeters to over 100 KFT.

There is no easy way to calibrate a GPS altimeter inexpensively that I am aware of.


You are confusing precision and accuracy. The digital barometric pressure gauges are extremely precise and accurate however the conversion of pressure to density altitude to actual altitude is subject to a lot of natural variation as it is sensitive to both base level atmospheric pressure and temperature, the temperature gradient with altitude, humidity, and weather fronts. GPS is not effected by any of these natural phenomenon however it is very sensitive to the internal almanac data, the relative position of satellites, RF atmospheric propagation, time and acceleration. Any random GPS fix is good to about +/-5 meters in altitude if you have 6 satellites with 1 overhead. Without 1 over head the accuracy will drop to about +/-50 meters.

A barometric altimeter will correctly deploy at apogee if the programing algorithms are properly written since apogee is only determine by the minimum pressure observed. The assignment of altitude corresponding to that pressure can be in error by 1% or more depending on the atmospheric model and temperature measurements employed in the conversion algorithm.

The best apogee detection systems today below 100 kft are still barometric based.

Bob

 

[Adrian A]

Not for the Raven, no. The channels are completely independent. If your bay is very leaky you can fool a Raven into deploying main at apogee with the normal settings, though it takes a significant leak to get past its noise filtering.

I'm not sure if other altimeters use lockout logic, but it would make a certain amount of sense to do so.

I can confirm this with my Raven 3s. It was a pretty significant leak - the apogee charge pressurized the AV bay - and it was enough to trigger the main/700' channels. I do not know if there is any filtering in the firmware, but for sure at some point any filtering that may exist can be swamped if the leak is big enough.

I wonder about a timed lockout of 'x' (one second or so?) on the lower altitude channels triggered by the firing of any apogee channel. Assuming you are flying well above the lower altitude threshold that sounds like an interesting approach to me.

It would be interesting to know if any altimeters are doing some form of apogee lockout. For a simple dual-deploy altimeter with minimal configurability it would be trivial to add it.

I've never seen a flight that would require any kind of 'ejection lockout', and because we fly redundant electronics much of the time, you really wouldn't want to count on that in any case -- when the other altimeter fires ejection charges, you still want to behave reasonably.

Agreed. A lot of people fly redundant altimeters, and in those cases there will be events that happen from one altimeter that the other one doesn't know of ahead of time, so a lockout based on its own apogee detection wouldn't be effective.

In the case of the Raven, the default settings have 2 baro-related checks that are done before main deployment: A heavily-filtered "pressure increasing" check, and a lightly-filtered current altitude check. Pressure spikes near apogee are routine, but only in the very worst cases do they cause both baro triggers to come true. When the rocket is near apogee at a much higher altitude than the main deployment altitude, it takes a really bad blow-by event to make the altimeter think it has lost all of that altitude. I've been known to be not very careful about sealing up the av-bay, but the Raven ignored the spike anyway. One example that I have data for from a flight where the apogee charge did cause the main charge to fire prematurely is a case where the two rocket sections that were supposed to separate from the apogee charge didn't, so the extra gas had nowhere else to go, and was continuing to pressurize the av-bay over several seconds.

If there is an accidental pressurization event at lower altitude, like a staging ejection, the "pressure increasing" check is effective at filtering those out.

As a general philosophy, I tend to avoid trying to code in special cases or exceptions like this because it makes it harder for the user to anticipate what the altimeter will do, and interpret what happened after the flight.

The design I'm working on -- a 38mm MD -- has the Raven in the nose cone with an aft-facing chute cannon. The vent hole is just below the nose cone seam and is sealed from the apogee side. I wasn't expecting the barometric to be right given the vent location and am going to use accel apogee detection. I'm going to try flying it this weekend and if it works I'll post photos -- if it doesn't work, it won't be useful except as an example of what not to do

I have done designs like this too, and as long as you ignore baro data during the high-speed portion of the flight, the baro works fine when the rocket is moving slowly near apogee and during descent.

 

[bobkrech]

All of the integrated baro sensors are relatively precise, typically 20-24 bits. The accuracy is of course what is in question; since you're taking readings while the rocket is moving at a pretty good clip while going upwards there IS going to be some error, no matter what the precision may be. When the accuracy error exceeds the precision of the sensor, the precision no longer matters. It's like truncating to significant digits; your final value is only as good as the least accurate data element used in computation.

You are only considering samplng accuracy for pressure which depends on the rate of climb, acoustic time constant of the altimeter compartment, and altimeter sampling rate. What is more relevant for accuracy is the conversion of barometric pressure to altitude which requires that you know base altitude and temperature, and the temperature profile versus temperature. If you are not measuring the temperauture at altitude you can be way off on altitude even if you measure the pressure with no error.

Going down you're not moving very fast, so the baro error is much less. As I have stated, the best high-altitude baro systems use separate sensors and ADCs, but not many of us have the means to launch something up to 100kft so the cheaper baro systems work fine for most sport launches.

Again you are talking about sampling error due to insufficient acoustic time constant not barometric error. Your are within 4' of apogee for 1 second and withi 16' for 2 seconds around apogee on all rocket flights so the acoustic time constant of the altimeter compartment should not be an issue. In actuality noise is what limits simple rapid apogee detection so modern altimeters run a Kalman filter (predictor/corrector model) that uses the barometric pressure changes to predict the next pressure value and corrects that prediction to predict the following point. Dave Schultz (UnClem) has described exactly how Kalman filters work for apogee detection in several award winning NARAM research papers.

Integrated digital pressure sensors are inexpensive and are replacing individual analog pressure sensor chips followed by adc's because they are cheaper more accurate and output pressure or altitude directly. All current PerfectFlite altimeters which range in price from $40 to $80 use them and are rated to 100 kft and are more accurate and have greater dynamic range than earlier versions which were good to begin with. They also employ a Kalman filter so a mach inhibit timer is not required to avoid deployment in the transonic region.

As far as determining apogee, yes, all you have to do is look for the lowest pressure and wait a second or so to make sure that it's not going any lower. Once you get there, you can pop the drogue. It's actually harder to do with accel because the rocket kinda floats around near apogee compared to ascent/descent, the G's drop to a small negative number then they might to slightly positive as the rocket noses over, but it's kind of a crapshoot because you don't have any way of knowing which way your rocket was pointing at the time. If your rocket was overstable and had significant horizontal component near apogee it becomes tougher. The trick is figuring out where the transition likes, which is where Kalmann filters and the like come into play. I can see somebody using a gyro chip in the near future along with an accel to figure out very accurately when the rocket starts moving downward, regardless of forward velocity.

Your idea on apogee detection is not used very often because of the inherent delay in detection. Kalman filters don't have significant delays. The noise on an accelerometer makes it difficult to predict apogee directly and off vertical flights are problematic. Barometric apogee detection is more accurate and more straight forward.

Bob