refactor(rc channels): Use event handler for fail-safe and RC channels #79
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This Pull Request re-factors the old API for reading RC Channels, and puts them into their own event handler.
This same event handler also reads the receiver's fail-safe state based on the RSSI and LQI thresholds set in the
CFA_Config.hpp
file.Details
Like the other event handlers, you register the callback using
CRSFforArduino::setRcCallback(serialReceiverLayer::rcChannels_t *)
The underlying
_rcChannels
array has been rewritten as a data structure, which now holds not only your raw RC channels data, but also holds afailsafe
flag which you can read out in the Event's callback function.Here is what the RC Channels Event Handler API looks like:
In
CFA_Config.hpp
you have two options:CRSF_FAILSAFE_LQI_THRESHOLD
CRSF_FAILSAFE_RSSI_THRESHOLD
The
CRSF_FAILSAFE_LQI_THRESHOLD
is the minimum Link Quality value that the receiver considers to be connected. You can set this to any arbitrary value from0
to100
.The
CRSF_FAILSAFE_RSSI_THRESHOLD
is the minimum RSSI. It is recommended that you set this to the same value as your packet rate's RSSI Sensitivity Limit.When either one of these thresholds are crossed, this is what constitutes a fail-safe.
This is pretty rudimentary, but it will do for now, and it can be expanded later on down the track, if the need to do so arises.
Additional notes
I decided to leave out the ability to read back whether-or-not a received CRSF packet has either passed or failed its checksum for the time being. I know this was a part of what was brought up in #51, however, later on down the track, it may be better to automatically incorporate multiple checksum fails into "what constitutes a fail-safe".