Analyzing MPL3115A2 Precision Altimeter performance

As I promised at the end of the previous post, today we will put together all the code we discussed thus far related to synchronous I2C communication using MPL and I2C  libraries. We will be working with the 14-MPLI2C-Sync project developed in MPLAB X IDE from Microchip. This project is rather simple and contains single code file main.c, which includes single function int main(void).

This function starts with initiating various components that we discussed in the earlier posts and then initializes I2Cl library  assigning it interrupt priority (level) of 5 and setting speed at 400 KHz. After a short delay of 3 seconds (I am using PIC Kit 3 for programming the MCU with the firmware and during programming it may put MCU in a working state for a few seconds, which a 3 second delay should cover), it initializes MPLlibrary, which, in turn, initializes the MPL3115A2 sensor.

A few local variables are defined, including Msg structure, which is used to communicate back over the XBee link collected sensor data together with the timestamps. The core of operation is in the loop, which goes through all eight (from zero to 7) possible values of OSR (over-sampling rate) for the sensor. After sensor is reconfigured for the current value of OSR through the call to MPLReset(…), the “ground” level is adjusted for this series of samples. Then the Alarm is set for 5 seconds and the timestamp (StartTS) of the start of the series is captured.

Following these configuration steps, a series of samples collected from the sensor for 5 seconds and reported back using SerialData Logger. Complete captured file is available here. The same data converted to Excel spreadsheet and split by series available here. While you could check the raw data on your own, I would like to bring attention to a few points. The following table provides a summary of the data collected from the sensor in this series of runs:

OSR	Avg. over	T (Msec)	F (Hz)	Err (max, m)	Err (avg, m)	Avg (m)
0	1	6.0	166.67	5.125	1.226	-0.179
1	2	9.0	111.11	3.906	0.912	-0.263
2	4	14.8	67.80	2.281	0.632	-0.119
3	8	26.5	37.74	1.375	0.407	-0.063
4	16	49.8	20.10	1.063	0.293	-0.035
5	32	96.4	10.37	0.688	0.258	-0.181
6	64	189.8	5.27	0.500	0.150	-0.016
7	128	376.4	2.66	0.438	0.152	0.098

The first two columns represent OSR and corresponding number of measurements averaged for each sample. T (msec) and F (Hz) columns present the average time required to obtain a sample and respective frequency of samples generated by the sensor. The next two columns, Err (max, m) and Err (avg, m), provide maximum absolute error (remember, we adjusted “ground” to zero, so in the best case all samples should read zero) and the average error of all collected samples. Finally, the last column provides the average of all samples.

It is very illustrative to look at the chart of the maximum and average sample error plotted against the number of measurements averaged for a single sample:

As we may see from the chart, there is a diminishing return in terms of precision of the sample with the increase in number of measurements averaged for a single sample. For example, when we increase the number of measurements averaged from 2 to 4, the maximum error drops from about 4 to about 2 demonstrating close to linear dependency. However, when we again double the number of measurements averaged from 16 to 32, the maximum error declines by about 25%. The average sample error even less dependent on number of measurements averaged.

On the next chart, maximum and average errors and sample acquisition time are plotted against OSR:

With OSR changing from 0 to about 3 the maximum and average sample error drop almost linearly and then decrease in error slows down while sample acquisition time grows exponentially. Considering that the average of all samples sustain minimal changes with the changes in OSR, it appears that for dynamic systems like a quad we may get the best balance between precision and sample acquisition time by limiting OSR to 2 or 3 and applying some low-pass filtering.

Due to the simplicity of implementation and speed of calculation, I prefer IIR filters. When I take this new board to the air, I will share altitude measurement results using various values of OSR and low-pass filtering.

Meanwhile in the next post we will discuss asynchronous (interrupt-driven) acquisition of samples from MPL3115A2.