Down the LoRa(bbit) Hole: From Meshtastic to Reticulum

It all started quite innocently, during a NixOS meetup last year. A friend of mine (Hello Theo!) showed off his new SenseCap Tracker T1000E running Meshtastic, and that was it ! My curiosity was well and truly piqued. I have been exploring the world of LoRa and “off-grid” networks ever since, and what a journey it has been. I thought it was a good time to write down my experiences, so here’s a look at how a curiosity turned into some kind of full-blown obsession.

Dipping My Toes into Meshtastic

To get the ball rolling, I decided to start with Meshtastic, an open-source “off-grid” messaging platform for LoRa networks. It seemed like the perfect entry point. I picked up a pair of WisMesh Tags just to run some basic tests and see what all the fuss was about. During a trip to Italy, I was so impressed to see that I could communicate with my family from the plane without any trouble. I was also receiving signals from other Meshtastic users on the ground. Such a small device, yet it could reach so far. I was hooked. The WisMesh Tag worked brilliantly, but as is always the way with these things, I immediately wanted more range and better network coverage.

Building the Solar Relay Node

If I was going to do this properly, I needed to extend the Meshtastic network. This meant gathering some hardware to build my own relay node. Here’s the kit I ended up putting together:

• A MikroTik 868 Omni Antenna
• A RAK4631 core module sitting nicely on a RAK19003 base board
• An environment sensor RAK1906 to monitor the temperature, humidity, pressure, and air quality
• A 3000mAh battery
• A Unify enclosure with a built-in solar panel
• A window suction mount

After some tinkering, I had my Meshtastic relay up and running. I mounted it on my Velux window with the window suction mount, where it is happily ticking away 24/7… well, mostly… Belgium weather has other ideas :)

The Belgian weather is the real bottleneck here. On days with decent sunshine, it is flawless and runs for days. But as anyone living in Belgium will tell you, those days are not exactly guaranteed. The 3000mAh battery is just a bit too small to bridge the gap during our gloomy stretches, so the node occasionally drops offline from a lack of light. Worry not because an upgrade to a beefy 10000mAh battery is on my to-do list in the upcoming days… but let’s be honest, given the crazy heatwaves we have been experiencing in Belgium lately, there hasn’t been much of a problem. The node has been running flawlessly for weeks now.

Falling into the Reticulum Abyss

As if Meshtastic wasn’t enough to keep me occupied, I stumbled upon the Reticulum project. And… oh boy, that was an absolute game-changer. It is a proper bottomless pit of fascinating tech.

While Meshtastic is a great project, it is a bit limited in its scope. Reticulum, on the other hand, is a full-fledged mesh networking stack that can be used to build all sorts of applications. For example, Reticulum can be used to provide the same feature set as Meshtastic. The possibilities are endless, and I am having a blast exploring them.

I have been buying and mounting devices left, right, and centre, and running tests everywhere I can. It has been a fascinating process to understand how everything routes and communicates.

After wrapping my head around the basics, the concepts, and the terminology, I finally managed to set up a small Reticulum network at home.

After that, I started investigating how to make a public node that would contribute to the wider network. To do that, a couple of requirements had to be met to align with NixOS standards and practices, as further explained in the next section.

In practice, anyone can run a Reticulum node, and no specific hardware is required: running the rnsd daemon with a proper configuration is enough to contribute to the network. Once you have a node up and running, you can also run the lxmd daemon (from the LXMF project) to provide a local messaging service for your Reticulum network. This allows you to send and receive messages from other nodes. The lxmd daemon is also a great way to test your setup and confirm everything is working properly.

As if all of this were not enough, I decided to build a public LoRa and TCP gateway to contribute to the Reticulum network. Reticulum is a mesh network after all, and the more nodes there are, the better the network becomes! :D

So I decided to buy a new set of things:

• A RAK4631 core module sitting on a RAK19007 base board
• An ethernet module RAK13800 and its PoE module RAK19018
• An environment sensor RAK1906 to monitor the temperature, humidity, pressure and air quality
• A NOR flash module RAK15001 required for microReticulum
• A Unify enclosure without solar panel
• A couple of 10000mAh batteries to increase the uptime of the node during the gloomy Belgian weather
• Another window suction mount. Actually, I have 2 Velux windows, so I can keep 2 nodes up and running at the same time: the more, the merrier!

I initially bought these devices because I had seen ethernet support land in a PR. Sadly, the PR has been closed and I am unable to use the ethernet module with the most up-to-date firmware as of today. I hope proper ethernet support lands in microReticulum one day, but for now I am stuck using the USB serial interface to connect to my node.

I love the Reticulum project, but I am a bit sad to see so much fragmentation in its ecosystem. There are many implementations of Reticulum itself, and many of RNode, the Reticulum firmware to install on real hardware. Unlike Meshtastic, there is no central repository or place to find all the different implementations of RNode. I hope that in the future, the Reticulum project will be able to unify its ecosystem and provide a more cohesive experience for users.

Reticulum works very differently from Meshtastic, and it is a bit more complex to set up because the physical device does not own the user identity; instead, the identity is generated by the Reticulum software itself running on your device. This paradigm shift is great, but it requires a bit more work to set up. As an example, it is harder to set up an autonomous RNode on your roof simply because a RNode alone is not very useful without a running rnsd (Reticulum Network Stack daemon) operating it.

That said, there is an alternative firmware called microReticulum, which lets you run an autonomous RNode on a microcontroller without relying on an external rnsd instance. It is a promising approach, my favorite, and it is the one I use by default. Once deployed on your hardware, it removes the need for a separate daemon, because the Reticulum stack runs directly on the chip. This is similar in spirit to how Meshtastic works, though the architecture is not exactly the same. A microReticulum-powered node can operate in host-controlled mode like a regular RNode, but it can also be switched to transport mode. In transport mode, it runs the embedded microReticulum stack directly on the microcontroller and autonomously routes packets for other Reticulum nodes on the LoRa mesh.

One of the biggest frustrations I had was seeing a bit of smoke come out of one of my RAK boards just after plugging in the new 10000mAh battery. I was so excited to see my Reticulum node up and running that I did not check the polarity of the battery, a rookie mistake. Needless to say, I learned my lesson.

So, after a broken board, a few other broken expectations and attempts, a lot of tinkering… I finally managed to get my Reticulum node up and running.

The roof node acts as a transport node on the LoRa mesh and communicates with another node at home, connected to a local server over USB. That home server is then bridged to the internet, allowing me to seamlessly link the LoRa mesh with the wider Reticulum network.

On top of exploring the arcana of this project and tinkering with the hardware, I have also been exploring the various applications that can be used to communicate over Reticulum. I have been testing Columba, Ratspeak, Reticulum Mobile App, Retichat, Sideband, Nomadnet, Meshchat, MeshchatX, … Most of these implementations use the Reticulum reference implementation in Python, and I can’t wait to see better alternatives in the future. Not that Python is bad (erm erm!), I believe it is a great language for prototyping, but I also think that better implementations in other languages will be needed to make Reticulum much more efficient, especially on smartphones.

My wish list for the future of Reticulum is a more unified ecosystem: an alternative implementation in a compiled language, a more coherent set of applications for communicating over Reticulum, and a clearer path for contributing to the core project. Open source should give users the freedom to choose the implementation that best suits their needs, but not at the expense of the project’s overall health. I do not really know the details behind why the GitHub repository for Reticulum is no longer open to contributions, but I hope that, in the future, it will become easier to contribute to the project and help it grow while keeping the core stable, secure, and aligned with the vision of its original author, Mark Qvist.

I also hope for broader hardware support, especially for the RAK13800 ethernet module and the RAK1906 environment sensor. I hope the microReticulum project will continue to grow and evolve into an even more robust and reliable implementation of Reticulum for microcontrollers.

Giving Back

I have always believed that if you are going to use open-source projects heavily, you ought to give something back when you can. Since NixOS is my daily driver, I focused my efforts there in the Nix ecosystem.

For Meshtastic, I introduced firmware builds. It is also now entirely possible to build the firmware straight from source (#466509).

For Reticulum, the work is ongoing but very exciting. I currently have two new modules (rnsd and lxmd) in the works (#530406). Introducing these modules required the introduction of a new formatter for Nix code so that the configuration files for Reticulum (using configobj format) could be generated from Nix code. It was a very exciting development, as it was the first time I had to write a custom formatter for Nix code. Lastly, I have also contributed by adding various tools and implementations of Reticulum like Reticulated, Leviculum, Reticulum-go, rs-reticulum, rs-lxmf, lxmf-rs, rns-proxy, reticulum-group-chat, …

What’s Next?

Honestly, I am having the time of my life messing about with all this. There is always a new device to test, a new configuration to try, a new RNode firmware version to deploy… or another bit of code to package in Nix.

If you are on the fence about getting into LoRa, consider this your sign to just go for it. Grab a couple of nodes (it is not that expensive… erm, wait!), set them up, and see where the rabbit hole takes you!