A BME280 in forced mode performs one measurement and then returns to sleep. Firmware should trigger that measurement, poll the status register until conversion completes, and only then read the result registers. A fixed delay can be too short after an oversampling change or needlessly long at lighter settings.
This is a post-detection pattern. If the device does not acknowledge on I2C, first resolve address, wiring and bus issues with the separate BME280 bus-first debugging guide.
Forced mode is a one-shot state transition
The Bosch BME280 datasheet, revision 1.23, defines mode bits 01 and 10 in register ctrl_meas at address 0xF4 as forced mode. After completing pressure, temperature and humidity measurements according to the configured oversampling, the sensor stores the results and returns to sleep. Starting another sample requires writing a forced-mode value again.
That behavior makes the command sequence explicit: configure oversampling, request one conversion, wait for completion, read, and repeat only when another sample is needed. Rewriting the mode bits continuously in a tight loop defeats the low-duty-cycle purpose and makes it harder to tell whether a result belongs to the current trigger.
Use status register 0xF3 as the completion signal
Bit 3 of register 0xF3 is measuring. Bosch specifies that the bit becomes 1 while a conversion runs and returns to 0 after the result has moved to the data registers. Bit 0, im_update, describes nonvolatile-memory data being copied into image registers; it is not the general conversion-ready flag.
write8(0xF4, ctrl_meas_with_forced_mode);
const uint32_t deadline = millis() + timeout_ms;
while (read8(0xF3) & 0x08) {
if ((int32_t)(millis() - deadline) >= 0) return SENSOR_TIMEOUT;
}
read_compensated_temperature_pressure_humidity();The timeout keeps a broken bus, brownout or logic error from trapping the main loop forever. It should exceed the worst-case measurement duration for the selected temperature, pressure and humidity oversampling, plus bus and scheduler margin. Bosch provides measurement-time calculations in Appendix B; the duration is configuration-dependent, which is why one hard-coded delay is not portable across profiles.
Write humidity oversampling before ctrl_meas
Humidity oversampling lives in ctrl_hum at 0xF2, while temperature oversampling, pressure oversampling and mode live in ctrl_meas at 0xF4. The datasheet states that a changed ctrl_hum value becomes effective only after a write to ctrl_meas. Configure 0xF2 first, then commit the combined temperature, pressure and mode selection through 0xF4.
A second ordering issue appears when changing the config register at 0xF5: Bosch warns that writes in normal mode may be ignored, while writes in sleep mode are not. A predictable reconfiguration path therefore returns or leaves the device in sleep, applies configuration, writes humidity oversampling, then writes ctrl_meas with forced mode to launch the sample.
Keep readiness separate from data validity
A cleared measuring bit says the conversion is no longer running; it does not validate the physical reading. Firmware should still reject impossible values, preserve the previous good sample when appropriate, and expose timeout or bus errors separately from environmental alarms. Compensation must use the calibration coefficients read from the device rather than treating raw pressure, temperature and humidity fields as engineering units.
For battery-operated logging, the complete cycle can remain asleep between scheduled samples: wake the host, trigger forced mode, wait with a bounded poll, read and compensate the result, then put the host back into its low-power state. The important boundary is that the sensor—not a guessed delay—declares the conversion finished.
