Temperature Issue

Hello,

I recently launched a rocket with a team of other engineering students at the IREC. The flight was mostly good, except that when the rocket was retrieved, we got abnormally high altitude and velocity readings from the Stratologger sensor that we had used. After a bit of investigation, we found that the temperature recorded by the sensor had stayed the same throughout the ascent (a nice and toasty 102 Fahrenheit).

We're assuming that this temperature difference caused the abnormally high altitude reading, since many devices that determine altitude use both pressure and temperature in conjunction with an equation based on the International Standard Atmosphere model.

Is this a reasonable conclusion? If so, would there be any way to prevent this from occurring in the future?

thanks!

Neilw said:

Hello,



We're assuming that this temperature difference caused the abnormally high altitude reading, since many devices that determine altitude use both pressure and temperature in conjunction with an equation based on the International Standard Atmosphere model.

Is this a reasonable conclusion? If so, would there be any way to prevent this from occurring in the future?

thanks!

Click to expand...

They shouldn't because there would be a very large error between the temperature of the atmosphere during flight and the temperature inside the av-bay. Barometric sensors use the temperature of the sensor to compensate the pressure reading to read a more accurate pressure.

If you are getting a large altitude error it is most likely due a pressure reading error and not a STD Atmospheric modeling error.

Neilw said:

Hello,

I recently launched a rocket with a team of other engineering students at the IREC. The flight was mostly good, except that when the rocket was retrieved, we got abnormally high altitude and velocity readings from the Stratologger sensor that we had used. After a bit of investigation, we found that the temperature recorded by the sensor had stayed the same throughout the ascent (a nice and toasty 102 Fahrenheit).

We're assuming that this temperature difference caused the abnormally high altitude reading, since many devices that determine altitude use both pressure and temperature in conjunction with an equation based on the International Standard Atmosphere model.

Is this a reasonable conclusion? If so, would there be any way to prevent this from occurring in the future?

thanks!

Click to expand...

Temperature affects the altitude reading in two ways.

1) The local temperature of the AV bay can affect the sensor. Instruments vary in their tolerance to this effect.

2) The ambient temperature of the atmosphere affects the altitude accuracy at a given temperature. Most altimeters are calibrated to read correctly at 59 degrees F - according to the Standard Atmosphere Model, which you mention. Higher ambient temperatures make the altitude readings *low*, rather than high.

jderimig said:

They shouldn't because there would be a very large error between the temperature of the atmosphere during flight and the temperature inside the av-bay. Barometric sensors use the temperature of the sensor to compensate the pressure reading to read a more accurate pressure.

If you are getting a large altitude error it is most likely due a pressure reading error and not a STD Atmospheric modeling error.

Click to expand...

Do you know what kind of equation is used to calculate altitude then? Most of our sources provided an equation based on the ISA which used temperature.

Larry Curcio said:

Temperature affects the altitude reading in two ways.

1) The local temperature of the AV bay can affect the sensor. Instruments vary in their tolerance to this effect.

2) The ambient temperature of the atmosphere affects the altitude accuracy at a given temperature. Most altimeters are calibrated to read correctly at 59 degrees F - according to the Standard Atmosphere Model, which you mention. Higher ambient temperatures make the altitude readings *low*, rather than high.

Click to expand...

We were following the logic similar to that presented in the following equation:



It the case of this equation, if the temperature is larger, it makes the term (17.326P/(459.67+T))^0.235 smaller. But since the equation has 1-(previous term), it would make the overall result larger.

Of course, if the Stratologger does not calculate altitude that way (or in a similar way), then that wouldn't matter anyways.

Neilw said:

Do you know what kind of equation is used to calculate altitude then? Most of our sources provided an equation based on the ISA which used temperature.

Click to expand...

A standard practice is to assume the ISA is valid and just use the pressure term to calculate altitude. (Assume T follows the standard model).

There are "hot day" and "cold day" standard models also. In those models the pressure altitude is simply displaced up or down from the standard model. Rocket altimeters are differential devices, they record a ground altitude and an apogee altitude then use the difference to calculate the AGL altitude of the rocket. Model differences due to non standard temperature would largely be nulled out.

One thing that wasn't mentioned in your post was how "abnormally high" were your readings?

jderimig said:

A standard practice is to assume the ISA is valid and just use the pressure term to calculate altitude. (Assume T follows the standard model).

There are "hot day" and "cold day" standard models also. In those models the pressure altitude is simply displaced up or down from the standard model. Rocket altimeters are differential devices, they record a ground altitude and an apogee altitude then use the difference to calculate the AGL altitude of the rocket. Model differences due to non standard temperature would largely be nulled out.

One thing that wasn't mentioned in your post was how "abnormally high" were your readings?

Click to expand...

All the simulations we had done (including those which took into account the conditions at the time of launch) indicated an altitude of around 10,500 feet. The Stratologger returned an altitude of 12,700 feet and a velocity of Mach 1.3.

Neilw said:

All the simulations we had done (including those which took into account the conditions at the time of launch) indicated an altitude of around 10,500 feet. The Stratologger returned an altitude of 12,700 feet and a velocity of Mach 1.3.

Click to expand...

Well the velocity calculations from a Baro altimeter traveling near mach or past should be completely disregarded IMO.

The altitude difference between your sim and the altimeter although large would not be unusual. I would trust the altimeter result more than the simulation. Both have opportunities for error but I trend to believe measurements more than models.

Can you provide more information on the rocket and the motor used? Also if you have an OR or RS file and are willing to post it, this may shed some light as well. On face value simulated to 10,500 but actual 12,700 could be explained based on the sim.

Here are two StratoLogger log files from the same flight. One log was from an SL100 the other the new SLCF. What John is saying about about Mach transitions with Baro based altimeters can be seen in both logs as the rocket approaches 1000f/s. You will notice it drops off then comes back up. However you are talking AGL which should be reasonably accurate with what you are using.

View attachment 269680
View attachment 269679

All of the integrated baro sensors have internal thermistors, and the calculations that are used to provide the pressure readings are temperature-compensated. The temperature sensors typically take a little longer to respond to changes than the pressure elements, but near apogee you're not moving very fast so relatively speaking you have a nice long settling time. The Stratologger (as well as every other altimeter that I'm aware of) uses the manufacturer's recommended pressure calculation, so it's already temperature-compensated; the standard model should work just fine.

Neilw said:

We were following the logic similar to that presented in the following equation:

It the case of this equation, if the temperature is larger, it makes the term (17.326P/(459.67+T))^0.235 smaller. But since the equation has 1-(previous term), it would make the overall result larger.

Of course, if the Stratologger does not calculate altitude that way (or in a similar way), then that wouldn't matter anyways.

Click to expand...

Yes, when you plug the temperature into the equation, higher temperatures lead to higher altitudes. Most altimeters omit the temperature, and use 15 degrees Celsius (59 degrees F), so higher temperatures make the uncorrected figures too low. (Actually, the constant temperature is substituted at a reference altitude, which is usually sea level or launch pad level. A standard temperature lapse rate with altitude is then imposed.) As you well understand, by your arguments, including onboard measured temperature doesn't answer the problem.

Actually... Could you post your data set?

The Bosch BMP180 is the digital barometer chip used in the current PerfectFlite products. They are self-contained digital chips containing the MEMS pressure sensor, a 24-bit sigma delta ADC, a thermistor for temperature measurement, and a uP programed with the standard atmosphere. https://www.bosch-sensortec.com/en/homepage/products_3/environmental_sensors_1/bmp180_1/bmp180

They are extremely accurate up to 100 kft, somewhat surprising considering this is a $3 chip. Download the well documented datasheets and read how the data is processed and converted to altitude. We use them as the digital altimeter in our uSAS and in FAA altimeter calibration testing, the standard deviation in altitude from 0 MSL to 20 kft is only 11'! That's more than a order of magnitude better than the FAA requirement.

If your altitude reading is significantly different than your expectations, it is unlikely that the PerfectFlite is in error. More likely your pressure sampling ports are suspect or your simulations are in error. BTW you did obtain your altitude by examining the actual pressure altitude record downloaded from the altimeter and are not relying on the instantaneous reading obtained from the beeps.

Bob

As Bob has said, it is important to be looking at the actual data and not the instantaneous readout you hear with the beeps. My Perfectflite altimeters are pretty good at recognizing data spikes from the ejection charge, but when you look at the actual data you will see the spikes. The altimeter USUALLY does not report them as real data in the beeps or as the true apogee on the plot. Every once in a while the altimeter will report bad data for apogee, but a quick look at the downloaded data confirms that it was just a spike and should be ignored.

bobkrech said:

They are extremely accurate up to 100 kft, somewhat surprising considering this is a $3 chip. Download the well documented datasheets and read how the data is processed and converted to altitude.

Click to expand...

Hi Bob,

I have read the datasheet and the device is rated from 300kpa to 1100kpa so per the data sheet it is rated to 9000m MSL. Do you have experience or knowledge that it functions beyond the datasheet specification to 100kft?

--jd

Hey,

I'll try to get the data up ASAP. Bit busy with other stuff right now

jderimig said:

Well the velocity calculations from a Baro altimeter traveling near mach or past should be completely disregarded IMO.

The altitude difference between your sim and the altimeter although large would not be unusual. I would trust the altimeter result more than the simulation. Both have opportunities for error but I trend to believe measurements more than models.

Click to expand...

The problem is that the craft should not have been travelling near Mach. The maximum velocity should have been around Mach 0.85. In fact, had it gone supersonic, the parachutes would have deployed, as we had another redundant sensor for deployment which did not have Mach protection.

Hello,

A few of you asked for the OR model and the Stratologger flight data. So here are both!

https://drive.google.com/folderview?id=0B99UjkI1pg7aUzA4LWVMeVVIbTQ&usp=sharing

Look at your velocity curve or plot it. At around 4.5 second it has an anomaly that looks like a mach or transonic transition. Probably right around your engine burnout or max velocity point. Remove that data (which is impossible physics) and it looks like max velocity was between 900 and 1000 ft/s.

The data suggests your altimeter is correct and your simulation is under estimated.

jderimig said:

Look at your velocity curve or plot it. At around 4.5 second it has an anomaly that looks like a mach or transonic transition. Probably right around your engine burnout or max velocity point. Remove that data (which is impossible physics) and it looks like max velocity was between 900 and 1000 ft/s.

The data suggests your altimeter is correct and your simulation is under estimated.

Click to expand...

I still don't see it being possible for the vehicle to have gone to that altitude. In OpenRocket, everything was just so. The weight on the pad was to the gram and we even tried to include the conditions we had that day. As well, I can't really see the rocket flying better than the model, because of all the pressure relief holes and screw heads that were sticking out of it.

Addt'l: We looked at the time you indicated and we noticed the little anomaly. We're pretty bewildered.

Neilw said:

I still don't see it being possible for the vehicle to have gone to that altitude. In OpenRocket, everything was just so. The weight on the pad was to the gram and we even tried to include the conditions we had that day. As well, I can't really see the rocket flying better than the model, because of all the pressure relief holes and screw heads that were sticking out of it.

Click to expand...

Have you done a tolerance analysis with your simulations to determine confidence limits of your altitude estimation?

How much variation in Cd and motor impulse would be required to achieve your recorded altitude?
Is this variation within the uncertainty of these values?
Have you simmed the flight with a more aerodynamically accurate simulation package such as RASAero?
You do know that motor impulse can easily vary +/-10% of the certification value and up to 20% variance is allowed under NFPA1120 correct?

Have you compared the time to apogee of your sim to the the time to apogee from the altimeter data?
You may suspect the pressure altitude calculation but the clock on the altimeter is almost certainly correct. If your sim time is not close to the actual flight time then your model (sim) is wrong.

I did some investigation of my own questions. Your Stratologger data indicates 29.55 seconds to apogee. Your OR sim shows 25.7.

Your Cd as configured is 0.78. If the actual Cd of your rocket over the flight is 0.69 this results in an additional 1000 ft of altitude. If you motor is 10% higher than published value this would result in another ~1000 ft.

Was your flight relatively vertical or did you have some large horizontal component to it? If it did air velocity over the port at apogee could cause lower pressure in the avbay than atmospheric.

Seeing the data really helps. My previous comments about data spikes are not relevant to this analysis; although you can see a downward spike at each ejection event. That doesn't explain your altitude difference between the altimeter and the sim.

One thing I always look at is the delta altitude between two consecutive readings. Something odd happens between 4.6 and 4.95 seconds. The altitude difference between readings is very high compared to values just before and just after. I have seen this happen with my data and I can't explain it.

I agree with John's comments. I think your Cd was off and you probably had a motor on the high end. You could test this theory by launching the rocket again. You don't need to use the same motor; a smaller motor would work as you could adjust the Cd and see what happens in regards to the sim and the actual altitude.

And in regards to temperature recorded by the altimeter; your data is consistent with what I see in my data. You get very little change in temperature readings during the flight; especially on ascent as you would be venting air out of the rocket. On descent you would be drawing air in and would expect the temperature to get closer to ambient.

Neilw said:

I still don't see it being possible for the vehicle to have gone to that altitude. In OpenRocket, everything was just so. The weight on the pad was to the gram and we even tried to include the conditions we had that day. As well, I can't really see the rocket flying better than the model, because of all the pressure relief holes and screw heads that were sticking out of it.

Addt'l: We looked at the time you indicated and we noticed the little anomaly. We're pretty bewildered.

Click to expand...

No need for bewilderment. What you are seeing happens all the time. Mass is the least of your worries because you can control it. It is very easy to match the weight (obviously) and the ground level weather conditions between the sim and the flight. As John points out, the two biggest unknowns in any comparison are the 1. motor data file and 2. drag coefficient. 10% variation in one or both of these is very common and easily explains your discrepancies. Unless you measure these yourself, you are at the mercy of the data analyst and software programmer who supplied the numbers for your simulation.

There are lots of bad motor data out there. In one of my experiments, the software database had duplicate entries for a motor but with wildly different thrust curves. These two motors caused 20% altitude variation in my sims. Also, the attached pic shows the drag profile predicted by two of the popular simulation software. Note the huge difference after Mach 1. WTF? With all this motor and Cd variation, it is impossible to correlate sims and flights any better than 10%, and your 20% it quite plausible. The temperature of the altimeter is most likely not the problem.

Zeus-cat said:

I agree with John's comments. I think your Cd was off and you probably had a motor on the high end. You could test this theory by launching the rocket again. You don't need to use the same motor; a smaller motor would work as you could adjust the Cd and see what happens in regards to the sim and the actual altitude.

Click to expand...

This will not always work. The backtracked Cd is a function of the motor and can be very different depending on the velocity regime the motor pushes the rocket. See my CD curves above. Tuning just one catch-all sim parameter (Cd) to match repeated flights can be a tail-chasing exercise.

jderimig said:

Hi Bob,

I have read the datasheet and the device is rated from 300kpa to 1100kpa so per the data sheet it is rated to 9000m MSL. Do you have experience or knowledge that it functions beyond the datasheet specification to 100kft?

--jd

Click to expand...

Yes, and you probably do as well if you have used a PerfectFlite altimeter or any other similar altimeter. The PerfectFlite altimeters use the Bosch TMP180 barometer chip which is an industry standard design.

The MEMS pressure sensing element is very sensitive, however it is sensitive to temperature, vibration and needs internal electrical amplification to provide a useful output. The original circa 1970s analog versions came 3 flavors: the basic sensor version, unamplified temperature compensated version and a temperature compensated amplified version. High precision pressure measurement devices used the unamplified temperature compensated version with a low noise precision amplifier. The Adept altimeters were the best of the breed and employed a log ratio amplifier and were accurate to 100+ kft. and when used as an apogee sensor worked to a verified 120+ kft. equivalent altitude (~0.004 atm.) (Ref. FIT JAMSTAR Project circa 2003). The most common version used in most hobby altimeter were the temperature compensated amplified versions. Unfortunately the amplifier circuit design was horrible and the typical sensor flat-lined at ~0.2 atm or ~38kft. Since there are few applications that needed better resolution at dirt cheap prices, it was never changes as it became an industry standard design.

After 2000, the digital MEMS sensor was developed with al the digitization performed on-board the chip. This revolutionized the altimeter designs. https://www.meas-spec.com/technical-papers.aspx# Buy using 24-bit sigma delta converters and uP that could store and run the standard atmosphere model and measure temperature, the pressure measurement could be accurately and precisely converted to altitude. Using DSP oversampling and averaging it is possible to obtain 10 cm altitude resolution (precision) at sea level, 100 cm resolution at 50 kft and 10 meter resolution at 100 kft. While the relative accuracy can be quite goood, the absolute accuracy is most likely a factor of 3 to 10 less since the value depends on the accuracy of the standard atmosphere model and other uncertainties such at the linearity of the circuitry and the hysteresis of the MEMS device. Informal uncertainty calculation I and others have performed indicate that the uncertainty in the altitude derived from a barometric altimeter is equal to the uncertainty in a gps altitude measurement at 30 kft. Mathematically a good barometric altimeter should be more accurate below 30 kft than GPS and conversely, the GPS with constant accuracy is more accurate above 30 kft.

The Bosch BMP180 we use as an altimeter in our sUAS drones has a standard deviation of 11' over a 0-20kft altitude range in FAA altimeter testing. The lat-lon positioning of the drone using a GPS assisted 9-DOF IMU made from cell phone components is within 1M of the gold standard US Army system. Current consumer electronics grade MEMS components are pretty good if you know how to process the data......

Bob

bobkrech said:

Yes, and you probably do as well if you have used a PerfectFlite altimeter or any other similar altimeter. The PerfectFlite altimeters use the Bosch TMP180 barometer chip which is an industry standard design.

Click to expand...

Thanks Bob for the response, but I am still wondering if you know if the BMP180 has response up to 100Kft which is outside thier datasheet specification. I understand that the technology used is can go that high but specifically does the BMP180 continue to provide output beyond the specification?

Do you know if anyone has put one of these in a vacuum chamber and ran pressures below 300kpa and observed output? Certainly the manufacturer is not saying.

For some real world data the flight data from the flight that won the Carmack 100K prize is available.:

https://aeropac100k.insaneprojects.com/Team_AeroPac_2012_100k_Project/100k_Project.html


There is data for two altimeters plus a BeeLine GPS.

The peak GPS altitude was ~108.5Kft. The RDAS sensor was limited to far less than that and the Raven went up to 106Kft or so. I think the Raven uses a Measurement Specialists sensor.

bobkrech said:

Download the well documented datasheets and read how the data is processed and converted to altitude.
Bob

Click to expand...

Bob,

Thanks for the lead to the data sheet! The altitude formula on page 16 doesn't use onboard temperature readings (which is a good thing, IMHO). It's a familiar formula, standardized to 15 degrees Celsius, and it does require temperature correction.

Alas, I cannot agree with your accuracy assessment. On a very hot or cold day, uncorrected altitude readings could be 10%-15% off. (Altimeter temperature correction is a significant concern in aviation, as a quick search on those three words will demonstrate.) The reported onboard reading likely doesn't reflect the actual temperature, but it's safe to say it was well above 15 degrees Celsius. That said, the corrections would make the (perceived) errors worse, and not better.

jderimig's error analysis may hold the key here.

Quite forgot about the thread yesterday. Will have to consult the data after work...

Regards,
-LarryC

jderimig said:

Thanks Bob for the response, but I am still wondering if you know if the BMP180 has response up to 100Kft which is outside thier datasheet specification. I understand that the technology used is can go that high but specifically does the BMP180 continue to provide output beyond the specification?

Click to expand...

I can't provide an answer to the question regarding the behavior of BMP180 below 300mBar, but the reason why the Perfectflite altimeters are specified to 100kft is that they actually use a different sensor. The pictures show what appears to be an MS5607 or MS5611 from Measurement Specialties (formerly Intersema). Both the old plastic version as well as the more recent plastic version can be seen. Those also match the description by Perfectflite (10mBar ~ 100kft, 24bit ADC). The BMP180 has a noticeable different package and can therefore be ruled out, unless the altimeters have since been redesigned.

Generally, every altimeter manufacturer that specifies its products to work at 100kft (PerfectFlite, Altusmetrum, Featherweight *), Black Magic Missileworks *), Entacore **), Altimax) appears to be using Meas Spec sensors.
*) Different sensor in different package, either MS5540 or MS5803
**) Speculative; the pictures of the AIM Extra that I found, don't show the underside with the sensor

Reinhard