@Scott Andrew great question and honestly one that doesn't get asked enough — most people just see the 2Mbps headline and run with it.
The 2Mbps figure is the PHY layer data rate, so that's raw air throughput before you account for BLE packet overhead, L2CAP framing, ATT protocol bytes, and yes, AES-128 encryption on top. The STM32WB07 at the heart of the MultiNav Pro+ handles AES-128 in hardware, which means the encryption itself isn't the killer — the hardware crypto engine is fast enough that it's not your bottleneck the way it would be on a software-stack BLE implementation. What actually eats your effective throughput is the combination of packet overhead plus connection interval tuning plus, as you correctly identified, retransmissions at extended range.
For an 8-12km water crossing specifically, I'd focus less on encryption overhead and more on how you tune your connection parameters — connection interval, slave latency, supervision timeout. At that range you're going to want to be conservative with your connection interval to give the link room to breathe when signal conditions vary, and that'll have a bigger practical impact on your effective data rate than AES ever will. The firmware repo on GitHub is open so you can actually dig into how the connection parameters are configured and tune them for your link budget rather than relying on defaults that were probably optimized for shorter ranges.
What kind of sensor data and update rate are you targeting? That'd help narrow down whether you're even approaching the point where throughput becomes a real constraint versus just a theoretical one.
