Lorenz Meir of the Pixhawk team had a good email discussion with the APM dev team on airspeed math, and was kind enough to write it up in a very helpful primer.
Check out the whole thing here, which walks through the math and measurement techniques.
His tips at the end apply to sensor measurements of all sorts:
"Conclusion To get an optimal altitude or speed estimate, follow these rules of thumb:
- Get as much ADC resolution as possible, in the best case 10-100 times or more than your needed accuracy
- Sample at a much higher frequency and take the average/median (e.g. sample 10 times in a row, take the average/median, return this filtered value). This technique is called oversampling and if the sampling repetitions occur at a much higher frequency than the sampling interval, it should not delay the signal (no phase shift).
- Do a plot over a sensor range to figure out if your sensor is linear, if not, fit a quadratic/cubic function and linearize
- Do a static calibration if necessary
- Compensate for temperature changes if the sensor is sensitive to it
- Do not over-fit or over filter and just correct as much error as you need to make your application work. Too many projects and people get entangled in their own complexity and failures and crashes are the result of too high complexity and too few testing"
Comments
I've gone through the calibration a few times and I can never get it better than 5 mph over temperature. I've tried a few sensors and they'll calibrate and work great one day, but 3 months later I'm off a few mph. Go figure.
I note that APM_ADC already samples the 12 bit A/D inputs at 400Hz and averages when you call APM_ADC.Ch(), so oversampling is already being done.
My advice for working with pressure sensors, especially when dealing with very small variations in pressure is:
- Calibrate the sensor yourself, in my case I'm dealing with water pressure so I calibrated them with a vernier height scale and a water column. You could easily set up a similar calibrated water column but have the sensor in contact with air.
- The temperature calibration of those sensors is pretty rough, you can clearly see the readings drift and then suddenly 'snap' back into line every so often. Granted they only deviate by 10mm of water (0.1kPa) or so before snapping back which is only a tiny fraction of their full scale range.
- Most of the sensors will be ratiometric which doesn't matter if you're supplying your A/D with the same voltage as your sensor. In my case my A/D is running off a separate 5V reference so I'm also reading sensor supply voltage and have calibrated the ratio of input to output voltage for each sensor.
- Always think about noise. My sensors are about 2m from the A/D so everything to and from them goes along shielded twisted pair cable, shields pulled to earth, careful not to create ground loops etc. My sensors are running off a low noise linear power supply, when running them from the 5V USB power of a laptop the noise level in the signal was an order of magnitude higher.
- I'm using a 16bit A/D, in my opinion you should turn to increasing A/D resolution as a very last resort, if you can get away with 12 bit resoultion all the better. If you start going to 18 or 24 bit resolution A/D's you'll have a hard time making use of the extra bits without having the eaten up by electrical noise (also high bit-count A/D's tend to take much longer per conversion, better to oversample a number of times with a lower count A/D).
I'm designing a new airspeed limiter/controller and this discussion showing i'm on right way :)
Another point: *forget the non-temperature compensated sensors,
I'm using 24bit ADC and last 5 digits going crazy from temperature changes. This is my second design and production from this reason.