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.
Best Answer
In ADC or DAC terminology, one LSB is the size of one step that an ADC can resolve or that a DAC can output. So you can have a one LSB step between 0 and 1, and one LSB step between 254 and 255, or anywhere else in the ADC range.
One LSB is the smallest that a single reading of the ADC can resolve, not measure. - If an ADC is noisy, then you may not be able to measure down to 1LSB in a single measurement, but if it's noisy and more accurate than its ADC, you may be able to average multiple measurements below one LSB.
Basically, the 10 bit resolution of the ADC affects your reading because, for a perfectly linear 10-bit ADC, there are \$2^{10} = 1024\$ steps between its minimum reading and its maximum reading. A \$\pm\$2g accelerometer with a 10-bit output is going to have 1024 different possible measurements from -2g to +2g, so -- depending on some fine details in how they treat end points -- one LSB will be exactly, or close to, \$\frac{4\mathrm g}{1024}\$.
As a counter-example, if it were a 16-bit output, then 1 LSB would be \$\frac{4\mathrm g}{65536}\$.