I am using a BMI160 with a TI MSP430FR6989. I am able to communicate with the BMI160 without problems, reading chip ID, registers, etc. However, when I read data from the X, Y, and Z accelerometer registers I get strange values, even after I run fast offset compensation. My code is available here
When I run my code, the output from the main function is 6 bytes. These are the three 2 byte outputs of the three data registers for the accelerometer. When I have the sensor sitting so that the Z axis is parallel to gravity and the fast offset compensation is compensating for the Z axis, I get this output.
11111001 11111111 01010011 11111111 00011111 00000111
This is the X, Y, and Z registers, in LSB, MSB format because I am burst reading through registers 0x12-0x17. Therefore, the decimal values for X, Y, and Z respectively are 65529, 65363, and 1823. With a range of 8g, I divide by 4096 to get values of 16g, 16g, and 0.45g respectively. I do not understand how this could even occur. Offset notwithstanding, the values should never be that wrong. I am expecting to get 0g, 0g, and 1g if I am calibrating around the Z axis. This makes me think that I have initialized the accelerometer wrong. Can anyone tell what might be wrong or things I can try to fix this?
I've tried calibrating around different axes, such as setting the BMI160 so that X is parallel to gravity, then running fast offset compensation around the X axis. This provides the same results, where the axis parallel to gravity always reads 0.45g~0.5g, and the other two axis perpendicular to gravity read 15.5g~16g.
Solved! Go to Solution.
There was BMI160 example code in github, you could refer and run it first. First run the function normally, then optimize it to your platform.
the value you read out from the chip is 16bits in 2's complement.
So 65529, 65363, and 1823 would actually mean:
0xFF29, 0xFF53, 0x71F (16 bits)
and thus respective true values are: -215, -173, 1823
and likely (my guess) you have set the g range to +/- 16G (instead of 8G), to confirm this, register dump of 0x40 would clarify things up.
and in that case (assuming range of 16G), the g values are:
-215/2048 = -0.1g (close to 0)
-173/2048 = -0.08g (close to 0)
1823/2048= 0.89g (which is close to 1g)
like the other user commented, it would be helpful to use the APIs on the github (https://github.com/BoschSensortec/BMI160_driver) for easy translation/convertion of the register values in to g-values, also it would help with the proper set up of the sensors to avoid surprises, it should have some examples on how to use as well.