Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMX055 with BSX Lite Bug

    BMX055 with BSX Lite Bug

    New Poster


    I have spent the last week trying to figure out why the BSX Lite library (Cortex M0+ version from the BMF055 evaluation board shark demo) would give bad orientation data on my custom BMX055 board whenever I fed the gyro data into the library.

    In order to save everyone else having this problem some time, here is what I found: In bmf055.h, the gyro is initialized as

    /* BMG settings for running BSXLite: Range = 500dps, BW = 64Hz*/

    This is wrong! Apparently that version of BSX lite requires 250dps, so all raw values are too low by a factor of 2. If I change this to

    /* BMG settings for running BSXLite: Range = 250dps, BW = 64Hz*/
    bmg160_set_range_reg(0x03); // fixed range

    it works. Another alternative if one wants to keep the larger gyro range is to manually scale the raw values instead:

    /* Read and process gyro data */
    /* Convert the timer tick to micro seconds */
    timestamp_dataxyz.gyro.time_stamp = local_timestamp * 1000; = bmf055_gyr_data.datax*2; // scale everything = bmf055_gyr_data.datay*2; = bmf055_gyr_data.dataz*2;

    With these modifications is works very well. I'm a bit lost though why they are required. I find it hard to believe that such a bug has made it into the evaluation board, as it pretty much breaks the sensor fusion. So it might be something else, but I have not idea what could cause an incorrect reduction by a factor of 2.

    2 REPLIES 2

    Is your timestamp accurate ?

    Thanks, you suggestion is very much to the point. I can see that the quality of the output largely depends on the frame rate. If it is just a few percent off 100fps, it starts to drift a lot. I'm assuming this is due to the double integration of the acceleration data?

    I also had delay in the I2C routines as I found that commands were ignored if sent too fast. The result was that reading the accelerometer data took 1-2 ms. As I was using the same timestamp for accelerometer and gyro, that probably caused some inaccuracy as well.

    Finally I'm currently taking the timestamp from the 32.768kHz RTC; as the MCU must sleep between cylcles, which probably also causes some inaccuracies. I will see if I can get a more accurate counter.