Bosch Sensortec Community

Physical housing / enclosure for the BME690

Saket — Wed, 09 Sep 2026 03:22:38 GMT

Hi, I am working on an application that requires that the BME690 sensors not be directly exposed to the environment. Instead, I want to house the sensors in some physical enclosure/casing. Of course, this will affect air flow and the ability of the sensor to interact with odor molecules. I was curious if anyone has designed a good solution to this general problem? Thanks.

BSEC 3.3.0.1 on RISC-V: request for a hard-float ABI build (-mabi=ilp32f) for T-Head E907 / Bouffalo BL618

lucas — Tue, 08 Sep 2026 13:03:33 GMT

Hello,

We are integrating BME690 with BSEC 3.3.0.1 (downloaded from the Bosch Sensortec portal
under the accepted license terms) into a commercial indoor air quality monitor. We only
need the IAQ feature set — `BSEC_OUTPUT_IAQ`, `BSEC_OUTPUT_CO2_EQUIVALENT`, plus the
heat-compensated temperature/humidity and raw pressure — running in LP or ULP mode, so we
are using the `IAQ` library variant rather than `Sel_IAQ`.

**Target platform**

The target MCU is a **Bouffalo Lab BL618** (32-bit RISC-V, T-Head/XuanTie E907 core) on the
**Ai-Thinker Ai-M61-32S** module. This part was selected for its Wi-Fi 6 and BLE 5.3
combination, which our product requires and which we cannot get from the Cortex-M or
Espressif parts currently covered by the BSEC release package.

**What already works in our favour**

The RISC-V library shipped in `release_bin/IAQ/bin/esp/esp32_c2c3/libalgobsec.a` looks
genuinely portable rather than Espressif-specific. Inspecting the archive we see:

- ELF32, `e_machine = 0xF3` (RISC-V)
- `.riscv.attributes` arch string: `rv32i2p0_m2p0_c2p0` (i.e. rv32imc)
- 45 undefined external symbols, and **all** of them are standard toolchain symbols:
  libgcc soft-float helpers (`__adddf3`, `__mulsf3`, `__floatsisf`, …), libm
  (`sqrtf`, `powf`, `sinf`, `expf`, `log10f`, `atanf`, `fabsf`, `fmaxf`, …) and
  `memcpy` / `memset`
- **no ESP-IDF, ESP ROM or FreeRTOS symbols at all**

rv32imc is a strict subset of the BL618's rv32imafc, so no instruction is missing. The
BSEC 3.3.0.1 release note also lists `RISCV` under "Tested MCUs" rather than naming a
specific Espressif part, which suggests the build is not intended to be vendor-locked.

**The blocker: float ABI mismatch**

`libalgobsec.a` has `e_flags = 0x1`, i.e. **soft-float ABI (ilp32)**.

Every prebuilt closed-source library in the BL618 SDK is **hard-float ABI (ilp32f)**,
`e_flags = 0x3`, with arch string
`rv32i2p0_m2p0_a2p0_f2p0_c2p0_p0p9_zpn0p9_zpsfoperand0p9_xtheade2p0`:

| SDK library | ELF objects | e_flags | float ABI |
|---|---|---|---|
| `libwifi6.a` | 208 | 0x3 | ilp32f |
| `librf.a` | 14 | 0x3 | ilp32f |
| `libbtblecontroller_bl616_*.a` | 119 | 0x3 | ilp32f |
| `libpka.a` | 3 | 0x3 | ilp32f |
| `libcsi_xt900p32f_dsp.a` | 319 | 0x3 | ilp32f |
| `libalgobsec.a` (BSEC 3.3.0.1, esp32_c2c3) | 39 | **0x1** | **ilp32 (soft)** |

The GNU linker refuses to merge the two, failing with
`can't link soft-float modules with single-float modules`. As far as we can tell this check
is unconditional in BFD's RISC-V attribute merge — there is no flag to downgrade it to a
warning.

**Why we cannot work around it on our side**

Both sides of the conflict are closed binaries:

- We cannot rebuild the Wi-Fi 6 / RF / BLE / PKA libraries as soft-float — no sources are
  published for them, and they are essential to the product.
- We will not modify `libalgobsec.a` in any way, including its ELF header, since the license
  terms do not permit altering the Software.
- Compiling *our own* code as `-mabi=ilp32` does not help, because the vendor blobs remain
  `ilp32f` and the link still fails.

So the mismatch cannot be resolved by any build-flag choice available to us.

**Request**

Could you please advise on the following:

1. Is a `libalgobsec` build with **`-march=rv32imafc -mabi=ilp32f`** (single-precision
   hard-float ABI) available, or can it be planned? From the outside this looks like the
   same RISC-V build you already produce, with one ABI flag changed.
2. Is the existing `esp32_c2c3` build officially supported on non-Espressif RISC-V targets,
   given that it carries no Espressif-specific dependencies?
3. Are there any known issues linking BSEC against code built with the T-Head XuanTie GCC
   toolchain? The SDK's arch string carries the draft P extension and `xtheade`
   (`p0p9_zpn0p9_zpsfoperand0p9_xtheade2p0`); we expect these to be additive and
   ABI-irrelevant, but we would rather hear it from you.
4. If a hard-float build is not possible, is there a **supported** way to interface the
   soft-float BSEC library with a hard-float application on the same target? We note that
   the BSEC API itself never passes or returns floating-point values by value — every entry
   point takes structures by pointer — so the API boundary looks ABI-neutral. The friction is
   only in the ~19 libm functions that BSEC calls. If a supported shim or wrapper approach
   exists, we would follow it rather than improvise.

Happy to provide the exact commands used to read the ELF flags, or to test a candidate build.

Thank you,

BHI360 and BMM350 Schematic Review

Greg_C — Thu, 03 Sep 2026 09:34:42 GMT

Hello,

I have a board featuring the BHI360 and BMM350 designed for spatialization. I believe I followed the hardware recommendations for I2C communication with the component.

I am connecting my sensor board to the Application Board 3.1 and using the Desktop Development Software 5.1.

The software does not detect my board. There is likely an error in my design, but I cannot seem to find it.

Connections from the Application Board 3.1 to my board:

GND => GND

P1-2 SCL => HSCX

P1-4 SDA => HSDX

P3-6 GPIO2/INT => HIRQ

P3-5 GPIO1 => RESET

I can see the component at I2C address 0x28, but I am unable to upload any firmware.

Does anyone have any idea where I might have gone wrong?

Thank you in advance.

Regarding the BMI270 supply voltage.

Gladson_Asir_A — Wed, 02 Sep 2026 04:04:45 GMT

Hi,

I am planning to use the Bosch BMI270 in one of my applications, and I have a question regarding the supply voltage.

According to the datasheet, the typical supply voltage is 1.8 V, while the maximum operating supply voltage is 3.6 V. The absolute maximum rating is 4 V.

I would like to operate the BMI270 directly from a 3.3 V supply.

Since 3.3 V is below the specified maximum operating voltage of 3.6 V, is it safe and recommended to operate the BMI270 with VDD = 3.3 V and VDDIO = 3.3 V?

Are there any performance, accuracy, noise, or other considerations when operating the BMI270 at 3.3 V instead of the typical 1.8 V?

Thanks.

libalgobsec.a (BSEC v3.3.0) build with -ffunction-sections -fdata-sections

BMusizza — Tue, 01 Sep 2026 21:31:53 GMT

We're integrating BSEC v3.3.0 (libalgobsec.a, Cortex_M7/fp_hard, gcc) into a flash-constrained STM32F7 firmware image and are trying to minimize the linked footprint of the library. We already build our own code with -ffunction-sections -fdata-sections and link with --gc-sections, and we only subscribe to a minimal set of BSEC virtual outputs (IAQ, CO2eq, temperature, humidity, pressure) at ULP sample rate.

We inspected the shipped archive's object files directly (arm-none-eabi-readelf -S) and found that each .o inside libalgobsec.a has a single monolithic .text section rather than being split per function, e.g.:

Bsec.o .text 5,388 bytes (1 section) GasHumidityBaselineTracker.o .text 4,596 bytes (1 section) ChannelHub.o .text 2,636 bytes (1 section) IaqEstimator.o .text 1,292 bytes (1 section) bsec_interface.o .text 208 bytes (1 section)

Because --gc-sections can only discard a section as a whole, referencing even one function from an object like Bsec.o forces the linker to pull in its entire .text, including any functions in that translation unit our integration never calls. .rodata appears to already be split into multiple per-symbol sections in the objects we checked, so this seems specific to .text (and possibly .data/.bss).

Could you provide us with a custom build of libalgobsec.a (with enabled -ffunction-sections) or ensure that future BSEC release compile libalgobsec.a with -ffunction-sections -fdata-sections?

Thanks.

Best wishes

Bojan

Cannot find conversion tool for BME690 data

Daniel — Thu, 27 Aug 2026 17:04:43 GMT

Hello,

We are trying to use the BME690 development board to be able to detect certain smells. The online guide mentions a conversion tool found in the "firmware release package" and can be found in "tools/converter/data" however im not sure where the firmware release package is located. Any help would be really appreciated.

Thank You

BNO055 Firmware Update

Sunny — Tue, 25 Aug 2026 13:56:01 GMT

I am using a BNO055 sensor on an Adafruit BNO055 breakout board and need to update the sensor firmware.

According to the BNO055 datasheet, the nBOOT_LOAD pin (pin 4) is active LOW and must be LOW during reset/power-on to enter bootloader mode. The nRESET pin is pin 11.

However, on the Adafruit breakout board, the nBOOT_LOAD signal appears to be permanently pulled HIGH to 3.3 V. Because of this, I cannot directly pull nBOOT_LOAD LOW during reset to enter bootloader mode.

I would like to know:

Is it possible to update the BNO055 firmware on the Adafruit breakout board?
What is the recommended procedure for entering bootloader mode when nBOOT_LOAD is pulled HIGH?
Which exact pins and interface are required for the firmware update?
Is firmware updating supported through I2C, or is another communication interface required?
Is there an official Bosch firmware-update tool or procedure for the BNO055?
Can the BNO055 firmware be updated from version 3.11 to version 3.14?
If a hardware modification is required on the Adafruit breakout board, what modification is recommended?

I would appreciate the official Bosch procedure and hardware connection details for safely performing the firmware update.

BME280 Dual-Use

WHOSIL — Mon, 24 Aug 2026 14:51:12 GMT

Hello,

We are using a BME280 in an electronics housing and I wanted to see if there is any declaration available for dual-use of the item. That is a declaration confirming if it has both civilian and military applications.

Look forward to the reply.

Many thanks,

Will

BME280 - detailed definition of Oversampling

Frank — Mon, 24 Aug 2026 09:10:07 GMT

I provide a arduino library for the BME280 sensor.
See https://github.com/hasenradball/Bosch_BME280_Arduino

For documentation issues and code examples I would know how oversampling is defined in detail.

I understood that no oversampling means no measurement.
But what means
oversampling_x1...x16
Thats not really clear, because in theory oversampling refers to Nyquist Theorem.

If we use oversampling greater than x1 are there done kind of meanvalue calulation?

BMM350 CRST Pin Sharing

lm2018 — Fri, 21 Aug 2026 21:32:32 GMT

I am developing with multiple tightly integrated BMM350 3-axis magnetometers in a space constrained application. To enable a tighter sensor array, I'd like to explore whether it is reasonable to share a CRST capacitor bank between multiple sensors.

In other words, I would like to use one 2.2uF capacitor bank (consisting of many smaller value capacitors and a plane to keep ESL and ESR down) for multiple sensors. The idea here is that we would make sure that the BMM350_INIT function, which to my knowledge triggers the reset function on the chip, was run one at a time for sensors that share a common CRST bank to avoid having multiple chips charging / discharging the bank at the same time.