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.

The ClusterDuck Protocol (CDP) was where my mesh networking journey truly began. The story behind Project OWL (Organisation, Whereabouts, and Logistics)—students building emergency communication networks after Hurricane Maria—resonated deeply, highlighting a technology designed not for hobbyists or industry, but for saving lives when infrastructure fails. While I found its concepts “much better thought through” from the outset, the project’s slow pace and patchy hardware support meant my personal involvement never truly moved beyond some initial tinkering.

ASUS ExpertBooks are popular enterprise laptops with a well-priced combination of hardware and solid build quality. However, installing Ubuntu on these laptops can be challenging due to UEFI issues. In this blog post, I am documenting the challenges and the steps to overcome these issues and successfully install Ubuntu on ASUS ExpertBooks.

Whilst UEFI is arguably useful, the choices made by ASUS in their BIOS settings are problematic. Whilst I have no knowledge of the exact reasons for these choices, they seem to be overly restrictive and limiting for advanced users. Enforcing the device to boot only from the UEFI firmware can be problematic for advanced users who want to dual-boot or install other operating systems.

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.

While Meshtastic serves as a solid introduction to LPWAN mesh networking, MeshCore represents a move toward more structured networks, particularly when the limits of ad-hoc flooding become a bottleneck. It addresses the “airtime” congestion common in simpler protocols, offering a far more robust path for community-scale infrastructure where a “best effort” approach isn’t enough. MeshCore is built for managed deployments and regional sensor networks where reliability and structured routing are the priority.

For many new to LPWAN mesh networking, MeshTastic often appears as a starting point due to its affordability and active community. It can get you from zero to sending a basic mesh message relatively quickly. For some, it may seem like a convenient entry into mesh networking.

In this post, I’ll dive into what makes MeshTastic tick, where it excels, and where it falls short based on my own experience using it across various scenarios.

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 the first two parts of this series, we explored why community telecoms matter and how resilient mesh networks can save lives during emergencies. Now comes the question I’m asked most often: “That sounds great, but how do I actually build one?”

This is the knowledge I wish I’d had when I started.

If my journey from those early Austrian tele-working centres to deploying mesh networks across remote Australian properties has taught me anything: the hardest part isn’t the technology—it’s overcoming the psychological barrier between “consumer” and “creator.” We’ve been conditioned to believe telecommunications infrastructure is something large corporations build, not something communities can create themselves.

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{target="_blank”}", 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.

We live in an era where a reliable connection to the digital world is not a luxury, but a lifeline. It’s how we work, learn, access essential services, and connect with our communities. Yet for many in regional and rural Australia, this lifeline is frayed, unreliable, or simply non-existent. We’ve been told to accept a digital landscape dominated by a handful of corporate giants, a landscape where postcodes dictate the quality of our connection to the modern world. But what if there’s another way?

In the first two posts of this series, we explored the risks of corporate-controlled IoT—from devices being turned into ‘bricks’ to the sustainability challenges facing ‘open-source alternatives’. But what if the bigger danger isn’t just that your smart device will stop working, but that it’s working all too well—just not for you? This post dives into the pervasive, built-in surveillance that has become a standard feature in so-called ‘smart’ devices.

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.