@Rob_Lefebvre I put a X8R receiver on the scope this morning to see what has transpired since we did the special builds for 3.3.3 that had a fix in it, and then subsequently got dropped. What I’m seeing is that the SBus protocol is kinds of like a voltage inverted RS232. It sends two packets alternately with 8 channels per packet. Actual data update rate appears to be 18ms (9ms per packet).
There is also a failsafe bit and a frame lost bit (flags byte) that goes inverted (1 to 0) about one second after the Tx is switched off. It appears that ArduPilot holds last received value on the aux channels when this flags byte is set for the SBus failsafe. How it exits from that when the flags byte is unset remains unclear to me. On the scope I can definitely get a corrupted frame on channels 1-8 if the receiver is set for programmed values instead of no pulses. Then get a “clean” frame on channels 9-16. But the next frame is “clean” also. And it’s 18ms from the “dirty” frame to the clean one.
So I got several different receivers, some of these I updated with the latest firmware thru the serial port in the Tx, some haven’t been updated. I didn’t keep track of which ones I had updated. But I got a XSR that I found in a box of stuff that I know has not been updated. I tried that XSR and amazingly that receiver will fail to set itself to “no pulses” following the procedure unless you turn on the Tx after setting the failsafe option in it. The other X-series ones I got (X8R and RX8R) it don’t seem to matter. I don’t have a X4R to test.
I cannot get it to send a “dirty” frame if the receiver is set to no pulses. But there also is no way to know if the receiver has actually accepted the “no pulses” failsafe option other than to follow the procedure and hope for the best. And as noted above I can defeat that with the XSR.
So it seems kind of amazing to me that ArduPilot can react in an undesired fashion with one “dirty” frame in a SBus failsafe when that flags byte is switched off. But evidently it can. Or maybe in some cases it takes more than one bad frame after it exits to cause it to react to it. I can’t see how ArduPilot is converting the serial protocol to PWM values on the scope. But there may be a bug in FrSky’s receiver firmware in unsetting that flags byte before it puts out “clean” frames for channels 1-8. This problem may exist with other radios too. Futaba originally invented this protocol and everybody else copied it, and the copies may be less than perfect, or Futaba’s original implementation may have a flaw. So I think this pull that @rmackay9 pushed into 3.6 will fix it:
I think I would still recommend setting the receiver failsafe as recommended in the manuals for the receivers, though. But based on what I found with the XSR, I think I would add the step to turn on Tx after the F/S button is pushed, otherwise it doesn’t appear to save to the Rx in some cases. I think the radio manufacturers designed these things to shut the model down and crash it in the event of failsafe, and they never considered that they may be used on more advanced flight controllers that can take over in the event the SBus flags byte is set, then unset, and continue to fly the model. And on the fringe of RC reception this could potentially happen several times in quick succession, and get corrupted frames anyway.