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.


MPU-9150 Datasheet

  • \$\begingroup\$ The datasheet link isn't working for me. Do you know what type of A/D converter is inside the module? For successive approximation A/Ds, I have seen lower bits dropped in poor (noisy) designs. Examine the data in binary, if you are seeing a disproportionate quantity of data divisible by 4 (2 LSbits zero), then this could be the cause. \$\endgroup\$
    – Mattman944
    Jun 3, 2019 at 2:31
  • \$\begingroup\$ Sorry the link didn't work, try this one: link I didn't see any details on what type of ADC is in the module other than it's a 16-bit ADC. I did ask Invensense if they can share any details on the ADC and I'm waiting to hear back now. I did check the accelerometer data and all the values returned are divisible by 4. I hope you'll forgive my ignorance, but my background is ME, not CS or EE. Could you provide some more details on how these two least sig bits relate to this issue? Thanks for the suggestion! \$\endgroup\$ Jun 4, 2019 at 20:00

1 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.

  • \$\begingroup\$ Now these are some really interesting details. It may require quite a change in my setup to get a more consistent power supply. Do you happen to have any other resources on how these scale factors work at the ADC level? I'd like to understand more about why this noise issue doesn't affect the other scale factors. Thanks for your input! \$\endgroup\$ Jun 16, 2019 at 23:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.