Looking for supersonic barometric altimeter data

[Andrew Bullock]

Hi,

Would any of you lovely folk be able to share some barometer based flight data with me where your rocket travelled supersonic?

I'm trying to understand the effects of supersonic speed on barometric altimeters.

I understand that the air behind the shock is likely to be subsonic and at higher pressure, therefore leading to a wrong altitude reading, but I'm curious to know quantitatively what this looks like.

Some possible scenarios to illustrate my ignorance:

1) Does the pressure behind the shock remain ~constant regardless of altitude at supersonic speeds? Presumably not, but if so, what pressure is it? How does it relate to speed and altitude?

2) Does the pressure become some arbitrary level?

3) Does the pressure directly correlate with true subsonic altitude, but some % different?

4) What happens when you slow down from super to subsonic, is the pressure transition instant or does it converge as the speed decreases?

5) Many more variations!

I'm hoping some graphs can illuminate me

Many thanks

Andrew

 

[OverTheTop]

If you download AltoOS from altusmetrum.org you can look at the baro data on this flight.
The baro ports are just where the NC goes to the main airframe in this case.

 

[SparkyVT]

Andrew,

In my experience, the barometric pressure during supersonic flight still follows the altitude, but not as well. After supersonic flight the data recovers pretty quickly. If you PM me I'll send you a few Excel files of flights in the Mach 1.4 - 1.9 range. My system collects a LOT of data, approximately 5-10 million data points per flight, so each file is about 20MB. Too big to post.

 

[jderimig]

The red line is a mach 2.4 flight. IT went Mach early (around 1-2 second but you can see where it crossed mach 1 during the coast. The electronics and venting were on the nose cone in this rocket.

 

[AllDigital]

Most of my data looks something like this altitude chart derived from barometric pressure. The "dip" and recovery all depends on the flight profile, when it hits Mach 1 and how fast it is going through it. Generally, it is a "dip and then recovery". It could be more immediate off the pad or closer to motor burn out with a progressive burn. This is why it is important to always have an appropriate "mach lock-out" period on any events that could be triggered by your barometer. If you were purely going off of the baro you would have thought you hit apogee at .4 seconds.



This is a "zoom in" on a flight that hit mach right off the pad. It looks like it crawled off the pad, but you could actually hear the sonic boom as it left the rail.

 

[Andrew Bullock]

@AllDigital thanks. A mach-lockout implementation is actually where I'm going with this.

I'd like to be able to detect motor burnout in addition to apogee, so tuning the implementation to be mach-transition-insensitive will be key.

I've seen how Eggtimer do it, was hoping to be able to be a bit more sensitive

 

[jderimig]

You want to detect motor burnout using Baro data?

 

[Andrew Bullock]

You want to detect motor burnout using Baro data?

Yeah why not? Acceleration should become -g

 

[UhClem]

Yeah why not? Acceleration should become -g

Because baro sensors are awful at measuring acceleration. Particular when there are sensors available designed to do just that. Without doing two numerical differences.

The best example of Mach 1+ data I have seen I used for Figure 4 of a NAR R&D report. That flight spent a long time above Mach 1 so the transitions are quite clear.

 

[OverTheTop]

Yeah why not? Acceleration should become -g

Data might be confounded by Mach transition if they occur contemporaneously. Dont forget to consider all edge-cases if you are going down this route.

 

[Worsaer]

This from a 4" Performance Rocketry Nike Smoke on a K1440.

 

[cerving]

Because baro sensors are awful at measuring acceleration. Particular when there are sensors available designed to do just that. Without doing two numerical differences.

The best example of Mach 1+ data I have seen I used for Figure 4 of a NAR R&D report. That flight spent a long time above Mach 1 so the transitions are quite clear.

Yup... that's why we don't give an acceleration figure in our baro-only altimeters. We DO give you an "average acceleration" figure from launch until the velocity delta starts to decrease (a poor-man's burnout indicator)... but that's only reasonably accurate for non-mach flights. With the Proton's accelerometer, you're measuring acceleration directly, so it's pretty accurate.

 

[cerving]

This from a 4" Performance Rocketry Nike Smoke on a K1440.

View attachment 505435

That's a pretty classic graph for a mach flight. That's why we do the baro qualification for deployments, < |100 fps| for over 1 second. That won't happen with a "mach dip" because the baro velocities are way outside those bounds. Once you've hit that qualification, you can be assured that the highest recorded baro altitude that you get is your apogee, and you can base your deployments on that point.

 

[AllDigital]

Yeah why not? Acceleration should become -g

No amount of baro data is going to give you reliable motor burn-out data. On the other hand, an accelerometer will tell you within a millisecond when you have motor burn-out. Accelerometer data is (almost) as good as using pressure/load calculations to characterize a motor.

 

[rocket_troy]

Accelerometer data is (almost) as good as using pressure/load calculations to characterize a motor

How do you account for the drag force contribution? If you're only relying on accelerometer data, you'll need to integrate in a flight profile from that data with the mass loss of propellant consumption included. Certainly doable and perhaps even automatable, but there's quite a few critical measurements with masses, CD and whatnot that need to be factored in to produce something as reliable as direct force or pressure measurement.

Edit: I'm assuming here we're talking about characterizing motors from accelerometer data, but I might be reading it wrongly (again).

TP

 

[jderimig]

How do you account for the drag force contribution? If you're only relying on accelerometer data, you'll need to integrate in a flight profile from that data with the mass loss of propellant consumption included. Certainly doable and perhaps even automatable, but there's quite a few critical measurements with masses, CD and whatnot that need to be factored in to produce something as reliable as direct force or pressure measurement.

Edit: I'm assuming here we're talking about characterizing motors from accelerometer data, but I might be reading it wrongly (again).

TP

After the motor burns out the deceleration can be used to estimate the Cd as a function of speed.

 

[jderimig]

No amount of baro data is going to give you reliable motor burn-out data. On the other hand, an accelerometer will tell you within a millisecond when you have motor burn-out. Accelerometer data is (almost) as good as using pressure/load calculations to characterize a motor.

An accelerometer will tell you within a millisecond when the acceleration goes negative but the motor can still be burning (thrusting) at that point.

 

[AllDigital]

An accelerometer will tell you within a millisecond when the acceleration goes negative but the motor can still be burning (thrusting) at that point.

Correct. The same is true when I do a vertical static fire with a load cell. To be accurate, you have to factor in the weight of the motor and the propellant over the course of the burn. When the load cell measures zero, the motor can still be burning (thrusting) and registering pressure, but not enough to lift 15 pounds of casing and remaining propellant onto the cell. The same is true when analyzing the accelerometer data in flight, but the mass of the rocket and drag need to be accounted for.
That said, I've got a bates motor that I've characterized on the stand three times that always burns with the same profile for 3.9 seconds. Accelerometer "burn-out" (neg acceleration) on flights (dozens of them) almost always comes in around 3.85 seconds. The accelerometer curve almost always matches the pressure/load curve on the stand. If there are anomalies in the motor burn, I see it in the accelerometer data. For staging and other real-time measurements that depend on burn-out, I always add one second to be safe.

 

[jderimig]

Sure, in-flight data can give you a decent estimate estimate of motor performance. Marsa Connect provides this feature and gives decent results. But it is much easier to get an accurate characterization from test stand data than flight data because there are many more sources of error in a flight data characterization that need accounting for. These include:

1. A test stand load cell is much easier to calibrate over its range than an accelerometer. A 1g calibration may not be sufficient.
2. The drag force versus speed needed for flight characterization is a power-off measurement which is different than a power-on drag force.
3. Need a mostly vertical flight unless the body frame to earth frame acceleration is accounted for with an accurate tilt measurement.

For a horizontal test stand you need to;
1. Calibrate the load cell.

For a vertical load cell firing up:
1. Calibrate the load cell.
2. Interpolate starting and ending weight to account for mass during burn.

 

[rocket_troy]

*If* you could accurately account for the drag force and you were meticulous with weight measurements of both wet and dry mass and dealt with tilt angles carefully (all big IFs); the acquisition of the motor performance might provide some additional dynamics not available on the test stand ie. the effect the interaction of the exhaust with the base of the rocket and the effect of altitude on nozzle performance (which should have a positive influence on performance) albeit subtle influences for most typical HPR flights.

TP

 

[jderimig]

*If* you could accurately account for the drag force and you were meticulous with weight measurements of both wet and dry mass and dealt with tilt angles carefully (all big IFs); the acquisition of the motor performance might provide some additional dynamics not available on the test stand ie. the effect the interaction of the exhaust with the base of the rocket and the effect of altitude on nozzle performance (which should have a positive influence on performance) albeit subtle influences for most typical HPR flights.

TP

Also burn rate is affected by rocket dynamics. Usually faster under acceleration.

 

[rocket_troy]

Also burn rate is affected by rocket dynamics. Usually faster under acceleration.

Yup, indeed it is - both axially and gyroscopically (for want of the correct term).

TP

 

[rocketace]

Here are two of mine zoomed in. The first is cropped not long after motor burn out, the second is cropped right after apogee.

 

[Joshua Smith]

Yup, indeed it is - both axially and gyroscopically (for want of the correct term).

TP

"radially" maybe?

 

[Andrew Bullock]

Thanks all for your responses, thats really helpful.

Sorry for the slow reply, got distracted.

@cerving Thanks too, I was reading the Quantum manual and I can see you wait until the velocity is arbitrarily low before arming deployment channels. Not that I doubt the implementation of course, I was simply wondering how you'd arrived at such an arbitrary value. With my original ignorance, "waiting for the velocity to be low to know you've not above mach" could be problematic, depending on how the baro data behaves. I can now see from the data above how this makes sense

 

[cerving]

Thanks all for your responses, thats really helpful.

Sorry for the slow reply, got distracted.

@cerving Thanks too, I was reading the Quantum manual and I can see you wait until the velocity is arbitrarily low before arming deployment channels. Not that I doubt the implementation of course, I was simply wondering how you'd arrived at such an arbitrary value. With my original ignorance, "waiting for the velocity to be low to know you've not above mach" could be problematic, depending on how the baro data behaves. I can now see from the data above how this makes sense

Empirical trials... lots of them. There's a secondary mechanism in the later builds that's triggered by apogee... it's also velocity-related, but the threshold is higher, that's to prevent very noisy baro data from keeping the low-velocity trigger from working. Neither one of them can be triggered by a mach-dip.

 

[Adrian A]

*If* you could accurately account for the drag force and you were meticulous with weight measurements of both wet and dry mass and dealt with tilt angles carefully (all big IFs); the acquisition of the motor performance might provide some additional dynamics not available on the test stand ie. the effect the interaction of the exhaust with the base of the rocket and the effect of altitude on nozzle performance (which should have a positive influence on performance) albeit subtle influences for most typical HPR flights.

TP

I used to do this a lot a few years ago, and I can confirm that in-flight thrust curves are noticeably different than the published data. The method I used was:

1. Use the coast period to calculate the coefficient of drag (Cd) as a function of velocity, including the estimate of air density as a function of altitude
2. Calculate the drag force during the burn, looking up the Cd based on velocity, and the air density based on altitude.
3. Calculate the motor mass during the burn, assuming that mass loss rate during the burn is proportional to the thrust. This can be a little tricky and iterative because you have measurements of the acceleration rather than the thrust, which is what you're trying to calculate. I did it by picking a mass loss coefficent and adjusting it until the total mass lost was correct by the end of the burn.
4. Then the thrust at each point during the burn is the measured acceleration/mass, plus the aero drag.

The tilt angle doesn't really factor in to first order, because the acceleration you're measuring is along the rocket axis whether it's tilted or not. It has a small effect on the altitude estimate you're using for the air density calculation.

I have been thinking about automating this analysis for years; I might do it in the app for the upcoming Blue Raven.