MultiNav Pro+ BLE - firmware OTA updates over long range, any experience?

Done a few OTA sessions at ~30km with the Pro+ and honestly it's more about link budget discipline than raw range - keep your payload chunks small (I was doing 128 byte blocks), add solid CRC checks, and make sure your retry logic is aggressive because you *will* get packet drops at the edge of range. The 50km claim holds up in open terrain but I wouldn't push a full firmware flash at that distance without a rollback mechanism baked in, learned that the hard way on a soil monitoring deploy last spring.

@Sugandha Sharma yeah your instincts are solid here — 128 byte blocks and aggressive retry logic is pretty much the right approach, and the fact that you've already got that discipline in place puts you ahead of most people attempting this.

 

The rollback mechanism is non-negotiable in my opinion. What I'd suggest is keeping a known-good firmware image in a separate flash partition and only committing the swap after the node has booted successfully and phoned home with a valid status packet. If you don't get that confirmation within a timeout window, the node rolls back automatically. Learned that pattern from a few painful edge cases where the update landed fine but the new firmware had a runtime bug that silenced the node entirely.

 

One other thing worth adding to your stack — a pre-update link quality check before you kick off a flash session. If RSSI is marginal at that moment, just reschedule it rather than rolling the dice. A bricked node at 30km is a very bad day.

 

The GitHub repo for the MultiNav Pro+ firmware is at github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07 if you want to dig into the STM32WB07 side of things — there's useful context in there for how the radio stack is structured that'll help you plan the OTA flow properly.

Kent's point about rollback is huge, I'd add that we had good results staging our OTA through a two-slot bootloader so even a botched mid-transfer cutout couldn't brick the node - saved us a site visit on a deployment that was absolutely not worth driving to. Also worth logging your RSSI through the session so you can correlate any block retries to signal dips and tune your chunk size accordingly.

Both solid points - one thing I'd add from our deploys is that scheduling OTA windows around known interference patterns (we had issues with agricultural machinery cycles throwing off link quality at predictable times of day) made a huge difference in completion rates, basically went from ~70% first-pass success to well over 90% just by shifting the update window 2 hours earlier. Also make sure your watchdog timer is configured to give the bootloader enough headroom during a slow block transfer or you'll get phantom resets mid-flash that look like link failures but aren't.

All three of these are gold - the watchdog thing Joanna flagged especially, we got burned by exactly that and spent way too long chasing what we thought was a BLE stack issue before someone finally checked the WDT timeout config. One thing I'd throw in: if you're not already, persist a "update in progress" flag to non-volatile storage before you kick off the transfer so even a power cycle mid-flash doesn't leave the bootloader confused about what state it's in.