Bosch Sensortec Community

BME690 humidity compensation: datasheet vs. SensorAPI formula

mr-dannyk — Fri, 23 Oct 2026 17:43:25 GMT

Hello Bosch Sensortec team,

We noticed a difference between the humidity compensation formula in the BME690 datasheet (revision 1.4, page 26) and the floating-point calc_humidity() implementation in SensorAPI v1.1.0.

Expanding the datasheet formula appears to produce an additional tk2sh * temp_comp term that is absent from the driver.

We documented the equations and source reference in GitHub issue #8. Could you confirm which formula we should use?

Thank you.

BMI270 gyroscope zero-rate offset steps versus temperature

rtlongdon — Fri, 23 Oct 2026 04:55:16 GMT

Hello,

We are using a BMI270 for attitude and heading-hold work where the gyro is integrated for tens of minutes, and we see a deterministic staircase in the gyro zero-rate offset as the die temperature changes. We would like to understand what the part is doing, and whether it is documented or controllable.

Setup. BMI270 on a SparkFun breakout for eval, SPI, Bosch BMI270 Sensor API (config blob loaded normally). Gyro 800 Hz ODR, +-500 dps, normal filter mode, performance mode on, noise performance optimised, advanced power save off. Board still on a bench, X axis vertical (the offset behaviour does not depend on orientation within about 0.01 dps/g on Z only). In-use offset compensation (IOC) is off: GYR_OFF_X/Y/Z read 0 and OFFSET_6.gyr_off_en = 0 (OFFSET_6 = 0x80, gain compensation bit set) throughout. Die temperature from the TEMPERATURE register, resolution 1/512 K. Heating was a lamp (0.2 to 0.5 K/min) and natural cooling.

Observation. Stationary gyro zero (1 s to 30 s means) is flat or slides smoothly with temperature, then jumps by a nearly constant amount at fixed die temperatures. Steps repeat on cooling at the same temperature (within 0.01 to 0.09 K), repeated on a second warm-up, and are reversible to about 0.003 dps:

|---|---|---|---|

| X | 25.775, 28.46, 34.25, 38.15 | up | +0.05 to +0.065 |

| Y | 25.45, 31.43, 37.4 | down | -0.055 to -0.06 |

| Z | none from 24.8 to 39.5 C | | |

Between steps the zero slides smoothly (X about -0.01 to -0.02 dps/K, Y about +0.01 to +0.02 dps/K). The step size (about 0.059 dps) is within 5 % of one LSB of the GYR_OFF registers (0.061 dps). Each step takes about 100 s when the die moves at 0.04 K/min, 10 to 15 s at 0.3 K/min and about 10 s at 3 K/min. Raw gyro noise (0.10 to 0.11 dps per sample at 800 Hz), the accelerometer and the other axes do not change at a step. A 40 minute heading hold is therefore wrong by several degrees whenever the die crosses one of these temperatures.

Questions.

1. Is this the documented behavior of the internal gyro offset temperature compensation? Is the correction quantized to the offset DAC LSB (0.061 dps), and how is the temperature input to it filtered or updated (which would explain the rate-dependent transition width)?

2. Are the temperature thresholds and step table per device (OTP-trimmed) or common to all BMI270s? Can they be read out?

3. Can the compensation be disabled, bypassed or supplemented (e.g., through a register, the config file, or the NVM), so that we can apply our own compensation? Why do the GYR_OFF registers stay at 0 while this happens?

4. How should this behavior be counted in the datasheet specification (zero-rate offset +-0.5 dps, TCO)? Does the datasheet TCO include these steps?

5. Is there a BMI270 configuration or a different part (BMI323, BMI085/BMI088, BMI160) that avoids these steps for long gyro integration? Is there an application note on temperature calibration for heading-hold use?

Thank you.

BMV080 failing bmv080_serve_interrupt when obstructed

Victor — Tue, 20 Oct 2026 15:46:34 GMT

Hello,

We're using BMV080 with this measurement loop, called once per minute:

start continuous measurements

wait 4 seconds

serve interrupt

stop measurement

Measurement algorithm is set to fast response.

We're using I²C communication with a TI CC26x2 host MCU.

It works correctly and we get measurements as wanted.

When a sheet of paper is put in front of the sensor (~10 cm), we can see the "obstruction" status bit as expected.

When approaching the sheet of paper to around 2 cm in front of the sensor, the bmv080_serve_interrupt function fails (returns E_BMV080_ERROR_HW_READ).

What could cause this behavior ?

Thank you

BME690 + application board 3.1 - how to make it work

Ania — Sun, 18 Oct 2026 21:48:05 GMT

Hi,

I am looking for a clear, step-by-step guide on how to properly set up and use the Application Board 3.1 together with the Shuttle Board 8x 690, as I have been searching everywhere and cannot find an easy-to-understand tutorial for this setup.

I am trying to make it work, but i have run itno some problems. I run into an issue where the LED on the board is flashing red with a hint of green and I am not sure what that indicates.

While flashing the boards using the instructions and firmware from the bme690_development_kit_software_v3-1-3 package makes everything work (for a little bit), trying to convert data files following Bosch website instructions causes a problem where the files convert partialy. When i click run_me in the release_bin/tools/converter/data it does something, but i don't think it work. Files .labelinfo and .udf convert only into file .bmelabelinfo, which BME AI-Studio doesn't even recoginize and i am unable to import data into BME AI-Studio.

Could someone please point me toward a reliable guide or explain what I might be doing wrong during this conversion process?

BMV080 measurement every minute

Victor — Fri, 16 Oct 2026 16:02:04 GMT

Hello,

We want to take a BMV080 measurement every minute.

What would be the better way to do it ?

Start continuous measurement, wait for only 1 (using interrupt line or waiting a certain timing ?) and stop measurement ?

Or other solution ?

We would like to optimize the system for reliability and energy consumption.

Thank you

Best regards.

BSEC binary compatibility with ESP32-C5

Jenny — Fri, 16 Oct 2026 07:40:47 GMT

Hello,

I am developing an embedded application using the BME690 sensor with an ESP32-C5 and ESP-IDF v6.0.2.

I would like to use BSEC for IAQ calculation and VOC/odor classification.

The BSEC v3.3.0.1 Supported Platforms document lists ESP32-C2/C3 for riscv32-esp-elf-gcc, but does not explicitly list ESP32-C5.

Could you please confirm:

Is there a BSEC binary compatible with ESP32-C5 and ESP-IDF v6.0.2?

If not, is an ESP32-C5-compatible binary or source-code build available?

Which BSEC version and BME AI-Studio version should be used for BME690 IAQ and gas classification?

Thank you.

BME690 Parallel Mode displays no new data during second step.

Bgin — Thu, 15 Oct 2026 11:43:59 GMT

static int32_t run_step(uint8_t mode, bme690_sample_t *out)
{
	char str[35];
	int err;
    memset(out, 0, 10 * sizeof(*out));
    out->sensor_id  = s_sensor_id;
//    out->step_index = step;
    s_heatr.enable = BME69X_ENABLE;
    s_heatr.profile_len = s_profile.num_steps;
    s_heatr.heatr_temp = s_profile.temperature[0];
    s_heatr.heatr_dur  = s_profile.duration_ms[0];
    s_heatr.heatr_temp_prof = s_profile.temperature;
    s_heatr.heatr_dur_prof = s_profile.duration_ms;
    struct bme69x_conf conf;


    if ((err = bme69x_get_conf(&conf, &s_dev)) != BME69X_OK){
    	snprintf(str, sizeof(str) - 1, "BME conf Err: %d", err);
    	ui_terminal_write(str, ST7789_COLOR_RED);
    	return -1;
    }
    s_heatr.shared_heatr_dur = (uint16_t)(140 - (bme69x_get_meas_dur(mode, &conf, &s_dev) / 1000));

    if ((err = bme69x_set_heatr_conf(mode, &s_heatr, &s_dev)) != BME69X_OK) {
    	snprintf(str, sizeof(str) - 1, "Htr conf Err: %d", err);
    	ui_terminal_write(str, ST7789_COLOR_RED);
        out->err = 1; return -1;
    }

    uint8_t regs[11];
    int len = 0;

    for (uint8_t i = 0; i < 10; i++) {
        regs[i] = 0;
        if(bme69x_get_regs(0x64 + i, ®s[i], 1, &s_dev) != BME69X_OK){
        	snprintf(str, sizeof(str), "%02X error", regs[i]);
        	ui_terminal_write(str, ST7789_COLOR_RED);
        }
    }

    regs[10] = 0;
    bme69x_get_regs(0x71, ®s[10], 1, &s_dev);

    for (uint8_t i = 0; i < 10; i++) {
        snprintf(str, sizeof(str),
                        "%02X: %02u", 0x64 + i, (unsigned int) regs[i]);

        ui_terminal_write(str, ST7789_COLOR_LIGHTGREEN);
    }

    snprintf(str, sizeof(str) - len,
             "71: %02X", regs[10]);
    ui_terminal_write(str, ST7789_COLOR_LIGHTGREEN);

    struct bme69x_data d[10];
    uint8_t n_fields = 0;

    if(mode == BME69X_FORCED_MODE){
	    if ((err = bme69x_set_op_mode(mode, &s_dev)) != BME69X_OK) {
	    	snprintf(str, sizeof(str) - 1, "Op Mode Err: %d", err);
	    	ui_terminal_write(str, ST7789_COLOR_RED);
	        out->err = 2; return -2;
	    }

    	err = bme69x_get_data(mode, d, &n_fields, &s_dev);
    	if (err != BME69X_OK) {
    		snprintf(str, sizeof(str) - 1, "Get Data Error: %d", err);
    		ui_terminal_write(str, ST7789_COLOR_RED);
    		out->err = 3;
    		return -3;
    	}
    	if (n_fields == 0)     {
    		ui_terminal_write("Error: n fields is zero", ST7789_COLOR_RED);
    		out->err = 4;
    		return -4;
    	}

    	out->tick_ms        = app_get_millis();
    	out->temperature    = d[0].temperature;
    	out->pressure       = d[0].pressure;
    	out->humidity       = d[0].humidity;
    	out->gas_resistance = d[0].gas_resistance;

        /* heat_stab_r: check the dedicated status register if you want this bit.
         * bme69x_data.status is the driver's own validity flag, not a raw
         * register value — do not mask it with register-bit constants. */
        out->heat_stab = 0;

        out->err = 0;

    }
    else if(mode == BME69X_PARALLEL_MODE){
	    if ((err = bme69x_set_op_mode(mode, &s_dev)) != BME69X_OK) {
	    	snprintf(str, sizeof(str) - 1, "Op Mode Err: %d", err);
	    	ui_terminal_write(str, ST7789_COLOR_RED);
	        out->err = 2; return -2;
	    }

	    uint32_t start_ms = app_get_millis();

	    uint8_t op_mode = 0;

	    err = bme69x_get_op_mode(&op_mode, &s_dev);

	    bool step_collected[10] = { false };
    	uint8_t collected = 0;
    	uint8_t succ_fields = 0;
    	while (collected < s_profile.num_steps){
    		uint32_t dur_us = 3 * (bme69x_get_meas_dur(BME69X_PARALLEL_MODE, &conf, &s_dev) + ((uint32_t)s_heatr.shared_heatr_dur * 1000));
    		uint8_t count = 0;
    		do{
    			s_dev.delay_us(dur_us, NULL);

    			err = bme69x_get_data(mode, d, &n_fields, &s_dev);

    			count++;

    		} while (err == BME69X_W_NO_NEW_DATA && count < 3);

    	    snprintf(str, sizeof(str),
    	             "t:%lu err:%d n:%u c:%u",
    	             (unsigned long)(app_get_millis() - start_ms),
    	             err, n_fields, collected);

    	    ui_terminal_write(str,
    	        err == BME69X_OK ? ST7789_COLOR_LIGHTGREEN
    	                         : ST7789_COLOR_RED);

    		if (err != BME69X_OK) {
        		snprintf(str, sizeof(str) - 1, "Get Data Error: %d", err);
        		ui_terminal_write(str, ST7789_COLOR_RED);
        		snprintf(str, sizeof(str) - 1, "Successful reads: %d", succ_fields);
        		ui_terminal_write(str, ST7789_COLOR_YELLOW);

    		    out->err = 3;
    		    return -5;
    		}
    		succ_fields += n_fields;

        	for (uint8_t j = 0; j < n_fields; j++) {
        		if((d[j].status & BME69X_NEW_DATA_MSK) && (d[j].status & BME69X_GASM_VALID_MSK)){
        			uint8_t idx = d[j].gas_index;
        			if (idx >= s_profile.num_steps) continue;

        			out[idx].tick_ms        = app_get_millis();
        			out[idx].rtc 			= app_get_unix_time();
        			out[idx].sensor_id      = s_sensor_id;
        			out[idx].temperature    = d[j].temperature;
        			out[idx].pressure       = d[j].pressure;
        			out[idx].humidity       = d[j].humidity;
        			out[idx].gas_resistance = d[j].gas_resistance;
        			if (!step_collected[idx])
        			{
        			    step_collected[idx] = true;
        			    collected++;
        			}
        		}
    		}

    		if (n_fields == 0) {
        		ui_terminal_write("Error: n fields is zero", ST7789_COLOR_RED);
    		    out->err = 4;
    		    return -6;
    		}
    	}
    }
    return 0;
}

The above code is a function that is supposed to manage the data collection mode from a given heater profile. The run step waits for approximately the time for the 3 field registers to fill, and then retrieves the data, and filters for the ones with valid gas measurements. The issue is that the BME690 stops recording new data during the second step, as shown from the LCD terminal:

64: 02
65: 41
66: 02
67: 14
68: 14
69: 14
6A: 02
6B: 14
6C: 14
6D: 14
71: 2A
t:430 err:0 n:3 c:0
t:860 err:0 n:3 c:1
t:1290 err:0 n:3 c:1
t:1719 err:0 n:3 c:1
t:3004 err:0 n:3 c:1
Get Data Error: 2
Successful reads: 12

The heater profile used to test used is based on HP-301 from the AI studio as such:

    p1 = build_profile(1, now,
                       steps=[(100, 280/140), (100, (6020-280)/140), (200, (6300-6020)/140),
                                (200, (8260-6300)/140), (200, (10220-8260)/140),
                                (200, (12180-10220)/140), (320, (12460-12180)/140),
                                (320, (14420-12460)/140), (320, (16380-14420)/140),
                                (320, (18340-16380)/140)],
                       shared_heater=140, duty_scan=1, duty_sleep=4)

But that is likely irrelevant, as the register values reflect that the proper times are included.

BHI360 PCB Layout Example

jrlitzenberger — Wed, 14 Oct 2026 22:27:25 GMT

I want to replace the TDK ICM-20948 because of EOL. I am currently in layout and am having trouble making the right decision for getting out the signals of the center pads of the BHI360. I have two options.

Via-in-Pad. I would need to increase the internal pads to fit the capabilities of my PCB manufacturer to allow a via in pad 6 mil drill, 12 mil annular ring.
3mil trace/3mil spacing.
I purchased the BHI360 Shuttle Board for evaluation purposes but can't interface to it without spinning a carrier board due to the non standard pitch of the header pins. I decided to just build a board with the actual parts on the board and evaluate it that way.
I am interested in the PCB layout files of the Shuttle Board to assist me in my design decisions and/or any guidance from Bosch.

Thank you for your time.

Fast Mode Plus at 1 MHz support

JustinM — Wed, 14 Oct 2026 14:32:20 GMT

Could you confirm which I²C modes the BME680 supports—particularly whether it supports Fast-mode Plus at 1 MHz, or whether operation above 400 kHz requires the High-speed mode entry sequence? The datasheet lists Standard, Fast, and High-speed modes but does not explicitly mention Fast-mode Plus. We’re seeing questionable ACK signal quality at 1 MHz and want to confirm the supported mode and required setup before troubleshooting further.

Inquiry on Long-Term Availability and EOL Status of Bosch Sensors

Dinesh — Wed, 14 Oct 2026 09:58:22 GMT

Hello Bosch Community,

We are evaluating the following sensors for our drone flight controller:

BMI088
BMI270
BMP390

Could you please confirm their current lifecycle status, expected market availability, and long-term supply commitment?

We want to ensure these components remain available for production for several years and avoid obsolescence that could require PCB redesign. Please also clarify the advance notice period in case of planned discontinuation.