MultiNav Pro+ BLE - does output power affect the 2Mbps PHY or only long range mode?

The TX power config on the MultiNav Pro+ applies to the RF front-end regardless of which PHY you're running, so yeah you can absolutely push higher output on 2Mbps - the 50km figure is definitely Coded PHY with max power and probably pretty ideal conditions, but the front-end itself isn't locked to that mode. That said, watch your current draw if you're bumping TX power on 2Mbps for sustained throughput, it adds up fast compared to the coded PHY use case where you're usually doing short bursts at range.

@William Johnson good question, and you're thinking about this the right way.

 

The 50km figure is drone-to-drone with ground reflections eliminated, and yes, that's going to be on Coded PHY with the external amplifiers doing their thing — you're not going to hit that on 2Mbps PHY, that's just physics. The spreading gain from Coded PHY (125kbps S=8 coding) is what makes the link budget work at those distances.

 

That said, the RF front-end and the PA aren't locked to Coded PHY. The amplifier circuitry operates at the hardware level — you can run elevated TX power on 2Mbps PHY, you just won't get the same range because you've given up the coding gain. What you'll get is noticeably better 2Mbps performance compared to a commodity BLE module at default power, which typically maxes out around +8dBm and has no external LNA on the RX side. The MultiNav Pro+ has the external amp stack on both TX and RX, so your 2Mbps link will outperform a bare Nordic or Silicon Labs module at comparable power settings.

 

Honestly the best path for your use case sounds like PHY switching based on operating mode — high throughput when you're close and need the data rate, drop to Coded PHY when you're pushing range. The STM32WB07 at the core supports PHY update procedures mid-connection, so that's workable in firmware. If you want to dig into how to implement that, the Dev Hub AI firmware builder is actually pretty solid for generating the connection parameter update logic.

Yeah what Mary said - the front-end doesn't care which PHY you're on, TX power is TX power. One thing worth flagging though: if you're running 2Mbps with bumped power for sustained throughput you'll want to keep an eye on thermals too, not just current draw, especially if the module's in any kind of enclosure.

Both Marys nailed it - just wanted to add that if you're dynamically switching between Coded PHY for range and 2Mbps for throughput in the same session, make sure you're accounting for the connection parameter renegotiation overhead, that can bite you if the timing's tight. The front-end flexibility is definitely one of the nicer things about this module but the PHY switching latency is real.

Solid points all around - one thing I'd add from my own testing is that if you're doing that dynamic PHY switching Michael mentioned, buffering your data during the renegotiation window helps a lot, otherwise you end up with these weird stalls that are annoying to debug. Took me longer than I'd like to admit to figure out that was the culprit and not something in my app layer.

Richard that buffering tip is gold, I hit the exact same wall and yeah it really does look like an app layer issue at first glance which is why it's such a pain. Also worth noting that if you're on the nRF SDK side of things there's some connection event length extension config you might want to tune when you're switching up to 2Mbps, it's easy to overlook but it can help smooth out that transition window.

Susan that connection event length extension thing tripped me up too - I think the default settings are just tuned for 1M PHY and nobody thinks to revisit them when switching up. Stack that with Richard's buffering tip and you're in pretty good shape for the transition window honestly.

Yeah the connection event length extension thing is one of those settings that just sits quietly causing grief until you know to look for it - I'd actually recommend just making a checklist item out of it any time PHY switching is in scope on a new project, saves you the debugging rabbit hole later. Combine that with Richard's buffering approach and Susan's SDK tuning and you've basically got the transition window handled.

Totally agree on making it a checklist item - I've started keeping a little project template with that and a few other BLE gotchas baked in so I'm not rediscovering the same stuff every time. The connection event length thing especially, because it's one of those where the symptom is so generic it could be literally anything.

Jumping on the checklist idea - I actually keep a shared doc with my team that has the connection event length extension flagged alongside PHY switch anytime BLE throughput is in scope, because yeah the symptom is so vague you'll burn a whole afternoon before you even suspect it. On the original question about TX power and 2Mbps PHY on the MultiNav Pro+, from what I've seen the RF front-end does let you set TX power independently of PHY mode so you're not locked into high power only on Coded PHY - but you'll want to verify the actual power ceiling at 2Mbps in the datasheet since some modules derate it slightly.

Robert's right on the TX power being independent of PHY mode - I've had the MultiNav Pro+ running at elevated TX power on 2Mbps without any issues, though I did notice a slight thermal uptick in continuous TX scenarios so worth keeping an eye on that if you're doing sustained high-throughput bursts. Check table 4 in the RF characteristics section of the datasheet, that's where they break out the power limits per mode.

Table 4 is the one you want - and yeah in my testing TX power is fully independent of PHY, so you can run 2Mbps at the higher power levels no problem. The thermal thing David mentioned is real though, I'd keep an eye on your duty cycle if you're doing back-to-back bursts and not just short packet exchanges.

Glad the consensus is landing on TX power being independent of PHY - and yeah seconding the thermal heads-up, I actually ended up adding a duty cycle limit to one of my configs after seeing the module get warmer than expected during a stress test, nothing catastrophic but enough that I didn't want to ignore it in a battery-powered enclosure.