A quick introduction to MPL3115A2 Precision Altimeter

Prior to delving into the details of developing PIC MCU software to configure and operate MPL3115A2 precision altimeter from Freescale Semiconductors, we should get some basic details about this sensor. Conveniently enough, Freescale provides extensive documentation for this sensor, including some sample code and Application Notes.

However some of the features of this sensor make it less convenient to use it on the flight control board. For example, in the Auto Acquisition mode, when sensor’s firmware direct it to make periodic samples automatically, the shortest Time Step (interval between subsequent measurements) is 1 second, which is too low frequency to use altimeter data to control hovering or automatic landing. Thus for all practical purposes we would have to resort to One-Shot Mode when setting the OST bit in the CTRL_REG1 control register initiates immediate measurement. Unfortunately to set OST bit respective control register need to be read first, which results in necessity to issue multiple I2C commands – set WRITE mode on I2C bus, send register address, change direction to READ, read register value, set OST bit, change direction to WRITE, write register address and then write register value. And all of this need to be added to each measurement read operation to instruct sensor to start next measurement, which ties I2C bus for much longer time than would be required for a simple read if the sensor would be able to automatically initiate next measurement.

A single measurement in the OST mode takes just 6 msec, so sensor is capable of providing altitude data at a rate of about 166 Hz. However at this rate the precision of the measurements will be less than the stated 0.3 m. To achieve this level of precision multiple measurements need to be averaged. Averaging can be done externally (in the software) or can be done utilizing advanced feature of MPL3115A2 firmware – oversampling, which is controlled by the value of the OSR flags (3 bits OS0, OS1, and OS2 of the CTRL_REG1 Register). OSR takes values from 0 to 7; number of measurements that will be taken and averaged by the firmware to produce one sample defined by 2^OSR – that is from 1 to 128 measurements.

MPL3115A2 documentation provides upper bound of time (in milliseconds) required for producing a sample depending on the value of OSR. Multiple tests that I performed using MPL3115A2 indicate that the actual time required to produce a sample is significantly less than the upper bound. Moreover, capturing a long series of measurements I never saw any meaningful deviation of sample time between samples. The upper bound of the sample time from the documentation and my results from testing MPL3115A2 are summarized in the following table:

Both series of data are also plotted on the following chart:

As it follows from the chart, both series (the one from the documentation and the results of the actual testing) perfectly match linear trend lines. Looks like single measurement takes about 3 msec plus another 3 msec to prepare sensor to take the first measurement. Alternative interpretation of this data could mean that a single measurement takes about 6 msec, but the firmware allows about 3 msec of overlap in some processing for a series of measurements. Later on we will look at how averaging of multiple measurements reduce noise and will try to find the optimal balance between the level of noise and time required to produce a sample.

With this background we may proceed to the topics of developing MPL library facilitating configuration and reading data from this sensor. Obviously this specialized library will rely on my generic I2C library, which we discussed in the previous posts.