Unintentional parachute release, due to Sbus glitch:

I have suffered two unintentional parachute release, the cause of these deploys is a high pulse (greater than 1800) on channel 7, which is assigned the function of “parachute release”.
These pulses have a very short duration. In the dataflash logs, which sample RCIN values at 10Hz, these errors are represented by a single sample I’m guessing they can be “glitches” in a single package of the Sbus frame.

Months ago, I experienced problems with FailSafes and Sbus frames. If the receiver FailSafe was set to “no pulse” it could happen that some channels “returned” from the failsafe before others causing low pulses of short duration that could change the flight mode, disarm the equipment etc. Same problems as #9389 #9400 #10139 which were fixed with #10216. At that moment I fixed it by configuring the failsafe of the receivers in hold mode.

The problem I’m experiencing now is somewhat similar. I have periodic glitches in which one of the 8 channels changes to a low value during a very short period, but this low value is not necessarily less than 900. But also, although it is a stranger event, I have had glitches in which one of the 8 channels changes to a high value, not necessarily higher than 2200. If this happens on channel 7 with a pulse greater than 1800, the parachute fires immediately.

These glitches are not very frequent, I may have many flights in which none are observed. This makes it very difficult to do a bench tests to determine the exact cause of the problem. it may be wireless corrupted packets, a problem in de RX generating the Sbus frame or a bad handling of the Sbus frame and failsafes by the autopilot.

In addition, I have tried different combinations of Frsky radios and receivers (X9D plus, QX7) (XM+, X8R) and I experience the same problem with everyone.

On the other hand, most of the radio protocols used in the sector are not reliable enough and do not include functionalities such as ECC or EDC, so I think that critical flight and safety functions such as “Parachute Release”, “Disarm” or “Emergency Stop Motors” should have some extra security layer for their activation. A combination of different channels, a minimum pulse duration (Ex: 1s) for activation or both.

Attached some photos of the RCIN graphics of the dataflash logs.

Two glitches that fired the parachute:

Other observed glitches:

Yes, that’s a known situation. Because of this, the HOLD FS mode is the only right option for SBUS connection.

just for that reason some time ago I did a PR that introduced a debounce time parameter (per channel). So for example you can set the debounce time for your parachute channel to let’s say 500 or 1000 ms. And any spikes that are shorter will be ignored.

1 Like

That’s very interesting and can be an elegant solution to this problem. I have been looking at this PR you did. Has it been implemented in any stable version? Is the debouncing parameter configurable or is it a fixed value of 200ms for all channels?

In Copter 4 it is a fixed 200ms for all channels.
But it is easy to move that to the parameters (and compile FW binary then)

Why was the fixed value of 200ms chosen? I suppose that can be enough since these “glitches” are of a very short duration, but for something so critical I would feel safer with a larger margin.

200ms looks like reasonable value to be fast enough for any function and to protect against a bounce.