Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMP388 first byte always zero


    Re: BMP388 first byte always zero

    By definition, the SPI communication is always bi-directional, but in the Bosch SPI protocol, there is always only one valid byte.


    Could it simply be that your MCU code needs to throw away 2 bytes ? (one read while transferring the register address, then a second one for the dummy byte)


    In any case, are you able to provide a screenshot of a logic analyzer to make sure that your are decoding the bus transactions properly?

    New Poster

    Re: BMP388 first byte always zero

    It appears that this is a factor of the ODR and OSR. 3.4.1 in the data sheet mentions this, and is sort of what I thought would be the culprit. Oversampling controls the resolution and the low order bits are set to zero unless OSR is 32x. Having all 8 bits zeroed threw me off. Incidentally, the example code on github turns off oversampling. It would be helpful to add some examples of higher resolution settings.

    I still dont have a good feel for the optimal setting (i.e. what setting yeilds the fastest sample rate as well as highest resolution?)

    The API kicks out invalid combinations, but I'm still a bit lost for the proper settings. Do you have some cookie-cutter setting combinations?

    Established Member

    Re: BMP388 first byte always zero

    I can confirm successful operation of BMP3-Sensor-API v1.1.0, 05 Apr 2018 using SPI.  The following SPI transactions were obtained by calling bmp3_get_sensor_data(BMP3_PRESS | BMP3_TEMP, ...).

    TX: 84 00 72 6B 75 20 EE 92
    RX: 00 00 66 6B 75 58 EE 92
    TX: 84 00 66 6B 75 58 EE 92
    RX: 00 00 6C 6B 75 C2 ED 92
    TX: 84 00 6C 6B 75 C2 ED 92
    RX: 00 00 61 6B 75 91 ED 92
    TX: 84 00 61 6B 75 91 ED 92
    RX: 00 00 39 6B 75 AD ED 92

    The first byte is zero because this is the byte received during the transmission of the control byte (0x84).  The second byte is zero because this is the "dummy byte" as described on page 42 of datasheet v1.1.

    @Spanky wrote:

    Do you have some cookie-cutter setting combinations?

    Page 16 of datasheet v1.1 describes the recommended settings for six use cases.  I use the following initialisation code to implement the "drone" use case. This achieves an ODR of 50 Hz. Lower ODRs can result in a large phase lag that I judge not to be worth the reduction in noise.

        // Configure device structure
        bmp3.intf = BMP3_SPI_INTF; = Bmp3Read;
        bmp3.write = Bmp3Write;
        bmp3.delay_ms = Bmp3Delay;
        // Initialise device
        // Perform soft reset
        // Configure settings for drone use case as per datasheet
        bmp3.settings.press_en = BMP3_ENABLE;
        bmp3.settings.temp_en = BMP3_ENABLE;
        bmp3.settings.odr_filter.press_os = BMP3_OVERSAMPLING_8X;
        bmp3.settings.odr_filter.temp_os = BMP3_NO_OVERSAMPLING;
        bmp3.settings.odr_filter.iir_filter = BMP3_IIR_FILTER_COEFF_3;
        bmp3.settings.odr_filter.odr = BMP3_ODR_50_HZ;
        bmp3_set_sensor_settings(BMP3_PRESS_EN_SEL | BMP3_TEMP_EN_SEL | BMP3_PRESS_OS_SEL | BMP3_TEMP_OS_SEL | BMP3_IIR_FILTER_SEL | BMP3_ODR_SEL, &bmp3);
        // Set the power mode to normal mode
        bmp3.settings.op_mode = BMP3_NORMAL_MODE;