MultiNav Pro+ BLE - retransmit behavior when link goes marginal, tunable?

@Scott Andrew yeah 30km LoS holding stable is exactly what we'd expect from the module in a clean ground-to-ground setup, so good to hear that part's working well.

 

On the retransmit behavior — what you're seeing is largely the BLE stack's native acknowledgement and retransmit mechanism doing its job at the link layer. When the link goes marginal it'll automatically retry packets before dropping them, and that's happening below the level where you'd normally tune it through application code. The short answer is that some of that is "just doing its thing" by design.

 

That said, the firmware is open source and the repo is at github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07 — if you want to dig into the connection parameter configuration and see what's actually exposed for tuning, that's your best starting point. Connection interval, supervision timeout, and related parameters can meaningfully affect how the stack behaves under marginal conditions.

 

What are you actually trying to optimize for — latency, throughput recovery, or just understanding when the link is about to fall over so you can react to it in your application?

The retransmit behavior you're seeing is mostly baked into the BLE stack's link layer and not directly exposed through the standard AT command set, but you can get some indirect control by tuning the connection interval and supervision timeout parameters - tightening those up will change how aggressively it decides the link is recoverable vs. just dropping and reconnecting. Worth digging into the `AT+CONINTVL` and `AT+SUPVTO` registers if you haven't already, those two together basically define the retry envelope.

Yeah Jeffrey's right on the money with those two registers - I spent a while fighting similar behavior on a long-range deployment and the combo of loosening `AT+CONINTVL` slightly while keeping `AT+SUPVTO` tight was the sweet spot that let it ride out brief fades without nuking the connection entirely. One thing to watch tho: if you push `AT+SUPVTO` too aggressive you'll start seeing phantom disconnects during momentary multipath dips that the link would've recovered from on its own.