Advanced Repeater Configuration

MeshCore Repeater Name and Identity

Every MeshCore repeater broadcasts an identity advertisement that makes it visible to the network. Setting a meaningful name and position makes your repeater useful to the wider community.

Setting a Repeater Name

The repeater name appears in client apps when users are selecting which repeaters to contact or route through. Use a consistent naming convention for community repeaters:

Note: Call signs in these examples are just a human naming convention. MeshCore devices operate under FCC Part 15 (license-free) on 902-928 MHz, not Part 97 amateur rules - no station ID is required, and a call sign in the name does not make the device an amateur-radio station.

Configure via the MeshCore app or serial console:

set name MyRepeaterName

The node name maximum length is 24 bytes if a location is set, 32 bytes otherwise (the limit is measured in bytes, and emoji or accented characters use more than one byte each). Plain ASCII names of roughly 24 characters or fewer are safe. As a separate style suggestion, keeping names short also improves display readability across client apps.

Setting Geographic Position

Position data is included in flood advertisements, making your repeater visible on network maps and helping operators understand coverage. Configure with decimal degrees:

set lat 37.7749
set lon -122.4194

MeshCore position advertisements use latitude and longitude only; there is no altitude setting in the CLI. Use your deployment coordinates, not your home address - the position is broadcast to the entire network.

Advertisement Configuration

Control how often your repeater sends its flood advertisement:

set flood.advert.interval 12

The flood advert interval is specified in hours (range 3-168), with a repeater default of 12. The 12-hour default is appropriate for stable, permanent deployments. To verify a repeater is appearing in client apps during initial deployment, temporarily lower the flood interval (for example to 3 hours) and then return it to 12 for steady-state operation to minimize network load. A separate zero-hop advert interval, set advert.interval <minutes> (60-240 minutes), controls only the local zero-hop advert.

Flood vs Local Advertisement

MeshCore adverts are sent as one of two types - there is no per-advert hop-count setting. To send a flood (multi-hop) advert that other repeaters propagate across the network, run:

advert

advert.zerohop - sends a zero-hop advert visible only to nodes in direct radio range (local-only). advert - sends a flood advert that propagates through the mesh, making the repeater discoverable to distant nodes; its propagation depth is limited by flood.max (range 0-64, default 64), not by a per-advert hop count. Use flood adverts (advert) for public community repeaters; use zero-hop adverts (advert.zerohop) for private or testing nodes.

Multi-Repeater Network Coordination

When multiple MeshCore repeaters serve the same community, coordination between operators ensures the network behaves predictably and provides maximum benefit to users.

Radio Preset Consistency (and the Channel-Key Myth)

A common misconception is that every repeater on a community network must share a "channel key." It does not. In MeshCore, repeaters forward packets based on routing/path information and do not decrypt message payloads — they relay encrypted traffic for any channel without needing that channel's key. Channel keys are a client-side concern: only clients holding a channel's key can read that channel's group messages. So a repeater never "silently drops traffic it cannot decrypt." What every repeater (and client) must share to interoperate is the same radio preset / frequency — if the radio parameters don't match, the repeater literally cannot hear the packets. When deploying a new repeater, coordinate the radio preset, frequency, and repeater naming/placement with the network coordinator before commissioning.

Verify a new repeater is relaying by sending a test message from a client node so that it routes through the new repeater. A successful delivery confirms the repeater is hearing and forwarding correctly (correct preset, placement, and RF range). It does not test channel-key alignment — that is verified between client nodes (whether two clients can read each other's group messages), not at the repeater. A failed route-through test points to a radio-config/preset mismatch or insufficient RF range, not a missing channel key.

Coverage Overlap Planning

Adjacent repeaters should have some coverage overlap for redundancy and continuity. The exact amount depends on terrain, antenna height, and node density — there is no universal percentage. Validate overlap empirically with drive/walk tests confirming each area is reachable via at least two repeaters. Overlap provides:

Insufficient overlap creates coverage holes where users are out of range of all repeaters. At the other extreme, deploying many repeaters very close together — covering the same footprint with no new coverage — adds channel airtime contention and flood amplification without proportional benefit. Note that close spacing is not inherently wasteful: in dense urban terrain with heavy building attenuation, sub-kilometer spacing can be necessary and appropriate (the density guidance suggests roughly one repeater per ~1 km² / ~500 m radius). Avoid overlap only where it is genuinely redundant.

Frequency and Preset Coordination

All community repeaters must use the same radio parameters (the USA/Canada preset is recommended in this region). Verify with:

get radio

The get radio output shows the current frequency, bandwidth, spreading factor, and coding rate (get freq and get tx report frequency and TX power individually). MeshCore presets are an app-side selection; the serial CLI reports the raw radio parameters rather than a named preset. Confirm these values match the community-standard USA/Canada preset before committing a new repeater to service.

Network Documentation

Maintain a community document with:

This documentation is invaluable when diagnosing network problems or planning expansion. Store it in a shared document that all operators can access and update.

Repeater Retirement and Replacement

When a repeater is permanently taken offline, notify the community so they can update routing expectations and coverage maps. Removing a node that other nodes' cached routes depend on will cause temporary routing failures until routes are rediscovered. This is normal behavior; MeshCore re-discovers routes when existing paths fail.

MeshCore Repeater Diagnostics via Serial Console

The MeshCore serial console provides direct access to repeater state and diagnostic information. Connecting via USB to a deployed repeater is the most reliable way to diagnose problems that cannot be addressed remotely.

Connecting to the Serial Console

On Windows: use PuTTY or the Arduino Serial Monitor. On Linux/Mac: use screen or minicom as a serial terminal.

# Linux/Mac
screen /dev/ttyUSB0 115200

# Windows (PuTTY): Connection Type = Serial, Speed = 115200, COM port varies

MeshCore boards use 115200 baud for the serial console, including RAK boards. (If you have configured an attached GPS module, that module's own UART may run at a different baud rate such as 9600 - but that is a separate interface from the console.)

Key Diagnostic Commands

These are commands from the on-device MeshCore serial CLI (see docs.meshcore.io/cli_commands). There is no single combined "status" command - health information is split across several get ... and stats-... commands.

CommandOutputUse for
verFirmware versionConfirm firmware build
stats-coreBattery voltage, uptime, queue depthOverall health check
get radio / get freqRadio config (frequency, bandwidth, SF, coding rate)Verify radio settings match the network
neighborsUp to the 8 most recently heard nodes, with timestamp and SNRVerify which nodes are reaching this repeater
stats-packetsPacket counters: Received and SentIdentify traffic/routing problems
stats-radioNoise floor, last RSSI/SNR, airtime, receive errorsSignal quality of last received packet
logPrints a captured rx log (must first be started with log start, stopped with log stop, cleared with log erase)Capture and review received-packet activity
reboot(restarts device)Recover from hung state

Note: contacts and list are companion/client-side concepts, not repeater serial commands - on a headless repeater, use neighbors instead. The log command is a packet/rx capture you start and stop, not an always-on event log.

Interpreting Stats Output

The stats-packets command is a useful diagnostic tool. The firmware exposes Received and Sent counters. A healthy repeater shows:

Common Issues and Diagnostics

SymptomCheckFix
Received count stays at zeroCheck antenna connection, verify radio settings match networkReconnect antenna; verify radio parameters with get radio and get freq (frequency, bandwidth, SF, coding rate) and confirm they match the USA/Canada preset values shown in the app
Sent count zero despite receivesVerify device is running repeater firmware variant and that forwarding is enabledReflash with repeater firmware; confirm set repeat on
Battery voltage decliningCheck solar panel output, charge controller LVD settingClean panel, verify charge controller settings
Rebooting frequentlyCheck for low battery voltage causing brownoutSize battery correctly; check charge controller
Not appearing in client node listRepeater may not be sending flood adverts; check the flood advert interval with get flood.advert.intervalSend a flood advertisement with advert and confirm a flood advert interval is set, e.g. set flood.advert.interval 12 (hours). Zero-hop adverts (advert.zerohop / set advert.interval) are local only. There is no advert_hops parameter.