03-03-2022 10:38 AM
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:
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?
2. What would be the issue to speed it up?
3. (extra) What would be the issue to not perform FOC at all?
03-03-2022 01:37 PM
Hello aloiseau,
Yes, the FOC of BMI 160 is processed internally, and its FOC completion time is fast.
For BMI 270, what is the expected completion time of FOC?
03-03-2022 02:39 PM - edited 03-03-2022 06:22 PM
Of course, the faster the better, but factory ask me to reach a global FOC duration (accel+gyro+saving NVRAM) under 5 seconds max.
I was thinking about modifying the BMI270 FOC loops (increasing ODR likely), but I was unclear about current algoritm choices. I don't want to mistakently break FOC accuracy by blindly speeding it up without understanding current algorithm choices.
03-08-2022 08:04 AM
Hello aloiseau,
To reduce the completion time of FOC, you could increase accel, gyro ODR.
Accel ODR: higher than 50 Hz
Gyro ODR: higher than 25 Hz
And modify delay time in sensor API.
03-11-2022 09:12 AM
Thanks,
Yes, this is the idea I had in mind, and I will likely implement it.
I was trying to find why Bosh chosen to implement a "slow" FOC here, in case there were specific reasons I should be aware of before speeding it up.