MultiNav Pro+ BLE - advertising interval vs. discoverability at long range?

@Joseph Hawkins yeah your instinct is actually pretty solid here. At extreme range the link margin is thin enough that the receiver is working hard to pull packets out of the noise floor, and if you're hammering the advertising channels with a short interval you're not giving the radio time to recover between transmissions — plus you're increasing the probability that two adv packets land on the same channel at the same time as interference from other sources. The STM32WB07 on the MultiNav Pro+ has pretty aggressive LNA sensitivity so it helps, but you can't hardware your way out of a collision on ch37/38/39 if the timing is just unlucky.

 

What I'd actually suggest is running a longer interval — somewhere in the 500ms–1s range — and compensating by extending the scan window on the central side so it's listening long enough to catch an adv event even with that slower cadence. You get the power savings on the peripheral, you reduce the collision window, and at that range the few hundred milliseconds extra to first discovery doesn't really matter in a sensor deployment context anyway. The solar buffer situation makes this even clearer — if your harvesting is marginal, radio TX is probably your biggest draw and tightening that interval is the worst place to fight it.

 

One thing worth checking: if you're using the AI Firmware Builder in the Dev Hub, you can describe this exact scenario (low-power peripheral, long-range central, solar buffer) and it'll generate a tuned config that balances the advertising timing with sleep cycles in between. Saves a lot of empirical tuning time.

At longer range you're fighting path loss and interference way more than timing, so stretching the interval out to something like 500ms-1s is usually the right call for power-constrained nodes - the scanner just needs more time to catch a packet but it'll still find it. Worth also checking if your central supports extended scan windows, because if it's only scanning in short bursts it might just be missing the peripheral entirely regardless of interval.

Stephanie's right on the scan window point - that's actually bitten me before more than the interval itself. If your central is duty-cycling its scan to save power too, you can end up in this awful situation where both sides are trying to be efficient and they just keep missing each other's windows, so I'd lock the scanner to a longer continuous window during the initial discovery phase even if it costs you a bit on that end.

Yeah the "both sides duty-cycling and missing each other" problem is real and super annoying to debug - one thing that helped me in a similar solar-harvested setup was having the peripheral briefly drop to a fast interval (like 100ms) right after a power event or reset when the buffer was healthy, then step back to something conservative once it confirmed a connection or timed out. Adds a bit of complexity but you get that reliable initial handshake without just leaving it hammering away at short intervals indefinitely.

Philip's burst-on-power-event trick is solid and honestly that's close to what I ended up doing on a similar node - one thing I'd add is make sure you're gating that fast interval on actual buffer voltage rather than just a reset event, otherwise a brownout-recovery loop will just hammer your radio at exactly the moment you can least afford it.