BMI270 gyro scaling incorrect if using FIFO with prefiltered data

[etracer]

First let me start by saying in my application I'm not using the API and have implemented my own driver. Everything is working properly when not using the FIFO. However we want to utilize the 6.4KHz ODR and this requires using the FIFO and prefiltered data. The problem I'm seeing is that when we choose filtered data for the FIFO (FIFO_DOWNS = 0x88) the data is correct and the GYRO_RANGE of +=2000dps (GYRO_RANGE = 0x00) works as expected (and matches the behavior when doing direct register reads instead of using the FIFO).

However when switching to prefiltered data (FIFO_DOWNS = 0x00) to get the 6.4KHz ODR the GYRO_RANGE seems to be ignored and the data behaves as if the range is +-250dps (as if GYRO_RANGE was set to 0x03) even though it's set to 0x00 (and verified by reading the register back). So instead of 16.4 LSB/dps it's behaving like 131.2 LSB/dps. This is unworkable in our application as we need the full +-2000dps scale.

Everything else behaves as expected. The ODR in the FIFO is 3.2KHz when using filtered and 6.4KHz when prefilitered as it should. It's just the GYRO_RANGE and the full-range scaling that seems to be misbehaving.

In this test case the FIFO was configured for headerless mode and only the gyro data was enabled (FIFO_CONFIG_1 = 0x80).

So to recap, the gyro data in the FIFO behaves normally if it's configured to be filtered data. However when set to be prefiltered data the scaling is incorrect and seems to be behaving like GYRO_RANGE = 0x03 (+-250dps) even though it's set to 0x00 (+-2000dps).

Any thoughts?

[Vincent · Accepted solution]

You can change the register 0x43 bit 3 to 1, then the gyro range is 2000 dps as expected.

[etracer]

Thank you, that seems to work. But I don't know why. According to the datasheet bit 3 of the GYR_RANGE register (0x43) is the ois_range. I'm not using OIS and it's disabled (by default). Is the datasheet wrong or is there something else going on here? I was setting GYR_RANGE to 0x0 (which is the default anyway) and this selects 2000dps for the gyro data. And this works properly if using register based reads or even the FIFO when filtered data is selected. However when prefiltered data is selected is seems to ignore bits 0-2 and only uses bit 3 (when 0 means 250dps). I can't find anything int he datasheet that documents this behavior.

[Vincent]

Yes, it is not in current datasheet yet.

When you select the prefilter data then the OIS data channel will be used to fill into the FIFO. 

We will udapte our spec later on to make it clear. 

[etracer]

Thank you. A couple of other suggestions for improvements in the datasheet for things that seemed confusing:

• Better document the unusual SPI register read behavior where 16 bits must be read with the initial 8 bits ignored. There is only one small mention of this critical fact and it's embedded and not easily noticed. See page 141.

Please note that the first byte received from the device via the SDO line correspond to a dummy byte and the 2nd byte correspond to the value read out of the specified register address. That means, for a basic read operation two bytes have to be read and the first has to be dropped and the second byte must be interpreted.

---

• In the register detailed descriptions identity all the bits. There are numerous cases where only the funtional bits are identified and often it's not clear that some bits are skipped - leading to easy mistakes. For bits that are not valid identify them as "reserved" or "not used". For example INT1_IO_CTRL and INT2_IO_CTRL only define bits 1-4 but it's easy to misread this as the first nibble. Or INT_STATUS_1 which defines every bit but 3 and 4. So not saying the datasheet is incorrect in these cases, but it could be more clear and easier to interpret if all the bits were defined - even as "reserved".