# Meshtastic Repeater Setup

Step-by-step setup, role selection, and channel configuration for Meshtastic repeaters.

# Router vs. Repeater Role — Which to Choose

## Overview of Device Roles

Meshtastic firmware supports several device roles that control how a node behaves on the mesh. For infrastructure nodes, the two most relevant are **ROUTER** and **REPEATER**.

## ROUTER Role

- Actively participates in flooding and rebroadcasting *all* packets it hears.
- Maintains a node position - appears on the map at meshmap.net and in the app node list.
- Can receive and display messages; someone in the field can text the node directly to check status.
- Higher airtime usage because it retransmits more aggressively.
- Prioritises rebroadcasting packets that still have maximum hops remaining.
- **Good for:** nodes that also serve as monitoring points, nodes with a screen or GPS that need to appear on maps, medium-traffic networks.

## REPEATER Role

- Optimised purely for packet relay - rebroadcasts with lower overhead.
- Does **not** broadcast its own position - will not appear on maps, which reduces network traffic.
- Does **not** receive messages for "self" - cannot be texted directly.
- Lower power consumption than ROUTER in practice because it generates fewer self-broadcasts.
- Firmware configures the device as a "hop maximiser" - prioritises packets that still have hops remaining.
- **Good for:** permanent unattended infrastructure, solar deployments, maximising battery life, reducing self-generated traffic.

## When to Use Each Role

<table id="bkmrk-scenariorecommended-"> <thead><tr><th>Scenario</th><th>Recommended Role</th></tr></thead> <tbody> <tr><td>Temporary deployment or field relay that doubles as a client</td><td>ROUTER</td></tr> <tr><td>Node needs to appear on the map for coordination</td><td>ROUTER</td></tr> <tr><td>Permanent mountaintop or rooftop installation</td><td>REPEATER</td></tr> <tr><td>Solar-powered, unattended node</td><td>REPEATER</td></tr> <tr><td>Maximise battery life and minimise self-generated traffic</td><td>REPEATER</td></tr> </tbody></table>

## CLIENT\_MUTE Role

**CLIENT\_MUTE** is the opposite of a repeater - it prevents a regular client device (phone, laptop) from rebroadcasting mesh traffic. This is useful for devices that are on the mesh but should not consume airtime acting as relays, such as tablets used only for monitoring.

## Setting the Role

In the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app): **Config → Device Config → Role → select ROUTER or REPEATER**.

Via the web client at [client.meshtastic.org](https://client.meshtastic.org): connect via USB, navigate to Device Config, and choose the desired role from the drop-down.

# Initial Setup Walkthrough

## Prerequisites

- A Meshtastic-compatible device (T-Beam, Heltec, RAK WisBlock, etc.) flashed with current firmware - use the official flasher at [flasher.meshtastic.org](https://flasher.meshtastic.org).
- A phone with the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) (iOS or Android) **or** a Chrome-based browser for the web client.
- An antenna connected *before* powering the device.

## Step 1 - Connect to the Device

**Via Bluetooth:** Open the Meshtastic app, tap the **+** button, and scan for your device. Pair when prompted.

**Via USB:** Navigate to [client.meshtastic.org](https://client.meshtastic.org) in Chrome, click **New connection → Serial**, and select the device's COM/serial port.

## Step 2 - Set the Device Name

Navigate to **Config → Device**:

- **Long Name:** Your full identifier for this node, e.g. `KD9XYZ-Hilltop-1`. This appears in message headers and node lists.
- **Short Name:** Up to 4 characters, shown on the map, e.g. `H1`.

## Step 3 - Set the Device Role

**Config → Device → Role → REPEATER** for permanent infrastructure, or **ROUTER** for nodes that also act as monitoring points. See the *Router vs. Repeater Role* page for guidance.

## Step 4 - Configure the Channel

The default channel (*LongFast* or *Default*) works for joining the public mesh. To match a local community's private channel:

1. Navigate to **Channels → Channel 0**.
2. Set the **Name** and **PSK** to match the local standard.
3. Contact your local Meshtastic community (meshmap.net, Discord, or local club) for the channel name and key.

## Step 5 - Set the Modem Preset

**Radio Config → LoRa → Modem Preset** - select the preset your local network uses (typically *Long Fast* or *Medium Slow*). **Critical: all nodes on the same network must use the same modem preset or they cannot hear each other.**

## Step 6 - Configure a Fixed Position

For an unattended repeater without GPS, set a fixed position so the node appears on meshmap.net:

1. **Config → Position → Fixed Position → Enable**.
2. Enter the latitude, longitude, and altitude of the deployment site (look up coordinates with any map app).
3. Set **Position Broadcast Interval** to a longer value - `3600` seconds (1 hour) is appropriate for a static node - to reduce airtime.

## Step 7 - Power Optimisations (Battery / Solar)

- **Config → Power** - set sleep and minimum wake intervals to the lowest practical values.
- Enable power-saving mode if using the REPEATER role.
- Set **Screen Timeout** to `0` (display always off) to eliminate screen power draw.

## Step 8 - Disable Bluetooth (Optional)

**Config → Bluetooth → Enabled → false.** This saves power and removes an attack surface on unattended nodes. **Note:** once Bluetooth is disabled, you will need a USB/serial connection or a configured admin channel to re-enable it remotely.

## Step 9 - Verify Operation

- Watch the node list for other nearby nodes appearing - this confirms receive is working.
- Send a test message and verify it is received on another device.
- After a short while (typically 15 - 30 minutes), confirm the node appears on [meshmap.net](https://meshmap.net).

# Channel Configuration for Infrastructure Nodes

## What Are Channels?

Meshtastic supports up to **8 simultaneous channels** (numbered 0 - 7). Channel 0 is the *primary channel* used for most mesh traffic. Channels 1 - 7 can carry separately encrypted traffic for specific groups or purposes.

## PSK - Pre-Shared Key

Each channel has a **name** and a **32-byte encryption key (PSK)**. Two nodes can communicate on a channel only if they share the same name *and* the same PSK. The PSK is used for AES-256 encryption of all payloads on that channel.

## The Default Public Key

The *Default* channel uses a well-known, publicly published key (effectively no private encryption). Any node running Meshtastic with the default channel can participate in the public mesh. Using a **custom PSK** creates a private channel readable only by nodes that hold that key.

## Channel Strategy for Community Infrastructure Nodes

- **Channel 0 - Default PSK:** Keep the primary channel on the public Default key so all community users benefit from your repeater's coverage.
- **Channel 1 - Private PSK:** Adding a secondary channel with a private key for your personal use or club coordination is acceptable. The repeater will relay packets on both channels.

## Admin Channel

Meshtastic can designate any channel as the **Admin channel**. Nodes that share the admin channel with your repeater can send remote configuration commands - changing settings without physical access to the device.

**This is strongly recommended for unattended permanent deployments.**

1. Navigate to **Config → Channels** and add a new channel (e.g. channel 1).
2. Enable the **Is Admin** toggle for that channel.
3. Save the channel configuration as a QR code and store it securely - anyone with this QR code can reconfigure your node remotely.

## Channel Propagation

Your repeater only relays channels it has configured. If a node on the mesh is using a custom channel that your repeater does not know about, those packets will not be relayed. For a public community repeater, keeping only the public Default channel is the standard approach.

## Changing Channels on a Deployed Node

Options for modifying channel config after deployment:

- **Via admin channel** (preferred for remote nodes) - send a channel update from another device that shares the admin channel.
- **Via serial/USB** - connect a laptop directly to the node.
- **Via Bluetooth** - only if Bluetooth was left enabled.

**Common pitfall:** losing the admin channel config (or disabling Bluetooth and having no USB access) leaves a remote node inaccessible without a physical site visit. Always save admin channel QR codes before deployment.