Bad Perfectflite altimeter?

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
My FS sometimes (lees than half) gets the hiccup at cut off and the acceleration drops. Obviously the rocket doesn’t drop in elevation or freeze in time, so what’s going on here?

https://flightsketch.com/flights/2126/
The altimeter gets the weather data from some nefarious source. :cool: I’m not sure if at the time of flight, when it’s downloaded to the phone, or when uploaded to the website.
My surmise for the reason behind the blip is motor burnout. The airframe might compress a bit under power and drag, then relax at burnout. That transition might cause a tiny, momentary drop in air pressure within the airframe and trick the altimeter into thinking it "backed up" (or "jumped ahead") a few feet before continuing on with the coast to apogee. Just a guess.

Good skies,
GlueckAuf
 
Last edited:
My surmise for the reason behind the blip is motor burnout. The airframe might compress a bit under power and drag, then relax at burnout. That transition might cause a tiny, momentary drop in air pressure within the airframe and trick the altimeter into thinking it "backed up" (or "jumped ahead") a few feet before continuing on with the coast to apogee. Just a guess.

Good skies,
GlueckAuf
So the electronics just assume the rocket's carrying on from the new altitude...

Wouldn't this mean that the apogee was less than it actually was, 20ft in my example given? It looks like it jumped 20ft at apogee anyways so zero sum gain. (@BEC?)
 
The barometer on the Perfectflite (looks like an MS5607 or MS5611) contains a temperature sensor, because it is required to convert the raw sensor reading into a temperature compensated pressure value. So I assume the temperature reading is from this sensor. The correlation between negative temperature spikes and positive altitude points in that direction.
The temperature sensor should not be affected by vibrations and shocks, neither should the value be able to change that fast.
Curiously, the temperature reading on ascent seems to oscillate with a frequency roughly proportional to the rockets speed. I suspect that this shows the increasing and decreasing roll-rate of the rocket.
As @rklapp has pointed out, the exposed silicon on barometric sensors is susceptible to sunlight. If I had to guess, every dip in temperature is caused by sunlight reaching the silicon. This happens once per revolution on ascent and more or less randomly on descent under drogue.
The positive spikes in altitude can be either a direct consequence (sunlight messes with the pressure reading), an indirect consequence (changed temperature reading messes with the result of the pressure calculation), or a combination of both.

If you perform a vacuum chamber test, I'd try to play with exposing the sensor to sunlight. Maybe your problem can be fixed with a small "sunshade"

Reinhard

PS: The Raspberry Pi 2 was a somewhat famous example of that effect
https://www.raspberrypi.org/blog/xenon-death-flash-a-free-physics-lesson/

I tend to agree that the temp data and altitude comes from the same sensor. The noise on the two signals would bear that out. The roll rate doesn't really have anything to do with it. It only makes one, maybe 2 rotations the whole way up. Very straight flight with no real spin at all. Because of that, I don't think sunlight has anything to do with it. The altimeters are far enough away from the vent holes that direct sunlight would be almost impossible because of the angles through the holes and thickness of the coupler and switch band. It would only be what gets through the unpainted fiberglass. I don't know if that could have that much effect on it.

More testing coming. The vacuum chamber will be next.
 
Maybe after the airframe compression-expansion event at motor burnout, the internal/external air pressure differential normalizes through the airframe vents and corrects the barometer-based altitude calculation.

I took a look at the raw .pf2 file converted to Excel and the altitude and velocity numbers (in red) show the blip. What causes them? I don't know, but the timing suggests motor burnout, which on the Loki K627 occurs at 2.4 seconds. (About 3.5 seconds, less the 1-second false start from a chuff.)

1617631982547.png

Again, I have no certainty about the blip's root cause, it just seems plausible that something happens around motor burnout to cause some anomalous pressure measurements with the PerfectFlite Stratologger CF, and that in turn affects both the software's altitude and velocity calculations.

Good skies,
GlueckAuf
 
FlightSketch's current software will do this altitude blip thing at motor burnout, especially on a high thrust motor, where the deceleration due to drag is significant. I'd thought (with no actual algorithmic evidence) that this was because in this case there is a kinematic model involved that estimates altitude and which is used to help filter the spikes out of the barometric data. This is probably a poor understanding of what's really going on there, so don't go harass Russ over that understanding of what his software is doing and/or my inability to articulate it.

This is the first time I've seen (well noticed) that sort of thing on a PerfectFlite device. It's too bad one can't get the actual pressure data from a PerfectFlite log so once could plot that and see what that showed, as the altitude and velocity calculations are both driven off of that.
 
Last edited:
As has been previously mentioned, digital baro sensors are a pizoelectric device so they are subject to spikes due to shock. In flight, it's not uncommon to see a small spike around burnout (although you can't count on it...), and you almost always see a big spike near apogee/ejection if something other than your altimeter fires the parachutes. It's picking up the "jerk" from the ejection. Those are normal events and to be expected... when analyzing data it's good to know how your sensors work so you can explain where any anomalies may have come from.
 
FlightSketch's current software will do this altitude blip thing at motor burnout, especially on a high thrust motor, where the deceleration due to drag is significant. I'd thought (with no actual algorithmic evidence) that this was because in this case there is a kinematic model involved that estimates altitude and which is used to help filter the spikes out of the barometric data. This is probably a poor understanding of what's really going on there, so don't go harass Russ over that understanding of what his software is doing and/or my inability to articulate it.

This is the first time I've seen (well noticed) that sort of thing on a PerfectFlite device. It's too bad one can't get the actual pressure data from a PerfectFlite log so once could plot that and see what that showed, as the altitude and velocity calculations are both driven off of that.
Of course not. I figure I'm getting my money's worth out of the altimeter and appreciate Russ' rocket in the tree warranty. I'm just wondering if I need to add the blip to the apogee elevation?
 
Of course not. I figure I'm getting my money's worth out of the altimeter and appreciate Russ' rocket in the tree warranty. I'm just wondering if I need to add the blip to the apogee elevation?
No, you don't. I would just visually "smooth over" where that blip on boost occurs in the graph and pretend you didn't see it. Seriously. The apogee value will be based on the static air pressure at apogee and what happened several seconds earlier won't affect that.

I appreciate Cris' thoughts about why there might be such a blip with relatively sudden deceleration at motor burnout. I already knew about ejection events since they are clearly somewhat chaotic (from the rocket's motion point of view) so it makes sense. But there is no sudden change in the model's motion at burnout that we can see from the ground, so I didn't think to apply the same thought process to it.
 
Last edited:
No, you don't. I would just visually "smooth over" where that blip on boost occurs in the graph and pretend you didn't see it. Seriously. The apogee value will be based on the static air pressure at apogee and what happened several seconds earlier won't affect that.
Thanks. I'm I trying to figure this out. So the altimeter reads the initial barometric pressure as 0ft no matter what elevation it's at. As the rocket ascends and descends, it compares the BP to the initial reading so any shock along the way doesn't matter?
 
It's too bad one can't get the actual pressure data from a PerfectFlite log so once could plot that and see what that showed, as the altitude and velocity calculations are both driven off of that.

The Standard Atmosphere Model can be "undone" from the altitude data to reveal the measured pressure. I have done this to replace the SAM with more accurate weather balloon sounding data from a nearby airport. There are a couple different forms of the US Standard Atmosphere and International Standard Atmosphere. I hacked some Fortran code I found into a VBA routine for Excel. I think the Missileworks user guide gives a simplified equation, and more are derived here:

Density of air - Wikipedia
 
Thanks. I'm I trying to figure this out. So the altimeter reads the initial barometric pressure as 0ft no matter what elevation it's at. As the rocket ascends and descends, it compares the BP to the initial reading so any shock along the way doesn't matter?
Right. It's sampling and holding the instantaneous pressure in a rolling memory buffer, then locks that in when it detects launch and uses that as "zero" for the subsequent height calculations. This is true for any barometrically-based rocket altimeter, though the details of the implementations vary between different makers.

Filtering shocks, especially around ejection, is important in order to get an accurate apogee, and this is where the various makers each have their own "secret sauce" in how that's done. But a shock that happens at 1/4 of the final altitude on the way up, or the aberrations from sun exposure or "rattling around" that happen on the way down (again adequately filtered out) don't really mess with the apogee calculation. They can tell you all sorts of other interesting things, though....
 
Last edited:
The Standard Atmosphere Model can be "undone" from the altitude data to reveal the measured pressure. I have done this to replace the SAM with more accurate weather balloon sounding data from a nearby airport. There are a couple different forms of the US Standard Atmosphere and International Standard Atmosphere. I hacked some Fortran code I found into a VBA routine for Excel. I think the Missileworks user guide gives a simplified equation, and more are derived here:

Density of air - Wikipedia
Sorry...I wasn't clear enough I guess. Some other altimeters (Altus Metrum MicroPeak, Jolly Logic AltimeterThree, FlightSketch Mini) record and save the actual pressure data in their files for the flight and make those data available to the user for analysis outside their own provided applications. That way you can run your own instantaneous calculations or plot the pressure measurements rather than the calculated altitudes if you want. PerfectFlite doesn't make the recorded pressure data available that way (nor does Adrel/North Coast Rocketry). I was thinking about plotting the raw pressure readings to see what that looked like and lamenting that I couldn't when I wrote that.
 
Last edited:
Sorry...I wasn't clear enough I guess. Some other altimeters (Altus Metrum MicroPeak, Jolly Logic AltimeterThree, FlightSketch Mini) record and save the actual pressure data in their files for the flight and make it available to the user for analysis outside their own provided applications. That way you can run your own instantaneous calculations or plot the pressure measurements rather than the calculated altitudes if you want. PerfectFlite doesn't make the recorded pressure data available that way (nor does Adrel/North Coast Rocketry).

Loud and clear. Solve for p at each recorded h.

Raven also reports p and h at each time interval, and I confirmed the equations. All altimeter makers probably use the same Standard Atmosphere formulation.

1617662162933.png
 
Last edited:
The back-calculated pressure will be just as messy as the altitude data, so that probably won't reveal anything new.
 
They do use the same standard atmosphere calculation. But the displayed/plotted altitude may not be just a plug-and-crank of the pressure and temperature into that equation. That's where the interesting stuff happens, as they try, each in their own way, to get rid of bad data from various sources, including, especially, the stuff that happens around deployments.

That's why I thought it might be interesting to plot the pressures directly, to see what was going on independently of the action of any filtering algorithm. Whether I'd learn anything useful from that or not is another discussion :).
 
My FS sometimes (lees than half) gets the hiccup at cut off and the acceleration drops. Obviously the rocket doesn’t drop in elevation or freeze in time, so what’s going on here?

https://flightsketch.com/flights/2126/
The altimeter gets the weather data from some nefarious source. :cool: I’m not sure if at the time of flight, when it’s downloaded to the phone, or when uploaded to the website.
I had to go back and look at the specific flight. The current production firmware (FW 27) for the FS Mini is not the best at filtering out the spikes around ejection. For this particular flight of the Goblin I see that it ejected early and that there's a spike there that is probably skewing the reported apogee. From the graph the true apogee is probably ~200 feet, I'd guess.

Russ has refined this filter and will be making firmware using it available soon. It's been in work in order to get NAR Contest Board approval for use of FS devices in NAR Competition. If you go back through the logs and look at my flights from late February you can see comparisons. For example this one is using the currently released firmware: https://flightsketch.com/flights/1952/
This one is using the next iteration, which does a better job at filtering around apogee: https://flightsketch.com/flights/1951/

The two Minis, one with FW 27 and one with FW 29, were riding side-by-side in the same payload section on the same flight.

Weather data is supposed to be from the Dark Sky API, and I think it uses the location and time of the data when you upload to the log. If you save it locally and then use the logbook function of the app to upload later, it should capture the weather data at the time the data were saved locally and then upload that.

I don't know if it's at time of "arm for launch" or when it's initially downloaded from the Mini, but I suspect it's the latter.

This is a bit of thread drift from the original question about a Stratologger CF that seems to be wonky, so maybe we should take this FS discussion to one of the FlightSketch threads.
 
They do use the same standard atmosphere calculation. But the displayed/plotted altitude may not be just a plug-and-crank of the pressure and temperature into that equation. :).

I am 95% sure that all the hobby rocketry altimeters simply plug-and-crank the equations. I know the Raven does, because I computed it. Try your pressure data from the other altimeters you mentioned. The individual magic probably occurs as they try to filter and smooth the raw pressure/resulting altitude.

The standard atmosphere model is a "typical" day at the earth's mid latitudes, conditions which rarely occur at your real life rocket launch. The altimeters underpredict on hot days, and overpredict on cold days. The discrepancies are mitigated by computing the difference in altitude to give AGL measurements, but the errors in AGL can still be wrong be wrong up to 15%. This is the dirty little secret of barometric altimeters. GPS, even with its own errors, is the best measure of any altitude, IMO.
 
Last edited:
There are lots of things that can cause an altimeter to produce results that are not as expected. The number one that I have seen is the static pressure inside of the av-bay is not the same as the static pressure outside. This can be from a number of factors, undersized ports, acceleration induced pressure gradients, shifting recovery gear, flying at an angle of attack, etc... The result of these noise sources is the pressure sensor accurately reporting the local pressure which is expected, a very accurate recording of the error. Other things like flexure of the membrane under acceleration can have some impact but all of these sources are usually two sided. There should be one case where the pressure relative to the true altitude is too high and the opposite where it is too low. The only single sided error I've seen is from light. The photocurrent of silicon makes the sensor record the "correct" value when not exposed and have a single sided bias when under strong light sources. The data from the first post looks like a normal recording with large excursions in the up direction, nothing in the down direction. That would point to sunlight for me but hard to prove unless a fix can be tested.

The FlightSketch firmware uses a Kalman filter to help make sense of the pressure data. Basically, if the pressure trend shows the rocket going up, the next altitude is assumed to be higher than the last and it guesses what that value should be from the velocity and time step. The barometer is used to correct that estimate based on a weighted average of how much the filter trusts the sensor vs the kinematic model. There are several sets of coefficients used depending on where you are in the expected flight profile. That means you can't directly back calculate what the sensor recorded from the altitude so we also record the raw pressure values as well.

And yes, the standard atmosphere assumption is probably one of the biggest error sources of all. GPS is not perfect but much better in most cases with a good receiver. Even on low altitude flights where the time to apogee is in the 10s of sec, the absolute error may be large but the error sources are stable enough the relative altitude at apogee is actually very good. I'm very much looking forward to GPS getting more use as an altitude source!
 
There are lots of things that can cause an altimeter to produce results that are not as expected. The number one that I have seen is the static pressure inside of the av-bay is not the same as the static pressure outside. This can be from a number of factors, undersized ports, acceleration induced pressure gradients, shifting recovery gear, flying at an angle of attack, etc... The result of these noise sources is the pressure sensor accurately reporting the local pressure which is expected, a very accurate recording of the error. Other things like flexure of the membrane under acceleration can have some impact but all of these sources are usually two sided. There should be one case where the pressure relative to the true altitude is too high and the opposite where it is too low. The only single sided error I've seen is from light. The photocurrent of silicon makes the sensor record the "correct" value when not exposed and have a single sided bias when under strong light sources. The data from the first post looks like a normal recording with large excursions in the up direction, nothing in the down direction. That would point to sunlight for me but hard to prove unless a fix can be tested.

The FlightSketch firmware uses a Kalman filter to help make sense of the pressure data. Basically, if the pressure trend shows the rocket going up, the next altitude is assumed to be higher than the last and it guesses what that value should be from the velocity and time step. The barometer is used to correct that estimate based on a weighted average of how much the filter trusts the sensor vs the kinematic model. There are several sets of coefficients used depending on where you are in the expected flight profile. That means you can't directly back calculate what the sensor recorded from the altitude so we also record the raw pressure values as well.

And yes, the standard atmosphere assumption is probably one of the biggest error sources of all. GPS is not perfect but much better in most cases with a good receiver. Even on low altitude flights where the time to apogee is in the 10s of sec, the absolute error may be large but the error sources are stable enough the relative altitude at apogee is actually very good. I'm very much looking forward to GPS getting more use as an altitude source!
Thanks Russ. You da man!

I was scratching my head why the rocket went backward in time for a fraction of a second but it all makes sense now. The "blip" seems to happen about half the time. For example, it occurred with the Goblin C11-3 but not with the Honest John C11-3, same altimeter. Both went about the same height. Not a problem, just interesting.

I understand you don't have much control over the website but if I can make a suggestion, turn the Flight Log drop down list to a search text (or add). There seems to be many users with no flights and is clogging up the list.
 
I understand you don't have much control over the website but if I can make a suggestion, turn the Flight Log drop down list to a search text (or add). There seems to be many users with no flights and is clogging up the list.
I actually have full control over the site but that's good and bad... It can do anything but I have to write it. The new version will have user pages that will display all of your flights plus other things. Should make it much easier to keep track of what you've uploaded.
 
Of course not. I figure I'm getting my money's worth out of the altimeter and appreciate Russ' rocket in the tree warranty. I'm just wondering if I need to add the blip to the apogee elevation?
Some further investigating (and a quick bit of insight from Russ via email) and it appears that when these blips at burnout happen there is actually a pressure increase (so calculated altitude decrease) at that point in time. I just looked at a particularly egregious example from a few days ago (a plain ol' Alpha on a Q-Jet C12, https://flightsketch.com/flights/2142/) and sure enough, right where the altitude spikes downward, the pressure spikes upward in the data. So now the question is, what is the mechanism for this sudden pressure increase where the altimeter is riding when the motor burns out? I have a thought or two, but need to do some more experimenting to see if I'm right. For my models, it seems this happens when the FS Mini is flying in with the recovery system, but doesn't happen when it's in a dedicated compartment. Hmmmmmmm.....

I can't think of anything that would cause the pressures to really do what the Stratologger CF that started this thread is showing, but maybe there is an answer there if we stop thinking about things that confuse the sensor and start thinking about how, on that particular model, the pressure where the altimeter(s) ride is really fluctuating like that.
 
Latecomer to this thread, but two years ago I had crazy data like that, oddly enough on the same equipment. The rocket was an unpainted MadCow 2.6" fiberglass Tomach.

I never figured it out, but it happened every single flight.

Last year I got around to painting the rocket, and decided to give it one more flight before gutting the electronics and putting in Missile Works gear. SURPRISE, with paint blocking out the sunlight from summer filtering through the naked tube, the data traces was perfect then, and every flight since.

Since then, I've read up on how photosensitive some of these baro sensors are, and was surprised.
 
Some further investigating (and a quick bit of insight from Russ via email) and it appears that when these blips at burnout happen there is actually a pressure increase (so calculated altitude decrease) at that point in time. I just looked at a particularly egregious example from a few days ago (a plain ol' Alpha on a Q-Jet C12, https://flightsketch.com/flights/2142/) and sure enough, right where the altitude spikes downward, the pressure spikes upward in the data. So now the question is, what is the mechanism for this sudden pressure increase where the altimeter is riding when the motor burns out? I have a thought or two, but need to do some more experimenting to see if I'm right. For my models, it seems this happens when the FS Mini is flying in with the recovery system, but doesn't happen when it's in a dedicated compartment. Hmmmmmmm.....

I can't think of anything that would cause the pressures to really do what the Stratologger CF that started this thread is showing, but maybe there is an answer there if we stop thinking about things that confuse the sensor and start thinking about how, on that particular model, the pressure where the altimeter(s) ride is really fluctuating like that.
I'm still not discounting my time dilation theory.

giphy.gif
 
Back
Top