Electronic – arduino – Accelerometer data smoothing filtering pothole detection

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.

Yes, you need a time reference. A timer interrupt which sets off the ADC conversion is usually the best bet. Its also possible to let the ADC free-run and use periodic (every n-th) reading. That makes for OK time data, if not great.

As for the frequency of sampling, what you need to figure out is the bandwidth that you need. Suppose the vibrations that ensue are have a frequency of x Hz, you would need atleast 2x Hz to reconstruct a vibration assuming its purely sinusoidal. This is sort of a theoretical limit. Since a pothole isn't going to produce a sinusoidal vibration, and theory doesn't always translate directly to real life, you'd probably need to sample at atleast 10x Hz.

For something like a car, I would guess the vibrations to be in the order of, say, 10Hz to 1KHz. (For reference, buildings generally vibrate at sub 1-Hz. Small metallic objects designed to withstand vibration and things like rockets would vibrate in the 50-200 Hz range. Tuning forks vibrate at Kilohertz, usually , like the 32.768 KHz tuning forks commonly used in electronics for time keeping, and quartz crystals vibrate in the MHz range). So a sampling rate of above 10KHz is porbably more than enough. You could try with less and see if it works, but I really haven't done any calculations for cars to be sure. I'm fairly confident 1KHz should be as far as the vibrations should go, and it'll probably be less than than in reality.

EDIT : If you're only really interested in the large scale vibration of the car, as you say 10-13Hz is what you are interested in, 100Hz should be enough. I'd sample at 1KHz to be safe.