This is a case of something that grew in the telling. It was going to be a somewhat long post on Rocketry Planet but it grew to the point where I decided it was too much for that. Plus I thought that the occasional plot of data might be handy to help visualize what was going on. So here is a discussion of the AltAcc data conversion focusing on the pressure to altitude conversion.

The trigger for this discussion was the report of an altitude record attempt that was denied because the reported altitude of 44,000' exceeded the range of the altimeter used. An AltAcc. (Probably an AltAcc2 but this was never stated.) It would be nice to have the actual AltAcc data file for that flight. (nudge, nudge)

The AltAcc2x uses the MPX4100a sensor which is specified to 20kPa minimum pressure. This translates, using the Standard Atmosphere model to an altitude of nearly 39,000' MSL.

As an example of what happens on high altitude flights here is a plot of the raw pressure data (scaled to voltage) collected using an RDAS altimeter which also uses the MPX4100 sensor.

This shows the most obvious effect which is that the voltage reaches a minimum value. The not so obvious effect is the departure from linearity that occurs before then. But these effects will not result in the reporting of altitudes greater than actually reached. They always result in lower altitudes.

The stated reason for denying the record claim was that the pressure sensor was only accurate below 34,000' MSL. My copy of the AltAcc (and AltAcc2) manual states that altitudes above 30,100' may be inaccurate. The reasons for that are unstated. Since there are no additional circuits between the sensor and ADC to add error or constrain the reading and the ADC works for inputs from 0 to 5V (power supply) the only possible reason is the details of converting the pressure to altitude.

I have owned an AltAcc since 1999 (and an AltAcc2C since 2003) and like it a lot for controlling deployment. The data on the other hand leaves something to be desired. Aside from the low sample rate (16SPS) and pathetic resolution (8 bits) there is the data processing problem.

Once upon a time source code for a POSIX version of the AltAcc DOS tools was published and announced on rec.models.rockets. That FTP archive is long gone so I will make the code available here. After looking at the data reduction code (produce.c) I was not impressed.

The pressure to altitude conversion uses a logarithmic form that I hadn't seen so that was my first suspect:

P0 = Press_0 * CaliData [ GainBP ].Val + CaliData [ OffBP ].Val ; P1 = Press * CaliData [ GainBP ].Val + CaliData [ OffBP ].Val ; dP = P1 / P0 ; ln_dP = log ( dP ) ; Alt = ( 1 - exp ( ln_dP / 5.256 )) / 0.00000688 ; |

Press_0 and Press are the ADC readings for ground level and apogee respectively.

The last two lines seemed odd since first a log is taken and then it is immediately exponentiated. So I decided it was time to blow the dust off my knowledge of the laws of exponents...

a^(mn) = (a^m)^n so exp(ln_dP/5.5256) = exp(ln_dP)^1/5.256 |

Now that it is in this form it appears a lot more like the equations from the NASA site. When applied to data from a table of the standard atmosphere, the error is only 3' at 35,000'. Essentially zero.

But there are still some problems here. While at first it appears that calibration factors are applied to the readings that is not the case. The gain is fixed at 1 (or 1.1 if a really old unit using the MPX5100 produced the data) and the offset is fixed at 23.3 even though these values are read from a calibration file. According to the comments the offset was chosen to make the reported value match what was expected:

/* The Motorola data sheet sez 4.5 V / 14.5 PSI which implies 4.56 V * at 14.7 PSI. The unit output is 209 / 14.7 while the ideal is * 229.5 at 14.5 ( assume 255 / 5 Unit / volt ). This means the * readings are offset low 23.3 units. PALT_OFFSET is hardcoded * for now to +23.3 and all readings are adjusted up by this value. */

I find this not only a bit hard to follow but a bit hard to believe. My AltAcc output 209 at an altitude of ~2,850'. The standard atmosphere predicts a pressure of 13.65 psi (94 kPa) at this altitude. So at the very least this offset value is wrong for my altimeter on this day.

Then there is the problem of using the ratio of pressures. While this works fine when the launch is from sea level, it breaks down at higher elevations (as an example, using a base altitude of 5,000' MSL, the error at 30,000' AGL is ~300') and then of course there is the problem that this equation is only valid up to 36,152 feet. Although that isn't too awful a problem as that is almost the altitude where the pressure sensor runs into its limits.

But there is still a serious error in the computation. While the pressure ratio calculation doesn't care what scale factor is used (pressure can be in kPa, psia, or anything) the numbers used must not have any offset. They must be zero for a pressure of zero. Yet the offset correction used does not do this. To illustrate the problem consider...

To keep things simple assume the ground level pressure is 1 and the apogee pressure is 0.2 for a pressure ratio of 0.2. But how much error is there if these two values are offset by .01?

P1 | P0 | P1/P0 | altitude |
---|---|---|---|

0.2 | 1.0 | 0.2 | 38,338' |

0.2 + 0.01 | 1.0 + 0.01 | 0.2079 | 37,544' |

Note that this offset is just 1% of the ground level reading yet it changes the result by nearly 1,000'.

The best way to compute the gain and offset factors would be a two point calibration. Expose the altimeter to two known pressures, preferably at about 20% and 80% of the range, and record the ADC output. (A really good calibration would take readings at 0%, 50%, 100%, 50% and then 0%. This allows not only the measurement of the slope and offset but linearity and hysteresis.) Then use those two known points to compute the slope and offset. As calibrated vacuum chambers are hard to come by, a single point and an assumption will have to be used.

Looking at the data sheet for the sensor it appears that its slope does not vary much yet the offset does. So the slope from the data sheet will be assumed to be valid. Then fit the data to the equation:

y = mx + b where: y is the pressure in the units of choice x is the ADC reading m is the slope b is the y offset |

For example assume that the ADC reading was 209 at a pressure of 94 kPa. (actual data from a flight at Lucerne Dry Lake and nominal pressure for that altitude.)

The sensor sensitivity (corrected for 5V power supply) is given as:

54mv/kPa * 5V/5.1V = 52.94 mV/kPa

converting to ADC counts...

52.94 mV/kPa * 255 counts/5,000mV = 2.7counts/kPa

We really want the inverse of that or 0.37037 kPa/count So we have:

94 kPa = 0.37037 kpA/count * 209 counts + b

b is therefore 16.6 kPa which ie equivalent to 44.8 ADC counts

(Note: The AltAcc uses the raw ADC counts as its units and calls them "Orvilles".)

The data from my flight at Lucerne Dry Lake had a ground level pressure of 209 and apogee pressure of 189. What effect does this different offset have on the computed altitude?

P0 | P1 | P1/P0 | altitude | |
---|---|---|---|---|

"Stock" | 209+23.3 | 189+23.3 | 0.9139 | 2,468 |

"Corrected" | 209+44.8 | 189+44.8 | 0.9212 | 2,252' |

This isn't too big a change but the big changes will only appear for low apogee pressures. This is when the too small offset will have a big impact. What if the pressure was at the 20 kPa minimum for the sensor? (A quick computation is required to determine that this translates to an ADC reading of 9 counts.)

P0 | P1 | P1/P0 | AGL altitude | |
---|---|---|---|---|

"Stock" | 209+23.3 | 9+23.3 | 0.1390 | 45,489' |

"Corrected" | 209+44.8 | 9+44.8 | 0.2120 | 37,147' |

More than 8,000' high. It appears that offset error played a large role in the 44,000' altitude reported for the record flight. This also calls into question the use of the AltAcc to set records.

The pressure ratio method is really not the correct way to do this though. The correct way is to compute the apogee altitude and the ground altitude and take the difference between the altitudes. For this I will switch to using the NASA equations

Alt = (288.14 - 288.08 * pow(P/101.29, 1/5.256)) / 0.00649; Alt *= 3.2808; /* Convert from meters to feet. */

The ground level pressure is:

P0 = 209 counts * 0.37037counts/kPa + 13.6kPa = 91 kPa

P1 = 189 counts * 0.37037counts/kPa + 13.6kPa = 83.6 kPa

Ground level altitude is 2,968' and apogee altitude is 5,253' so the AGL altitude was 2,284'. Applying the same method to the hypothetical apogee reading of 20 counts results in a pressure of 21 kPa, a MSL altitude of 37,699', and a AGL altitude of 34,731'. At this altitude 1 ADC count is equivalent to about 360' of altitude.

The AltAcc calibration file has one other problem.

It is a plain text file which is easily altered. So if someone was interested in fudging the results, they would have no trouble at all. But in spite of this, the AltAcc can be used to get decent altitude readings so long as the raw data is available. The method is:

- Determine the ADC counts for ground level and apogee.
- Find the best estimate of actual barometric pressure at the time of launch.
- Use the actual pressure and ground level ADC value to compute the offset.
- Compute the ground and apogee pressures.
- Compute the apogee and ground level altitudes using the NASA equation above. Any results greater than 36,152' MSL are invalid although for purposes of setting a highest altitude record they can be used as they will be lower than the actual altitude and are thus self penalizing.
- Take the difference.

An alternate to steps five and six would be to get atmospheric sounding data from a nearby location and time. Then look up the computed apogee pressure in the table and subtract the launch site altitude.The launch site altitude can be easily found on maps. This method will work best with very high altitude flights.

This looked like a good excuse to dabble in a little Javascript. So here is a simple calculator.

BlackSky has been out of buisiness for a long time but I still see the occasional request for the software. So here are a couple versions: