What is MeshCore?

MeshCore is an open-source, off-grid communication system built around LoRa radio. It allows people and devices to exchange short messages across long distances without relying on cellular service, Wi-Fi, internet access, or centralized infrastructure.

Messages can travel directly between nearby radios or move across multiple strategically placed repeaters. This allows a community-operated network to cover areas far beyond the range of a single device while remaining decentralized and resilient.

MeshCore is designed primarily for text, location, telemetry, and other small packets of information. LoRa provides excellent range and low power consumption, but it is not intended for voice, images, or high-speed data.

Unlike networks where every portable radio repeats every packet, MeshCore assigns devices specific roles. This helps reduce unnecessary radio traffic and prevents poorly positioned mobile devices from becoming unreliable routing paths.

MeshCore is free, open source, and released under the MIT License. The firmware supports a growing selection of LoRa-equipped development boards and purpose-built radios.

Companion Nodes

A Companion is the radio a person normally carries and uses to communicate with the mesh.

The Companion connects to the MeshCore application using Bluetooth, USB, or Wi-Fi, depending on the hardware and firmware. The application provides the user interface for discovering contacts, exchanging direct messages, joining channels, and managing the radio.

Companions send and receive messages, but they do not normally relay traffic for other users. This allows portable devices to move freely without disrupting established routes through the network.

If you are new to MeshCore, a Companion is usually the best place to begin.

Repeaters

Repeaters provide the infrastructure that extends the mesh.

A repeater receives eligible MeshCore packets and forwards them toward their destinations. Messages can pass through several repeaters, allowing two Companion nodes to communicate even when they cannot hear each other directly.

Repeater performance depends heavily on location, antenna quality, terrain, and elevation. A modest radio installed high above the surrounding area can provide significantly more useful coverage than a powerful radio placed indoors or near the ground.

Repeaters are typically installed at fixed locations with reliable power, weather protection, and a properly tuned antenna. Solar-powered repeaters can provide coverage where utility power and internet access are unavailable.

Unlike simple flooding systems, a MeshCore repeater does not blindly rebroadcast every packet it hears. MeshCore uses discovered paths and controlled forwarding to move traffic more efficiently.

Room Servers

A Room Server is a persistent shared space on the mesh—similar to a small bulletin board or an extremely lightweight mail server.

Normal channel traffic must be received when it is transmitted. If a user is offline or out of range, that transmission may be missed. A Room Server stores posts so users can connect later and retrieve messages they have not previously seen.

Room Servers are useful for:

  • Community discussions
  • Event coordination
  • Announcements and status updates
  • Emergency information
  • Persistent conversations between roaming users

Although Room Server firmware can be configured to repeat packets, the MeshCore documentation recommends running Room Servers and Repeaters on separate devices. Each can then perform its intended job without compromising the features or reliability of the other.

Observers

An Observer listens to MeshCore activity and reports what it can hear to an analysis or visualization platform.

Observers can help operators understand:

  • Which nodes are visible from a location
  • What repeaters carried a packet
  • The route a message took through the mesh
  • Signal strength and radio conditions
  • Network coverage and connectivity
  • Repeater health and activity

An Observer is not necessarily a separate radio firmware role. A Companion, Repeater, or Room Server may supply observations to external software, depending on the system being used.

Observers are extremely useful for testing and improving a network, but they should be operated thoughtfully. MeshCore can protect message contents with encryption, but radio activity and routing metadata may still reveal that devices are present and communicating.

Standalone Nodes

A traditional Companion uses a phone or computer as its display and keyboard. Standalone devices combine the LoRa radio, screen, controls, and messaging interface into a single unit.

Devices such as supported LilyGo T-Deck and pager-style hardware can operate without a paired phone. They provide a self-contained off-grid communicator that is especially useful at events, in the field, or anywhere a phone is inconvenient.

Channels and Direct Messages

MeshCore supports several ways to communicate:

Direct messages are addressed to a specific contact and can be routed across the mesh.

Public channels allow multiple users with the appropriate channel configuration to participate in a shared conversation.

Private channels use a shared secret so a defined group can communicate privately.

Room Server posts provide persistent shared messages that users can retrieve after reconnecting.

Each serves a different purpose. Direct messages are best for person-to-person communication, channels are useful for live group traffic, and Room Servers are useful when messages need to remain available for users who were offline.

Sensors and Custom Projects

MeshCore is more than a chat application. Its routing library can be incorporated into custom embedded projects that exchange small amounts of data over LoRa.

Possible uses include:

  • Remote weather stations
  • Environmental sensors
  • Equipment status monitoring
  • Location beacons
  • Alarm and alert systems
  • Event badges
  • Infrastructure monitoring
  • Custom gateways and automation

The project also includes examples for sensor nodes, secure terminal chat, Companion radios, Repeaters, Room Servers, and KISS modem interfaces. Because MeshCore is open source, developers can build new hardware and applications around the protocol.

Getting Started

To join a MeshCore network, you generally need a supported LoRa radio, Companion firmware, and the MeshCore application.

  1. Choose a radio supported by the MeshCore firmware.
  2. Use the web flasher to install Companion firmware.
  3. Connect the radio to the MeshCore app.
  4. Select the correct regional radio preset.
  5. Discover nearby nodes or coordinate settings with your local community.
  6. Begin exploring the mesh.

All radios that need to communicate must use compatible frequency and LoRa settings. Always use frequencies and transmit-power levels permitted in your region.

MeshCore Resources

Note > Links will be to meshcore.co.uk that we use the most. You will also find valid links to meshcore.io. We predominantly use the .co.uk site.

MeshCore is still evolving, and features, supported hardware, and recommended configurations can change. Check the official documentation and firmware repository before building or deploying permanent infrastructure.

How Is MeshCore Different from Meshtastic?

MeshCore and Meshtastic use much of the same LoRa hardware and solve a similar problem: exchanging messages without cellular service or internet access. MeshCore is not simply a newer version of Meshtastic, however. It uses a different network architecture designed around dedicated infrastructure, discovered routes, and efficient direct messaging.

Meshtastic is excellent for quickly creating an ad-hoc network. Most devices can participate in forwarding traffic, making it easy for a group to turn on their radios and form a mesh with little planning.

MeshCore takes a more structured approach. Portable Companion nodes communicate through deliberately placed Repeaters, while Room Servers provide persistent message storage. This requires more planning, but it can create a cleaner and more predictable network as the number of users grows.

Path-Based Routing

The most important difference is how direct messages travel across the network.

When MeshCore does not yet know how to reach a contact, it initially floods the message through available Repeaters. The recipient returns a delivery report containing the successful route. MeshCore stores that route and embeds it into later direct messages.

Only Repeaters named in that path retransmit the packet. Other Repeaters hearing the same transmission remain silent. If the stored path stops working, MeshCore can retry and use flooding to discover a new one. This reduces unnecessary transmissions and helps preserve limited LoRa airtime.

Group channels are an exception: because a group message has multiple possible recipients, channel traffic still uses flooding.

Dedicated Node Roles

MeshCore separates devices according to their purpose:

  • Companions belong to users and do not relay other users’ messages.
  • Repeaters are deliberately positioned to provide reliable routing.
  • Room Servers store shared posts for later retrieval.
  • Standalone Nodes provide messaging without requiring a phone.
  • Observers monitor and analyze network activity.

Preventing portable Companion nodes from repeating traffic keeps routing from depending on radios that may be moving, powered off, indoors, or placed in poor locations. The network instead relies on known infrastructure installed where it can provide dependable coverage.

Persistent Room Servers

MeshCore’s Room Server is another major distinction. It operates like a lightweight bulletin board or mail server, storing posts for users who are offline or outside coverage.

A user can reconnect later and retrieve previously unseen posts. This is different from ordinary live channel traffic, which may be missed if the receiving radio is unavailable when the message is transmitted.

Less Routine Network Chatter

MeshCore Companions advertise themselves when directed by the user rather than continuously acting as routing infrastructure. Repeaters publish their own scheduled advertisements, and administrators can control how far flooded traffic is allowed to travel.

Combined with learned routes and fixed node roles, this gives network operators more control over radio utilization—an important consideration because LoRa has very limited bandwidth.

Which One Is Better?

Neither system is universally better. They are optimized around different priorities.

MeshCoreMeshtastic
Structured, infrastructure-oriented networkFast, flexible ad-hoc deployment
Dedicated Repeaters carry routed trafficUser nodes can participate in mesh forwarding
Learned paths for later direct messagesPrimarily broadcast/flood-oriented forwarding
Companion nodes do not repeatPortable nodes can help extend the mesh
Persistent Room ServersPrimarily live messaging and telemetry
Well suited to planned community networksWell suited to mobile groups and casual deployment

Meshtastic may be the better choice when a group wants to distribute radios and establish communication immediately without installing dedicated infrastructure.

MeshCore becomes especially compelling when building a permanent community network with carefully placed Repeaters, efficient direct-message routing, persistent Room Servers, and tools for observing how traffic moves through the system.

It is less of a replacement for Meshtastic and more of a different answer to the same problem: how do we communicate when the infrastructure we normally depend on is unavailable?

Decentralize. Connect. Resist.

Follow the signal.