MeshCore is an open-source, LoRa-based communication system for exchanging text messages without mobile service, Wi-Fi or conventional internet infrastructure.
Unlike systems in which almost every device automatically relays traffic, MeshCore assigns different jobs to different devices. A radio normally operates as one of three main types:
- Companion — connects a person to the network
- Repeater — forwards packets and extends network coverage
- Room server — stores shared messages so users can retrieve them later
This separation makes it easier to build an organized network in which personal devices remain personal, repeaters are installed at useful locations and message services are operated deliberately.
How a MeshCore network works
Each user needs a MeshCore radio. Depending on the device and firmware, the radio connects to a phone or computer, or provides its own screen and controls.
When two users are within direct radio range, their devices can communicate without additional infrastructure. If they are farther apart, messages can travel through one or more MeshCore repeaters.
A simplified message path may look like this:
Companion → repeater → repeater → companion
Room servers add another function:
Companion → repeater → room server
The room server can store shared posts until a user connects and retrieves them.
MeshCore does not require an internet connection or a central network operator. Internet services may provide maps, firmware downloads and community coordination, but the radio network itself can continue operating without them.
MeshCore device roles at a glance
| Device type | Primary purpose | Used directly by a person? | Relays network traffic? | Stores shared messages? |
|---|---|---|---|---|
| Companion | Personal messaging and network access | Yes | Normally no | Only local messages |
| Repeater | Extending coverage | No | Yes | No |
| Room server | Shared, retrievable message room | Indirectly | Not recommended as its main role | Yes |
| Standalone communicator | Personal messaging without a phone | Yes | Depends on its firmware and mode | Only local messages |
A single hardware model may support several firmware types, but it normally performs one role at a time. Changing its role generally means installing different firmware.
Companion nodes
A companion is the user-facing radio in a MeshCore network.
The MeshCore app runs on a phone, tablet or computer and connects to the companion radio using Bluetooth, USB or, on supported firmware and hardware, Wi-Fi. The radio handles LoRa communication while the app provides the messaging interface, contacts, channels, map and configuration.
Every person who wants to use the network normally needs their own companion node.
What a companion can do
A companion can be used to:
- Discover nearby MeshCore users and infrastructure
- Send and receive direct messages
- Join public or private channels
- Send and receive position information
- Connect to room servers
- View known repeaters and message paths
- Manage contacts and cryptographic identities
- Remotely administer authorized repeaters and room servers
- Change radio parameters and regional presets
MeshCore direct messages and private channels are designed for encrypted communication. Repeaters forward the packets but do not need to read the message contents.
Companion connection types
MeshCore provides several companion firmware variants.
Bluetooth companion
The radio connects to the MeshCore mobile app over Bluetooth Low Energy.
This is the usual choice for a portable personal node because the phone provides the screen, keyboard, map and user interface.
USB companion
The radio connects to a computer or compatible mobile device through USB serial.
This can be useful for:
- Desktop operation
- A permanently installed home station
- Devices without reliable Bluetooth
- Web and command-line clients
- Development and integration work
Wi-Fi companion
Some supported devices and firmware builds can connect to a client over Wi-Fi. Availability and behaviour depend on the hardware and current firmware.
Check the current options for your device in the official MeshCore flasher.
Do companion nodes repeat messages?
Ordinary companion nodes do not act as general network repeaters.
This is an intentional MeshCore design decision. Personal radios move, switch off, enter buildings and frequently change their radio visibility. Building important routes through them would make those routes unstable.
Keeping repeating traffic on dedicated infrastructure also reduces unnecessary retransmissions and allows network builders to place relays where they provide real value.
Some firmware versions may offer limited or specialized repeat modes, but these should not be confused with a dedicated public repeater. For permanent network coverage, use repeater firmware on a separate device.
Standalone MeshCore devices
A companion radio is not the only way to use MeshCore.
Supported devices with their own screen, controls and keyboard can provide a complete messaging interface without a connected phone. Examples include several LilyGo T-Deck-family devices and other hardware supported by MeshCore’s standalone firmware.
These are still user devices rather than unattended infrastructure. They allow a person to discover contacts, exchange messages and use network services directly from the radio.
Repeaters
A MeshCore repeater is a dedicated infrastructure node that forwards packets between devices which cannot communicate directly.
Repeaters are what turn separate local radio links into a wider multi-hop network.
A repeater may connect:
- Two sides of a town
- A valley with an elevated ridge
- Several neighbourhoods
- Rural users with an urban network
- Portable users with distant infrastructure
- Two or more existing repeater coverage areas
MeshCore repeaters do not repeat everything
A MeshCore repeater does not simply retransmit every packet it hears.
MeshCore uses a hybrid routing system. Direct messages can use learned paths through particular repeaters, while some discovery and group traffic may be flooded more broadly. This reduces unnecessary traffic compared with a network where every node rebroadcasts every eligible packet.
The distinction is important: installing more repeaters does not automatically produce a better network. Too many overlapping or poorly coordinated repeaters can consume scarce radio airtime and create collisions.
Where should a repeater be installed?
Repeater placement is usually more important than raw transmitter power.
Good locations include:
- Hilltops and mountain sites
- Tall buildings
- Radio towers
- Elevated rural properties
- Sites overlooking populated valleys
- Buildings with clear line of sight in several directions
- Locations connecting two otherwise separated coverage areas
Poor locations include:
- Indoor rooms at ground level
- Metal cabinets without an external antenna
- Basements
- Dense groups of repeaters covering exactly the same area
- Mobile vehicles presented as permanent infrastructure
- Sites with high cable loss or unsuitable antennas
A modest repeater with a clear radio horizon can outperform a much more powerful station installed in a poor location.
What a repeater installation needs
A permanent repeater normally includes:
- A MeshCore-supported LoRa device
- Repeater firmware
- An antenna appropriate for the legal regional band
- A short, low-loss antenna connection
- Reliable USB, battery or solar power
- Weatherproof housing for outdoor installations
- Protection from moisture and condensation
- Secure mounting
- Correct regional radio configuration
- A unique and useful node name
- Changed administration credentials
- Documented coordinates, owner and maintenance contact
Remote solar sites may additionally need:
- A solar panel
- Charge controller
- Battery with adequate winter capacity
- Low-temperature battery protection
- Surge or lightning protection
- Physical access planning
- Remote monitoring where practical
Do repeaters need internet access?
No. A MeshCore repeater forwards LoRa traffic directly and can operate without the internet.
Internet access may be convenient for monitoring, time synchronization or remote site management through additional systems, but it is not required for the basic radio network.
Coordinating a public repeater
Before installing a permanent repeater, contact the existing MeshCore community in your area.
Confirm:
- The regional frequency and radio preset
- Whether your location adds useful new coverage
- Existing repeater locations
- Naming conventions
- Whether exact or approximate coordinates should be published
- Administration and recovery arrangements
- Who can physically access the device
- Applicable power, antenna and duty-cycle limits
A coordinated repeater is community infrastructure. An uncoordinated one may merely duplicate coverage or interfere with an established configuration.
Room servers
A MeshCore room server is a radio-based bulletin board or shared message service.
Normal channels are live radio conversations. If a message is transmitted while a user is offline or out of range, that user may miss it.
A room server stores posts. Users can connect later and retrieve messages they have not previously received. This makes a room server closer to a small off-grid forum, bulletin board or mail service than an ordinary live channel.
According to the current MeshCore documentation, a client logging into a room server can receive up to the previous 32 unseen messages.
What a room server is useful for
Room servers can support:
- Local community notices
- Regional MeshCore discussions
- Trail, route or weather reports
- Event coordination
- Emergency volunteer information
- Technical help
- Repeater status notices
- Asynchronous messages for roaming users
- Shared information in places without internet access
For example, a hiker who was outside radio range during the morning could later reach the room server and retrieve recent posts.
Room server versus channel
| Channel | Room server |
|---|---|
| Messages are transmitted live | Posts are stored by the server |
| A disconnected user may miss a message | A user can retrieve unseen posts later |
| No dedicated server is required | Requires a device running room-server firmware |
| Useful for immediate group conversation | Useful for asynchronous community discussion |
| Traffic is sent through the mesh when posted | Retrieval creates additional exchanges with the server |
A room server does not replace direct messages or channels. It adds a different communication model for information that should remain available after its original transmission.
Can a room server also be a repeater?
Room-server firmware can offer a repeat setting, but the official documentation does not recommend using a room server as the main network repeater.
A room server with repeating enabled does not provide the complete repeater feature set. Combining both functions may also make an important messaging service compete with relay traffic on the same radio.
For a reliable public installation, use:
- One device as the repeater
- A separate device as the room server
They can be installed at the same site if that location provides good radio coverage, but each should retain its dedicated role.
Who should operate a room server?
A room server makes sense when there is already a group of users who would benefit from stored community messages.
The operator should be prepared to:
- Choose an appropriate name and purpose
- Set a secure administration password
- Decide whether access is public or restricted
- Set or change the guest password
- Keep the firmware current
- Maintain stable power
- Explain basic usage to the local community
- Establish rules for inappropriate content
- Consider privacy before publishing its exact location
- Monitor whether the server creates excessive radio traffic
A room server is a service, not merely another dot on a map.
What is an advert?
Before users can send direct messages, their devices need to learn about one another.
MeshCore uses an advert to announce a node’s identity. An advert can include its name, public key and, when enabled, location.
Two common advert modes are:
- Zero-hop advert — heard only by devices within direct radio range
- Flood advert — eligible repeaters forward it through the mesh
Companion adverts are normally initiated by the user. Repeaters can advertise themselves periodically so clients can discover the infrastructure.
Flood adverts use shared airtime, so they should be used deliberately rather than repeatedly pressed in the hope of improving reception.
How messages travel
MeshCore can deliver traffic in different ways depending on the message type and the information already known by the sender.
Direct messages
Direct messages are addressed to a particular contact. The network can learn and use a path through selected repeaters instead of asking every available node to retransmit every message.
Delivery acknowledgements can confirm that a message reached its destination, although radio conditions can still cause delays or failures.
Channels
Channels allow group communication. Public and private channels may use broader transmission behaviour than routed direct messages because a channel message can have multiple unknown receivers.
Room-server posts
A client connects to a particular room server, sends or retrieves posts and receives stored messages through the available radio path.
Choosing the right role
For most beginners, the decision is simple:
Choose a companion if:
- You want to send messages
- This is your first MeshCore device
- You want to connect a radio to your phone or computer
- You need a portable personal node
- You want to discover the existing local network
Choose a repeater if:
- You already understand the local radio settings
- You have a genuinely useful elevated location
- The community needs additional coverage
- The device will remain powered and stationary
- You can maintain the installation
Choose a room server if:
- A local community already uses MeshCore
- Users need messages to remain available
- You can operate and maintain a shared service
- The server has reliable access to the existing repeater network
- Its purpose and access rules are clear
If you have only one device, start with a companion. Do not begin by installing a repeater unless you already know which network you are joining and what coverage problem you are trying to solve.
How many devices do you need?
One device
Install companion firmware and connect to any existing MeshCore users and repeaters within range.
Two devices
If there is no nearby infrastructure, use both as companions to test direct communication between two people.
If an established network already exists, one device can be your companion and the other can become a repeater at a useful fixed location.
Three or more devices
A small independent deployment might contain:
- Two companion nodes
- One elevated repeater
A community deployment might contain:
- Many personal companions
- Several coordinated repeaters
- One or more room servers
Coverage should grow in response to actual needs and terrain, not simply the number of devices available.
Basic setup
- Check which frequency band and radio settings are legal in your country.
- Find the MeshCore community nearest to you.
- Ask which regional preset the local network uses.
- Choose a supported LoRa device.
- Open the official MeshCore web flasher.
- Select the correct hardware.
- Install companion, repeater or room-server firmware.
- Configure the same radio parameters used by the local network.
- Give the device a recognizable name.
- Change all default administration and access passwords.
- Connect a companion to the MeshCore app.
- Send an advert and discover nearby contacts and infrastructure.
- Test direct and multi-hop communication.
- Document any public repeater or room server you operate.
Repeater and room-server devices can be initially configured over USB using the official web configuration tool. Remote administration over LoRa is also available through supported MeshCore clients and configurations.
Radio settings must match
Two MeshCore devices must use compatible radio parameters to communicate, including:
- Frequency
- Bandwidth
- Spreading factor
- Coding rate
- Network or regional configuration
Using MeshCore firmware on both devices is not enough if their radio settings differ.
Do not invent a local configuration when an established community already exists. Matching the regional community helps users discover one another and prevents the area from becoming fragmented into several incompatible networks.
Legal considerations
MeshCore commonly operates in licence-exempt radio bands, but these bands remain regulated.
Rules vary by country and may restrict:
- Frequency
- Transmitter output
- Effective radiated power
- Antenna gain
- Duty cycle
- Channel occupancy
- Permitted equipment
- Installation type
The software may allow values that are not legal at your location. The operator is responsible for selecting the correct regional settings and complying with local regulations.
Do not assume that settings used in another country are valid in yours.
Security and privacy
MeshCore is designed to support encrypted communication, but secure operation also depends on the user and network operator.
Good practice includes:
- Change default server passwords immediately
- Protect device private keys and configuration backups
- Verify important contacts through a trusted method
- Do not publish sensitive coordinates unnecessarily
- Treat public channels and public rooms as public spaces
- Use private channels only with people who should possess the shared channel secret
- Keep firmware and client applications current
- Avoid placing personal details in node names
- Establish moderation rules for community room servers
Encryption protects message content in transit, but it does not make radio activity invisible. Nearby receivers may still observe that transmissions are taking place and collect technical metadata.
MeshCore is not Meshtastic
MeshCore and Meshtastic both use LoRa radios for off-grid messaging, but they are separate systems.
| MeshCore | Meshtastic |
|---|---|
| Uses distinct companion, repeater and room-server roles | Most ordinary client nodes can participate in packet relaying |
| Companions normally do not relay general mesh traffic | Client nodes may forward eligible traffic |
| Supports dedicated room servers with stored posts | Primarily provides channels, direct messages and optional store-and-forward features |
| Emphasizes learned or selected paths for direct traffic | Primarily uses managed flooding |
| Uses MeshCore firmware and clients | Uses Meshtastic firmware and clients |
A device may be supported by both projects, but it cannot join both networks at the same time with a single radio running one firmware image.
Adding MeshCore infrastructure to MeshAtlas
MeshAtlas distinguishes between the different MeshCore roles because they provide different public value.
A MeshCore listing should identify whether the station is a:
- Companion node
- Public repeater
- Private repeater
- Room server
- Standalone user device
- Experimental or temporary installation
Public infrastructure listings should ideally include:
- Station name
- Device role
- Country and region
- Exact or approximate location
- Coverage description
- Frequency band
- Community or network name
- Operational status
- Power source
- Antenna type and height, when appropriate
- Maintainer or community contact
- Last verification date
- Access instructions for room servers
- Links to coverage tests or local documentation
Personal companion locations should remain private by default. MeshAtlas should primarily map stable public infrastructure and communities, not reveal where individual users live.
Start with a companion, build infrastructure together
For most people, the best first MeshCore device is a companion.
Use it to discover whether a network already exists, learn how radio propagation behaves in your area and meet the people maintaining local infrastructure. Only then decide whether another repeater or room server would improve the network.
The most useful MeshCore deployments are not necessarily those with the most devices. They are the ones with well-positioned repeaters, reliable services, compatible settings and an active community that coordinates its infrastructure.