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.
Previously, the CSMA implementation did not perform well under circumstances where an ACK does not arrive. In that case, all other frames would be ignored until the timer for waiting on an ACK would run out, or an ACK would arrive. Before this PR, the timer for waiting on an ACK could take up to 24ms (for a full blown 127 byte frame).
The section in the IEEE specification speaks about waiting for an ACK to arrive in the 'expected time'. When looking at the diagrams in that section, they expect that from when the last frame is transmitted, the transmitting device should wait for the AIFS + time of sending an ACK + SIFS. Both AIFS and SIFS seem to be 1ms and sending an ACK (3 bytes) at 250kbps, seems to translate to 24us. This PR then sets the new waiting time to 2024us.
Additionally, the AIFS should be used on the receiving side to go from receiving mode to transmitting mode. As timers with Rust futures work in an at least this long-way, the time to wait before transmitting the ACK on the receiving side is halved. When testing this on an nRF52840 with Embassy and sniffing the traffic in Wireshark, the ACKs arrived between 1 and 2ms after the previous data frame had been sent.
Lastly, due to how join is implemented, the order of sending an ACK and sending the received frame to the network layer is reversed in order. This has as goal to transmit an ACK with a slightly higher priority over further processing the received frame.