I have a BMI160-based project switching to BMI270. This project relies on BoshSensortec libraries available on github(historically BMI160_driver, now BMI270-Sensor-API).
As opposite to BMI160 (for which library delegate the FOC process to the chip itself), BMI270 library perform the FOC itself. Both libraries exposes a foc function so this is transparent from the library user point of view.
But BMI270 fast offset compensation calls are very slow due to their current design:
- perform_gyro_foc performs 128 loops with 50 ms delay each (delay chosen because ODR set by set_gyro_foc_config is 25Hz / 40 ms), which results in 6,4 seconds minimum duration
- perform_accel_foc performs 128 loops with 20 ms delay each (delay chosen because ODR set by by set_accel_foc_config is 50 Hz / 20 ms), which results in 2,56 seconds minimum duration
This result in roughly 10 seconds to perform FOC on those two sensors, which is insanely slow for a factory. And my need is to calibrate accelerometers on factory side since products does not have a known position afterward.
My questions are:
1. Why those "slow" ODR have been chosen for FOC actions?
- Are low ODR wanted to operate a low-pass filter for a more accurate FOC?
- Were they chosen for wide hardware compatibility, in order to not require high speed buses and processor for this function?
2. What would be the issue to speed it up?
- Ideally, enabling FIFO and a higher ODR may collect 128 samples much faster
- Simply a higher ODR / smaller delays, without a FIFO which may be cumbersome to implement, may lead to faster FOCs
3. (extra) What would be the issue to not perform FOC at all?
- Well, if FOC must be as slow to be good, is there a known worst offset shift to expect after BMI270 chip is soldered?