I have a few LoRa radios running Meshtastic and they're fun to play with, but I wouldn't rely on them in a critical situation. It's too easy to accidentally configure a node incorrectly and cause problems for nearby nodes.
Perhaps someday the project will settle on a handful of sensible presets for different use cases. Even better would be if more of the options were managed dynamically by the software itself, things like adjusting timeouts and hops based on current network utilization and previous transmission success rate, or automatically tweaking the role based on the current mesh toplolgy, that sort of thing.
We need better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth with a simplified interface. There's no sense wasting spectrum or having malfunctioning radio gear when it can be standardized and used more efficiently without an artificial, protectionist, hoarding monopoly (excluding particular essential, prioritized uses).
Proprietary mesh networks tend to become unusable garbage because they omit DoS, rate limits, and proper configuration for dense metropolitan uses, and tend to fail at investing in upkeep.
> better radio silicon that can survey a wide swath of available spectrum (based on country limits) and pick channel(s) appropriate to the use optimized for battery life, distance, and/or bandwidth
That would certainly be helpful, but even with current radios I can imagine a configuration process that sequentially scans different channels to achieve the same result, just a little slower.
A full scan would take hours. With just the default choice of channel width (250 kHz), spreading factor and coding rate, in the US you'd have to listen to 104 different frequencies, and you'd need to listen for more than a minute to get any idea of whether each frequency is in use. The newest LoRa chips that support simultaneously monitoring multiple spreading factors aren't yet supported by Meshtastic or available in cheap devices. The base station chips that also support listening to eight frequencies at a time are way more expensive.
Even with the latest radios available but not yet used by Meshtastic, it would be very hard to implement any kind of frequency-hopping scheme or variable bandwidth, without requiring mesh nodes to burn a lot more power sending and receiving+acknowledging across multiple modem settings to maintain reliability. LoRa as implemented by the chips used in affordable Meshtastic devices is really more suited to operating many small disjoint mesh networks on separate channels, not one large mesh network spanning multiple frequencies/bandwidths/etc. (Dropping the ad-hoc mesh aspect in favor of centralized coordination is pretty much the only way to scale up to large networks.)
> LoRa as implemented by the chips used in affordable Meshtastic devices is really more suited to operating many small disjoint mesh networks on separate channels
My impression was that many of the folks who wanted a big shared mesh migrated to MeshCore, which I'm less familiar with. My use case is in fact a small disjoint mesh network, but even that requires proper configuration and can be unreliable due to things like misconfigured nodes (mine or others).
I'd be happy to specify the region and form factor (handheld, fixed router, mobile router, tracker) but it would be nice if the nodes could automatically configure the right role, rebroadcast mode, hop limit, timeouts, etc on their own. I'm not asserting it's possible, just that I don't otherwise see it breaking out of the hobbyist niche.
> A full scan would take hours.
My apologies, I misspoke, I agree that trying every frequency/bandwidth/spread factor/coding rate combination would be impractical, at least for battery-powered nodes. Instead of "scan different channels" I should have said cycling through the half-dozen modem presets for a specific region.
Perhaps someday the project will settle on a handful of sensible presets for different use cases. Even better would be if more of the options were managed dynamically by the software itself, things like adjusting timeouts and hops based on current network utilization and previous transmission success rate, or automatically tweaking the role based on the current mesh toplolgy, that sort of thing.