"DISARMED by safety switch" in flight

Hi, back on the PX4 track after quite some time…

PX4FMU_V1 + PX4IO
Firmware 1.5.5
DJI F330 frame

Works quite well, but occasionally it’ll fall out of the sky after disarming itself with a “DISARMED by safety switch” message:

1971_03_21_02_43_34: ARMED by RC
1971_03_21_02_43_34: [blackbox] /fs/microsd/log/sess010
1971_03_21_02_43_35: [blackbox] recording: log001.px4log
1971_03_21_02_43_41: Takeoff detected
1971_03_21_02_44_10: DISARMED by safety switch
1971_03_21_02_44_11: [blackbox] stopped (777 drops)
1971_03_21_02_44_12: Landing detected

Here’s the log of this short indoor flight: http://logs.uaventure.com/view/A4RcA8AWkrLx2fzHPVtzLD

(BATT.V looks funny I admit)

Alas, QGC won’t let me replay the .mavlink file (attached to issue https://github.com/mavlink/qgroundcontrol/issues/4464).

Kind regards
Hannes.

Ok, found a bug causing the battery voltage to jitter between 0 (in .px4log) or uint16_max (in MAVlink messages) and the correct voltage, as can be seen in the linked log.

BAT_SOURCE defaults to 0 (“Power Module”) even when PX4IO is present.

This causes both ADC channel 10 on the PX4FMU_V1 (which is open input and catches all kinds of static, mainly from telemetry RF) and ADC channel 4 on the PX4IO (which does yield the correct voltage) competing for the battery_status ORB topic.

sensors.cpp - Sensors::adc_poll()
px4io.cpp - PX4IO::io_handle_battery()

A counter intuitive and more or less dirty workaround is to set BAT_SOURCE to 1 (“External”), but the sensors driver better should disable readout (or publishing) ADC channel 10 in case PX4IO is present, I think.