Meshtastic (MT) and Meshcore (MC) both use small handheld LoRa radio units that connect to smartphones via Bluetooth, allowing users to send short text messages without relying on cellular service or the Internet. Because Bluetooth works independently of phone networks, both systems function even when infrastructure is down.
Meshtastic creates an ad hoc mesh network where every node acts as a repeater. Its repeating algorithm prioritizes nodes that receive the weakest signal; those nodes repeat first, while nodes that received a stronger signal stay silent if they hear the weaker node repeat. In theory, this helps distant nodes extend the network.
In practice, this behavior can cause messages to travel in one direction but not another, making communication inconsistent. Consider the following scenario:
![]() |
|
|
A group of Meshtastic nodes is arranged as in the above illustration. Node A sends a message. Node B receives a strong signal from Node A, so it waits to see if another node will repeat the message before repeating it itself. Node C, however, receives a weak signal from Node A, so it repeats the message sooner than Node B. When Node B hears the weak repeat from Node C, it decides not to repeat the message at all.
The message then propagates only to the nodes on the right side of the network. Node D is too far from Node A to receive the original message, and it is even farther from Node C. Node B could have relayed the message to Node D, but because Node B never repeats, Node D and all nodes beyond it never receive the message.
You can configure a Meshtastic node as a dedicated repeater, which repeats every packet it hears. In the scenario above, placing a dedicated repeater near Node B would solve the problem. However, Meshtastic is limited to seven hops. Adding too many repeaters can consume all available hops and trap messages within a small geographic area.
Real-World Example
I had two nodes about a mile apart that couldn't communicate due to terrain. I placed a third node halfway between them. Even though both end nodes could reach the larger network, they still couldn't reach each other. The midpoint node wasn't repeating, likely because it heard a distant repeater first, and that repeater was out of range of the second end node.
When I reconfigured the midpoint node as a dedicated repeater, communication became reliable. Adding another dedicated repeater at the community library on Atlas View Drive provided solid coverage throughout Santee.
This illustrates that Meshtastic often requires dedicated repeaters for reliability, but adding too many can create "black holes" where messages can't escape due to the hop limit.
Like Meshtastic, Meshcore nodes can communicate directly if they are close enough, often several miles with clear line of sight. However, Meshcore companion nodes cannot repeat. Only dedicated repeaters extend the network.
Meshcore's repeaters use a more advanced routing algorithm that determines the best path from one repeater to the next. Meshcore also supports up to 64 hops, far beyond Meshtastic's limit. In practice, networks rarely come close to using that many.
Meshcore is not perfect, but it has proven significantly more reliable than Meshtastic (direct messagesthose addressed from one node to anotherare more reliable than those broadcast messages on a channel). Despite being less than a year old, many users are migrating from Meshtastic to Meshcore because of its stability and long-range performance.
I routinely receive messages from the Los Angeles area. One message relayed from a repeater on the jetty in Port Hueneme; others have come from Victorville. Long-distance reliability is still being evaluated, but the results so far are impressive.
Here is a comparrison table
| Feature / Behavior | Meshtastic (MT) | Meshcore (MC) |
|---|---|---|
| Basic Function | LoRa texting via Bluetooth-connected nodes | LoRa texting via Bluetooth-connected companion nodes |
| Repeating Behavior | Every node can repeat (mesh) | Only dedicated repeaters repeat |
| Routing Algorithm | Weak-signal nodes repeat first; can cause one-direction routing | Repeaters calculate best path between repeaters |
| Hop Limit | 7 hops maximum | 64 hops maximum |
| Reliability | Can be inconsistent; messages may not reach all directions | Generally more reliable, especially over long distances |
| Dedicated Repeaters | Optional but often required for stability | Required; companions never repeat |
| Risk of "Black Holes" | High if too many repeaters consume hop limit | Low due to high hop limit and controlled repeater behavior |
| Best Use Case | Small groups in close proximity (e.g., campsites) | Large-area, long-range, community networks |
| Long-Distance Performance | Limited by hop count and routing quirks | Capable of very long paths; messages often travel across counties |
| Maturity | Older, widely used | Newer but rapidly growing |
| User Migration Trend | Many users switching away due to reliability issues | Increasing adoption due to stability and range |