Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BMX160 fifo sensor_time not always provided

    BMX160 fifo sensor_time not always provided

    André
    Established Member

    I use the following settings:

    #define LATCH_DUR BMI160_LATCH_DUR_320_MILLI_SEC
    #define ODR BMI160_ACCEL_ODR_400HZ
    #define FIFO_SIZE (2048) // 25 bytes overread to fetch timestamp of last frame
    #define FIFO_LENGTH (FIFO_SIZE)
    #define FIFO_ACC_SIZE 140 // fifo can contain max (1024 - 25 overread)/7 = 140 entries
    #define FWM_LEVEL 110 // full watermark at 80%
    #define FIFOCONFIG BMI160_FIFO_ACCEL|BMI160_FIFO_HEADER|BMI160_FIFO_TIME

     

    What I get is sometimes a dev->fifo->sensor_time  is set and sometimes not.

    Requirement is that the last header in the fifo must be a 0x44 timestamp header (see extract_accel_header_mode() )  but that is not always the case.

    it also hits the break below in unpack_accel_frame()

     

    /*Partial read, then skip the data*/
    if ((*idx + BMI160_FIFO_A_LENGTH) > dev->fifo->length)
    {
    /*Update the data index as complete*/
    *idx = dev->fifo->length;
    break;
    }

    Consider the following table that shows the last 10 bytes from several fifo dumps:


    66 3 c6 40 12 b 84 82 3 ef   dev->fifo->sensor_time=0
    ef 6 fd 3e 82 e 84 34 8 8f      dev->fifo->sensor_time=0
    41 1 91 3c 82 9 44 8e b3 1   dev->fifo->sensor_time=1b38e
    f9 3 78 40 6 b 84 a9 3 e8    dev->fifo->sensor_time=0
    e0 4 8a 42 91 b 84 4d 4 12    dev->fifo->sensor_time=0
    0 3 69 40 8a a 44 8e f c    dev->fifo->sensor_time=c0f8e

    I assume that every fetched fifo should always provide a sensor timestamp. 

    thanks!

     

     

     

     

     

     

     

     

    4 REPLIES 4

    BSTRobin
    Community Moderator
    Community Moderator

    Hi André,

    As you enable FIFO header and sensor time, you could see the following code in extract_accel_header_mode() function, sensor time was parsed in this function, not unpack_accel_frame.

    /* Sensor time frame */
    case BMI160_FIFO_HEAD_SENSOR_TIME:
    unpack_sensortime_frame(&data_index, dev);
    break;

    André
    Established Member

    that is indeed correct, it is the unpack_sensortime_frame()

     

    However, within this  function

     

    static void unpack_sensortime_frame(uint16_t *data_index, const struct bmi160_dev *dev)
    {

    /*Partial read, then move the data index to last data*/
    if ((*data_index + BMI160_SENSOR_TIME_LENGTH) > dev->fifo->length)
    {
    /*Update the data index as complete*/
    *data_index = dev->fifo->length;
    }
    else
    {

    /* Sensor time */
    dev->fifo->sensor_time = (uint32_t)(sensor_time_byte3 | sensor_time_byte2 | sensor_time_byte1);
    *data_index = (*data_index) + BMI160_SENSOR_TIME_LENGTH;
    }
    }

     

    checks first to see if there are 3 bytes after the 0x44 header: this is not the always case as described in the original post . Sometimes the fifo ends with 0x44 followed by 3 bytes but often it ends with 0x84 followed by not exactly 6 bytes whitch is also incorrect.

    There is more than sufficient memory to read in the entire fifo twice (2KB) so there is no reason why the read fifo end with an incorrect 0x84 frame and there is no reason why it should not end with a 0x44 Sensor_time frame as configured. 

    The fifo is read straight out of the chip so in my view this seems to be an issue with the chip and not with the driver or user application.  As stated the contents of dev->fifo->data as described in my original post shows a malformed fifo contents.

     

    Thanks!

     

     

     

    André
    Established Member

    I think it has to do with the ODR and latch time: if I set latch time to NONE than the problem is gone and every fifo read provides a sensor_time. 

     

    BSTRobin
    Community Moderator
    Community Moderator

    Hi André,

    As you set FIFo watermark level 110, then it will generate watermark interrupt when FIFO length reachs 110*4=440 bytes. According you FIFO configuration "#define FIFOCONFIG BMI160_FIFO_ACCEL|BMI160_FIFO_HEADER|BMI160_FIFO_TIME", each frame of FIFO data is 7 bytes(6 bytes ACC, 1 byte header).
    When host received watermark interrupt and read FIFO data, total FIFO frames = 440/7=62.86. You should try to make the received FIFO frame an integer to avoid incomplete FIFO data.

    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