Use invalid CRSF value to differentiate from an actual 0 ChannelData value #3405
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pkendall64
approved these changes
Nov 16, 2025
Collaborator
pkendall64
left a comment
There was a problem hiding this comment.
Minor grammar fix in the comment, other than that, all good
mha1
approved these changes
Nov 18, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Changes the internal ChannelData structure to be initialized with an invalid CRSF value, so our code on the RX can tell if a channel has been updated OTA yet. Also updates CRSF EXT min/max to match CRSF spec 880-2120us (we referenced 885-2115)
Bug
Servos running in FullRes mode could not distinguish a "0" channel value (880us) from a value that had not been received yet. The servos will not output a value if the channel value is 0, leading to a low throttle never outputting a value.
CRSF Ext Limits
When writing Fullres mode, I somehow landed on +/-120% (885-2115us) as being the CRSF Ext Limit. However, looking at the calculation on their spec, it is 0=880us and 1984=2120us. I've updated our references to match this, although no values we're sending will change since we send them in CRSF.
For discussion!
What do we write to our serial outputs for channels we have not received yet? Currently we output CRSF(0), so this PR replicates this behavior. However, we can output 1500us if we want. I'm not sure if we want to move all the sticks and switches to center before they've all been received, as Betaflight (and I believe iNav) will discard channels outside the 988-2012us range by default, so 1500us would make them "valid".
Any channel could not be received yet, so this is somewhat of a hidden gem of ExpressLRS. Switch channels take 8 packets to fill all of them. Fullres 16ch mode takes 2 packets.