Configuration

Meshtastic Guides

The settings that matter

• Region: mandatory, and the node will not transmit until set. Covered in Frequencies & Regions.
• Modem preset: the speed/range tradeoff, and it must match the nodes you want to talk to. The default (LongFast) is what nearly every public mesh runs. Change it only if your local group has standardized on something else; a lone node on a different preset is invisible.
• Name: a long name and a four-character short name, both public.
• Hop limit: defaults to 3, maximum 7. Raising it makes every one of your packets occupy more total airtime across the mesh. Leave it at 3 unless you know the topology actually needs more.

Roles: almost everyone is CLIENT

The default CLIENT role already relays for the mesh; it is a full participant. The ROUTER role exists for well-placed infrastructure (a ridge, a tower, a rooftop with real coverage) and changes rebroadcast behavior so that node takes priority. Setting ROUTER on a desk node in a dense area makes the mesh worse, not better, and the official docs are blunt about it. If your node lives in your pocket, it is a CLIENT. CLIENT_MUTE exists for nodes that should never relay (a dense cluster in one house does not need four relays).

Channels and encryption

Direct messages are encrypted per recipient, using public-key cryptography on firmware 2.5 and later. Channels are AES encrypted with a pre-shared key, and they come in three practical flavors:

• The primary channel: the default channel every node ships with, using a published default key. Shared by everyone running the defaults; treat it as open air.
• Private channels: a channel with a generated key, shared with your group as a QR code or URL. Exactly as private as your handling of that link.
• Secondary channels: a node holds the primary plus additional channel slots, so you can stay on the public mesh and run private groups on the same node.

Unlike MeshCore, there is no join-by-hashtag mechanism: joining a channel means receiving its key. And one sharp edge: the primary channel's name feeds the frequency-slot calculation, so renaming it moves your radio to a different frequency. A "cosmetic" rename of the primary channel makes you invisible to the public mesh. Leave its name alone; personalize with secondary channels.

Know the delivery semantics: channel messages are broadcast in the moment, like a voice transmission on ham or GMRS radio: if your radio was not on and listening when it went out, it is gone. A node that is powered off or out of range when a message goes by simply misses it; there is no retransmission, and no MeshCore-style room servers holding messages for you (an experimental store-and-forward module exists for specific ESP32 router setups, but do not plan around it). Your node does hold the messages it hears while away from your phone and hands them over when Bluetooth reconnects, so the node being on and in range is what matters, not the phone being in your hand.

Broadcast intervals

Nodes periodically broadcast position and telemetry. The defaults are reasonable; shortening intervals to make the map feel fresher burns shared airtime on data nobody urgently needs. On duty-cycle-limited regions (EU) this is not just courtesy, it is your legal transmit budget. When in doubt, lengthen intervals on fixed nodes.

MQTT: the internet bridge

The MQTT module (off by default) can bridge your node to an internet broker: uplinking local traffic, downlinking remote traffic, and feeding the public maps. Two things to understand before enabling it: traffic you uplink leaves the radio and lands on a server, and enabling downlink is why some meshes show "nodes" thousands of km away. It is a useful tool for linking islands of coverage and for map visibility, and it is also the setting most likely to surprise you. Decide deliberately.

Power settings

Battery behavior is mostly determined by the board you bought (see Hardware). The firmware's power-saving options help most on nRF52 hardware; no setting turns an ESP32 into a low-power device.