At Xebia we have a group of people that are enthusiastic about experimenting with microelectronics and IoT devices. As part of one of our long-term projects we maintain a solar-powered LoRa node on the roof of our Hilversum office.
This node powers a decentralized messaging mesh network. Your phone, paired with a companion LoRa device, can use this system to provide a WhatsApp-like experience that will still work when all normal infrastructure fails. For this reason we lovingly call this node "The Doomsday Device" or "Doomtenna".
In 2022 we posted a series of blog posts in which we explained how and why we got started with Meshtastic, described the placement of the node on the roof of our office, and explained the change from an ESP32-based device to an nRF52-based device. We have not provided any update since then, so it is time for another one.
Switching to MeshCore
The most important change since the last update has been switching to a new LoRa mesh messaging system. For the past few years we have been running Meshtastic, but recently, in January 2026, we made the switch to MeshCore.
We were immediately able to reach much longer distances. For example, from our Hilversum office we could ping one of our homes at a 60 km distance, which we were never able to do with Meshtastic.
A proper discussion about which system is better would be an entire study by itself. Still, these are the reasons why we think this worked with MeshCore and not with Meshtastic:
- the Meshtastic routing behavior is vulnerable to configuration mistakes that people are likely to make (more on that below)
- MeshCore allows for way more hops (MeshCore defaults to 64 where Meshtastic defaults to 3)
- because it works better, it attracts more users, strengthening the network
- Meshtastic presets strictly conform to airtime limits, where with MeshCore the user must consciously configure the node to be law-abiding
Routing
The routing behavior is the most interesting difference to us.
When a Meshtastic node receives a message, it waits for a while before repeating the message. This wait time has a fixed component and a random component. Both are chosen based on the role of the node.
The clever part is that a node only repeats the message if it has not heard another repeat of that same message yet. This reduces airtime, because not every node repeats every message.
The problem is that this behavior depends quite heavily on nodes being configured sensibly. If a node with bad range is configured to repeat messages very quickly, it can be the first node to repeat a message. Better nodes within its range then hear that repeat and decide not to repeat the message themselves.
So a badly placed node with an over-eager role can effectively block better placed nodes from helping. It does not need to be malicious. It only needs to be misconfigured in a way that people are quite likely to do when they think: "my node is important, so I will make it a router".
MeshCore works differently. First, normal companion nodes do not repeat messages at all. Repeating is a specific job for repeaters and room servers that have repeat mode enabled. That already removes some accidental bad routing behavior.
Repeaters in MeshCore are not prevented from repeating a message just because they heard another retransmission. For flood-routed messages, every repeater that is allowed to repeat the message will do so. That makes the routing more predictable, but it also uses a lot more airtime.
To manage airtime, MeshCore has features like regions, which decide which flood traffic repeaters should forward. More importantly, it introduces a mode in which the sender specifies the path to follow. For messages to one specific node, MeshCore does not keep flooding every message forever. The first message can use flood routing to discover a path. When the destination receives it, a delivery report comes back with the repeaters that were used. Future messages can then include that path in the packet. A repeater only retransmits the message when it matches the next hop in that path.
There is still flood traffic in MeshCore, especially for public channels and route discovery, so placement and configuration still matter. But the failure mode is different, and has more impact on availability (airtime) than on the distance a packet can travel.
To be continued
So the Doomtenna is still alive, and the network around it has become a lot more interesting since switching to MeshCore. The biggest change is not just that we got a 60 km ping, but that the routing behavior seems to fit the network we are actually building much better.
The next step is to keep using it, keep measuring it, and see whether MeshCore keeps behaving better once the network around us gets busier.
Written by

Thomas de Ruiter
Cloud Consultant with a passion for everything Cloud. Likes to automate all the things. Believes security is everyone's responsibility!
Our Ideas
Explore More Blogs
Contact




