Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMX160 fifo sensor_time not always provided

    Established Member

    BMX160 fifo sensor_time not always provided

    I use the following settings:

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


    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;

    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. 










    2 REPLIES 2
    Community Moderator

    Re: BMX160 fifo sensor_time not always provided

    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 */
    unpack_sensortime_frame(&data_index, dev);

    Established Member

    Re: BMX160 fifo sensor_time not always provided

    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;

    /* 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.