Running Copter 4.3.7 (with a custom motor mixer so I can’t easily upgrade right now).
With an X8R FRSKY receiver configured in “no pulses” failsafe mode, and with a saleae logic analyzer hooked up to the sbus lines going into the cube, I can see proper RC commands make it on the wire and read by the cube. When I turn the transmitter off, I see 0’s go out on the wire and the failsafe bit set, but the cube sees the last input RC channel. Is this some kind of known bug for 4.3.7? FS_THR_VALUE is set lower than the lowest possible input throttle value via stick, but the flight controller sees the last real throttle value instead of what is on the sbus wires. It seems to ignore the FS bit as well (or else is still seeing the last FS bit). When the Receiver is ultimately unplugged from the cube, the cube seems to detect it’s loss and trigger the failsafe.
I have used the receiver manual to reset it’s failsafe mode to “no pulses”, but it doesn’t matter what I do, it seems that when the receiver goes into failsafe mode, the readings are no longer respected by the cube.
I have also started a Discord chat for this issue here
Thanks, not sure why I didn’t think to post the log before. In spite of RC_OPTIONS set to include logging, there are no RCDA messages present in the log.
When plotting, you’ll see input on channel 3, then a flatline, this was when we shut the transmitter off. We turned it back on, changed the throttle again, and turned it off for a second time.
Let me know if more or different logging is necessary. Thank you for your help
When we disable the scripting interface, the problem goes away. I’m not sure if it is a specific script or if it’s a consequence of running the whole scripting engine.
The culprit is a lua script designed to toggle a relay. Below is the original script
-- example of overriding RC inputs
local RC14 = rc:get_channel(14)
function update()
RC14:set_override(1900)
return update, 10
end
return update()
When I add a delay, the RC Failsafe from the SBUS is respected. Whenever this command triggers, the RC Failsafe is ignored. This behavior is present in 4.5.7
Still, without this script, when the receiver is in failsafe mode, the rc channel values seem to be ignored, and I’m not sure what to do about that
I tried several things before I arrived at this approach. Ideally, that would be what I would do, but it wasn’t clear to me how to get that to work…
Edit:
Also, what is the expected behavior when there’s 0’s for the channel readings and the FS bit is set on SBUS? Should the RC channels be recorded as 0’s (or the appropriate pwm signal), or are all channel readings invalidated?
This is a simple script I use to turn on and off a video transmitter that would overheat if left on.
There might be something there you can use.
--[[
Script to toggle relay pin
from arming status
so the VTX can be automatically
powered on and off
Set
SERVOx_FUNCTION,-1
RELAY1_FUNCTION,1
RELAY1_PIN,55 (to match the chosen Servo channel)
--]]
-- set a bad value so the armed test is gaurnteed to be run
local last_armed = 3;
-- check for a relay
if relay:enabled(0) then
gcs:send_text(5, "VTX power under scripted control")
else
gcs:send_text(5, "VTX power incorrect config")
return
end
function update () -- periodic function that will be called
local armed = arming:is_armed()
-- only make changes if the armed status has changed
if armed ~= last_armed then
if armed then
relay:on(0)
gcs:send_text(5, "VTX power on")
else
relay:off(0)
gcs:send_text(5, "VTX power off")
end
last_armed = armed
end
return update, 1000 -- request updates every 1000 milliseconds (1 second) after script is loaded
end
return update, 1000
Use your script to get the RC channel PWM, then set the Relay accordingly.
In parameters don’t set the relay to operate directly from an RC channel, but the LUA script instead - therefore no override required.
Unsure - all I can suspect is that overridding the RC channel input was also overriding the RC lost status. The RC failsafe bit in SBUS should override everything else in theory.
I’ll see what goes on in the code and let you know - but I believe the correct way to proceed is to operate the relay solely via the LUA script.
You can even put something in the script to ensure desired relay action during RC failsafe.