Fixes for common setup and connectivity issues.
In the MeshCore companion app, go to Tools → Discover Regions. This scans for nearby repeaters and shows which region tags they're actively carrying — so you can see what scopes are live within RF range before setting one on a channel. Useful for verifying your own repeater is advertising the right tags, or for checking what a new site supports before coordinating traffic.
Source: gessaman.com/meshcore/regions/ — "Tools → Discover Regions scan to see which region tags are live nearby"
Most radios ship defaulting to a different band — check your radio settings and confirm the channel and frequency are configured correctly for the Palouse mesh. If you haven't done this yet, work through Client Setup first; the full radio settings are covered there.
More troubleshooting steps coming soon.
Starting or growing a mesh in another region? Things worth getting right early, with sources to back each one up.
MeshCore has changed meaningfully between firmware releases. A confirmed example from PUW testing: repeaters on v1.15 require a full reboot to activate a newly-added region scope — v1.16 applies it live without a reboot. Mixed-version networks can produce confusing behavior where a region "should" work but silently doesn't. The protocol itself supports variable-length node hash sizes (1–3 bytes, encoded per-packet via the path length byte) — older firmware may not negotiate these correctly with newer nodes.
Sources: PUW scope test results — v1.15 vs v1.16 behavior (live packet data, June 2026) · DeepWiki §7 — path hash size encoding
A repeater that physically bridges two metro areas (e.g. a hilltop heard by both Moscow and Spokane) is the most important node to get right. gessaman documents three strategies: (1) carry only state-level ancestry for dedicated long-haul links; (2) single-metro affiliation even with broad RF reach — for high-sites that primarily serve one metro; (3) dual-metro affiliation for repeaters with a genuine bridging role. Don't default to dual-carry on everything: "RF reach is not scope boundary."
Every repeater — regardless of antenna height or coverage area — should carry its full region ancestry (e.g. west · pnw · wa · e-wa · puw). "Limited RF range is not a reason to strip tags." A neighborhood node not carrying its full ancestry chain cuts off devices that reach the mesh through it from region-scoped traffic.
Source: gessaman.com/meshcore/regions/ — Cross-Boundary Regional Links & repeater tagging strategies
A scope set on one channel only limits flood propagation if the repeaters in the path don't carry that scope. If a wildcard repeater (one that forwards all TRANSPORT_FLOOD packets regardless of TC₁) sits anywhere in the path, it passes the flood through unchecked — negating the scope entirely. From PUW testing: CB59 was confirmed to be wildcard — it relayed all tested scopes regardless of its configured region list. A single uncoordinated wildcard node in a multi-hop path defeats scope containment.
This matters especially for communities using scope to limit bot traffic or noisy channels to a local area — it only works if every repeater in the propagation path is configured consistently, or explicitly deny-floods that scope.
Sources: PUW isolation tests — CB59 wildcard behavior confirmed · Scopes page — practical takeaways
gessaman's guidance: "Scope as narrowly as the conversation warrants. Metro scope for local chat is the right default." Sending a local weather update scoped to pnw when puw would do floods the entire Pacific Northwest unnecessarily. Recommended scope ladder: metro tags for general public chat → state/provincial tags for statewide announcements → pnw for cross-regional emergencies only → west for mesh-wide announcements only.
Source: gessaman.com/meshcore/regions/ — Region Scoping Recommendations
Bots sending unscoped floods propagate mesh-wide — a weather bot for one city shouldn't flood the entire PNW. gessaman's guidance: "A weather bot for Seattle should scope to #sea, not #wa or #pnw. Scope as narrowly as practical." Use dedicated hashtag channels for bot output (e.g. #bot-palouse) — this allows repeaters and users to filter or deny-flood bot traffic independently of general channels. Configure a flood_scope matching the bot's actual service area.
Source: gessaman.com/meshcore/regions/#bot-behavior-with-regions
Metro region tags are typically derived from the nearest airport's IATA code — but not every airport code is unambiguous. The Tri-Cities area is a real example: RLD (Richland) is the code already used in MeshMapper's map and leaderboard data, but the proposed MeshCore region tag for Pasco/Tri-Cities is PSC (Pasco's IATA code). Using RLD as a region tag would create confusion with MeshMapper leaderboard data and make your scope incompatible with the rest of the PNW community's naming. Pick one code and make sure MeshMapper and MeshCore agree on it before nodes start advertising it.
Boundaries matter too. MeshMapper supports three ways to define a region's geographic footprint: a radius around a point, a manually-drawn polygon, or a geoJSON polygon — which the MeshMapper wiki calls "the recommended method for regions with complex borders and/or adjacent neighbors (with coordination)." geoJSON boundaries can be prepared from GIS data (e.g. county shapefiles in QGIS, exported to geoJSON) and imported directly into the MeshMapper admin panel. The wiki explicitly says: "it is strongly recommended to coordinate with neighboring region administrators when planning region boundaries" — coordinated geoJSON edges mean seamless wardriving handoffs across regions without the app needing manual intervention.
Before settling on a tag for a new metro, check: (1) what IATA code MeshMapper already uses for that city, (2) whether another community has already staked a MeshCore region tag, (3) the gessaman region hierarchy — it documents existing PNW community tags and is the de facto coordination point, and (4) define and share a geoJSON boundary with adjacent region admins before going live.
Sources: wiki.meshmapper.net/region_boundaries/ — geoJSON boundary definition & coordination guidance · gessaman.com/meshcore/regions/ — PNW region name registry & hierarchy
Rather than hand-typing region def commands and risking a mis-ordered hierarchy, gessaman's interactive config generator produces ready-to-paste CLI commands from your repeater's location and type (home node vs. high-site). Repeater type drives whether you get single-metro or multi-metro tags — but the deciding factor is always your actual location relative to metro boundaries, not antenna height.
Source: gessaman.com/meshcore/regions/config/ — Region Config Generator