I don't need humidity and the BME280 is out of stock (I am hoping to go into production next year) so I was wondering if can I simply replace the BME280 with a BMP280 ?

I used the BME280 driver downloaded from the Bosch website and its running on an STM32.

Can I still use the same BME280 driver or do I need to use the BMP280 driver ?

Is the pin out and package the same i.e. no PCB footprint changes are required ?

This is assuming the BMP280 is still available, if not when will the BME280 be back in stock ?

I think there's a mistake in the datasheet for BMV080:

Page 17 the ZIF connector pin schematic (example) is presented in a direction that is not clear and induces errors.

Connectors (like Molex and Kyocera recommended references) usually have pins 1 and 13 facing the connector opening.

The 2 BME080 views on the left indicate the opening towards the top, whereas the ZIF connector schematic indicates it towards the bottom.

That makes the connector pins numbering opposite to the "pin dscription" numbering from the datasheet (opposite direction). This can be seen in the shuttle board schematic, which has pin numbers opposite to the datasheet (1 is 13, 12 is 2... 2 is 12 and 1 is 13).

Please make this clear (eg pinout of the Molex recommended connector vs pin label).

Thank you.

Reading forums it appears that these are sensitive to washing and chemicals. I cleaned one board with IPA and an acid brush and the sensor started to read 42kPa atmospheric pressure. Nominal in my area is about 89kPa. Is this an expected result of cleaning? Did I damage the gel?

Assuming the software is correct because we have units that work fine, are these devices this sensitive to chemicals and dust? Is there a better option? Should I be considering the BMP390?

Thanks

Russ

I am Ritabrata, a student member and point of contact for Team VITAKSH at VIT Bhopal University, India.

We are developing OSAD (Open Spectral Atmosphere Dataset), a scientific payload for a high-altitude balloon mission. Our team previously completed a successful high-altitude balloon mission in March 2026, and we are now developing a more advanced scientific measurement payload.

We are using the BMI088 6-axis IMU together with the MMC5983MA 3-axis magnetometer from MEMSIC to estimate the orientation and movement of our payload.

Our application

The payload carries multispectral sensors to measure solar radiation. Since the measurements depend on the angle of incoming sunlight, we want to estimate the payload's orientation and use that information to implement an orientation-based cosine correction.

We are developing the firmware using an STM32 NUCLEO-F722ZE board.

We would appreciate guidance on the following:

1. What is the recommended approach for calibrating the BMI088 accelerometer and gyroscope for this application?

2. What filtering or sensor-fusion approach would you recommend for estimating orientation using accelerometer, gyroscope and an external magnetometer?

3. Are there any recommended methods for compensating gyroscope bias and temperature-dependent drift?

4. What should we consider regarding vibration, payload rotation and sensor mounting during balloon flight?

5. Are there recommended BMI088 drivers, reference implementations or best practices for STM32 integration?

6. Our expected operating environment may reach temperatures below -40°C. What limitations should we consider, given the BMI088 operating-temperature specification?

We are particularly interested in understanding how to obtain reliable orientation estimates during flight rather than simply reading raw accelerometer and gyroscope values.

We already have the development hardware and are working towards firmware integration and calibration. Any practical guidance, documentation or recommendations from your engineering team would be extremely valuable.

Thank you for your time.

Kind regards,

Dyumna

We are looking at new devices and ecosystems such as XREAL AURA, Snap SPECS and other upcoming smart glasses, with a strong focus on real industrial use cases: remote support, guided work, training and hands-free access to information.

And while doing this research, I came across something that made the topic even more interesting: Bosch itself is developing technology that enables the next generation of XR devices.

Bosch Sensortec’s BMI5 platform includes sensors specifically designed for XR headsets, glasses and controllers. The BMI560, for example, targets precise head tracking, frame prediction and 3D interaction, while the BMI563 also addresses high-dynamic XR tracking and robotics.

So I thought this community might actually be the perfect place to ask:

👉 Is anyone here working directly with XR / smart-glasses manufacturers or XR-related applications of Bosch Sensortec technology?

I would love to connect and exchange ideas. Maybe there is an opportunity to bring the Bosch technology inside XR devices closer to the Bosch teams actually testing and using XR in industrial environments.

Sometimes you search outside Bosch for the technology of tomorrow… and discover that part of it is already being built inside Bosch. 🙂

What is the lens used on the BMV080 shuttle board ?

Can we buy that part ?

Thank you.

Best regards.

The OSR register (0x1C) on my BMP390 and BMP388 reads 0x00 after power-on and after a soft reset. Both datasheets list the default as 0x02.

References:

• BMP390: BST-BMP390-DS002-07, Rev 1.7 (03/2021), Table 25

• BMP388: BST-BMP388-DS001-07, Rev 1.7 (11/2020), Table 24

Results:

PWR_CTRL (0x1B) reads 0x00 in both cases, which matches the datasheets.

Method:

• Raw single-register I2C reads in standard mode, with no sensor driver involved. Read buffers were filled with a known value first so a failed read could not pass as data.

• Power-on reads came before anything was written to the sensor.

• For the soft reset, I wrote OSR = 0x15, confirmed it read back, wrote 0xB6 to CMD (0x7E), and read again. STATUS showed cmd_rdy and EVENT.por_detected was set.

• To confirm each power-on capture was real, the previous run left 0x15 in OSR. A capture only counted if that value was gone and por_detected was set on the first read.

The post-reset value of 0x00 on the BMP390 was also seen on an RP2040 host, so it does not depend on the MCU or I2C implementation. This is one unit of each part.

Questions:

1. Is the 0x02 default in Table 25 and Table 24 correct, or is 0x00 the expected reset value?

2. Is there an errata or later datasheet revision that covers this?

3. Can a driver rely on OSR being 0x00 after reset, or should it treat the reset value as unspecified?

Thanks.

Could a strong magnetic field affect the data quality or stability of the BMI088 gyroscope and accelerometer? For example, could it cause changes in bias, more drift or noise, or reduced accuracy?

Do you have any test results or practical advice for using the BMI088 near strong magnets?

Thanks!