MultiNav Pro+ BLE - does range drop significantly with multiple active connections?

@Richard Brown good question and honestly one that comes up a lot when people start thinking about scaling from point-to-point to fleet deployments.

 

The short answer is the RF front-end itself doesn't "split attention" the way you might imagine — the radio is still running at the same output power and sensitivity per connection. What you're actually dealing with when you add more simultaneous connections is a scheduling and time-slicing problem at the firmware/stack level. Each connection gets a connection interval, and the more connections you have, the more those intervals have to be staggered, which means any individual node is effectively getting less frequent attention from the central. That doesn't degrade the link quality *when* it's active, but it does increase latency and can cause missed connection events if the scheduling gets tight.

 

For your 8-10 node fleet setup, the practical concern I'd watch for isn't range degradation per se — it's whether your connection intervals are tuned aggressively enough that you're dropping events under load. If you're doing periodic GPS telemetry where a few hundred milliseconds of added latency is fine, you've got a lot more headroom than if you need tight real-time updates. Worth testing with your actual data rate requirements before you assume the range numbers hold cleanly across the whole fleet.

 

If you haven't already, it'd be worth posting your use case over in the Dev Hub — the AI Firmware Builder can also help you dial in the connection parameter config for a multi-peripheral central role setup if you want a starting point.

From what I've seen with similar setups, the range hit comes more from the scheduling overhead than anything happening at the RF level - the radio itself isn't really "splitting" its power, but you do get increased latency and potential missed packets as the coordinator juggles more connections, which can *feel* like range degradation especially on the edges. With 8-10 nodes I'd honestly stress test it at maybe 60-70% of your expected max distance first and see how packet loss behaves before committing to a deployment layout. Also worth checking if your firmware version supports the async polling mode, that helped a lot in a similar multi-node thing I did a few months back.

Agree with Susan on the scheduling point - also worth noting that if you're running all 8-10 nodes at the same connection interval you're basically guaranteeing collisions at range, so staggering those intervals even slightly made a noticeable difference for me. The RF front end itself is fine but the coordinator getting backed up is where things fall apart at distance.

Staggered intervals is def the move, and I'd also look at bumping your connection timeout values a bit higher than default if you haven't already - at range you start getting retries stacking up and if the timeout is too tight the coordinator just drops nodes that are otherwise perfectly reachable. Learned that one the hard way on a 6-node outdoor test last summer.

Jumping in late but just wanted to add - on top of all of the above, watch your TX power settings on the individual nodes too, because if they're all cranked to max trying to punch through to the coordinator you can actually create interference with each other at closer ranges that muddies things up further out. Counterintuitive but backing them off slightly and letting the staggered intervals do the work got me cleaner connections across the board.

All of the above is solid advice - one more thing I'd throw in is that if your gateway node is running on default antenna config, that's often the weakest link when you scale up connections, so if you haven't already swapped to a higher gain external antenna on the coordinator side that alone bought me way more headroom than tuning the node settings did. Especially noticeable once you're past 6 simultaneous connections in my experience.