Meshtastic is not the only project using LoRa (Long Range), a low-power radio modulation technique, for communication beyond mobile and Wi-Fi coverage. MeshCore, Reticulum and several smaller experimental projects use similar radios for messaging, sensors or resilient networking.
However, sharing the same type of radio does not make these systems interoperable. They are more like different languages spoken over the same kind of walkie-talkie: the hardware may be capable of transmitting the signal, but the software does not automatically understand the packets.
MeshCore companions, repeaters and room servers
MeshCore is an open-source system for secure text communication over LoRa. It uses distinct firmware roles for personal devices and network infrastructure. Its official documentation describes companion radios, repeaters and room servers as separate parts of the network. [MeshCore FAQ]
Companion
A companion is the user-facing radio. It connects to a phone, tablet or computer through Bluetooth or USB, allowing the user to send and receive messages with a MeshCore application. A companion normally does not act as a general-purpose repeater. This prevents portable or poorly positioned devices from becoming unintended routing paths. [MeshCore source and overview]
Repeater
A repeater is fixed infrastructure used to extend a MeshCore network. It forwards packets toward their destinations, but it does not simply retransmit every packet it hears. Repeaters are most useful at elevated, reliable locations where they can connect otherwise separated users or areas. [MeshCore firmware roles]
Room server
A room server provides a bulletin-board-like group space. It stores posts so that users who were offline or out of radio range can retrieve recent messages when they reconnect. This differs from an ordinary live channel, where a user may miss a transmission while unavailable. MeshCore recommends using separate devices for the repeater and room-server functions. [MeshCore room servers]
These roles make MeshCore attractive to communities that want planned fixed infrastructure, selected routes and stored group messages. For a full explanation, see MeshCore companions, repeaters and room servers.
Meshtastic and MeshCore compared
| Feature | Meshtastic | MeshCore |
|---|---|---|
| Typical personal device | A client node that can send, receive and usually relay eligible traffic | A companion that sends and receives but normally does not provide general relaying |
| Coverage infrastructure | Selected router or repeater roles, while ordinary clients can also participate in relaying | Dedicated repeaters |
| Group communication | Live channels, direct messages and optional modules | Live channels plus dedicated room servers with stored posts |
| General routing approach | Primarily managed rebroadcasting, with hop limits and role-dependent behavior | Lightweight multi-hop routing with companions excluded from normal repeating |
| Native interoperability | None: the two systems use different firmware and network protocols | |
Meshtastic radios rebroadcast eligible packets to form a mesh, while MeshCore assigns a clearer separation between user devices and infrastructure. Meshtastic devices must also share compatible regional and modem settings before they can communicate with one another. [Meshtastic introduction] [Meshtastic LoRa configuration]
Neither design is universally better. Meshtastic is convenient for informal groups in which ordinary nodes help carry traffic. MeshCore may suit a planned community network built around stable repeaters and room servers. Network size, terrain, radio congestion and the way the local community operates all affect the practical result.
Other compatible or experimental LoRa mesh systems
The word compatible needs care. A board can be supported by several projects, but only after installing the firmware for the chosen system. Radio-band support must also match the frequencies permitted in the user’s country.
Reticulum and RNode
Reticulum is a cryptography-based networking stack rather than only a LoRa messenger. It can operate over LoRa through an RNode, but it can also use Wi-Fi, Ethernet, packet-radio equipment, serial links and internet connections. Reticulum automatically builds multi-hop paths across these different interfaces and provides end-to-end encryption. [What is Reticulum?]
Applications such as Sideband use Reticulum for messaging, while other software can use it for different kinds of low-bandwidth networking. Reticulum is more flexible and more technically involved than a typical phone-plus-radio Meshtastic setup. It does not natively exchange Meshtastic packets.
Ripple
Ripple is an open-source LoRa mesh project aimed mainly at closed messaging and sensor networks. Its firmware includes pager or messenger devices, repeaters, sensors, trackers and standalone QWERTY devices on supported development boards. It is useful as an example of how LoRa mesh networks can be designed for a specific group or application rather than a large public ecosystem. [Ripple project repository]
Research and custom systems
Developers and radio enthusiasts also build experimental LoRa store-and-forward networks, sensor meshes, emergency-communication prototypes and purpose-built trackers. Some use common LoRa development boards and open radio libraries, but they may have only a small user community, limited documentation or no maintained phone application.
Before buying hardware for an experimental project, check:
- Whether its firmware is still maintained
- Which exact boards and LoRa radio chips it supports
- Whether a usable phone, desktop or standalone client exists
- Whether anyone nearby operates the same protocol and radio settings
- Whether its frequency, power and airtime settings comply with local regulations
What interoperability really means
| Type of compatibility | What it means |
|---|---|
| Hardware compatibility | The same board may be able to run Meshtastic, MeshCore or another firmware image. |
| Radio compatibility | Devices use the same frequency band and may be physically capable of hearing one another’s signals. |
| Protocol interoperability | Devices understand the same packet format, routing rules, identities and encryption. The systems discussed here do not provide this natively across projects. |
| Bridge interoperability | An external computer or service receives data from one system and translates or republishes it into another. |
A single LoRa radio normally runs one firmware system at a time. Installing MeshCore on a board that previously ran Meshtastic changes the network it joins; it does not make the board a member of both networks simultaneously.
An experimental bridge may connect two systems at the application level, but that bridge is a translator, not native interoperability. It may lose metadata, alter delivery behavior, create duplicate traffic or weaken the privacy assumptions of either network. Meshtastic’s own FAQ says other LoRa services will probably not work directly with Meshtastic, although a separately developed bridge may be possible. [Meshtastic FAQ]
LoRaWAN is also not an interoperable Meshtastic network. LoRaWAN uses gateways and network servers for low-power wide-area sensor communication, while Meshtastic uses custom LoRa peer-to-peer packets and mesh rebroadcasting. A LoRaWAN gateway does not automatically relay Meshtastic, MeshCore or Reticulum traffic. [Meshtastic: Does Meshtastic use LoRaWAN?]
Which system should you choose?
- Choose Meshtastic when you want a widely used, approachable system for short messages, positions and telemetry, especially when an existing local Meshtastic community is available.
- Choose MeshCore when your community prefers dedicated repeaters, companion devices and stored room-server posts.
- Explore Reticulum when you need a broader encrypted networking layer that can cross LoRa, local networks and other communication media.
- Explore Ripple or another experimental system when you are building a controlled network for a particular group, device or sensor application and accept a smaller ecosystem.
The most practical choice is often the system already used nearby. Two excellent but incompatible networks cannot relay one another’s messages. For public infrastructure, MeshAtlas should therefore list the protocol, radio band, modem settings and device role clearly instead of grouping every LoRa installation into one apparent network.
What to read next
- LoRa Mesh Systems Compared: Can They Talk to Meshtastic?
- MeshCore: Companions, Repeaters, and Room Servers
- Other LoRa Mesh Systems Beyond Meshtastic