MultiNav Pro+ BLE - passive scanning range vs active, any real difference?

@Gerardo Casasola good question — at extreme range passive scanning is almost always the better call, and here's why it actually matters in practice: when you send a SCAN_REQ at the edge of your link budget, you're betting that the peripheral has enough SNR margin to decode it *and* respond with a SCAN_RSP before your scan window closes, and that's two additional transactions that can both fail independently. You're essentially doubling your exposure to a bad link event at exactly the moment the link is most stressed.

 

The timing jitter piece is real too — the SCAN_RSP has to come back within a tight window after the peripheral receives the request, and if there's any multipath weirdness or the signal is hovering near sensitivity floor, you can get situations where the central receives the ADV_IND cleanly but the SCAN_REQ or SCAN_RSP gets corrupted, and depending on how your scanner handles that it can either drop the advertisement entirely or introduce a detection latency spike. Neither is great for a telemetry link where you want consistent advertisement detection rate.

 

For a point-to-point telemetry use case where you're not pulling anything from the scan response data, just lock in passive and tune your scan interval/window ratio instead — that's where you'll get more reliable detection at range than anything the active/passive choice gives you on the upside.

Passive vs active shouldn't really affect your detection range since the advertising packets themselves are what the central is receiving either way - active just adds the scan req/resp round trip after initial detection, so if you're already marginal on link budget that extra exchange can fail without taking down your adv reception. That said I've noticed on the MultiNav Pro+ specifically that running active scanning seems to keep the radio busier in ways that can slightly hurt sensitivity in dense RF environments, probably just duty cycle stuff, so if you don't need the scan response data just stick with passive and save yourself the headache.

Yeah Tony's right, and I'd add that at extreme range you really want to minimize any unnecessary radio activity on the central side anyway - passive scanning means you're not burning air time on scan requests that might not even complete cleanly when you're already scraping the bottom of your link budget. Stick with passive, tune your adv interval if you haven't already, and you'll have a much cleaner time.

One thing worth adding - if you're doing point-to-point telemetry and you control both ends, have you considered just skipping scanning altogether and using directed advertising to the central's address? Cuts out a lot of the uncertainty at range and your central isn't wasting any time sifting through other devices' adv packets. Might not fit your use case but worth a thought if you haven't gone down that road yet.

Rajesh's point about directed advertising is solid if you can lock in the central's address ahead of time - I did something similar on a MultiNav build last year and the reliability improvement at range was pretty noticeable just from cutting out all that scanning overhead. Only gotcha is if your central ever changes address (resolvable private addresses etc) you'll need to handle that pairing logic, but for a fixed telemetry link it's honestly the cleanest approach.