Home The Playbook
Learn
Settings Guide Field Guides Certifications
Get
Meshtastic Meshcore Reticulum Nodes About Contact
Node Star · Settings Guides

Which protocol
are you running?

Pick your protocol and find the right configuration for your goal — no guesswork. Direct links work too: settings.html#meshtastic and so on.

flood broadcast
Meshtastic

The most widely deployed LoRa mesh. Flood broadcast routing, a polished mobile app, and a huge hardware ecosystem. The best on-ramp into off-grid radio comms.

Flood broadcast LoRa only Named presets 50–80 node practical limit
Open Meshtastic guide →
REPEATER path-based routing
MeshCore

Path-based routing with explicit node roles. Repeaters, room servers, and companion radio mode — a more structured architecture that scales beyond Meshtastic's practical limits.

Path routing Explicit roles E2E encrypted DMs Manual LoRa params
Open MeshCore guide →
any transport
Sideband / Reticulum

A full cryptographic network stack. LoRa via RNode, TCP, I2P, serial — all at once. Sideband is the Android app. Reticulum is what's underneath. Always-on encryption, no presets.

Any transport Crypto-native Multi-interface Config file driven
Open Sideband / Reticulum guide →
Meshtastic · Settings Guide

What do you
want to do?

Find the right settings for your goal. Pick a scenario, read the plain-English explanation, and copy the configuration. No guesswork.

All Off-grid Internet bridge Infrastructure Power saving Privacy High density Tracking IoT / home
Hiking & backcountry group
off-grid
Your group is spread across a trail with no cell service. Everyone needs to text each other, share location, and know who's ahead or behind. No internet needed — radio only.
Key settings
Device → RoleCLIENT
LoRa → PresetLongFast
LoRa → Hop limit3
Position → Smart positionEnabled
MQTT / WiFiDisabled
Works out of the box. Pair each person's node to their phone. The Meshtastic app shows everyone's location on a map as long as nodes can hear each other.
!
Neighborhood emergency network
off-gridinfrastructure
Cell towers are down. You want your block or neighborhood to stay in contact without relying on any infrastructure you don't control. One node per household, one central relay mounted high.
Key settings
Central node → RoleROUTER
Home nodes → RoleCLIENT
Channel → Custom PSKYes — neighborhood key
LoRa → PresetLongFast
S&F on central nodeEnabled if PSRAM
Mount the central router as high as possible — rooftop, attic, or pole. Use a private channel so only your group is on it. Share the QR code in person.
Basic off-grid mesh (default)
off-grid
Just getting started. You have a few nodes and want to send messages between them without any internet or setup complexity. This is the factory default — it works immediately.
Key settings
Device → RoleCLIENT
LoRa → PresetLongFast
LoRa → RegionUS (or your region)
Hop limit3 (default)
MQTT / WiFiDisabled
The only change you must make: set your LoRa region. Everything else works at default. Pair via Bluetooth to the Meshtastic app on your phone.
Maximize range
off-gridinfrastructure
Nodes are far apart — remote cabins, rural properties, mountain ridge-to-ridge links. You're willing to sacrifice message speed for the absolute maximum radio distance.
Key settings
LoRa → PresetLongSlow
Hop limit5–7
LoRa → Tx powerMax
Device → RoleROUTER_CLIENT
Tradeoff: LongSlow means one message every several seconds. All nodes in your mesh must use the same preset — a LongFast and a LongSlow node can't hear each other.
MQTT internet
Connect two distant meshes over internet
internet bridge
Your mesh in one city, a friend's mesh in another. Messages flow between them as if they were one network — over WiFi and the internet, bridging back to LoRa on each end.
Key settings (gateway nodes on both ends)
Network → WiFiEnabled + credentials
MQTT → EnabledEnabled
Channel → UplinkEnabled
Channel → DownlinkEnabled
Channel → Custom PSKSame key on both ends
Heltec V4 handles this natively — WiFi built in, no phone proxy needed. Only the gateway node needs WiFi; all nearby nodes benefit automatically.
Dedicated router / relay node
infrastructure
You're mounting a node permanently on a roof, mast, or hilltop to extend the mesh for everyone nearby. It's not a personal device — it just repeats and forwards traffic 24/7.
Key settings
Device → RoleROUTER
Rebroadcast modeALL_KNOWN
Position → Fixed GPSSet manually
Screen / BluetoothBoth disabled
Telemetry intervals3600s+
Every meter of elevation dramatically extends range. Set a fixed GPS position manually so it appears correctly on the mesh map without needing a GPS module.
S&F buffer offline
Store & forward server
infrastructure
Nodes that go offline miss messages. A store-and-forward server buffers them and delivers them when the node reconnects — like a local answering machine for the mesh.
Key settings
Device → RoleROUTER
S&F → EnabledEnabled
S&F → Is serverTrue
S&F → Max records0 (auto ~11k)
Requires PSRAM — Heltec V4 ✓, T-Beam ✓. Since firmware 2.4+, clients auto-retrieve history on reconnect. Older clients send "SF" via DM to request.
A B
Private encrypted channel
privacy
The default channel uses a publicly known key — it's effectively no encryption. You need your own channel with a unique key so strangers on the public mesh can't read your messages.
Key settings
Channel → PSKGenerate new key
Channel → NameAnything non-default
MQTT → Okay to MQTTDisabled
Default LongFast channelDelete or mute
Critical: the default "LongFast" key is publicly documented — anyone can decode your messages. Generate a fresh key and share it only via QR code in person.
Solar-powered / low-power remote node
power saving
Deploying a node somewhere without power — a trail junction, a field sensor, a remote relay. Needs to run weeks or months on battery and solar without anyone touching it.
Key settings
Device → RoleSENSOR or ROUTER_CLIENT
Power → SleepEnabled
Position interval1800s+
Telemetry interval3600s+
Screen / WiFi / BTAll disabled
Heltec V4: under 20µA sleep current. Solar input via SH1.25-2P at 4.7–6V. Tx power is the biggest draw — reduce it if nodes are within a few km of each other.
congestion!
High-density event (festival, conference)
high density
Dozens or hundreds of nodes in a small area. Default settings cause massive congestion — messages fail, the network slows to a crawl. You need to tune aggressively to keep things functional.
Key settings
LoRa → PresetShortFast
Hop limit1–3
Rebroadcast modeKNOWN_MIN_HOP
MQTTDisabled or gated
Position broadcastReduce or disable
One unconfigured MQTT bridge crashed the entire network at the 2024 Hamvention. DEF CON uses ShortTurbo + custom firmware for 2,000+ nodes. Coordinate settings with organizers before the event.
here
Live GPS tracking
tracking
See where someone or something is in real time on a map — a moving vehicle, a person in the field, a dog, a piece of equipment. The node broadcasts its location regularly over the mesh.
Key settings
Device → RoleTRACKER
Position → GPSEnabled
Position → Broadcast60–300s
Smart positionEnabled
Position precisionReduce if privacy matters
Smart position only broadcasts when the node moves significantly — critical for battery life. Frequent position packets are the #1 cause of congestion on busy networks.
Heltec V4 internet
Full base station (router + S&F + MQTT)
infrastructureinternet bridge
One node doing everything: relay traffic for nearby nodes, store messages for offline nodes, and bridge the whole local mesh to the internet. The Heltec V4 has the hardware for all three simultaneously.
Key settings (Heltec V4)
Device → RoleROUTER
Network → WiFiEnabled
MQTT + Uplink/DownlinkAll enabled
S&F → ServerEnabled
Channel → Custom PSKRequired
Mount high with a good antenna. V4's 2MB PSRAM handles the S&F buffer (~11k messages). Built-in WiFi handles MQTT without a phone proxy. One device, three jobs.
No matching scenarios. Try a different search or filter.

Ready to prove you know your mesh?

The Node Star CNO certification tests the knowledge behind these settings — LoRa, routing, encryption, deployment strategy, and more. Knowledge-based, no gatekeeping.

Get certified → Handbook →
MeshCore · Settings Guide

What do you
want to do?

MeshCore is not Meshtastic. Different routing model, different config, different tradeoffs. Pick your scenario and get the right settings.

MeshCore uses path-based routing — not flood broadcast. Nodes must hear each other to establish paths. Repeaters are discrete roles. LoRa parameters are set manually — there are no named presets like "LongFast."
All Off-grid Repeater / infra Long range Power saving High density Room server Companion radio Privacy
Hiking & backcountry group
off-grid
Your group is spread across a trail with no cell service. Each person runs a CLIENT node paired to their phone via BLE. MeshCore routes messages directly between nodes that can hear each other.
Key settings (CLIENT node)
Node → RoleCLIENT
LoRa → Freq906.875 MHz
LoRa → BW / SF / CR250 / SF9 / 4:5
Tx Power20 dBm
BLE pairingEnabled
All nodes in the group must use identical LoRa parameters or they won't hear each other at all. Set one node first, then copy to the rest via the app.
Dedicated repeater node
infraoff-grid
A fixed node on a hilltop, rooftop, or ridge that extends range between clients who can't hear each other directly. This is the MeshCore equivalent of a Meshtastic ROUTER — but it's an explicit role, not a setting toggle.
Key settings (REPEATER node)
Node → RoleREPEATER
LoRa → BW / SF / CRMust match network
Tx Power27 dBm (max legal)
BLE / USBDisable after config
Sleep / low powerDisabled — always on
Repeaters don't pair to phones — they just forward traffic. Once configured, they run headless. Elevation is everything. A repeater 30m above surrounding terrain can extend reach more than any antenna upgrade.
!
Emergency comms deployment
off-gridinfra
Grid down, cell towers out. You're running a neighborhood or CERT net with CLIENT nodes distributed to residents and a REPEATER elevated somewhere central.
Repeater config
Node → RoleREPEATER
LoRa → BW / SF125 / SF10
Tx Power27 dBm
Client config
Node → RoleCLIENT
LoRa → BW / SFMust match repeater
SF10 / BW125 trades throughput for range — good for low-bandwidth check-in traffic across a neighborhood. Pre-configure all CLIENT nodes before the emergency. Distributing unconfigured hardware during a disaster is a real problem.
~50+ km
Maximum range link
long range
Two fixed nodes on towers or rooftops needing the longest possible link — connecting two remote sites, a mountain cabin to a valley base, or a distant relay into a network segment.
Key settings (both ends)
LoRa → BW125 kHz
LoRa → SFSF11 or SF12
LoRa → CR4:8 (most robust)
Tx Power27 dBm
AntennaHigh-gain directional
SF12 / BW125 gives maximum link budget (~157 dB) but throughput drops to ~250 bps. Fine for text check-ins. SF11 is usually the better call — nearly as much range, ~2x the throughput.
high density
High-density or urban deployment
high density
Many nodes in a small area — a festival, conference, or dense urban grid. You want faster airtime, lower collision risk, and better throughput at the cost of some range.
Key settings
LoRa → BW500 kHz
LoRa → SFSF7 or SF8
LoRa → CR4:5
Tx PowerReduce — 14–17 dBm
SF7 / BW500 is the fastest MeshCore LoRa config — ~20x the throughput of SF12 / BW125. Also reduce Tx power in dense scenarios: overpowered nodes drown out weaker signals and create dead zones.
ROOM_SERVER
Room server (group chat hub)
room serverinfra
A fixed node that hosts a named room — like a local channel or bulletin board. Clients connect to it to send and receive messages. Stores messages and distributes them even if clients missed the original broadcast.
Key settings
Node → RoleROOM_SERVER
Room nameSet a clear name
LoRa paramsMust match client nodes
Always-on powerRequired
Room servers are MeshCore's alternative to Meshtastic's "public channel" model — but more structured. Clients must explicitly join the room. This is also the node type to run when you want a local message hub that survives client disconnects.
CR mode MeshCore app
Companion radio (CR) mode
companion radio
The node acts as a "dumb pipe" LoRa modem tethered to your phone over USB serial or BLE. The MeshCore Android app drives all logic — the hardware is just the radio. This is the standard daily-carry setup.
Key settings
Node → RoleCLIENT (CR mode)
ConnectionUSB serial or BLE
LoRa paramsMatch the network
Node-side logicMinimal — app drives it
This is MeshCore's primary use pattern. The MeshCore Android app handles routing, encryption, and message storage. The node itself is closer to a radio transceiver than a smart device — unlike Meshtastic where the node can run semi-independently.
Solar-powered remote node
power savingoff-grid
An unattended node on a pole, rooftop, or trail junction running on solar and a small LiPo. It needs to survive days of low sun and transmit reliably for months without maintenance.
Key settings
Node → RoleREPEATER
Tx PowerOnly what you need
LoRa → SFSF10–SF11
BLEDisabled
LoRa transmit is the biggest current spike but BLE and active CPU idle are the biggest battery drains over time. Disable BLE entirely on solar nodes after initial config. Use a T-Beam with the AXP power IC for hardware-level power management.
E2E encrypted
Private / encrypted comms
privacy
MeshCore encrypts direct messages end-to-end by default using public key cryptography — no PSK required. This is a meaningful difference from Meshtastic's optional shared-key model.
Key settings
Direct messagesE2E encrypted (always)
Key exchangeAutomatic on first contact
Room messagesDepends on room config
FrequencyShared — anyone can receive
MeshCore DMs are encrypted by design. Anyone on the same LoRa parameters can still receive the encrypted packets — they just can't read them. For real op-sec, combine encryption with a non-default frequency plan.
No matching scenarios. Try a different search or filter.

Want the full picture on mesh protocols?

The Node Star Mesh Networking Handbook covers both Meshtastic and MeshCore — LoRa fundamentals, routing models, deployment strategy, and the tradeoffs between every protocol in the stack.

Get the handbook → Get certified →
Sideband / Reticulum · Setup Guide

What do you
want to build?

Reticulum is not a mesh radio protocol — it's a network stack. Sideband is just one app that runs on top of it. The power is in the interfaces. Pick your scenario and get the right configuration.

Reticulum runs on whatever transport you give it — LoRa via RNode, TCP/IP, serial, I2P, or all of them simultaneously. Config lives in ~/.reticulum/config on desktop, or in Sideband's interface settings on Android. Encryption is always on — there is no option to disable it.
All Off-grid / RNode Transport node Propagation Multi-interface Long range I2P / privacy Power saving NomadNet
Sideband RNode
First RNode setup with Sideband
off-grid
You have an RNode-flashed Heltec or T-Beam and you want to start sending messages through Sideband on Android. This is the baseline — one phone, one RNode, LoRa transport only.
Sideband interface config (Android)
Interface typeRNode LoRa Interface
ConnectionUSB serial or BLE
Frequency915.0 MHz (US)
Bandwidth125 kHz
Spreading FactorSF8
Coding Rate4:5
TX Power17 dBm
SF8 / BW125 is a solid starting point. Both nodes must use identical LoRa parameters. Reticulum won't decode packets from a mismatched config — it'll just ignore them silently.
transport = True Raspberry Pi
Transport node (relay / router)
transport
A Pi, old laptop, or any always-on Linux box that forwards Reticulum traffic between interfaces — bridging LoRa nodes to each other or to TCP. This is how you extend a Reticulum network without adding more LoRa hardware.
~/.reticulum/config
[reticulum] enable_transport = True share_instance = Yes [[RNode LoRa]] type = RNodeInterface interface_enabled = True port = /dev/ttyUSB0 frequency = 915000000 bandwidth = 125000 spreadingfactor = 8 txpower = 17
enable_transport = True is the single most important line. Without it, the node passes traffic for itself only. Run as a systemd service: sudo systemctl enable rnsd
LXMF store
LXMF propagation node
propagationtransport
A node that stores LXMF messages and delivers them when an offline recipient comes back online. This is Reticulum's store-and-forward layer — more robust and protocol-native than Meshtastic's S&F module.
Enable via lxmd daemon
# Install: pip install lxmf # Run alongside rnsd lxmd --propagation # Or in Sideband Android: # Settings → LXMF → Enable # propagation node = On # announce interval = 360s
Delivery methodDirect + Propagation
Preferred prop. nodeSet to known node hash
LXMF has two delivery modes: direct (immediate, node must be online) and propagation (queued, collected later). For resilient off-grid comms where nodes come and go, propagation is the right default.
60+ km SF12 / BW125
Maximum range RNode link
long rangeoff-grid
Two fixed nodes on towers or elevated structures needing the longest possible LoRa link — connecting remote sites, a valley base to a mountain relay, or a distant segment into your network.
RNodeInterface config (both ends)
frequency = 915000000 bandwidth = 125000 # 125 kHz spreadingfactor = 12 # SF12 = max range codingrate = 8 # 4:8 = most robust txpower = 22 # dBm
SF12 / BW125 gives maximum link budget (~157 dB) but throughput drops to ~250 bps. SF11 is usually the smarter call — nearly identical range, ~2x the throughput. Use directional antennas on fixed links.
RNS instance 2 interfaces LoRa TCP/IP internet
Multi-interface bridge (LoRa + TCP)
multi-interfacetransport
A node with both an RNode LoRa interface and a TCP interface. Local LoRa nodes automatically get paths to the broader Reticulum network — and vice versa. This is how you connect a radio mesh to the internet backbone.
~/.reticulum/config
[[RNode LoRa]] type = RNodeInterface interface_enabled = True port = /dev/ttyUSB0 frequency = 915000000 spreadingfactor = 8 bandwidth = 125000 txpower = 17 [[TCP Upstream]] type = TCPClientInterface interface_enabled = True target_host = reticulum.net target_port = 4242
With enable_transport = True, Reticulum automatically routes packets between interfaces — no extra config needed. LoRa nodes near this device suddenly have paths to every other Reticulum node on the internet.
I2P overlay
I2P transport integration
privacymulti-interface
Run Reticulum over I2P instead of clearnet TCP — or alongside it. Your node's IP address is never exposed. Traffic is routed through the I2P darknet. Useful for censorship-resistant or surveillance-resistant deployments.
~/.reticulum/config
# Requires I2P router on port 7656 (SAM) # i2pd or Java I2P [[I2P Interface]] type = I2PInterface interface_enabled = True peers = [] # Leave empty — auto-discovers # peers via I2P network
Reticulum has native I2P support — no tunneling hacks needed. Your node gets a stable I2P destination address. Combine with LoRa for a hybrid network: radio for local off-grid comms, I2P for anonymous long-distance reach.
rnsd
Solar-powered unattended transport
power savingtransport
A headless Pi Zero W with an RNode, running on solar and LiPo. Runs rnsd as a systemd service, forwards traffic between interfaces, and needs zero maintenance for months at a time.
Key config choices
enable_transportTrue
txpowerOnly what's needed
WiFi / BT on PiDisable — saves ~50mA
rnsd systemdEnabled + auto-restart
Pi Zero 2W idle is ~120mA. Disable HDMI (tvservice -o), BT, and unused USB. RNode TX is the spike — plan your battery around TX duty cycle, not idle current.
NomadNet → more
NomadNet pages node
NomadNettransport
Host pages — community bulletins, resource guides, local announcements — accessible to anyone on your Reticulum network, no internet required. Think of it as a dark-net local web, rendered in terminal or the NomadNet app.
Setup
# Install: pip install nomadnet # Pages live in: ~/.nomadnetwork/storage/pages/ # Start the node: nomadnet --daemon # Markup: Micron format # Heading: >heading text # Link: [label|destination_hash] # Bold: `Ftext`
NomadNet uses Micron markup — lightweight text that renders in terminal and GUI clients. Your node's page address is its Reticulum destination hash. A Pi running both rnsd and NomadNet becomes a local community hub — no internet, no server, no DNS.
No matching scenarios. Try a different search or filter.

Want the deep dive on Reticulum and RNodes?

The Node Star Field Guide Vol. 1 covers RNode setup, Reticulum configuration, and running a resilient off-grid network from scratch. And the Handbook covers the full protocol stack.

Vol. 1 Field Guide → Handbook →