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?
... View more