Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BMI160 correct way of reading accelerometer and gyroscope

    BMI160 correct way of reading accelerometer and gyroscope

    SaberKazemi1992
    Established Member

    Hello Bosch sensortec community

    I am using BMI160 IMU in my application. I need continuous read of accel/gyro sesnors. I have configured the sesnors' parameters like indicated in Bosch github can be found here. With 4 wire SPI interface protocol, I could read the chip_id which is 0xD1 that means the protocol works fine. 

     

    For reading the sensors' data without sensortime as mentioned earlier, I am using the function in an infinite loop, while(1).

     

    /* To read both Accel and Gyro data */
    bmi160_get_sensor_data((BMI160_ACCEL_SEL | BMI160_GYRO_SEL), &accel, &gyro, &sensor);

     The problem arose is that for when I change the sensor, either in translational or rotational direction, all registers will change. For example, if I rotate the sensor, the accel->x will change. Do you have any idea where the problem is?  

    Thanks in advance!

    Saber

    ............................................................................................................................

    For your reference, I have included the way I am getting the data:

     

    while(1)
    {
    /* To read both Accel and Gyro data */
    bmi160_get_sensor_data((BMI160_ACCEL_SEL | BMI160_GYRO_SEL), &accel, &gyro, &sensor);
    }

     

    Also, the user_SPI_read:

     

    int8_t user_spi_read(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t length)
    
    {
    int8_t rslt = BMI160_OK; /* Return 0 for Success, non-zero for failure */
    /* Communicate len number of bytes: if RX - the procedure sends 0x00 to push bytes from slave*/
    
    SPI_BMI160_BEGIN;
    reg_addr = reg_addr | 0x80; // For read operation, the reg_addr should be ORed with 0x80.
    SPI_BMI160_TX(reg_addr);
    __delay_cycles(15); //after write operation, at least 2 micro-seconds is required for the next operation.
    //SPI_BMI160_RX(rslt);
    
      for (i = 0; i < length; i++)
      {
          SPI_BMI160_TX(0);            /* Possible to combining read and write as one access type */
          SPI_BMI160_RX(*reg_data++);     /* Store pData from last pData RX */
      }
      SPI_BMI160_END;
    
        return rslt;
        }

     

    user_SPI_write:

     

    int8_t user_spi_write(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t length)
    {
            int8_t rslt = BMI160_OK; /* Return 0 for Success, non-zero for failure */
            SPI_BMI160_BEGIN;
            reg_addr = reg_addr & 0x7F;
            SPI_BMI160_TX(reg_addr); // For write operations, the register should be ANDed with 0x7F.
             __delay_cycles(15);
                 /* Communicate len number of bytes: if TX - the procedure doesn't overwrite pData */
                 for (i = 0; i < length; i++)
                 {
                   SPI_BMI160_TX(*reg_data++);
                 }
                 SPI_BMI160_END;
    
                 return rslt;
    }

     

     

     

     

    3 REPLIES 3

    shellywang
    Occasional Contributor

    Please provide  the following information :

    1. Slowly rotate around the sensor Z-axis on a horizontal plane, and stay at every 45 degree for 5s, and log the X/Y/Z-axis data of the accelerometer and gyroscope.
    2. Send us the log data so that we can analyze it. (Acc: ms2 or mg, gyroscope: dps)

    Thanks for your reply. I did something and the roblem resolved (the data for both accel/gyro are updating). In the first version, I defined the accel and gyro registers for storring the data as global variable (before main() function) and I got the problem. 

    I moved them to the while(1) loop and defined them as local variable and now, it is working fine. 

     

    Thanks

    Saber

    Can you you reproduce the behavior with the first implementation with global variables? 

    It indicates a potential problem with your program, i.e. overwriting memory accidental from other parts of the program. You should follow up on that. With your changed design now other memory areas may get overwritten uncontrolled.

    if possible set a  break or watch point on any change to the variable which is changed unexpectedly, and let the program run.

    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