@Stephanie Williams good question — this is something that comes up a lot with the MultiNav Pro+ in variable-range deployments.
The short answer is that the module itself doesn't dynamically adjust connection interval based on distance, so you won't see the stack quietly stretching your intervals as you move further out. What you *will* see at the far end of the range envelope is the retransmission behavior kicking in more — BLE has acknowledgment and retry mechanisms built into the link layer, and when RSSI drops and packet error rate climbs, you can accumulate latency from retries even though your configured connection interval stays the same. At 100m that's basically invisible; at several kilometers in open terrain it depends a lot on what's in between and atmospheric conditions on the day.
The firmware repo is on GitHub at
https://github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07 — worth digging into the connection parameter configuration there, because for an asset tracking use case where you don't need sub-second updates, tuning your connection interval and slave latency settings to something a bit more relaxed will actually make the link more resilient at long range rather than fighting to maintain a tight interval the link can't reliably sustain. If your status updates can tolerate a second or two of delay, that headroom gives the link layer more room to breathe.
What's your current update rate requirement? That would help figure out if you're working against the link or with it.
