# MeshCore-Specific FAQ # What is the difference between a Repeater and Room Client in MeshCore? ## What Is the Difference Between a Repeater and Room Client in MeshCore? MeshCore ships two primary firmware variants for end-user nodes, each optimized for a different role in the network. Choosing the wrong one is a common source of confusion. This page explains both in detail. ### REPEATER\_FIRMWARE A node flashed with REPEATER\_FIRMWARE acts as pure RF infrastructure. Its sole job is to receive LoRa packets and re-transmit them to extend the reach of the mesh. Key characteristics: - **No screen required:** Repeater firmware is designed to run on minimal hardware - a bare ESP32 or nRF52 board with a LoRa module. It has no UI and does not need a display. - **Minimal power consumption:** Because it does not maintain Bluetooth, Wi-Fi, or app connections, a repeater node consumes significantly less power than a room client. This makes it ideal for solar-powered or battery-backed infrastructure deployments. - **No identity:** A repeater does not have a user-facing identity on the mesh. It does not send or receive user messages; it only forwards packets at the radio layer. - **No room server interaction:** Repeater firmware does not connect to a room server. It has no concept of message storage or retrieval. **Best for:** Hilltop relays, tower-mounted infrastructure nodes, solar repeaters in remote locations - any deployment where the goal is coverage extension rather than message origination. ### ROOM\_CLIENT\_FIRMWARE A node flashed with ROOM\_CLIENT\_FIRMWARE has a full client identity and can connect to a MeshCore room server for message storage and retrieval. Key characteristics: - **Client identity:** The node generates a public/private key pair on first boot. This keypair is its identity on the mesh and with room servers. Messages can be addressed to it specifically. - **Room server connectivity:** A room client can connect to a room server (over RF through the mesh, or via Wi-Fi/TCP if configured) to upload outgoing messages and download stored messages it missed while offline. - **Higher power use:** Maintaining a client identity, processing addressed messages, and optionally maintaining a TCP connection to a room server consumes more CPU cycles and radio time than a pure repeater. - **Can also relay:** A room client node will re-broadcast packets it receives just like a repeater does, within its configured hop limit. It is not *only* a client - it also participates in mesh routing. **Best for:** User-carried nodes, [base station nodes](https://wiki.meshamerica.com/books/hardware-guide/page/base-station-nodes) that interact with a room server, nodes that need to send and receive addressed messages. ### Can a node be both? No. You must choose one firmware at flash time. A single physical node cannot simultaneously run REPEATER\_FIRMWARE and ROOM\_CLIENT\_FIRMWARE. If you need both roles at one location - for example, a hilltop site that also serves as a room server gateway - you need two separate physical nodes, or a single node running ROOM\_CLIENT\_FIRMWARE (which also relays, accepting the higher power overhead). ### Summary comparison
FeatureREPEATER\_FIRMWAREROOM\_CLIENT\_FIRMWARE
Relays RF packetsYesYes
Has user identityNoYes
Connects to room serverNoYes
Sends/receives messagesNoYes
Power useLowHigher
Screen neededNoOptional
# How do I connect to a MeshCore room server from the app? ## How Do I Connect to a MeshCore Room Server From the App? A MeshCore room server stores messages for offline nodes and enables larger-group conversations that persist beyond the RF range of any single transmission. Connecting to one from the MeshCore app is straightforward once you have the server address, port, and room key from your community administrator. ### Step-by-step connection 1. Open the **MeshCore app** on your phone and ensure your node is connected via Bluetooth. 2. Tap the **Settings** icon (gear icon, usually in the top-right or side menu). 3. Select **Room Servers** from the settings list. 4. Tap **Add Server** (or the + button). 5. Enter the **server address** - this is the hostname or IP address of the server running pyMC\_Repeater or another MeshCore room server implementation (e.g., `mesh.example.com` or `192.168.1.50`). 6. Enter the **port number**. The default port for MeshCore room servers is `5005`. Your administrator may have configured a non-standard port. 7. Enter the **room key**. This is a shared secret provided by your community administrator. It must match exactly, including capitalization. 8. Tap **Save** or **Connect**. The app will attempt to establish a connection. A green indicator or Connected status confirms success. ### Troubleshooting connection failures If the connection fails, work through these checks systematically: #### Connection refused error - The room server node may not be powered on or may be out of range. Verify the room server node has power and that your node can hear it on the mesh (check the node list in the app). - The port is wrong. Verify with your administrator what port is in use. - A firewall is blocking the connection. On the server, confirm the port is open: `sudo ufw status` or `sudo iptables -L -n | grep 5005` #### Authentication failed or wrong key error - The room key you entered does not match the server configured key. Keys are case-sensitive. Try re-entering it manually rather than copy-pasting to rule out invisible characters. - The server may have had its key rotated. Ask your administrator for the current key. #### App shows Connecting indefinitely - Your phone cannot reach the server. Try opening a browser and navigating to `http://[server-address]:[port]` - if it times out, the network path is blocked. - If you are on a mobile data connection, your carrier may be blocking the port. Try connecting over Wi-Fi first to confirm the server is reachable. - The server address may have changed. DNS may have cached an old IP. Try using the IP address directly. ### Verifying the server is running (for administrators) On the server host: ``` sudo systemctl status meshcore-room-server sudo journalctl -f -u meshcore-room-server ``` You should see lines indicating the server is listening on the configured port. Incoming connection attempts will be logged when clients connect. # Can I run MeshCore and Meshtastic simultaneously on the same hardware? ## Can I Run MeshCore and Meshtastic Simultaneously on the Same Hardware? The short answer is: **no**. You can only run one firmware at a time on a given LoRa node. However, there are practical workarounds if you need coverage of both protocols at one location. ### Why only one at a time Both MeshCore and Meshtastic are compiled firmware images flashed directly to the microcontroller (ESP32, nRF52840, RP2040, etc.) on your LoRa board. When you flash a firmware image, it replaces whatever was there before. There is no multi-boot capability, no virtual machine layer, and no way to timeshare the LoRa radio hardware between two independent firmware stacks. The LoRa transceiver (SX1276, SX1262, LR1121, etc.) is a single physical peripheral that can only be driven by one firmware at a time. Additionally, even if you could somehow run both, they would need to use the same LoRa radio simultaneously - which is physically impossible without two separate radio modules. Each transmission requires exclusive use of the transceiver. ### Switching between firmwares You can re-flash a node from MeshCore to Meshtastic (or vice versa) at any time using the appropriate web flasher or CLI tool. The process takes a few minutes and requires a USB connection. However, you lose all configuration from the previous firmware when you do so, making it impractical to switch frequently. ### Running both protocols at one location If your community or deployment site genuinely needs to participate in both a MeshCore mesh and a Meshtastic mesh, the practical solution is two separate physical nodes: - **Node A:** Running MeshCore (REPEATER\_FIRMWARE or ROOM\_CLIENT\_FIRMWARE as appropriate) - **Node B:** Running Meshtastic firmware Both nodes can be co-located at the same site, connected to the same power supply, and mounted on the same antenna mast (using a splitter or separate antennas). Many community infrastructure operators run exactly this configuration at hilltop repeater sites to serve both ecosystems. ### The future: software-defined gateways Community developers have discussed building a software gateway that runs on a host computer (Raspberry Pi, etc.) and uses two LoRa radio modules - one for each protocol - to bridge messages between the two networks at the application layer. As of today, no such gateway exists in a production-ready state. Any such project would also need to handle the fundamental differences in addressing, encryption, and routing described in the cross-protocol FAQ page. ### Recommendation For most communities, the right answer is to **choose one protocol and standardize**. Mixed-protocol communities face ongoing friction in coordination, troubleshooting, and user experience. If your regional mesh has already standardized on one platform, matching that choice eliminates the need for dual-protocol coverage entirely. If you are starting a new community from scratch and expect to attract users from both ecosystems, deploying two nodes at each infrastructure site is a legitimate and manageable approach - the hardware cost of an extra node (~$30 - 60 USD) is usually worth the interoperability it provides.