Jonathan BennettandClaude Opus 5.5 e069a8d491 LR2021: time received frames on the configured coding rate (#12183) ...

* LR2021: time received frames on the configured coding rate

The LR2021's reported RX coding rate can pick up extra bits at a bad
status read right after our own TX and keep them until a hard reset.
Explicit-header frames still decode, since the rate travels in the
header, but the wrong value inflates RX airtime: a latched 4/8 against
a configured 4/5 times a 200-byte frame about 55% long. That feeds
channel utilisation, the CSMA contention window and the reliable-router
retransmit timers.

computePacketTime() gains useRxHeaderInfo; LR20x0Interface passes false,
so received frames are timed on the configured coding rate and CRC, and
the readout task no longer reads the header info on that chip.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GTiifXrVc4YdonmLRCeWhw

* LR2021: describe the coding-rate accumulator in the comments

The reported RX coding rate was described as latching after a post-TX
status read. That attribution was wrong: GetLoraPacketStatus accumulates
the bitwise OR of every received header's coding rate since reset, which
an SX1262 injector reproduces on demand - frames at 4/5, 4/6 and 4/7
each OR their bit in, a frame at the configured rate changes nothing,
and the field reaches values DS rev 2.2 Table 9-4 does not define. It is
invisible on a single-coding-rate mesh, since cr | cr == cr.

No behaviour change: comments only.

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-20 04:42:18 +00:00

..

test_main.cpp

LR2021: time received frames on the configured coding rate (#12183)

2026-10-20 04:42:18 +00:00