Invensense MPU9150 Accelerometer Raw Values Even

Question

I've been working on pulling data from an MPU-9150 for a data filtering project, and I ran into a issue that I'm not sure of the cause.

When I set the accelerometer to ±2g or ±4g range, all the raw values are even (i.e. evenly divisible by 2). However, if I set the range to ±8g or ±16g, the values can be even or odd.

I've been in touch with Invensense tech support because of a different issue of spiky data distributions, however they didn't think there should be a reason the values should be only even. I've run into this issue using my own code as well as Jeff Rowberg's I2Cdev MPU-9150 library.

What I'm looking for is some more opinions on what might be the reason behind this as I wait to hear back from Invensense. I'm far from an expert on MEMS architecture, and there are tons of computer science nuances that I'm sure I'm unfamiliar with, but I'd like to hear if people have an idea on why I'm getting what seems like an anomaly.

Please let me know if I can provide more information.

Thanks,

MPU-9150 Datasheet

Answer 1

Getting 16-bit resolution from an ADC is difficult. Power supply switching noise can easily be coupled into your ADC causing loss of resolution. The fact that you only get even data with some scale factors tells me that the ADC is OK at some scale factors and the noise is being amplified.

I have seen this behavior with successive approximation ADCs. https://en.wikipedia.org/wiki/Successive_approximation_ADC For example, lets say the true value of a reading is 61. The ADC will successively test for smaller and smaller bits, Is the value >=256?, is the value >=128?, is the value >=64? Lets say that because of a noise glitch, it thought it was >=64. Now, it will be testing for values >64, and when it tests for the lowest bits (assuming no more noise glitches), they will be zero.

This issue would cause lower bits to be zero with a higher than expected probability, but not always, since a comparison won't always happen coincidental with a noise glitch. It would be interesting to analyze a large amount of data. You would need to do something to assure that a large variation of data occurred, this could be a simple as manually moving the module around. Assuming a fairly random input, each of the least significant bits should be "1" an average of 50% of the time. If not, then there are errors in the system.

To truly diagnose this, you need to demonstrate that the erroneous readings correspond to the noise glitches. This may not even be possible since this is an integrated system.

Cheap power supplies produce a tremendous amount of high-frequency noise. You could use a quieter power supply, or filter the one you have. An extreme modification would be to power this module with a separate linear supply, with just one ground connection between this module and the remainder of your system.

Finally, it is possible that the module could meet it's navigation specifications even though a few LSbits are invalid.