@Moon Kimberly yeah this is pretty classic BLE behavior at range edge — what you're seeing is the link layer fighting to maintain connection parameters that made sense at closer range. When RSSI degrades past a certain threshold, the controller starts missing ACKs, triggers retransmissions, and if your connection interval and supervision timeout aren't tuned for that condition, you end up in exactly the burst pattern you're describing — technically alive, practically useless.
The first thing I'd look at is your connection interval. If you're running something aggressive like 7.5ms or even 20ms for smooth streaming, that's great at close range but brutal at the edge because missed packets cascade faster than the link can recover. Bumping the connection interval out to something like 100-200ms at range edge gives the radio more time to actually complete a transaction before the next one fires, which tends to smooth out the bursting significantly.
The other lever worth pulling is the slave latency and supervision timeout — if your supervision timeout is too tight, the stack is triggering internal recovery logic that compounds the retransmission problem. Loosening that up gives the link more forgiveness when you're eating occasional missed intervals. The GitHub repo has the firmware source so you can dig into how those parameters are currently set and experiment from there — would be worth logging RSSI alongside your throughput data too so you can see exactly what signal level the bursting starts at, that'll tell you a lot about where to set any adaptive logic.
