BMX055 gyro offset compensation

[murrellr]

We are using the BMX055 in a new product and I am seeing an offset on the gyro Z axis that I can't get nulled out.  I am only looking for rotation on the Z axis, so I don't know if the problem is the same on the other axes.  The SPI communications is working correctly as I can set registers and read back the setting.  I have set the following parameters on the device:
- FIFO is in BYPASS mode reading X,Y,Z.  I don't read the interrupt bytes.
- RANGE is +-1000 deg/sec (001)
- BANDWIDTH is 47Hz (0011)
- SPI reads are in burst mode when reading the rate.

I am polling the device every 10ms.  I presume by the BANDWIDTH setting, the device outputs about every 21ms.  Since my polling rate is faster than the update rate, I read presumably correct frames followed by one or more 0x8000 frames, which I assume are "no data" values.  I discard these.

For my test, I set an initial counter to zero, and then accumulate the Z axis data for a few seconds.  The accumulated data creeps up over time.  I would expect a compensated value to average out to zero over time.

I tried to enable slow compensation by setting register 0x31 to 0x07 (min threashold and duration) to 0xEF (max), but this has no effect.  In all cases, when I read the offset registers 0x36 to 0x39, their values are always zero.  I have verified that the raw Z axis values are mostly positive, with a few negative values.

Am I doing this correctly or am I missing a step or two?

[o_o]

Hi murrellr,

I think that indeed you are missing a step or two 😛

First of all, in 47Hz Bandwidth setting the Output data rate is 400Hz, so a new data point every 2.5ms. Please refer to the datasheet documentation for gyroscope register 0x10.

Secondly, when the FIFO is set to BYPASS more, the depth is reduced to 1, which means that you will always read a single data frame, no matter how many samples happened since the last read, this does not offer any advantage vs directly reading the data register in your use-case. You may consider the STREAM mode instead.

Thirdly, the slow offset compensation may not work like you think that it works. It has a minimum threshold of 0.1dps, which means it will never fully converge towards zero. It is essentially a high-pass filter with an automatic disabling for the duration parameter while the value is below the threshold.

If you have a way of knowing that the device is at rest, then I would recommend the use of fast offset compensation, which will average up to 256 samples. Or, you can sample the data, calibrate the offset yourself and write it to the OFFSET registers. In any case, the noise is not gaussian. Integrating the data will always eventually diverge.

[murrellr]

I tried fast compensation but did not see any effect.  I set various values to register 0x32.  I also tried different sequences of values to register 0x32: 0x0F (single command), 0x03 followed by 0x0F, and 0x03 followed by 0x08.  After each attempt, I would read the offset registers 0x36 to 0x39, but they are always zero.  I was expecting that the fast compensation values would show there.

At this time, we are only using the gyro on this chip.  Here is how we are accessing the chip.

1. The chip powers up to factory defaults.
2. Perform a BIST to verify the gyro operation.
3. Set the range register 0x0F to 0x01, +-1000 deg/sec.
4. Set the bandwidth register 0x10 to 0x03, 400Hz ODR, 47Hz bandwidth.
5. Read the angular rate registers 0x02 to 0x07 every 10ms, using burst access.

I can read and write registers dynamically from a command interface to test the gyro operation.  Am I missing a configuration step?