Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore RC channel values sent by receiver in failsafe #3482

Merged
merged 1 commit into from
Jul 16, 2018

Conversation

digitalentity
Copy link
Member

A few releases ago we had a piece of code processing RX data and only populating rcData if receiver was sending trusted values (not failsafe, within limits).

Roughly after we removed this piece of code we started getting reports about spontaneous disarms in near-failsafe conditions. Most likely suspect - RC filtering (default enabled by co-incidental mistake).

What probably happened - RC receiver was set to send a "disarmed" value in "ARM" channel when in link loss state. By itself this is harmless, but combined with RC filtering that introduced delay to channel values we might have hit a race condition between signal recovery and channel values getting back to normal state. This explains why we see normal "switch disarm" in logs - from firmware's point of view this IS a valid switch disarm followed by attempt to re-arm (failing due to non-zero throttle).

This PR re-introduces the check for valid channel values and valid link before populating rcData. Raw receiver values (rxrange-d but unfiltered) are sent to Configurator to keep user experience the same.

… RC filter and rcData. Only meaningful for digital receivers that signal the link loss explicitly
@digitalentity digitalentity added this to the 2.0 milestone Jun 30, 2018
@digitalentity
Copy link
Member Author

I believe this is a proper fix for #3248 and #2981

@digitalentity
Copy link
Member Author

Did some testing. RC receiver is connected by SBUS set to "No pulses". However in failsafe reciever sends all channels at 1500 regardless of pre-failsafe settings. Combined with filtering this causes rcData to hold incorrect values when recovering from brief receiver failsafe (short enough to not trigger the actual FAILSAFE procedure).

image

@digitalentity digitalentity removed Feedback required The issue/PR is missing information to proceed further Testing Required labels Jul 16, 2018
@digitalentity digitalentity merged commit 3e670db into development Jul 16, 2018
@digitalentity digitalentity deleted the de_rcdata_ignore_failsafe branch October 28, 2018 18:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants