Electronics at 100,000+

[cerving]

Not if as Adrian suggests the noise increases with altitude (decreasing pressure). It's unclear to me if this means that the actual noise increases non-linearily with decreasing pressure, or if it's relatively linear and therefore it's simply a larger component of the total pressure value with decreasing pressure.

If you filter the pressure data before converting to altitude it should do it automatically, assuming noise is constant no matter the pressure level.

 

[CarVac]

If the noise is constant regardless to the pressure level, then the signal-to-noise ratio drops as the pressure drops, thus increasing the output noise when converted to altitude.

 

[UhClem]

Actually, it doesn't imply that at all. A positive and negative range simply means that the error can be in a positive or negative direction relative to a perfect linear slope. The differential nonlinearity is a measure of the nonlinearity errors sampling 2 different channels; i.e. do the errors in 2 channels tend to move in the same direction to cancel out. The data sheet shows that for the most part, they do.

Differential non-linearity has nothing to do with sampling two different channels.

The differential nonlinearity error shown in Figure 5 (sometimes seen as simply differential linearity) is the difference
between an actual step width (for an ADC) or step height (for a DAC) and the ideal value of 1 LSB. Therefore if the
step width or height is exactly 1 LSB, then the differential nonlinearity error is zero. If the DNL exceeds 1 LSB, there
is a possibility that the converter can become nonmonotonic. This means that the magnitude of the output gets smaller
for an increase in the magnitude of the input. In an ADC there is also a possibility that there can be missing codes i.e.,
one or more of the possible 2n binary codes are never output.

Page 6

One of many references.

 

[cerving]

If the baro noise was a constant then it would be relatively easy to remove. It's not, however, I've run into that with the Eggtimer. It appears to be relatively linear, i.e. the noise is proportional to pressure so the SNR is about the same at all altitudes. For a few given consecutive baro samples the pressure-altitude curve is very shallow, so you can use linear regression or other mechanisms to correct the errors if you assume that the error is both linear and random within the error band.

If the noise is constant regardless to the pressure level, then the signal-to-noise ratio drops as the pressure drops, thus increasing the output noise when converted to altitude.

 

[Adrian A]

Differential non-linearity has nothing to do with sampling two different channels.

Page 6

One of many references.

I stand corrected; thanks for the info. Looks like neither of us got it quite right, but you were a lot closer than I was. A differential non-linearity spec with a worst-case value of -1 LSB says that in the worst case, an analog input increase of 1 LSB may result in the digital output not changing. It would have to be worse than -1 to imply that the digital output could go in the wrong direction. Based on a lot of recorded data plots, I don't think I have ever seen behavior quite that bad, so I think the spec is conservative. But now I understand better your dismay.

 

[Adrian A]

If you filter the pressure data before converting to altitude it should do it automatically, assuming noise is constant no matter the pressure level.

There are 2 effects from the simple recursive filter I use that are beneficial to getting a good baro-based apogee detection. One of them is to decrease the post-filter noise, and the other is that it introduces a measurement delay. Consider a rocket's vertical velocity represented as a line trending downward with a slope of -G. Near apogee, the rocket is moving slowly enough that drag isn't a big factor, so it's a nice straight line that passes through zero when the rocket is at apogee. You can represent uncertainty in baro-based apogee detection as a band around zero that increases in size when the atmosphere gets thinner. As the rocket slows down and the velocity is low enough to get into the noise band, it becomes likely that a few measurement points will line up to be interpreted as pressure increasing. At low altitudes, the error band is really small, and so the delay caused by the filter will be larger than the ability for the noise to cause an early detection, and so you get a typical apogee ejection about 0.5-1 second after apogee, which is a good situation. At high altitudes, the noise floor is a lot higher, and so the velocity line will run into it much sooner, somewhere around 10 seconds early on a flight to 105,000 feet. A longer filter time would both lower the noise floor and delay the filtered measurement, both of which would help make the "pressure increasing" trigger more accurate at extreme altitudes.

I have been thinking about whether filtering the pressure would make a difference rather than filtering the altitude. Since this trigger is set to detect when the measurement is passing through zero (either pressure rate or altitude rate) I don't think that it actually would make a difference whether the filtering is done on altitude or pressure, since although higher altitudes would affect the step size, zero rate would still be zero.

 

[keithp]

It's unclear to me if this means that the actual noise increases non-linearily with decreasing pressure, or if it's relatively linear and therefore it's simply a larger component of the total pressure value with decreasing pressure.

Just use a Kalman filter. No magic values or ad-hoc filters required, just straight forward American rocket science from 1960.

The sensor noise model is part of the computation; noisy samples automatically get filtered more than quiet samples.

Figuring out apogee is trivial when you fuse all of the sensors with the obvious physics model of a ballistic body -- the vertical velocity goes through zero precisely when the rocket hits apogee.

When you run past the range of the baro sensor, you simply phase out the baro sensor and run on just the accelerometer.

If you've got a GPS, just mix that in using the error term provided in the GPS solution.

When you start descending, and the attitude of the airframe is indeterminate, then phase out the accelerometer and depend on just the baro sensor.

Going through mach on a baro-only flight computer? No problem -- the Kalman filter tells you when the sensor data and the physics model are way out of whack so you know you can't be at apogee yet.

A bunch of recent flight computer advertisements mention using Kalman filters now; seems like it's becoming more common these days.

 

[bobkrech]

And David Schultz, aka UhClem on TRF, was a pioneer in applying Kalman filters to hobby rocket altimeters. He received several NARAM R&D awards for his excellent experimental research papers on the subject... https://home.earthlink.net/~david.schultz/rnd/index.html

Bob

 

[Adrian A]

Just use a Kalman filter. No magic values or ad-hoc filters required, just straight forward American rocket science from 1960.

It's been on my to-do list for a while now. One of those things that will probably seem easier in retrospect than ahead of time.

 

[UhClem]

I stand corrected; thanks for the info. Looks like neither of us got it quite right, but you were a lot closer than I was. A differential non-linearity spec with a worst-case value of -1 LSB says that in the worst case, an analog input increase of 1 LSB may result in the digital output not changing. It would have to be worse than -1 to imply that the digital output could go in the wrong direction. Based on a lot of recorded data plots, I don't think I have ever seen behavior quite that bad, so I think the spec is conservative. But now I understand better your dismay.

Figure 3 gives a better illustration. DNL of -1 is missing code and DNL of +1.5 (or greater) is non-monotonic. Consider that the maximum DNL of the eZ8 ADC is +4 counts and that with a 70G accel that 4 counts is about 0.6G. Not a huge problem at 20G acceleration but if it crops up while coasting...

Finding these flaws in flight data is impossible because there is no way to tell if it is an ADC error or the signal. Now if you could put the altimeter on a shaker table and excite it with a nice low distortion 198Hz sine wave you might find something.

 

[dixontj93060]

And David Schultz, aka UhClem on TRF, was a pioneer in applying Kalman filters to hobby rocket altimeters. He received several NARAM R&D awards for his excellent experimental research papers on the subject.

Go Dave!! (always appreciated your electronics insight.)

 

[UhClem]

There are 2 effects from the simple recursive filter I use that are beneficial to getting a good baro-based apogee detection. One of them is to decrease the post-filter noise, and the other is that it introduces a measurement delay. .

Filtering of the pressure data does not have to introduce any delay.

While digging into details for a non rocket project I discovered the world of digital filters with zero group delay at DC. Or even negative.

The version that I have been playing with was in an article on the subject of GPS disciplined oscillators. (which is my project)

Attached is a sample of Raven data filtered through a 20 tap FIR filter.

This particular filter has the obvious defect of not really tracking the data so you wouldn't want to use it in most applications. (There is an offset between the filter output and data and this offset grows with filter length.) But the DC group delay is very low so it might be perfect for apogee detection. Its big plus is that the filter gains are dead simple to calculate since it is basically a modified moving average filter.