What Is MeshCore? Companions, Repeaters, Room Servers

MeshCore is a free, open-source LoRa mesh firmware for off-grid text messaging in which ordinary user devices never relay traffic: only dedicated repeaters do. You flash a device as a companion (paired with a phone or computer app), a repeater (to extend coverage), or a room server (a message board that stores posts), and messages find their way through repeaters using flooding at first and learned paths after that.

This guide summarizes the official MeshCore repository and its documentation. LoRa Mesh Atlas is independent and not affiliated with MeshCore. If you’re deciding between systems, see Meshtastic vs MeshCore.

What MeshCore is

The README describes MeshCore as “a lightweight, portable C++ library that enables multi-hop packet routing for embedded projects using LoRa and other packet radios.” The FAQ describes it from the user’s side as “a multi-platform system for enabling secure text-based communications utilizing LoRa radio hardware,” with uses including off-grid communication, emergency response, outdoor activities, and sensor networks.

Its defining design choice, per the README: “Nodes use fixed roles where ‘Companion’ nodes are not repeating messages at all to prevent adverse routing paths from being used.”

Firmware types

You choose the node’s job when you flash it.

Companion

Companions are your personal messaging device. The FAQ describes two versions:

• BLE Companion connects over Bluetooth to the MeshCore app on Android or iOS.
• USB Serial Companion connects over USB to a phone or computer running the web client.

The README and FAQ also mention Wi-Fi companion builds on some boards. Companions don’t relay: “MeshCore clients do not repeat. This is the core of MeshCore’s messaging-first design.”

Repeater

Repeaters extend the network. The FAQ notes a repeater “does not forward or retransmit every packet it receives, unlike other LoRa mesh systems”; it forwards packets along their intended path (or floods within limits). You can’t connect to a repeater over Bluetooth. Instead you configure it over USB with the web config tool or flasher console, or remotely over LoRa from the app.

Room server

A room server is “a simple BBS server for sharing posts.” It stores message history and pushes stored messages to users when they log in, “more like email servers where you can come back later and get your emails.” Per the FAQ, a client logging in receives up to 32 previously unseen messages. A room server can be set to repeat, but the FAQ says this “is not recommended nor encouraged” and suggests running repeaters and room servers on separate devices.

Other builds

The README also lists developer examples: a KISS modem bridge, a simple secure chat for serial terminals, and a sensor node with telemetry.

How MeshCore routes messages

From the FAQ:

1. First message floods. Your first message to a contact travels by flood routing through repeaters.
2. The path comes back. The destination returns a delivery report listing the repeaters the message passed through.
3. Later messages use the path. The path is embedded in each packet. A repeater retransmits only if it matches the next hop; otherwise it stays quiet, “hence minimizing utilization.”
4. Broken paths fall back to flood. If a repeater on the path disappears, the app retries, then by default floods on the last retry.

Group channels always flood, because there’s no single destination. Repeater operators can limit flood traffic by hop count with set flood.max.

The packet format stores the path as a list of short hashes, originally the first byte of each repeater’s public key. The packet’s path field holds up to 64 bytes, which the FAQ describes as up to 64 hops. Firmware 1.14 and later can use 2- or 3-byte path hashes to reduce ID collisions, which lowers the maximum to 32 or 21 hops respectively.

Adverts

An “advert” is how a node announces its name, position, and public key, signed to prevent spoofing. A zero-hop advert reaches only nodes in direct range; a flood advert is repeated by repeaters. Companions advertise only when the user taps the button. Repeaters send a flood advert every 12 hours by default, adjustable with set flood.advert.interval.

Apps and tools

Listed in the README and FAQ:

Tool	What it’s for
Web flasher (flasher.meshcore.io; README links meshcore.io/flasher)	Flash companion, repeater, or room server firmware; console access
MeshCore app (Android, iOS; also Windows and Mac)	Messaging via a BLE companion; remote repeater/room server management
Web app (app.meshcore.nz)	Messaging via a USB serial companion
Config tool (config.meshcore.io)	Set up repeaters and room servers over USB
meshcore.js, meshcore-cli	Developer libraries for Node.js and Python
MeshCore Map (map.meshcore.io)	Optional internet map of nodes added from the app

Cost and licensing. The firmware is MIT licensed. The FAQ says the native mobile app uses a freemium model (an in-app purchase removes a wait timer on remote repeater management), the Windows and Mac versions are fully unlocked, and the standalone T-Deck firmware is free with an optional paid registration for extras such as deeper map zoom. The FAQ also states that “everything is open source except the T-Deck firmware and Liam’s native mobile apps.”

Getting started

The FAQ’s suggested path:

• One device: flash BLE Companion and pair it with the app to talk to MeshCore users nearby.
• Two devices, few users nearby: flash both as companions for friends or family.
• Two devices with other users nearby: one companion, one repeater placed high above ground.
• More devices: add a room server.

The FAQ lists supported hardware including LilyGo T-Deck, RAK WisBlock RAK4631, Heltec V3, Heltec T114, Station G2, and Seeed T1000-E, with the flasher as the up-to-date list. See /devices/ for details on specific boards.

Flashing

From the README:

1. Open the MeshCore web flasher.
2. Select a supported device.
3. Flash companion, repeater, or room server firmware.
4. Connect a companion with an app, or set up a repeater/room server over USB.

If a device seems corrupted, the FAQ describes exporting settings from the app and doing a factory reset, or using the flasher’s DFU mode and Erase Flash before reflashing. On Linux, a “Failed to open serial port” error usually means your user lacks permission on the USB port.

Setting up a repeater

• Set the frequency first. On first flash, a repeater must be set to the frequency legal in your region (set freq in the console, or via the config tool).
• Change the default passwords. The FAQ documents default admin and room-server guest passwords; change them with password and set guest.password.
• Optionally set location with set lat and set lon so it can appear on the map.
• Pick a unique ID if you can. The FAQ suggests choosing a public key whose first byte isn’t used by repeaters within about 10 miles (16 km), to make path analysis easier.

The CLI reference covers repeater, room server, and sensor commands, including power saving on repeaters and duty-cycle limits.

Radio settings in the US

The FAQ says MeshCore supports the 868 MHz range in the UK and EU and the 915 MHz range in New Zealand, Australia, and the USA. Radio presets are suggestions served to the apps from MeshCore’s API server (Radio Presets), and you can configure any settings that comply with local regulations.

According to the FAQ, as of October 2025 many regions moved to a narrow 62.5 kHz bandwidth with lower spreading factors, and the “USA/Canada (Recommended)” preset is 910.525 MHz, SF7, BW62.5, CR5. The FAQ says narrower bandwidth and lower SF “allow MeshCore’s radio signals to fit between interference in the ISM band.” Check with your local group, since presets can change. FCC §15.247 sets a 500 kHz minimum bandwidth for digitally modulated systems in the 902–928 MHz band (with separate rules for frequency hopping), and a 62.5 kHz preset is much narrower than that; how a given preset and power level fit those rules is a legal question we can’t answer for you. Our legal guide summarizes the Part 15 rules that apply to any device in this band. This is not legal advice.

Security basics

• Nodes are identified by Ed25519 public keys, and adverts carry an Ed25519 signature (Payloads).
• Message payloads are encrypted with AES-128 using a shared secret and carry a 2-byte MAC, per the source code and packet docs.
• Group messages carry no sender signature, so “any channel-key holder can choose any sender name.”
• The default public channel’s key is published in the FAQ, so treat the public channel as public.
• The FAQ lists a default Bluetooth pairing code for companions.

Project governance note

In April 2026, the MeshCore core team posted on the official MeshCore blog about a split with a former team member over a trademark application and other disagreements, and stated that “the only ‘official’ MeshCore is the github repo.” This guide uses that repository and docs.meshcore.io. We have read only the core team’s account and haven’t verified the other side’s position.

MeshCore and Meshtastic

MeshCore and Meshtastic run on many of the same boards but can’t talk to each other, and a device runs one firmware at a time. Meshtastic lets most nodes relay by default; MeshCore restricts relaying to repeaters. For a full comparison, read Meshtastic vs MeshCore. To see if a MeshCore network exists near you, check the MeshCore Map and local groups, as described in finding nodes near you.