Recovering data from a saturated accelerometer

I have an ADXL345 accelerometer and mounted it to a hybrid rocket to launch. Unfortunately, I forgot to set the range from its default of +/-2g to +/-8g (we expected 6g during liftoff).

For +/-2g range, the datasheet lists an output resolution of 10 bits, and for +/-8g it lists a resolution of 12 bits.

I noticed this in the datasheet linked above, under the DATA_FORMAT register (0x31):

The DATA_FORMAT register controls the presentation of data to Register 0x32 through register 0x37. All data, except that for the +/-16g range, must be clipped to avoid rollover. (emphasis mine)

Based on this statement and the functional block diagram (a 3-axis sensor is connected to "sense electronics", then connected to an ADC), I am hoping there is a way to resolve the correct data. The scale factors are listed on page 3 of the datasheet.

Is there a way I can resolve this data, at least to 1 or 2 significant figures? (For instance, I have a detection of 1.9414g - this should be around 6). I don't think the sensor saturated, merely the number in the data registers - and given the scale factors and some creative bit-shifting (it is not totally clear how they get from 10 to 12 bits when changing resolution), hopefully I can recover something useful from my data.

Answer

What value did you actually store into "Register 0x31—DATA_FORMAT"?

I'm going to assume you didn't store anything into that register, so it is still in its reset value of 00. In other words, while you were collecting data (from Table 16 and also page 17 of the ADXL345 datasheet):

• Register 0x31—DATA_FORMAT == 00.


• The FULL_RES == 0. So the device is in 10-bit mode, and the range bits determine the maximum g range and scale factor.


• The Justify Bit == 0. So right justified mode with sign extension.



• The Range Bits == 00. So +- 2g range.

The first thing I would do is recover the original 16 bit values as read from the accelerometer. (i.e., if I've carelessly thrown away the original data, and all I have left is numbers in units of "g" that were calculated by subtracting some offset and multiplied by some incorrect scale factor, I would copy the collected data into a spreadsheet and divide by that same (incorrect) scale factor and then add that offset to try to recover something close to the original values).

Then I would graph the data and see if it looks more like "saturation", "linear", or "roll-over" (as described below).

The datasheet is maddeningly vague as to what happens when the sensor experiences an acceleration greater than 2 g.

tangential rant

Did I tell you how much it annoys me when technical writers insist on writing in the passive voice? When the writer uses the passive voice in the sentence you quoted,

"All data, except that for the ±16 g range, must be clipped to avoid rollover." (page 17)

I can't tell who exactly is supposed to do this clipping.

Many people recommend using the active voice. When I follow those recommendation, my text is usually more clear as to who does what. Isn't it better when I write stuff that is easier to understand, rather than using a style that people have been tricked into thinking sounds "more professional" or "more scholarly"?

automatic clipping

My best guess is that the accelerometer automatically does this clipping.

saturation: If you see the acceleration ramp up through plausible values, then mysteriously get stuck at a plateau, saturating at or near +2g, then the accelerometer "helpfully" clipped the data for you. After clipping, the "top" value no longer indicates "an acceleration very close to +2g", but now indicates "an acceleration at least 2g, and possibly much, much more -- there's no way to tell".

Because it was in 10-bit right-justified mode, when I interpret those 16 bit values as normal 16 bit signed integers, I expect to see values ranging from

• 0x01FF = +511, indicating more than 1.992 g. Possibly much, much more.


• 0x01FE = +510, indicating 510/256 g ~= 1.992 g


• 0x01FD = +509, indicating 510/256 g ~= 1.988 g



• ...


• 0x0001 = +1, indicating 1/256 g = 0.0039 g


• 0x0000 = 0, indicating 0 g


• 0xFFFF = -1, indicating -1/256 g = 0.0039


• ...


• 0xFE02 = -510, indicating -510/256 = -1.992 g


• 0xFE01 = -511, indicating -511/256 = -1.996 g


• 0xFE00 = -512, indicating something more negative -1.996 g. Possibly far, far more negative.

(Yes, I know that 4 decimal places of precision is unwarranted for this sensor). (I've seen some devices saturate at some other point, such as -511 or -510. I can usually look at the data and figure out the actual saturation point).

You can recover some useful data from this clipped data set. You can use it to measure, for example, how many milliseconds the acceleration was at least 1.5 g. Alas, when you see the plateaus in this kind of data set, it's impossible to measure the maximum acceleration or the total impulse -- the best you can do is say, "well, we know that maximum acceleration is at least 2g and probably more", and calculate "well, we calculate that the total impulse is at least (something) newton*second".

alternatives

It should be possible to figure out whether the accelerometer does clipping or not from the data. (I've described "saturation", "linear", and "roll-over" in terms of the ramp up -- with some sets of data, it may be more clear to look at the ramp down instead).

linear: If you see the acceleration ramp up through plausible values, then continue ramping up to higher values (values above 512, or more negative than -512), then you lucked out -- the accelerometer didn't actually do any clipping, and you have valid data through the whole range.

roll-over: If you see the acceleration ramp up through plausible values, and just before it gets to +2 g, it instantly jumps to a non-physically-realistic value near -2 g and then continues to ramp up -- possibly going through zero, then approaching +2g again, and jumping back down near -2 g again -- then you have roll-over wrap-around. If you are lucky, the values change extremely smoothly, making it possible to detect each rollover and "unwrap" these values to recover the true g force.

p.s.: feel free to edit Open Circuits: Rocket Computer.