Detect RC failsafe while sending RC override messages?

I’m using pymavlink to send RC override messages with a companion computer. I noticed that while sending RC override messages, the RC failsafe action will not occur if the transmitter link is lost. This is somewhat expected, but I need a way to determine that the RC link was lost… I’ve been digging through the code and not having luck finding a way to detect a lost RC link while sending RC override messages.

I thought the answer would be in the SYS_STATUS message. The onboard_control_sensors_health field of that message has a bit for the RC receiver status… 0 for error and 1 for healthy.

If not sending RC overrides, SYS_STATUS correctly reports an unhealthy RC receiver if the RC link is lost. If sending RC overrides on the other hand, it always reports a healthy RC receiver, even if the link is lost…kind of counterintuitive.

I’ve been trying this on Copter-4.1.5, both SITL and live hardware.

have you set rc-options parameter to 10 to enable multiple receiver support?

Thanks for the suggestion… I just tried that in SITL on the dev branch and it doesn’t seem to make a difference. Just to be clear, I’m not working with multiple receivers. Just one receiver, plus a companion computer sending RC overrides

have you got RSSI setup? that should show when the receiver is connected.

I do… but the last time I checked, the RSSI value seems to hold the last received value after the signal is lost. For example, if you have an RSSI of 10 and then the link is lost, the RSSI stays at 10 although it should probably go to zero.

I think you can set it to protocol and with sbus it should work as % of frames received so it should drop to zero when you loose signal.

hmm ok, wasn’t aware of that. I’ll look into that and report back… thanks again

I’m using SBUS on an FrSky receiver… currently have RSSI set up as a PWM channel. Looks like I’d have to switch the receiver protocol to FPort in order to use ReceiverProtocol for RSSI… don’t really want to mess with changing that at the moment… still looking for other solutions.

RSSI type 4 should also go to zero on signal loss.

apparently the Sbus loss counter method was never implemented .

I’m using RSSI type 2, with PWM embedded in a collective SBUS signal.
It seems to be a known issue, as the RSSI docs page has a note about it…
“Certain sBus protocol variances may lead to channel values not being updated during receiver failsafe conditions. In this case, you will see the last valid RSSI value displayed during a failsafe.”