Skip to main content

MeshCore Firmware Variants Explained

MeshCore Firmware Variants Explained

MeshCore is not a single firmware build. It is distributed as several distinct firmware variants, each designed for a specific role in the mesh. Choosing the correct variant for each node is essential — running the wrong firmware type wastes resources, wastes spectrum,resources and can degrade network performance.

The Four Firmware Variants

REPEATERCompanion (COMPANION)

The REPEATERCompanion firmware is for user-facing nodes. It is the firmware that end-users run on their personal devices to send and receive messages via the MeshCore mobile app.

    Primary function: Sends and receives direct messages and channel (group) messages. Maintains a contact list. Connects via BLE, USB serial, or WiFi to the MeshCore mobile app. Sub-variants: BLE (Bluetooth Low Energy), USB, and WiFi connection modes are available depending on hardware capability. When to use: Personal handheld nodes, base station nodes used for human communication, any node that a person interacts with via the MeshCore app. Firmware file example: rak4631_companion.uf2, tbeam_companion.bin

    Repeater (REPEATER)

    The Repeater firmware turns a node into a dedicated packet relay. It has no user interface and no messaging capability of its own.

    • Primary function: Receives MeshCore packets and re-transmits themthem. alongForwards learnedpackets routes.to Maintainsextend anetwork routing table of known paths through the mesh.reach.
    • Resource profile: Minimal. No display driver, no BLE advertising for user connections (only for CLI access), no message store. Designed to run indefinitely on a small battery or solar.
    • When to use: Any node whose sole purpose is extending mesh coverage — hilltop repeaters, building relay nodes, infrastructure backbone nodes.
    • When NOT to use: Do not flash REPEATERRepeater on a node you plan to use as a personal communicator. It has no user-facing messaging.
    • Hardware support: All supported MeshCore boards (RAK4631, T-Beam v1.2+, T-Beam Supreme, Heltec V3, T114, Heltec HT-n62).
    Firmware file example: rak4631_repeater.uf2, tbeam_repeater.bin

    ROOM_CLIENTRoom Server (ROOM_SERVER)

    The ROOM_CLIENTRoom Server firmware iscreates fora user-facingstore-and-forward nodesmessage thathub. send and receive messages, including connecting to roomRoom servers foract as persistent group chat.chat rooms accessible via LoRa.

    • Primary function: SendsStores and receives directincoming messages and room-based (group) messages. Maintains a contact list. Connects via BLE to the MeshCore mobile app.
    Resource profile: Moderate. Maintains a message store, contact table, and BLE advertising stack. More RAM-intensive than REPEATER. When to use: Personal handheld nodes, base station nodes used for human communication, any node that a person will interact with via the MeshCore app. Room server interaction: ROOM_CLIENT nodes can connect to a room server to join a group channel. They send a join request and subsequently receive/send room messages through the server node. Hardware support: All supported MeshCore boards. Firmware file example: rak4631_room_client.uf2

    ROOM_SERVER

    The ROOM_SERVER firmware turns a node into a group messaging hub. Other ROOM_CLIENT nodes connect to it to participate in a shared room (channel).

      Primary function: Maintains a list of connected room members. Receives messages from clients and relaysdelivers them to allnodes otherthat membersconnect inlater the(offline room.delivery). StoresActs recent messages so late-joining clients can catch up. Resource profile: Higher than ROOM_CLIENT. Maintaining per-client state,as a messagecentral buffer,hub andfor handlinggroup potentially many simultaneous incoming messages requires more RAM and flash. This is why some lower-memory boards (e.g., Heltec V3) do not support ROOM_SERVER.communication. When to use: Fixed infrastructure nodes serving as community message hubs — in a node deployedbuilding, on a rooftop,hilltop hilltop,tower, or centralat locationan thatevent willsite servewhere aspersistent themessage hub for a community or team channel. Why you should NOT run ROOM_SERVER on a repeater-only node: A node that also needs to relay packets for the broader meshhistory is doing two jobs. If the room server is busy processing a burst of incoming messages, it may delay packet forwarding, degrading routing performance for all nodes. Use dedicated hardware for room servers when possible, or accept the trade-off consciously. Hardware support: RAK4631, T-Beam v1.2+, T-Beam Supreme, T114. NOT supported on Heltec WiFi LoRa 32 V3 or Heltec HT-n62.needed. Firmware file example: rak4631_room_server.rak4631_roomserver.uf2, tbeam_roomserver.bin

      SENSORSensor (SENSOR)

      The SENSORSensor firmware is for nodes equippedthat withcollect and transmit environmental sensors (BME280 or BME680).telemetry It periodically reads sensor data and transmits it as a structured sensor packet over the mesh.data.

      • Primary function: Wake from deep sleep at a configured interval, read I2CReads sensor data (temperature, humidity, pressure,GPS, optionallyetc.) VOC),and transmittransmits a sensor data packet, returnit to deep sleep.
      Resource profile: Very minimal during operation. Spends most of its time in deep sleep. The nRF52840's ~3 µA deep sleep current makes months-long battery operation feasible. Sensor support: BME280 (temperature, humidity, pressure) and BME680 (temperature, humidity, pressure, VOC gas resistance). RAK WisBlock RAK1906 module provides the BME680.mesh network. When to use: RemoteUnattended monitoring nodes — weather stations, environmentalasset monitoring in a building or field site, any deployment where periodictrackers, environmental data collection is needed.sensors. Hardware support: Primarily nRF52840-based boards only (RAK4631, T114). Thedue to their low power consumption and hardware sensor firmware relies on nRF52840-specific deep sleep and I2C peripheral wake capabilities. ESP32-based boards (T-Beam, Heltec V3) do not currently have a SENSOR variant.interfaces. Firmware file example: rak4631_sensor.uf2

      HardwareSummary vs Firmware Variant MatrixTable

      FirmwareUser
      MessagingPacket RelayBoardMessage StoreSensor REPEATERData ROOM_CLIENT ROOM_SERVER SENSOR RAK4631CompanionYesYesNoYesYesLocal T-Beam v1.2+YesYesYesonlyNo T-Beam SupremeYesYesYesRepeaterNo Heltec WiFi LoRa 32 V3YesYesNoNo T114Room ServerNoOptionalYes (network-wide)YesYesYesNo Heltec HT-n62YesYesSensorNoNoNoYes

      Version

      Source: NumberingMeshCore Schemeofficial

      MeshCoredocumentation and firmware versions follow a major.minor.patch scheme (e.g., 2.4.1):

        Major version — significant protocol or architecture changes. Nodes on different major versions may have limited interoperability. Minor version — new features, new board support, API changes. Generally backward-compatible within the same major version. Patch version — bug fixes, performance improvements. Always safe to apply.

        Release Cadence

        MeshCore is an active project with releases driven by community needs and developer availability. As of 2026:

          Minor releases typically appear every few weeks to months. Patch releases may be more frequent, especially following reports of regressions. Pre-release (beta) builds are sometimes made available in the community Discord for testing before an official release. Release notes are published in the MeshCore GitHub repository underat the Releases section.

          Checking Which Version You Are Running

          Connect to your node via BLE using the github.com/meshcore-dev/MeshCore CLI or app and run:

          status

          The output will include the firmware version, board variant, and current configuration summary.

          Back to top