ZHomeSlice
commented
5 years ago 0100000000000000B = 16384 DEC = 1G at +-2G 0010000000000000B = 8192 DEC = 1G at +-4G 0001000000000000B = 4096 DEC = 1G at +-8G 0000100000000000B = 2048 DEC = 1G at +-16G 0 ^First Zero sets the value to positive (+) when zero and negitive (-) when one. Everything to the right of the 1 is a fraction of gravity depending on how many zeros to the left of the 1 depends on how many G's are shown but the resolution degrades accordingly. To tell what resolution you are seeing take the 16 bit signed int Z-axis number while right side up and on a flat surface, then divide it by one of the numbers (16384, 8192, 4096, 2048) the closest to 1 (G) is the resolution you are using with the accelerometer. DMP firmware handles lots of math behind the scenes and what it actually gets from the accelerometer could be different than what we are asking the MPU to stuff into the 16-bit integer in the FIFO buffer. The DMP Firmware setup may require the Accelerometer resolution to Match what it is reading. the details of how to Configure the DMP can be found in the Invensense Developers Login portion of the site once logged in search for the MPU6050 chip and the latest V6.12 firmware and example code is available to download. Z
in the MPU6050_6Axis_MotionApps20.h it says that
but in the register map documentation (https://www.invensense.com/wp-content/uploads/2015/02/MPU-6000-Register-Map1.pdf) it states on page 29:
I checked the AFS_SEL on my MPU6050 and it was on 0. But the example code that you get with
#define OUTPUT_READABLE_REALACCELwas working well (getting values of ±100 around 0 when not moving the sensor) even tho it is using the "wrong" value to calculate in dmpGetLinearAccel.Can someone please explain that to me.