@James Blackburn yeah this is a really common frustration when you're pushing toward the sensitivity floor — the module stays "connected" in the BLE sense because the advertisement/connection events are still getting through intermittently, but your actual payload throughput is basically toast. The STM32WB07 front-end is doing a lot of work at those ranges but there's a practical cliff somewhere around -95 to -100 dBm where PDU error rate starts climbing fast even if RSSI is still technically showing a number.
The thing I'd look at first is whether you're logging per-packet CRC errors separately from RSSI — because RSSI is an average and it'll mask the variance that's actually killing you at that range. If you're seeing connected-but-failing behavior, my bet is your instantaneous signal is dipping well below your average RSSI reading due to multipath or atmospheric conditions, and that's where the payload loss is coming from.
Have you checked the firmware repo to see if there's any PHY-level logging you can tap into for CRC fail counts? The GitHub has the STM32WB07 firmware source and depending on what you've built on top of it, you might be able to surface that data without too much work. That would tell you a lot more than RSSI alone about where your actual usable floor is in your specific deployment environment.
