Electrical – How to compute acceleration from accelerometer raw data

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.

What you're worried about is sampling jitter. I wouldn't sweat it for this application; running the sampling code in a loop will tie the sample time to the crystal oscillator on the Arduino, which should have more than adequate stability for your application.

Sample rate is something you should think more about, however. In order to resolve the acceleration from hitting a pothole, which is generally a short event, I'd recommend sampling rates in the range of 200Hz - 2kHz. The higher the better, at the cost of increased storage to hold all of the samples.

At lower sampling frequencies, you'll still see an acceleration spike from hitting the pothole, but it's likely that you'll miss the actual peak of the event due to sampling error. As a result, it will look less severe in your data than it actually was.

As an aside, it's fun to look at what your suspension does for you. Mount a high fullscale accelerometer directly to the unsprung mass (i.e. on your wheel hub). That will show you what the acceleration looks like before it's mechanically filtered by your suspension.