Configure a standard MeshCore repeater to join the Palouse Mesh network. No Wi-Fi or MQTT required — this is a radio-only node.
For Steps 1–4, use the Repeater Setup button on meshcore.io/flasher — it provides a guided web form that handles radio settings, identity, timezone, and coordinates without typing CLI commands. It's a good way to get familiar with what each field does.
For Steps 5 onwards, the Console is strongly recommended — enter commands directly on the same page. You can also make the equivalent changes through the app's settings menus if you prefer, but the Console is faster and less error-prone.
Each step builds on the last — especially the region hierarchy commands, which must be entered in the exact sequence shown. Skipping or reordering steps will result in a misconfigured node.
Go to meshcore.io/flasher, find your hardware, and select the repeater firmware variant. No local toolchain required.
Once flashed, use the Console or Repeater Setup buttons in the top-right of the same page to connect to your device and enter the commands below.
Frequency, bandwidth, and spreading factor must match exactly across all nodes on the network — these define the physical-layer channel and a mismatch means nodes cannot hear each other at all.
# US/Canada LoRa preset — 910.525 MHz, BW62.5, SF7, CR5
set radio 910.525,62.5,7,5
set tx 22
Set the node name and an admin password. The admin password is required for anyone to manage the repeater remotely.
set name [your node name] set admin.password [CHANGE]
If replacing an existing node and want to preserve its network footprint, inject the private key from the old device before rebooting.
set prv.key [128-character hex key from old node]
Setting coordinates places your node on the network map. Can also be set via the observer.gessaman.com interface. For residential deployments, consider offsetting by a block or two for privacy — a general location is still useful for coverage and routing, so it doesn't need to pin your exact home or property. If you offset the position, use a similar elevation to your actual site so distance/terrain estimates stay realistic.
set lat [decimal latitude] set lon [decimal longitude]
Switches from 1-byte to 2-byte path hashing. The value is zero-indexed — mode 1 = 2 bytes. With 1-byte hashing, collisions degrade routing accuracy on any real-sized network.
| Value | Bytes | Unique values | Notes |
|---|---|---|---|
| mode 0 | 1 | 256 | Default — collisions on any real network |
| mode 1 ✓ | 2 | 65,536 | Recommended for Palouse region |
| mode 2 | 3 | 16,777,216 | Large networks only |
set path.hash.mode 1
Tells the mesh where this node sits geographically, so traffic can be scoped appropriately. The single-line region def setup below requires firmware v1.16.0+ — older firmware (v1.14.x/v1.15.x) can do this too, just with a more involved per-line region put process. Select your firmware version below.
region def west pnw wa se-wa puw|pnw palouse|wa e-wa
region save
west · pnw · wa · se-wa · puw + palouse · e-wa (extra carries, not part of the chain)west
pnw
palouse
wa
se-wa
puw
e-wa
palouse and e-wa are shown inline above as siblings of wa / se-wa — since siblings don't inherit from each other, both still need the explicit extra carry in the region def above, not just a place in the tree.
region def west pnw id n-id lws|pnw palouse
region save
west · pnw · id · n-id · lws + palouse (extra carry, not part of the chain)west
pnw
palouse
id
n-id
lws
palouse is shown inline above as a sibling of id — since siblings don't inherit from each other, it still needs the explicit extra carry in the region def above, not just a place in the tree.
region def west pnw or c-or pdt|pnw palouse
region save
west · pnw · or · c-or · pdt + palouse (extra carry, not part of the chain)west
pnw
palouse
or
c-or
pdt
palouse is shown inline above as a sibling of or — since siblings don't inherit from each other, it still needs the explicit extra carry in the region def above, not just a place in the tree.
v1.15.x doesn't support the single-line region def shortcut above. Build the same hierarchy one region put <child> <parent> line at a time, then save — put grants flood permission automatically on this version. Same end result, same palouse / local-scope tags.
region put west
region put pnw west
region put wa pnw
region put se-wa wa
region put puw se-wa
region put palouse pnw
region put e-wa wa
region save
west · pnw · wa · se-wa · puw + palouse · e-wa (extra carries, not part of the chain)region put west
region put pnw west
region put id pnw
region put n-id id
region put lws n-id
region put palouse pnw
region save
west · pnw · id · n-id · lws + palouse (extra carry, not part of the chain)On v1.14.x, region put alone does not grant flood permission — each level needs its own region allowf <name> right after the matching put, before moving to the next level.
region put west
region allowf west
region put pnw west
region allowf pnw
region put wa pnw
region allowf wa
region put se-wa wa
region allowf se-wa
region put puw se-wa
region allowf puw
region put palouse pnw
region allowf palouse
region put e-wa wa
region allowf e-wa
region save
west · pnw · wa · se-wa · puw + palouse · e-wa (extra carries, not part of the chain)region put west
region allowf west
region put pnw west
region allowf pnw
region put id pnw
region allowf id
region put n-id id
region allowf n-id
region put lws n-id
region allowf lws
region put palouse pnw
region allowf palouse
region save
west · pnw · id · n-id · lws + palouse (extra carry, not part of the chain)No older-firmware block for the Oregon-side hierarchy yet — check back, or build it manually from the region def string above using the same per-level put (and, on v1.14.x, matching allowf) pattern.
When someone sends a message scoped to puw, only repeaters that explicitly carry puw will forward it. There is no automatic inheritance — a node carrying wa but not puw will not forward puw-scoped traffic. Every ancestor in the chain must be listed.
For a full breakdown of what each tag means and the complete per-side hierarchy, see the Regions page.
region def hierarchy above, scoped bots (weather, road conditions), and channels like #thepalouse and #bot-palouse which carry palouse scope.
The configuration above is for a general repeater. Nodes on a peak, hilltop, tower, or ridgeline with wide-area RF coverage that straddles a region boundary should consider carrying the bordering region tag(s) as well — so traffic scoped to a neighboring community can still route through the node.
An Idaho-side high site reaching toward Washington should consider also carrying wa, e-wa, se-wa, and puw alongside its own lws / id / n-id tags; a WA-side high site reaching toward Idaho should consider also carrying lws, id and n-id alongside its own puw / wa / se-wa / e-wa tags. On a site that can't actually reach that far, the extra scopes would just add noise. See the Regions page for the full picture.
Campus nodes are a separate case, not part of the standard config above: a dedicated wsu child scope nests under e-wa (WSU Pullman, live), and a proposed uofi child scope would nest under n-id (University of Idaho, Moscow). These keep campus mesh traffic on campus without flooding the broader scope, and only apply to nodes explicitly part of that campus deployment. See Roadmap — Campus Coverage for how a campus group can get set up with one.
Restart to initialize the radio with the committed configuration.
reboot
After reboot, verify:
get name — confirms identity loadedget radio — confirm frequency and settingsget path.hash.mode — should return 1Before advertising, sync the node's clock via the app: log into your repeater, go to Settings → Sync Clock. Then send an advertisement so observer nodes on the network can hear you:
advert
If you're within RF range of an observer node, your node should appear on the live network map within a few seconds. Check it at map.palouse-mesh.net — or open the Live Map here.
Your node is up and routing traffic — a few extra habits keep it a good citizen on the network and make life easier for you if something ever goes wrong.
Enable telemetry, and add your contact info as the node owner so people can reach you if there's ever an issue. Many owners use a separate address (e.g. Proton) for this to keep it off their main identity.
Put a recognizable general location in the node's name and pin it on the map at roughly the right spot (see Step 4). Other node owners use both to reason about coverage and routing — a vague or missing location makes that guesswork. Keep it general rather than your exact home/property coordinates, and match the elevation of your real site so the numbers stay useful.
Before finalizing — and after any reboot — sync the node's clock before sending an advert. An accurate clock keeps timestamps and diagnostics trustworthy across the network.
Region tags, firmware quirks, antenna placement — none of it needs to be figured out solo. Post in the Facebook group or Signal chat — the community would rather help early than untangle a misconfigured node later.