05-21-2020 12:08 PM
We're using the BMI270 with a BMM150 attached to the I2C auxilliary port. When I enable just the BMI270 accelerometer and gyro, everything works as expected, reading the FIFO produces the correct number of samples per second. As soon as I enable the auxilliary sensor, I get strange behaviour where the sample rate for the accelerometer and gyro seems to drop to 1 to 2 samples per second.
Code snippets for the configuration below. Samples per second is determined by reading a FIFO frame every 500 ms and using the
bmi2_extract_accel
etc functions.
/* Setup accelerometer data rate, range */
{
bmi2_sens_config config = {};
config.type = BMI2_ACCEL;
config.cfg.acc.odr = BMI2_ACC_ODR_100HZ;
config.cfg.acc.bwp = BMI2_ACC_OSR4_AVG1;
config.cfg.acc.range = BMI2_ACC_RANGE_8G;
bmi2_set_sensor_config(&config, 1u, device_);
}
/* Setup gyroscope data rate, range */
{
bmi2_sens_config config = {};
config.type = BMI2_GYRO;
config.cfg.gyr.odr = BMI2_GYR_ODR_100HZ;
config.cfg.gyr.range = BMI2_GYR_RANGE_250;
config.cfg.gyr.bwp = BMI2_GYR_NORMAL_MODE;
config.cfg.gyr.noise_perf = 0u;
bmi2_set_sensor_config(&config, 1u, device_);
}
/* Configure auxilliary sensor - BMM150 */
{
const uint8_t device_address = 0x13u;
bmi2_sens_config aux_sens_config = {};
aux_sens_config.type = BMI2_AUX;
aux_sens_config.cfg.aux.aux_en = BMI2_ENABLE;
aux_sens_config.cfg.aux.manual_en = BMI2_DISABLE;
aux_sens_config.cfg.aux.odr = BMI2_AUX_ODR_25HZ;
aux_sens_config.cfg.aux.aux_rd_burst = 6u; /* 3 axes * 2 bytes */
aux_sens_config.cfg.aux.read_addr = 0x42; /* 0x42 - MAG LSB X */
aux_sens_config.cfg.aux.i2c_device_addr = device_address;
bmi2_set_sensor_config(&aux_sens_config, 1u, device_);
}
/* Configure FIFO */
uint16_t config = BMI2_FIFO_HEADER_EN | BMI2_FIFO_ACC_EN | BMI2_FIFO_GYR_EN | BMI2_FIFO_AUX_EN;
bmi2_set_fifo_config(config, BMI2_ENABLE, device_); res != BMI2_OK );
Solved! Go to Solution.
05-23-2020 05:37 AM
Hello
Thanks for your posts and interests in using Bosch sensors.
I checked your settings into details, one thing I noticed is that:
aux_rd_burst = 6; /* 3 axes */
actually, 6 is an invalid value, valid values range from 0 to 3, from the datasheet:
https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi270-ds000-2.pdf, page 116 or search for: man_rd_burst
0: burst read of length1
1: burst read of length 2
2: burst read of length 6
3: burst read of length 8
You may want to change this and see what happens.
I personally had tested the sensors' streaming in FIFO with accel/gyro/mag in the past, but never seen issues with samples dropped or alike.
One thing to be noted though: the actual ODR is not exactlly the same as what is selected due to the fact that the clocks on the sensors can not be perfect, for example, when you set the ODR to 100hz, the actually ODR could be 99hz or 101hz, and this error is also specified in the datasheet on page 14 (ODR Accuracy), so in one second you might see 99 or 101 samples instead of expected 100 samples, if you see 99, you might think a sample is lost while this is absolutely expected normal behavior.
Hope this explains!
Take care!
05-24-2020 10:07 PM
Even with that value fixed it doesn't work. Interestingly it made no difference to operation (6 bytes was correctly being read by the BMI270 with both settings), I guess the library masked off the top bit making the values 2 and 6 the same anyway.
05-24-2020 11:33 PM
I found the problem. The extract_xxx functions for extracting data from the FIFO use the record lengths in the fifo frame structure (e.g. fifo_all_frm_len), but these values are incorrectly populated by the library. They're set to hardcoded values rather than matching the actual configuration of the device. So.. setting the burst read length of the auxilliary sensor to anything other than 8 results in these functions producing incorrect results. I'm going to open a bug on the github repo with this but Bosch doesn't seem to pay any attention to these.
05-25-2020 08:20 PM
I will ask our API team to look into this and come back to you later.
05-30-2020 12:37 AM
@Vincent wrote:Can you print out the frame header which you parse error to cause the function exited?
Your implementation looks fine and our API is considering all possible FIFO frame header situation in our API code.
It will only finish parsing if they met 0x8080 as padding bytes under FIFO header mode.
The length for aux data is hardcoded, it's not using the setting as far as I can see. When I had the aux read size set to 6 I would expect a full frame to have 6 aux + 6 accel + 6 gyro = 18 bytes, but the library assumes 20 bytes, so as soon as it seems a frame with aux data in it it breaks.