Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BHI160 and BMM150 accuracy definition for SW API what does this mean

    BHI160 and BMM150 accuracy definition for SW API what does this mean

    owain-incus
    Established Member

    Can someone please explain the meaning of the "accuracy" value given back in the SW API's for most sensor measurements for BHI160 and BMM150. I undertstand the algorithms train themselves to try and minimise errors and maximise accuracy.

    We are currently reseting the whole chip complex and re'initialising between taking measurements. I think this is probably wrong; meaning we would always start  sampling from a low accuracy point. How long does sensor complex have to be running to reach a state of best accuracy?

     

    I have seen a definition was posted here for one of the other sensors.

    https://community.bosch-sensortec.com/t5/Question-and-answers/What-does-the-IAQ-accuracy-mean-in-BSE...

    Is this defined anywhere for the BHI160 & BMM150?

    6 REPLIES 6

    owain-incus
    Established Member

    Just been dumping the accuracy value for the  VS_ID_ACCELEROMETER_WAKEUP, VS_ID_GYROSCOPE_WAKEUP, VS_ID_MAGNETOMETER_WAKEUP.

    When I start sampling I see them all start off 0 - unreliable; after a short period maybe a (second/minutes) I see the magnetometer has progressed to accuracy 3; yet the accelerometer and gyros still say 0. Can I expect these also to at some point start reporting high accuracy and not just unreliable?

     

    Hi owain-incus,

    BHI160 follows the Android sensor type and naming conventions. This question is already answered here:
    https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/BHI160-plus-BMM150-calibration-procedure...

    owain-incus
    Established Member

    Hi,

    Thanks for links; trying to digest these at the moment.

    So some background. We are working on a tracking/movement analysis product. We analyse how people move.

    Typical use case being someone goes for a 30 minute+ run. We log at 100Hz and use virtual sensors for accelerometer, Gyroscope, magnetometer, linear acceleration and orientation. We power-up the sensors at the start of the run and down at the end. We need high accuracy data for our further analysis.

    So are you saying this is the wrong way to use the device?
    Are BHI160 calibrators running all the time the device is on; irrespectful if we have enabled or disabled the virtual sensor?
    Is the fact we are power cycling the sensor complex screwing us?

    If we are powering the device up and down (Actually removing power and reloading FW each cycle); do we need to somehow save/initialisise the configuration?

    As said I can see magnetometer starting off un-reliable; but progresses to reliable; but I have not yet seen Gyro or Accel reporting anything but unreliable?

    Regards,

    Owain

     

    owain-incus
    Established Member

    This is still not resolved for us. 

    Some of the threads I have been pointed at talk of BN0055; we use BHI160B; they do talk of unrealiable or incorrect status fields; also of magnetometer drift. But they use different chip, FW and libraries.

    We really need a solution here; to help make things clearing WRT to status/acuracy fields for the sensors we have logged the following data at 100Hz to CSV; column headers being.....

    static const char csvHdr[] = "#timestamp, Accel(x,y,z,status), Gyro(x,y,z,status), LinearAccel(x,y,z,status), Ori(roll,pitch,yaw,status), Mag(x,y,z,status), "\
    "UncalGyro(x,y,z,xBias,yBias,zBias,status), UncalMag(x,y,z,xBias,yBias,zBias,status), " \
    "Rota(x,y,z,w,estimateAccuracy), GeoRota(x,y,z,w,estimateAccuracy)\n";

    I am attaching a short log file; where we turn the sensors on and start logging. The only sensor that seemes to indicate good status is the magnetometer; which progresses as it calibrates itself status moving from 0->1->2->3; BUT status for the accelerometer, Gyro, linear acceleration etc all are stuck at 0.
    Is this a Bosch Firmware issue or documentation issue with these status values.

    We are using firmware...

    Bosch_PCB_7183_di03_BMI160_BMM150_BME280-7183_di03.2.1.11696_secondaryAddr

    Could you please advise.

    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