Reduce jitter for CRSF RC packets on the receiver #2943
Merged
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
Reduces jitter to <+-30us with a std.dev of 5us
Collaborator
Author
|
Bonus trace for D-mode users. This is D250 on an ESP32 true diversity receiver. Also done with 5-second persistence on the traces so you can see the jitter. |
JyeSmith
reviewed
Sep 23, 2024
Member
JyeSmith
left a comment
There was a problem hiding this comment.
Did a BF BB log and its looking good!
JyeSmith
approved these changes
Sep 23, 2024
wvarty
approved these changes
Sep 29, 2024
frank26080115
pushed a commit
to frank26080115/ExpressLRS
that referenced
this pull request
Oct 19, 2024
* Split RC data sending from polling and queued data sending * Allow CRSF immediate sends when timer fires Reduces jitter to <+-30us with a std.dev of 5us * Document the new API function
wimalopaan
pushed a commit
to wimalopaan/ExpressLRS
that referenced
this pull request
Oct 22, 2024
* Split RC data sending from polling and queued data sending * Allow CRSF immediate sends when timer fires Reduces jitter to <+-30us with a std.dev of 5us * Document the new API function
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.
This PR is built on top of #2931 and should be merged after that.
Problem
As part of the serial framework refactor that happened some time ago... the sending of CRSF RC packets was moved to the main loop rather than after the packet was received. This move fixed an issue where ESP32 based receivers would crash because the UART was being accessed in the loop and in the interrupt handler.
The downside of moving the sending of the RC packet sending to the main loop is that it has created a bit of jitter in the timing.
Solution
noInterrupts()/interrupts().Funky Images
Before
This is an ESP8285 receiver sending the RC packets to the FC in the main loop.
The scope has been set to 5-second persistence to show the jitter.
This is an ESP32 receiver doing the same thing. The jitter is less but it's still there.
After
These images are after allowing the CRSF driver to send the RC packets in the "tock" interrupt.
As can be seen in these images, the jitter is significantly reduced as shown by the "Dev:" deviation value in the result panel at around 5us.
ESP8285 after
ESP32 after
Bonus Images
These images show the relationship of the interrupt "DIO" to the sending of CRSF RC packets after the PR is applied.
Also, in these images the result panel to the right shows the delay from receiving the interrupt to sending the RC data which is approx. 220us and the deviation "Dev:" which is approx 3us.
ESP8285 1000Hz
ESP32 1000Hz
ESP8285 150Hz
ESP32 150Hz