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.

There is nothing quite like the mild panic of joining a meeting only to be greeted by a void where your face should be. On the latest Ubuntu 26.04 and the 24.04 LTS (Wayland), this has become a recurring theme for anyone unfortunate enough to rely on the Zoom Snap package.

You check your settings. The camera is detected. It works perfectly in Firefox. It works in Cheese. You’ve even checked the Snap permissions and everything looks “correct”. Yet, Zoom remains a stubborn black screen.

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.

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.

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.

The Siemens IoT2000 series has been a very interesting development from Siemens and it’s really encouraging to see the use of Open Source in the Automation sector definitely on the increase. And that can only be a good thing for developer productivity. Seeing a different IDE for each manufacturer of a PLC invokes some nasty memories of last century web-application development…

Unfortunately, all the documentation for these units still assumes a Windows PC. And since I have not really been using a physical Windows machine for 10+ years now, that is really slowing things down. For the last few I didn’t really have to fall back to a VM, largely due to the fact that in web-development nobody cares about OS any longer. But I have a feeling that shifting my focus to the IIoT space this VM will get a bit more useful as some of these manufacturers don’t even bother with anything but Windows and are challenged enough to keep up with Windows upgrades.