MultiNav Pro+ BLE range claims - anyone actually tested this in the field?

Ran some informal tests out in a flat open field a few months back with a clear LOS and decent yagi setup and was hitting just over 8km pretty reliably, so the 5-10km range for asset tracking is definitely achievable if you're not fighting too much terrain or interference. Indoor/urban stuff is a totally different story tho - walls and buildings will eat into that fast so manage expectations there depending on your deployment environment.

Nice, Jason's numbers line up with what I've seen too - we did some testing out in a semi-rural area and were sitting comfortably around 6-7km with just a decent whip antenna, nothing fancy. For asset tracking that kind of range is honestly plenty unless you're doing something really spread out, just make sure your firmware is handling the reconnection logic cleanly because at those distances you'll see more intermittent drops than you would at close range.

Those numbers match pretty closely with what we've been seeing too - got solid 7km out of a whip in a mostly open area, dropped to maybe 2-3km once we moved into a area with more tree cover and rolling terrain. The reconnection point Jason G mentioned is worth taking seriously early on, we had to do a few iterations on that logic before it felt stable at range.

Solid numbers from everyone here - my field testing lines up pretty closely, though I'll add that antenna orientation ended up mattering more than I expected at the 6-7km range, even small adjustments were making a noticeable difference in link quality. On the reconnection logic front, we ended up implementing an exponential backoff with a max retry cap and that cleaned things up a lot - without it we were seeing the module hammer reconnect attempts and it was causing its own problems at range.

Antenna orientation thing Leonard mentioned is real - we saw the same, like at 6km+ even 20-30 degrees off axis was noticeably degrading the link. Also +1 on the exponential backoff, we're using something similar and the difference vs naive retry was pretty dramatic once we started logging the reconnect behavior at range.

Yeah the exponential backoff thing is basically a must-have once you're operating at those distances - we got burned by the hammering issue too before we sorted it out. One thing I'd add for the asset tracking use case specifically is to make sure you're logging RSSI over time during your field tests, not just whether you have a connection or not, because the signal variance at 6-7km can tell you a lot about where your weak spots are gonna be before they actually become drop problems.

The RSSI logging tip from Rodney is gold - we actually built a little heatmap from our field test data and it made it really obvious where the terrain was killing us before we ever hit an actual drop. Saved us a ton of guesswork on antenna placement for the fixed nodes.

The RSSI heatmap idea is something I wish I'd done from day one - we went through two rounds of antenna repositioning that probably could've been collapsed into one if we'd had that data up front. Also on the backoff thing, we cap our max interval at 30s and that's been the sweet spot for us, any longer and the asset tracking latency starts getting weird for our use case.

The 30s cap Harold mentioned matches almost exactly where we landed too - tried 45s for a while and yeah, the latency weirdness is real especially if you're doing any kind of geofence logic on top of the tracking data. One thing I'd throw in for the RSSI heatmap approach: if you can sync your logs with timestamps and cross-reference against time-of-day you might catch some interesting variance, we noticed our 6-7km links were noticeably noisier in the late afternoon and it took us embarrassingly long to figure out it was a thermal/atmospheric thing not a hardware issue.

The time-of-day correlation thing Kenneth mentioned is such a rabbit hole - we spent way too long chasing what we thought was an intermittent hardware fault on one of our longer links before we finally overlaid the drop timestamps against weather data and realized it was afternoon thermals every single time. Definitely worth building that timestamp sync into your logging from day one rather than retrofitting it later like we did.