# Planning Your Network

# Is There Already a Network in Your Area?

## Is There Already a Network in Your Area?

Before starting a new mesh network, check whether an existing network already covers your area. Joining an established network is almost always better than starting from scratch - you immediately have more repeaters, a larger community, and tested infrastructure.

### How to Check

#### Live Node Maps

- [map.meshcore.io](https://map.meshcore.io) - live worldwide MeshCore nodes
- [meshmap.net](https://meshmap.net) - worldwide Meshtastic nodes that uplink to the public MQTT server (community map; nodes with MQTT uplink off do not appear)
- [map.wcmesh.com](https://map.wcmesh.com) - West Coast Mesh node map

#### Community Search

- Search Discord for "\[your city/state\] mesh" or "\[your city/state\] meshtastic"
- Search Reddit for r/meshtastic or r/meshcore posts in your area
- The official MeshCore project Discord is at [meshcore.gg](https://meshcore.gg) - ask in a general channel if anyone covers your area. For RegionMesh-specific coverage questions, use [RegionMesh](https://wiki.meshamerica.com/books/north-american-networks/page/regionmesh)'s own community channels (regionmesh.com/community).

### Existing Networks by Region

<table id="bkmrk-regionnetworkwebsite"> <thead><tr><th>Region</th><th>Network</th><th>Website</th></tr></thead> <tbody> <tr><td>Nationwide US</td><td>RegionMesh</td><td>[regionmesh.com](https://regionmesh.com)</td></tr> <tr><td>North Dakota &amp; surrounds</td><td>[NoDakMesh](https://wiki.meshamerica.com/books/north-american-networks/page/nodakmesh)</td><td>[nodakmesh.org](https://nodakmesh.org)</td></tr> <tr><td>West Coast</td><td>WCMesh</td><td>[wcmesh.com](https://wcmesh.com)</td></tr> <tr><td>Pacific Northwest</td><td>[CascadiaMesh](https://wiki.meshamerica.com/books/north-american-networks/page/cascadiamesh)</td><td>[cascadiamesh.org](https://cascadiamesh.org)</td></tr> </tbody></table>

### If No Network Exists

If you genuinely can't find an existing network in your area, you have the opportunity to start one. A few considerations:

- **Start with RegionMesh:** If in the US, consider deploying MeshCore repeaters that join RegionMesh rather than a proprietary local network. You get national infrastructure from day one.
- **Two nodes minimum:** A single repeater is not a "network." You need at least two nodes to demonstrate mesh functionality and attract more participants.
- **Elevation first:** Your first repeater should be your highest-elevation option. One hilltop repeater can enable dozens of low-elevation nodes to communicate.
- **Document your settings:** Publish your channel name, frequency, and preset on a simple webpage or in a Discord server so others can join.

# Choosing Your Protocol and Channel

## Choosing Your Protocol and Channel

The two dominant LoRa mesh protocols for community networks are **MeshCore** and **Meshtastic**. They are not interoperable - nodes must use the same protocol to communicate.

### Protocol Comparison

<table id="bkmrk-featuremeshcoremesht"> <thead><tr><th>Feature</th><th>MeshCore</th><th>Meshtastic</th></tr></thead> <tbody> <tr><td>Infrastructure model</td><td>Dedicated repeaters + companion nodes</td><td>Peer-to-peer; any node can relay</td></tr> <tr><td>Room servers</td><td>Yes - built-in store-and-forward</td><td>No full equivalent (an optional Store &amp; Forward module on a PSRAM node is a partial analog, not a room-server/bulletin board)</td></tr> <tr><td>MQTT gateway</td><td>Community brokers (e.g. letsmesh.net, meshmapper.cc)</td><td>Official public broker (mqtt.meshtastic.org)</td></tr> <tr><td>Regional scoping</td><td>Yes - operator-defined region labels (lowercase alphanumeric + hyphen, max 29 bytes) hashed to 2-byte transport codes; no official registry or ISO standard</td><td>No</td></tr> <tr><td>App</td><td>MeshCore companion app</td><td>[Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) (iOS/Android)</td></tr> <tr><td>Hardware compatibility</td><td>Commonly ESP32 and nRF52840 boards with SX1262 radio (e.g. Heltec V3, RAK4631, T114, T-Beam); some SX1276 boards are also supported. Verify the current board list at flasher.meshcore.io / docs.meshcore.io.</td><td>ESP32 and nRF52 boards</td></tr> <tr><td>Large existing network</td><td>[RegionMesh](https://wiki.meshamerica.com/books/north-american-networks/page/regionmesh) (a growing national MeshCore network; see the live map at regionmesh.com for current coverage)</td><td>Meshtastic worldwide (meshmap.net, a community map - the official map link is on meshtastic.org)</td></tr> </tbody></table>

### General Guidance

- If your area has an existing **RegionMesh** presence or you want to contribute to a nationwide infrastructure, choose **MeshCore**.
- If your community already uses Meshtastic or you need nRF52 hardware compatibility, choose **Meshtastic**.
- Running both is possible but means operating two separate device fleets (the protocols cannot share a radio), which adds operational complexity.

### Channel Selection for MeshCore

Most North American MeshCore networks use the **USA/Canada preset**: 910.525 MHz / 62.5 kHz BW / SF7 / CR5 (as of 2026-06). This is the default for RegionMesh and many other communities; confirm current settings with your local network before deploying, as presets are periodically revised.

If your area has a pre-existing local MeshCore deployment on different settings, match those settings to join that network. Check locally first - then default to the USA/Canada preset.

### Channel Selection for Meshtastic

- **LongFast preset** is the documented Meshtastic default and the most widely used (as of 2026-06); some communities migrate to MediumFast/MediumSlow as they grow.
- Default channel key: `AQ==` (the publicly known default key, base64 for the single byte 0x01 - default-channel traffic is readable by any Meshtastic node)
- Hop limit: 3 (default; increase only if you have specific reason to)

Do not use a custom channel key unless your community has a specific reason to create a private channel. Using the default key ensures maximum interoperability with travelers and other local nodes.

# Setting Channel Keys and Network Identity

Your channel configuration defines who can communicate on your mesh. Getting it right from the start saves painful re-configuration later as your network grows.

## Understanding Channel Keys

Both Meshtastic and MeshCore use a shared channel key (Pre-Shared Key or PSK) that all nodes on a given channel must share to communicate. The key serves two functions:

- **Confidentiality** - Nodes without the key cannot decode messages, preventing outsiders from reading your mesh traffic. Note this is confidentiality, **not authentication**: because every member shares the same key, any member can forge or impersonate messages on the channel. A shared PSK does not prove who sent a message.
- **Network segmentation** - Multiple community networks can coexist on the same frequency by using different keys

**Important:** If you use the Meshtastic default key ("AQ==", which is base64 for the single byte 0x01 - the publicly known default key, *not* "all-zeros"), the firmware expands it into the well-known default PSK and your messages are readable by every Meshtastic node in range. For a community network, always set a custom channel key.

## Generating a Strong Channel Key

Meshtastic channel encryption uses AES-256-CTR when a 32-byte (256-bit) key is used. Custom PSKs can be 0, 128-bit (16 bytes), or 256-bit (32 bytes). Generate a strong 256-bit key:

```
# Generate a random 256-bit key (32 bytes, base64 encoded)
python3 -c "import os, base64; print(base64.b64encode(os.urandom(32)).decode())"
```

## Distributing Channel Keys

Methods for sharing your channel key with new members:

- **QR code** - Meshtastic generates a channel QR code that encodes the full channel configuration (name, key, modem preset). Share via your website or print at events. The most convenient method.
- **Deep link URL** - Meshtastic channel QR codes encode as an HTTPS web URL of the form `https://meshtastic.org/e/#<base64url>`, with the channel settings carried in the URL fragment after the `#`. Can be posted as a clickable link in your community documentation.
- **Manual entry** - For MeshCore and technical users, document the key as a base64 string in your private community documentation.

**Key distribution security:** Your channel key doesn't need to be secret from trusted community members, but don't publish it on your public website. Share it in your community Discord/Signal or at in-person events.

## Multi-Channel Strategy

Consider running multiple channels for different purposes:

<table id="bkmrk-channel-namekeypurpo"><thead><tr><th>Channel Name</th><th>Key</th><th>Purpose</th></tr></thead><tbody><tr><td>Community-Public</td><td>Published freely</td><td>General community chatter, newcomer welcome</td></tr><tr><td>Community-Ops</td><td>Members only</td><td>Network operations, node status updates</td></tr><tr><td>EmComm</td><td>Emergency teams only</td><td>Your group's own coordination and drills (see caveat below)</td></tr></tbody></table>

**EmComm channel caveat:** A private "EmComm" channel is fine for your own group's coordination and drills under unlicensed Part 15 (915 MHz ISM) operation, but it is **not** a substitute for authorized public-safety or amateur-radio emergency channels. Two limits apply: an encrypted channel **cannot** be used by stations operating under amateur radio (Part 97), which prohibits messages encoded to obscure their meaning; and formal ARES/RACES/served-agency traffic must stay on authorized, often monitorable channels. During a real activation, follow your served agency's and ARES/RACES communication plan rather than relying on a private encrypted hobby-mesh channel.

## Network Name and Node Naming Conventions

Establish naming standards early. Consistent naming makes the node list immediately informative:

- **Meshtastic long name format:** \[City/Area\]-\[Location\]-\[Type\] - e.g., "PDX-WestHills-Repeater" or "SEA-Capitol-Hill-Node"
- **Short name** (4 bytes): Use initials + number - "WH01", "CH02"
- **Repeater nodes:** Include "Rpt" or "Rep" in the name to distinguish from client nodes
- **Room servers:** Include "RS" - "PDX-RS01"

# Infrastructure Agreements and Permissions

Getting your repeater or backbone node onto high-elevation infrastructure dramatically improves coverage - but it requires agreements with property owners. (High-elevation, line-of-sight siting is core Meshtastic guidance; see the [Meshtastic siting tips](https://meshtastic.org/docs/configuration/tips/).)

## Types of Infrastructure Sites

The best sites for backbone nodes (roughly in order of typical access difficulty):

1. **Your own property** - On property you own you generally need no third-party agreement, but it is not automatically unrestricted: check HOA covenants, local zoning/permit rules for antenna masts, and (if you rent, or for a friend's house) the applicable lease. Start here: your house, or a friend's house with a tall tree or roof peak.
2. **Amateur radio repeater sites** - Existing ham radio clubs often have hilltop sites with tower space, power, and sometimes internet. Approach club leadership to discuss hosting. Note: default Meshtastic runs in the license-free 902-928 MHz ISM band (Part 15), where there is no ham frequency coordination and encryption is allowed. Formal ham-frequency coordination only applies if you operate in HAM mode under Part 97 (licensed, and encryption is not permitted) - clarify which regime applies before discussing "frequency coordination."
3. **Commercial buildings** - Restaurants, shops with flat roofs. Pitch: "We're a community communications nonprofit. We'd like to install a small weatherproof box the size of a paperback book on your rooftop. No wiring to your building, runs on its own battery/solar." Expect the owner to ask for proof of commercial liability insurance naming them as additional insured (see Insurance Considerations below).
4. **Municipal property** - Parks department, public works, and fire departments sometimes allow installations for emergency-preparedness benefit, but expect a formal license/use agreement requiring proof of commercial liability insurance (municipality named as additional insured), an indemnification clause, and sometimes risk-management or council approval - not just an informal MOU. Highly jurisdiction-dependent.
5. **Water towers** - Managed by municipal water utilities, and among the highest-liability, hardest-to-permit sites. Utilities universally require commercial general liability insurance naming the utility as additional insured, a formal site/license agreement, and often background checks and trained climbers, because access involves fall hazards and potable-water security. Do not treat a water tower as an informal site.
6. **Cell towers** - Carrier-grade macro tower and managed-rooftop colocation typically runs $1,000-$3,000+/month (urban higher); small-cell sites run roughly $100-$250/month. More importantly, many tower operators will not lease space for a device this small at any price - treat commercial tower colocation as a last resort. Amateur-radio repeater sites and municipal buildings are far more accessible.

## What to Include in a Site Agreement

Even for informal arrangements, a simple one-page written agreement protects both parties:

- Description of the hardware (size, weight, power source)
- Exact mounting location
- Duration (1 year renewable, or at-will with 30-day notice)
- Your responsibility for maintenance and removal
- Liability and insurance - the operator/nonprofit carries Commercial General Liability insurance and will name the property owner as additional insured on request (specify coverage limits). Note: a written agreement does not by itself transfer liability for structural/roof damage or injury during access; adequate insurance does.
- Contact information for both parties

## Insurance Considerations

Most institutional partners will ask whether you carry liability insurance. Coverage scope varies - confirm specifics with a licensed agent before relying on any policy. Options:

- **ARRL Affiliated-Club Liability Insurance** - ARRL does *not* provide individual members with liability insurance. ARRL administers a separately-purchased Club Liability Insurance Program (up to ~$2,000,000/year aggregate) for ARRL-Affiliated amateur radio clubs - the club buys and pays for the policy (roughly $200/year). It is not an automatic individual-membership benefit and does not cover a personal repeater site. An individual host or operator needs their own Commercial General Liability coverage; confirm scope at arrlinsurance.com.
- **Nonprofit general liability (CGL) policy** - The primary coverage most hosts will ask for. If you've formed a 501(c)(3), small-org premiums vary, commonly a few hundred to low thousands of dollars per year (industry average ~$500/year per Insureon, 2026), depending on limits, activity, and whether additional-insured endorsements are needed. Get a quote rather than budgeting from a rule of thumb. (An "umbrella" policy is separate excess coverage layered on top of CGL, not the primary policy itself.)
- **Personal homeowner/renter's policy** - Generally does *not* cover a transmitter you install and operate on a third party's commercial, municipal, or utility property, and cannot add the owner as an additional insured (which water towers and municipalities require). Such policies cover your own residence and personal liability and routinely exclude business pursuits and hosted third-party equipment. For installations on someone else's property you need a Commercial General Liability (CGL) policy - typically held by the nonprofit - that can name the site owner as additional insured.

## Maintaining Relationships with Site Hosts

- Annual "thank you" message or card
- Invite them to community events
- Update them when you add features or upgrade hardware
- Be responsive if they ever have concerns - a 24-hour response time builds trust
- Proactively reach out before any work at the site; never surprise a host