Every few years a piece of infrastructure I care about gets a new licence, and the reason given is some version of the same sentence: we need to stop the big players strip-mining this. I have written that sentence myself, more than once. The instinct is sound. A digital commons that nobody defends gets enclosed, and the people doing the enclosing rarely announce themselves.

So when Mark Qvist, the person behind the Reticulum mesh networking stack, replaced its MIT licence with a custom one built to keep the project out of corporate AI training sets and out of weapons systems, I understood the motivation completely. I just think it was the wrong move, and that the tool he actually needed was already on the shelf, tested, and free.

When I wrote LPWAN Meshes: Reticulum, Where I Landed earlier this year, I covered Reticulum as Mark Qvist’s reference Python implementation: rnsd, Sideband, NomadNet, all built on RNS. That was accurate at the time, and it undersold what was already starting to happen underneath it. Reticulum was never meant to be a Python project. It is a protocol, and a protocol with only one implementation isn’t decentralised yet, it’s just a single point of failure with good branding.

Part one and part two of this series covered how Reticulum and MeshCore actually move a sensor reading: LXMF’s delivery methods and Propagation Nodes on one side, a purpose-built sensor role and CayenneLPP encoding on the other. Both are genuinely decentralised, no shared infrastructure required beyond the nodes themselves. This closing part asks the question that decides whether that matters for a given deployment: what does the alternative, LoRaWAN, actually require to do the same job?

LPWAN Meshes: Reticulum, Where I Landed covered Reticulum as a communications stack: transport-agnostic, cryptographically addressed, built for chat and file transfer over LoRa, packet radio, or whatever medium is available. This post is narrower on purpose: it breaks down the specific mechanics of moving a sensor reading, not a conversation, through Reticulum: which delivery method to pick, what a reading actually costs in packets and bits per second, and what already exists in the open-source community to build on rather than reinvent.

A commercial telco and a mesh network are not different ways of solving the same problem. They are built on opposite assumptions about how infrastructure works. Understanding why that matters is the key to understanding why regional Australia keeps getting left behind, and what to do about it.

The Economics of Absence

In regional and rural areas, the connectivity gap is not a failure of effort or ambition. It is the predictable output of a particular economic model.

If you have spent any time in the off-grid radio scene over the last few years, you know the frequency divisions. You either ran on the sub-GHz bands (915 MHz in Australia and the Americas, 868 MHz in Europe) for long-range, bush-penetrating reliability, or you accepted the high-congestion limits of local Wi-Fi. It was a trade-off we took for granted. If you wanted to send a message across 10 km of dense stringybark, you needed the long waves. If you wanted global hardware standardisation, you looked elsewhere.

In the world of Internet of Things (IoT), the sub-GHz spectrum is a frontier of immense promise, offering the holy grail of long-range and low-power communication. Two fundamentally different philosophies are vying to define this frontier. On one side stands Wi-Fi HaLow (IEEE 802.11ah), a direct evolution of the familiar, IP-based Wi-Fi standard, engineered for higher bandwidth and seamless integration. On the other lies the diverse and adaptable LoRa landscape, a collection of distinct networking protocols all built upon the same remarkable long-range radio technology.

Over the past few weeks, I’ve pulled apart four different LPWAN mesh technologies. Now it’s time to bring those findings together and look at which tool fits which job on the property or in the community.

There is no “perfect” protocol. What we have is a set of tools with different trade-offs. I’ve evaluated all four across five parameters to help cut through the marketing noise and get to the technical reality.

After years of experimenting with various LPWAN mesh networking technologies, I’ve settled on Reticulum as my primary LoRa mesh platform. It emerged as the clear frontrunner not because it’s simpler than the rudimentary Meshtastic (it isn’t), nor because it’s overtly more feature-rich than the structured MeshCore, but because its design philosophy fundamentally aligns with what matters most: privacy, resilience, and true decentralisation. It supports multiple bearer protocols, making it a powerful tool for building a future decentralised network.

Long-range Sub-GHz wireless mesh networks have become essential for modern communication, particularly in remote areas where traditional infrastructure is impractical or impossible. By utilising lower frequencies (typically below 1 GHz), Sub-GHz networks can achieve remarkable range, low power consumption, and the ability to penetrate obstacles such as buildings and dense forests.

These characteristics make Sub-GHz mesh networks ideal for applications in IoT, outdoor communication, emergency response, and industrial networks. But with numerous technologies now available, choosing the right one for your needs can be challenging.

In an emergency, information is as vital as water. The official advice is clear: “leave early.” But how do you act on that advice when the power is out, the mobile network is congested to the point of failure, and the emergency broadcaster’s tower has been consumed by the very fire you’re trying to flee?

This isn’t a hypothetical. As Fiannuala Morgan chillingly documented in her article, “No power, no phone, no radio: why comms dropped out during the Central Victorian fires”, this is the reality for communities across Australia. The wholesale replacement of resilient copper landlines with power-dependent NBN connections, coupled with the shutdown of the 3G network, has created a communications infrastructure that is dangerously brittle in the face of climate-fuelled disasters.

In the last post, I explored the graveyard of ‘bricked’ devices, hardware rendered useless by corporate decisions. It’s a stark reminder that when you don’t control the software, you don’t truly own the hardware. The clear alternative is Open Source, but that path has its own critical vulnerability: sustainability.

But this is where the journey gets complicated. We flee to platforms like Home Assistant and embrace open-hardware projects, expecting a haven of stability and privacy. And while we find it, we often forget a crucial truth: “free and open source” does not mean free to create.