Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BMX055 with BSX Lite Bug

    BMX055 with BSX Lite Bug

    embed4
    New Poster

    Hello,

    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*/
    bmg160_set_range_reg(0x02);
    bmg160_set_bw(0x06);

    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
    bmg160_set_bw(0x06);

    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 */
    bmg160_get_data_XYZ(&bmf055_gyr_data);
    /* Convert the timer tick to micro seconds */
    timestamp_dataxyz.gyro.time_stamp = local_timestamp * 1000;
    timestamp_dataxyz.gyro.data.x = bmf055_gyr_data.datax*2; // scale everything
    timestamp_dataxyz.gyro.data.y = bmf055_gyr_data.datay*2;
    timestamp_dataxyz.gyro.data.z = 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

    o_o
    Contributor
    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.

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist