Funny Looking Altimeter Data

[BradMilkomeda]

I am beginning to get into dual deployment. So for a first experiment, I just used a Perfect Flight StratoLoggerCF Altimeter just for recording data without it controlling deployment. Here is the chart:

This was in a 3" Loc Athena on an H165R-8 with an ~7" avionics bay which has 4 5/64" sampling holes. Which is inline with the documentation for the altimeter. Here is the raw data from the outlier section:

9.20, 752, -37, 78.01, 9.20​

9.25, 751, -19, 78.01, 9.20​

9.30, 408, 29, 78.01, 9.20​

9.35, 732, 97, 78.01, 9.20​

9.40, 760, 167, 78.01, 9.20​

9.45, 775, 224, 78.01, 9.20​

9.50, 781, 233, 78.01, 9.20​

9.55, 829, 172, 78.01, 9.20​

9.60, 772, 56, 78.01, 9.20​

9.65, 774, -81, 78.01, 9.20​

9.70, 790, -200, 78.01, 9.20​

9.75, 770, -255, 78.01, 9.20​

9.80, 740, -238, 78.01, 9.20​

9.85, 724, -177, 78.01, 9.20​

9.90, 747, -112, 78.01, 9.20​

9.95, 759, -73, 78.01, 9.20​

10.00, 750, -81, 78.01, 9.20​

10.05, 754, -121, 78.01, 9.20​

10.10, 719, -158, 78.01, 9.20​

10.15, 710, -177, 78.01, 9.20​

10.20, 704, -169, 78.01, 9.20​

10.25, 697, -134, 78.01, 9.20​

10.30, 695, -97, 78.01, 9.20​

The chart shows at (late) motor deployment a significantly low outlier, followed by several higher. Is this and indication that the holes in the bay are not proper? Would it be a problem using it for dual deployment?

It seems that the recommendation by perfect flight is smaller than many I have read about. If the vents are smaller is may case some delay/discrepancy in the true altitude vs. the sensor data. My understanding is that the small port would add some type of "capacitance" to the bay's air pressure, which may be good to filter out wind on the launch pad?

 

[Nytrunner]

Motor deployment looked alright to me. Burn of 1 second, 8 second delay (if drilled properly) ~little wiggle room.

Are you sure your bay was sealed properly? a pressure spike could fool the sensor into saying "low"altitude.

 

[GrouchoDuke]

+1 Looks to me exactly like the av bay isn't sealed (separated from where the BP went off).

 

[BEC]

Or it took quite a shaking at deployment. G-forces can mess up the readings like that as well. For me that looks like a late deployment with a rather violent shaking as things got out and the ‘chute opened.

Notice that the reported apogee filtered that spike out.

I have a bunch of Pnut data from LPR and MPR models without any leakages into the payload compartment that look like that, though that is a fairly extreme-looking example.

But it could certainly also be pressure leakage as others have suggested.

 

[BradMilkomeda]

I can’t imagine there being any leakage. I gave made any hole for the ejection cups yet, and it quite s snug fit around the bulk head. I didn’t use any thing to seal around the all thread screws or the eye bolt, but the were tight too. I’ll have to done how test this tonight.

It certainly was a rough ejection with the late charge and the weather cocking causing a lateral velocity. It is not clear to be how G-forces would directly effect a the pressure sensor. Thanks for letting me know it looks extreme to you too.

 

[cerving]

External deployments (either motor eject or another altimeter) almost always generate a spike like this, due to the g-forces and/or the sudden pressure change as the AV bay separates from the body tube. The magnitude depends on a lot of things, but if you use shear pins you're likely to get a bigger spike because the separation isn't as gradual. You have to be cognizant of the mechanism that you're using to measure your altitude, either pressure or accelerometer... either one is subject to artifacts. In this case, it lets you know when your motor eject happened, so it's a good thing... it's an additional piece of data that you wouldn't have gotten otherwise.

BTW, I also concur that you may have had some leakage... the spike goes down first, which means that the pressure increased when the charge fired.

 

[manixFan]

I've done a lot of altimeter data analysis and have even written a program to extract and filter data a variety of ways. Without seeing your setup it's hard to say where the leakage is but the data doesn't lie, something is causing those peaks. One thing that I've seen is gas leaking between the A/V bay and the body tube if the unit is setup as a coupler, which is how I do mine. I also seal any opening, including the all-thread and eyebolts with neoprene (or similar) washers. If I have bare wires I'll use sticky-tack to plug the hole. That was based on my testing trying to pull a vacuum through a single vent hole. Without seals there are a lot of places air can get in and we are dealing with some pretty big pressure spikes.

But it is possible it is just caused by the violence of the late deployment. I've seen data that was very noisy caused by pieces bumping into each other during descent. Add in the wind and weathercocking and it doesn't seem that odd, other than the duration of the recovery back to good samples. A picture of the recovery bay might help.


Tony

 

[Nytrunner]

I'm interested in how the violent deployments trigger a rogue barometric reading. Do the new sensors have a diaphragm that gets screwed with by high magnitude impulses?

 

[manixFan]

I'm interested in how the violent deployments trigger a rogue barometric reading. Do the new sensors have a diaphragm that gets screwed with by high magnitude impulses?

Imagine driving down the highway at 70mph with your hand out the window like an airplane wing. Now tilt your hand around quickly. Feel that differing airflow? High pressure on one side and low on the other. From what I can tell violent or high speed deployments create pressure imbalances that are picked up by the baro sensor. They may be affected by G-forces as well but I'll let someone with baro sensor knowledge speak to that. I've shot lots of video of rockets over the years including my own. I'm never surprised when I see very noisy deployment data if the deployment looked rough.

Also keep in mind that BP does not burn instantly. It's possible that as the coupler separates gas can flow past the baro opening during the actual deployment and affect the pressure reading as well. I try to keep my vent holes way from the coupler line.


Tony

 

[woferry]

The barometric sensor is ultimately a mechanical device, i.e. moving parts (or at least different forces being applied to a part, so the "movement" may be extremely small). So if you can induce sufficient forces in the right direction it should look like a momentary pressure change. The masses should be small enough that it would take something pretty extreme though, I'd think, but that's just a gut feel, they do have to be extremely sensitive to detect air pressure differences of a few feet. The fact that (at least in my avionics bays) the sensor is mounted perpendicular to the direction the sled is going to move presumably helps, though by the time the bay is at the far end of the shock cord it might 'snap' in less ideal orientations. If you happened to mount the altimeter so that the PCB faced flat-side up/down instead of sideways (i.e. a larger bay and mounting to the bulkplate rather than a vertical sled) I'd think that might make things worse for the sensor.

Another thing I'd throw out there is what I think of (probably because someone else called it) as the 'piston effect'. You have a column of air in the av bay, and whenever the bay suddenly accelerates in any direction that air is going to want to resist that motion (Newton's first law, the walls of the bay being the thing acting upon the air mostly-trapped inside, save for the vent holes). So this can result in pressure differentials inside the bay, and depending on where the sensor is in the bay I'd think it could pick that up. This is more commonly seen during lift-off, where again the sudden upwards motion of the rocket (if the motor provides sufficient G-force) pushes the air towards the bottom of the av bay, so if the av bay volume is large and the sensor is near the top it will see an exaggerated pressure drop, and if the sensor is near the bottom the pressure might even increase before it starts to decrease with the rising altitude. Same thing should hold true for the bay even once it's in flight, if it suddenly accelerates/decelerates due to charge firing and reaching the end of the shock cord, you'd get the same sort of pressure changes inside the bay (whether it's more or less than lift-off I'd think just depends on the G-forces involved in separation vs. lift-off). I guess having vent holes placed near the top & bottom ends of the av bay would help let the air in/out where it needs to go rather than creating localized areas of high/low pressure, but I think most of us just have a set of holes in a circle around the av bay, probably usually near the middle.

 

[BEC]

The barometric sensor is ultimately a mechanical device, i.e. moving parts (or at least different forces being applied to a part, so the "movement" may be extremely small). So if you can induce sufficient forces in the right direction it should look like a momentary pressure change.

This is my understanding of why a violent ejection looks like what we see in in the graph in the first post from barometric sensor-based recording altimeters.

In the only data I have from a device that has both (AltimeterThree) there are spikes in the accleromter data at the same spot. Let me see if I can find a graph that shows this and add to this post. But - the AtimeterThree software does a great job of filtering spikes like that out of the altitude (baro) data so I might not be able to find one with spikes in both the altitude and acceleration data.

 

[jderimig]

That upward spike in pressure (500feet) was instantaneous. That happened before the av-bay could have reached any appreciable velocity, F=ma and all that. Accelerometer spikes can be instantaneous but velocity spikes cannot be. So I am skeptical of motion induced effects on the baro. The latter positive spike does follow the motion pattern because is it more "spread out".

My opinion is you had a instantaneous pressure spike inside theavebay or a electrical or software problem. It could be a solitary point in that plot that caused that spike. Also pressure doesn't behave that way either.

 

[BradMilkomeda]

Thanks for all the good perspective on this issue. Here pictures of the end of the avionics bay, to show how it it sealed:



This is my first bay, and I just went with the Loc kit. It has a stiffy tube in side the couple so it forms a really tight seal. Also note I have not drilled any holes for the ejection, yet.

To test the seal of the bay, I assembled the bay, taped over the vent ( not sampling ) hole in the body tube, then stick a shop vac into the motor tube to produce a suction for 30 seconds. The SLCF altimeter did not detect a launch. So I am concluding there was not significant leakage during deployment. To validate the setup, I closed two of the bay's sampling holes, and applied suction to another. This was detected as a launch. The downloaded data show it took about 2 seconds to peak at 350 ft, where the vacuum stood, and then took ~.15 seconds to return to normal presume when the vacuum was removed.

 

[manixFan]

That upward spike in pressure (500feet) was instantaneous. That happened before the av-bay could have reached any appreciable velocity, F=ma and all that. Accelerometer spikes can be instantaneous but velocity spikes cannot be. So I am skeptical of motion induced effects on the baro. The latter positive spike does follow the motion pattern because is it more "spread out".

My opinion is you had a instantaneous pressure spike inside theavebay or a electrical or software problem. It could be a solitary point in that plot that caused that spike. Also pressure doesn't behave that way either.

A couple of points:

* OP is just recording data not controlling ejection, so the indicated events are not reality - the motor ejection clearly happened before the spikes, the indicated M is just based on when it should have deployed, not when it actually deployed

* the StrataloggerCF only records at 20 hertz, so nothing can be said to be 'instantaneous' - a lot can happen in 1/20th of a second

I have 4 of the altimeters in question and have seen data that looks very similar on numerous occasions - a sharp spike followed by a recovery - at both apogee and main deployment. But certainly not on every flight. My PF's are nearly always a backup to an accelerometer based altimeter in a redundant dual-deploy setup. So I can correlate the PF readings to accelerometer data. The spikes aways occur during the ejection event. That leads me to believe the results are based on real world events. Whether or not it's caused by ejection charge or aerodynamic forces I don't know. In any event since it happens after the deployment event it has no effect other than to make a messy looking graph.


Tony

 

[Buckeye]

the motor ejection clearly happened before the spikes
Tony

The motor ejection occurs during the spikes. Typo above?

Since no deployment event was set for the main, how did the altimeter know where to place the "M"? It did a good job of placing it at the beginning of ~constant descent under chute!

 

[Nytrunner]

The motor ejection occurs during the spikes. Typo above?

Since no deployment event was set for the main, how did the altimeter know where to place the "M"? It did a good job of placing it at the beginning of ~constant descent under chute!

Easy. Stratologger comes default at 700 right?

It'll still call out the main even if nothing is in place. (Hey, you forgot to check continuity on your e-match, but this is where I WOULD have fired the charge.......ya doof)

 

[Buckeye]

Ah, correct. The fault value.

 

[manixFan]

Ah, correct. The fault value.

Yes, the M indicates when the Stratalogger would have fired had there been an e-match attached. But of course there wasn't so it's unrelated to what we are seeing. I could post several graphs that look very similar to what the OP shows. But they are from much higher altitudes and longer durations so it's very hard to see the plots once exported. But it's clear that the ejection event causes the spikes in the data, whether from actual variations in pressure or from dynamic forces I don't know.

To the OP - what your seeing is very common based on my experience. Since it occurs after the ejection events it doesn't hurt anything. As I mentioned some of my flights have shown similar spikes and some haven't - obviously based on the dynamics of the flight. If you were getting late deployments then you'd have cause for concern. In my experience the StrataloggerCF has been right on the money at detecting apogee.


Tony

 

[Nytrunner]

If the flight comes back undamaged, I just look at the smoothed data. Helps avoid getting stuck in Over-analysis Paralysis.

 

[Buckeye]

Right. There is a mini explosion inside the rocket and pieces of airframe are violently jerking around on the ends of a rope. Of course there will be some spikes in the data!.

Agreed on the PF apogee detection being spot-on. I used 3 MAWDs over the years - all perfect deployments. I now have a couple SLCFs and expect the same. Other altimeters did apogee deployments too early or too late for my tastes.

 

[jderimig]

As an aside, you cannot tell from an altimeter's own data if apogee detection was correct. You need another independent observation of altitude for this.

 

[Buckeye]

As an aside, you cannot tell from an altimeter's own data if apogee detection was correct. You need another independent observation of altitude for this.

True. The other observations of apogee (peak of flight, lowest velocity) came from my eyes, onboard camera, or dual accel/baro units.

 

[Larry Curcio]

Right. There is a mini explosion inside the rocket and pieces of airframe are violently jerking around on the ends of a rope. Of course there will be some spikes in the data!.

Yup. So many people see a negative spike in the data and are sure there was a leak of ejection gasses into the ebay.
That's like being punched in the eye, seeing stars, and then searching for the light source.

 

[Steve Shannon]

It’s also possible that this was an electrical glitch caused by impact events. What kind of battery was used to power the altimeter? How was it anchored?


Steve Shannon

 

[kevinkal]

I have a LOC Athena-3 with a StratologgerCF also. I've attached a number of data plots for you to compare with. Keep in mind there's about a 2:1 scaling difference between your y axis and the y axis on the plots below.


My Athena-3 launching on an I200W

I simply made some G10 fiberglass altimeter bay bulkheads to fit over the stock 6" cardboard coupler that came with the kit. The pictures below are before I finished mounting a single terminal block and single charge well on each side of the bay. But it should give you an understanding of how the Av bay is configured. My altimeter bay is vented using three 3/32" holes that are 120 degrees apart. I get very nice clean data on the StratoLoggerCF with this configuration.


Here are some plots from the StratologgerCF for various motors flown:


H268R-14A


H220T-M


I200W-L


H250G-M


H250G-M Motor Ejection was early.. (These motors will VERY often deploy early, around 6.5 seconds and not 10 seconds as they should)




I think your original data plot looks fine and that for various reasons, most of which are discussed above, there are some real and artifact sensed pressure dynamics immediately after your motor ejection separated the rocket. Since the ejection was "late" your rocket had a little airspeed on it, which would also contribute to some dynamic pressure and thus altitude readings immediately after ejection. If I were you, I'd get those charges connected and start flying this rocket in dual deploy mode. I love how they whistle! I find that the H210R and H250G are my favorite "whistle" motors for this rocket. They hit hard and burn out at low enough altitude that you can hear the rocket whistle up to apogee. The I200W and H268R burn a little longer and when they burn out, the rocket is higher and faster.. thus the whistle is a higher frequency and further away.. thus not as loud.

Here's a link to my Athena3 Build Thread if you're interested.


An Athena3 Whistle Video:
[video=youtube;MYW8_rvTguo]https://www.youtube.com/watch?v=MYW8_rvTguo[/video]

 

[manixFan]

It’s also possible that this was an electrical glitch caused by impact events. What kind of battery was used to power the altimeter? How was it anchored?

Based on the consensus of information presented here, I would say it's normal data for a StrataloggerCF. As I mentioned I have a fair number of flights that exhibit similar spikes and kevinkal posts a variety of similar looking plots.

All in, I'm not sure that the OP has anything to be concerned about. As he mentions he's new to DP and using altimeters and just not used to seeing a lot of data. The fact that the 'data squiggles' occur after an event implies that they won't impact the actual event itself, but are an artifact of it.

At some point it just becomes an exercise in over analysis.


Tony

 

[BradMilkomeda]

@kevinkal Thanks for sharing all those details of your flights!

I certainly read your build thread, and was inspired to get mine to whistle too, by not rounding the fin edges in between. I am most looking forward to the H268R motor, but all those big 29 motors I hope to try in the one.

I am moving on to installing the switch, the canisters, and testing. Hopefully, I'll be flying high with this rocket in November.

While this is a detail (that has cause a longer thread than expected), ruling out leakage as a problem, and seeing other's data from SLCF with similar spike has made it quite informative to me. Thanks.