Boot the SPRACING F3 with connected external BMP280. Running 1.7.2 official.
Altitude is reported correctly.
Disconnect it from the board.
i2c errors count increases, baro still marked as healthy by configurator and still used by iNAV.
As you're an mwp aficionado, would you humour me and see if mwp reports sensor failure. It does for me under similar circumstances.
Sensor reported as healthy, but it is being unplugged at runtime.
I can at least confirm that MWP works fine for GPS, since it was unplugged and the alarm went off!


then we will work on that MWP layout too @stronnag 馃拑
Good catch, thanks for finging this bug.
Very glad!
Let me know if you need further infos.
I've lost the control of wing wing z84 due to an unresponsive BMP280.
I'll post the blackbox log as soon I can find it.
But it is mostly this bug that has stricken rendering the looptime very unstable and gyro readings very messy.
@giacomo892 once some sensor mess up the I2C bus in flight - machine is almost always destined to crash - there is no protection from that.
@digitalentity isn't hardware health subsystem supposed to "isolate" the faulty sensor avoiding to poll it causing random delays and hickups in the main loop?
Unluckly I do not have the log.. since the BB was full.
And could have passtough saved the machine in this case? Thottle and servo are directly redirected or FC with a faulty sensor is still too laggy even to provide passtrough?
Sensor failure is designed to prevent user from taking off with failed sensor. Handling in-flight failure is another feature that's not implemented yet.
Even in case sensor failure is detected sensor is being polled periodically, but timeout for sensor reads makes any flight control next to impossible (including passthrough mode).
Oh. We should really fix this since we have detection :)
Ok, looks like it's going to be a massive change - we don't have baro sensor reporting read failures at all. Will require quite a bit of changes to baro driver code.
@digitalentity :) if the change is massive we should even find a method that allow to stop polling the device if reported as faulted.
Since I'm going to plan an overhaul of driver code for 1.9 it would be logical to deal with this issue then