Starting a Community Mesh How to bootstrap a new regional mesh network and grow your community. 📖 Start Here — Starting a Community Mesh Guide This book is for people who want to start or grow a LoRa mesh community - from bootstrapping the first nodes to governing a multi-network region. 🚀 Starting From Zero How do I start a mesh network where there are none? (FAQ) Starting from Zero: Your First Repeater Is There Already a Network in Your Area? Choosing Your Protocol and Channel 📚 What's In This Book Planning Your Network Setting Channel Keys and Network Identity Infrastructure Agreements and Permissions - Site host relationships, rooftop access Growing Your Community Finding Volunteers and Repeater Sites Recruiting Repeater Hosts Onboarding New Members Effectively Community Events and Meetups Running Mesh Events and Demonstrations Network Hygiene and Documentation Naming Conventions and Network Hygiene Network Documentation Standards Handling Network Growth and Congestion Community Operations Community Governance and Decision-Making Emergency Preparedness Integration Using RegionMesh Geographic Scoping ➡️ Related Books North American Networks - See what existing communities have done Network Planning - Technical planning tools Emergency Communications - EmComm integration with community networks 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.dev - live worldwide MeshCore nodes meshmap.net - live worldwide Meshtastic nodes 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 RegionMesh Discord at meshcore.gg - ask in a general channel if anyone covers your area Existing Networks by Region Region Network Website Nationwide US RegionMesh regionmesh.com North Dakota & surrounds NoDakMesh nodakmesh.org West Coast WCMesh wcmesh.com Pacific Northwest CascadiaMesh cascadiamesh.org 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 Feature MeshCore Meshtastic Infrastructure model Dedicated repeaters + companion nodes Peer-to-peer; any node can relay Room servers Yes - built-in store-and-forward No native equivalent MQTT gateway Community brokers (letsmesh.net) Official public broker (mqtt.meshtastic.org) Regional scoping Yes - ISO 3166-2 region system No App MeshCore companion app Meshtastic app (iOS/Android) Hardware compatibility ESP32 and nRF52840 boards with SX1262 radio (Heltec V3, RAK4631, T114, T-Beam v1.2+) ESP32 and nRF52 boards Large existing network RegionMesh (2,500+ US repeaters) Meshtastic worldwide (meshmap.net) 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 with dedicated gateway hardware, but 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. This is the default for RegionMesh, NoDakMesh , and others. 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 most common - used by NoDakMesh's Meshtastic segment and many other communities. Default channel key: AQ== 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: Authentication - Nodes without the key cannot decode messages, preventing outsiders from reading your mesh traffic Network segmentation - Multiple community networks can coexist on the same frequency by using different keys Important: If you use the Meshtastic default key ("AQ==" / all-zeros), 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 # 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 QR codes encode as URLs (meshtastic:///...). 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: Channel Name Key Purpose Community-Public Published freely General community chatter, newcomer welcome Community-Ops Members only Network operations, node status updates EmComm Emergency teams only Activated during drills and real events 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 chars max): 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. Types of Infrastructure Sites The best sites for backbone nodes (roughly in order of typical access difficulty): Your own property - No permission needed. Start here: your house, a friend's house with a tall tree or roof peak. Amateur radio repeater sites - Existing ham radio clubs often have hilltop sites with tower space, power, and sometimes internet. Approach club leadership and offer to coordinate frequencies. 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." Municipal property - Parks department, public works, and fire departments sometimes allow installations for emergency preparedness benefit. Requires formal request and sometimes a simple MOU. Water towers - Managed by municipal water utilities. Most require insurance documentation and a formal site agreement. Cell towers - Possible but expensive. Tower lease rates start at $500-2000/month. 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 limitation (you carry renter's/general liability insurance) Contact information for both parties Insurance Considerations Most institutional partners will ask whether you carry liability insurance. Options: ARRL membership - Provides $1M liability insurance for ham radio operations. Relevant if your network has ham involvement. Nonprofit umbrella policy - If you've formed a 501(c)(3), a nonprofit general liability policy is typically $400-800/year for small organizations. Personal homeowner/renter's policy - Sometimes covers volunteer activities; check with your insurer. 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 Growing Your Community Finding Volunteers and Repeater Sites Finding Volunteers and Repeater Sites The practical limit on any mesh network's coverage is the number and location of repeaters. Growing a community mesh means finding both people willing to host hardware and locations with good RF exposure. Identifying Good Repeater Sites The best repeater sites share these characteristics: Elevation: Hilltops, building rooftops, water towers - any location that has line-of-sight to a wide area Permanent power: AC power or solar with battery backup means no maintenance visits for power Internet connectivity: Enables MQTT gateway functionality and remote management Willing host: Someone at the location who can assist with initial install and occasional physical access Where to Find Volunteers Amateur radio clubs: Many hams are already interested in digital modes and emergency communications; LoRa mesh is a natural extension Community preparedness groups: CERT, neighborhood emergency response teams, and ARES/RACES members often see immediate value in mesh Tech and maker communities: Hackerspaces, makerspaces, and local tech meetups Existing mesh Discord servers: RegionMesh and other communities often have "looking for volunteers in [state]" channels The Repeater Volunteer Pitch The cost and effort for a volunteer are minimal. Emphasize: Hardware cost: ~$20 - $30 for a Heltec V3 Power draw: under 1 watt continuous (negligible electricity cost) Maintenance: essentially zero once installed and configured Contribution: one rooftop repeater can cover an entire neighborhood RegionMesh Volunteer Process If you're deploying under RegionMesh, the official 5-step volunteer repeater process is documented in the RegionMesh Discord at meshcore.gg . Following this process ensures your repeater is registered and visible to the broader community. Tracking Your Network As you grow, keep a simple inventory of deployed nodes: location, hardware, firmware version, radio settings, and host contact. This becomes critical for maintenance, upgrades, and troubleshooting. Using RegionMesh Geographic Scoping Using RegionMesh Geographic Scoping As your community grows within the larger RegionMesh national network, geographic scoping helps you manage channel capacity and create region-specific communications without polluting the national mesh. The Problem Scoping Solves On a nationwide mesh, every message without a scope floods all connected repeaters from Maine to California. This works fine for a small network, but as the network scales to thousands of repeaters, cross-country traffic consumes significant channel capacity. A neighborhood alert in Fargo, ND doesn't need to be relayed through repeaters in Miami. How to Enable Regional Scoping On each repeater in your regional network, configure the relevant region codes: region put us region put us-nd region save advert This example configures a North Dakota repeater to serve both national US traffic and North Dakota-scoped messages. Creating a Regional Channel When your users send messages with the us-nd (or your region) scope set, those messages are only forwarded by repeaters that have that region configured. This creates an effective regional "channel" over the national infrastructure without requiring separate hardware or frequencies. Registering a Metro Code If your community covers a metro area not served by a state code alone (e.g., Dallas/Fort Worth spans multiple states), you can propose a community metro code. The process: Join the RegionMesh Discord at meshcore.gg Propose the code in the appropriate channel (format: lowercase, max 29 bytes, e.g., us-dfw ) Achieve community consensus among local mesh operators The code is then registered and documented for others to use Existing Metro Codes us-dfw - Dallas/Fort Worth us-bay - San Francisco Bay Area us-atl - Greater Atlanta See the RegionMesh Discord for the current complete list. Onboarding New Members Effectively Your onboarding process determines whether new members stay active or quietly disappear after their first week. A smooth, welcoming, and technically successful first experience converts curious newcomers into committed network participants. The Onboarding Journey Discovery - They learn the network exists Acquisition - They obtain hardware Configuration - They get the node on the network First contact - They exchange messages with another member Deeper engagement - They explore features, attend events, consider contributing infrastructure Hardware Recommendations Standardize on 1-2 recommended hardware options. Current recommended starter kit: Budget option: Heltec WiFi LoRa 32 V3 (~$18) - USB-C, built-in OLED, no GPS. Good for indoor/desktop use. All-in-one option: LILYGO T-Beam (~$40) - GPS built in, battery connector, excellent for portable use Premium: RAK WisBlock Starter Kit (~$60-80) - Modular, excellent build quality, best for fixed outdoor installations Pre-Configured Firmware Distribution Create a saved configuration file with your community channel key, frequency preset, and node naming convention pre-filled Host it on your community wiki or website Link to meshtastic.org flasher with your settings pre-loaded Document: "Flash this firmware, scan this QR code, done." - Three steps maximum. First-Week Checklist for New Members Node powered on and flashed with community firmware Channel key loaded (via QR code scan or manual entry) Node name set to community naming convention Sent a test message received by at least one other member Joined community Discord/Signal channel Node visible on meshmap.net or community map Assign a "buddy" - an experienced member who agrees to be on-call for a new member's first week. A quick DM check-in on day 3 dramatically improves retention. Managing Stale and Orphaned Nodes Every network accumulates abandoned nodes - nodes still visible on the map but owned by someone who has moved on. Management strategies: Annual "node census" - Message all known node operators, ask for a check-in. Non-responders after 30 days are marked as inactive. Automatic expiry - Meshtastic shows "last heard" timestamps. Nodes not heard in 30+ days are visually distinguished on your community map. Node decommission policy - Backbone/shared infrastructure nodes require formal handoff if an operator leaves. Document the process. Community Events and Meetups Regular events keep the community engaged and accelerate network growth. Events serve three purposes: recruitment of new members, skill-sharing among existing members, and public demonstration of the network's value. Build Nights Monthly hands-on sessions where newcomers build their first node with help from experienced members. Format that works: Venue: Makerspace, library meeting room, or restaurant private room. 2-3 hours. Format: 15 min intro presentation → 90 min guided build → 15 min test on the live mesh Materials: Pre-order 4-6 extra kits to sell at cost to walk-ins. Keep spare USB cables, soldering irons, and spare antennas on hand. Cost to participants: Hardware cost only ($25-50). Experienced helpers volunteer their time. Document and promote the event on social media. "Before and after" photos of someone building their first node and seeing it appear on the map are highly shareable. Annual Range Test A fun event where participants drive, hike, or bike to test the limits of the network. Structure: Designate a base station at a high-elevation location Participants spread out across the coverage area with mobile nodes Track who can communicate from the farthest point Record SNR/RSSI at each test location Share results in a coverage report - excellent content for your community map The range test also generates real coverage data that helps you identify gaps for future backbone expansion. Tabletop Exercises Simulate a disaster scenario where the mesh is the primary communications tool. Good exercise scenarios: Extended power outage - Cell networks are down, no internet. How does the community coordinate? Evacuation coordination - Simulated wildfire. Use the mesh to coordinate shelter-in-place vs. evacuation by zone. Search and rescue - Member is "lost" in a park. Use the mesh to coordinate the search team. Tabletop exercises reveal gaps - in coverage, in procedure, and in member skills - before they matter. Document findings and publish improvements. Meetup Frequency Guidelines Event Type Frequency Time Investment Build night / intro session Monthly 3-4 hrs to organize, 2-3 hrs to run Infrastructure work party Quarterly Full day Annual range test Annually Weekend event Tabletop exercise Annually (before storm season) Half day Virtual sync call Monthly 1 hr Bootstrapping a New Network Starting from Zero: Your First Repeater Every community mesh started with one person who put up the first node. This page is for that person. The core insight A community mesh doesn't need to be large to be useful. A single well-placed repeater can cover a neighborhood, a rural township, or a county road corridor - and become the seed that grows a larger network. Start small, start working, and others will join. The minimum viable network You can have a functional, useful mesh with just: 1 fixed repeater in a good location 2 - 3 participants with portable nodes This covers a surprisingly large area if the repeater is well-placed. A rooftop-mounted repeater on the highest building in a small town can provide coverage across the entire municipality and several miles of surrounding farmland. Step 1: Pick your protocol Before deploying anything, decide which protocol your community will run: MeshCore Meshtastic Best if Joining an existing regional MeshCore network ( CascadiaMesh , WCMesh, RegionMesh , NoDakMesh ) or planning a larger community infrastructure Starting fresh with no nearby infrastructure; large global community; simpler initial setup Check first Is there existing MeshCore infrastructure in your area? (regionmesh.com, cascadiamesh.org) Are there existing Meshtastic nodes in your area? (meshmap.net) Key rule: Join the existing protocol in your area rather than fragmenting the community. Two separate protocols cannot interoperate. Step 2: Get your first repeater up The single highest-impact thing you can do is install one good, well-located, permanently-powered repeater. See the Hardware section for build guides. The minimum for a good first repeater: A device that can run 24/7 without attention (solar, mains, or long-life battery) Located at the highest accessible point in your area A quality external antenna (5 - 6 dBi vertical) mounted above obstructions Flood advertisements enabled (so it announces itself across the network) A name that indicates location (e.g., MILL-HILL-SOUTH, TOWNNAME-WATER-TWR) Step 3: Tell people it exists A mesh nobody knows about has no community. Before anything else: tell people the repeater exists and how to connect. Post in local Facebook groups, Nextdoor, amateur radio clubs Add your repeater to the regional network map (contact your regional network admin) Put up a simple info page or join the regional Discord Reach out directly to local emergency management - they're often interested in off-grid communication options What to expect in year one Growth is rarely explosive. A realistic year-one trajectory for a rural or small-town mesh: Months 1 - 2: You + 1 - 3 curious early adopters, mostly testing Months 3 - 6: 5 - 15 active participants; a few more repeaters added by enthusiasts Month 6+: Real use cases emerge (emergency preparedness groups, ARES coordination, outdoor enthusiasts) The community builds around real use, not around technology. When people find a genuine reason to use it, they stick with it. Recruiting Repeater Hosts The fastest way to grow coverage is to recruit hosts for additional repeaters - people who will let you mount a node on their property. A good host needs to provide: height, power, and patience. The ideal host profile Owns or has access to a high point (tower, tall building, hilltop property, water tower access) Has mains power available at or near the mount point (or accepts solar) Is comfortable with a small device mounted on their property for years Lives in an area that extends your coverage map Where to find hosts Amateur radio operators Ham operators already have antenna infrastructure, understand RF concepts, and are culturally aligned with community communication projects. Local radio clubs are the first call for any mesh network builder. Many hams already have hilltop or tower access and are open to co-locating additional equipment. Farmers and rural landowners Rural property owners often want better communication options themselves. A repeater on a grain elevator, water tank, or farm outbuilding benefits the farmer (they get a node) while extending your coverage into underserved rural areas. Frame it as mutual benefit. Local businesses on tall buildings Rooftop access to commercial buildings dramatically improves urban coverage. Property managers are more receptive if the installation is visually minimal (a small white antenna on an existing mast) and the equipment is professionally installed. Fire stations and public works facilities Many local government facilities are interested in off-grid communication resilience. Fire stations in particular often have tall buildings, 24/7 power, and emergency-preparedness motivation. Making the ask The pitch that works best: Explain what mesh radio is in one sentence: "It's like a community text messaging network that works without cell towers or internet." Show them the current coverage map and where their location fits in Offer to handle the installation completely - they don't have to do anything Describe the equipment: a small weatherproof box, one antenna, a power draw of <5 watts Offer to give them their own device so they can actually use the network Host agreement basics Keep it informal but clear. A simple one-page document covering: What equipment is being installed and who owns it Who is responsible for maintenance and removal Power consumption (approximately $1 - 3/year for a solar node; essentially zero marginal cost for mains-powered) How to contact you if there's a problem That you'll remove it on reasonable notice if they ask Don't over-engineer this. Most hosts will never look at the agreement again - but having it shows professionalism and prevents misunderstandings years later when personnel change. Naming Conventions and Network Hygiene Good naming conventions make the network easier to use, debug, and grow. Establish them early - renaming nodes later requires coordinating with the host. Node naming conventions Community networks that work well use consistent, descriptive names. The goal: someone who has never seen the network should be able to understand what each node is and roughly where it is, just from the name. Recommended format LOCATION-TYPE or LOCATION-DESCRIPTOR Examples: OAKHILL-RPTR (Oak Hill, repeater) DOWNTOWN-RTR (downtown area, router) SMITH-FARM (Smith Farm, named location) I90-MP45 (Interstate 90, mile post 45) N-COUNTY-TOWER (North County tower site) What to avoid Personal names ("Bob's Node") - doesn't convey location information Generic names ("Repeater 1", "Node A") - ambiguous when you have many nodes Emoji or special characters - may not display on all devices All lowercase or all uppercase inconsistently - pick a convention and stick to it Names longer than 20 characters - may truncate on some displays Network hygiene practices Document every node Maintain a simple spreadsheet or wiki page tracking each node: Node name and ID Physical location (general description, not exact address if security is a concern) GPS coordinates (for the network map) Hardware: board type, firmware version, antenna, power system Host name and contact Installation date and last maintenance Known issues Monitor for dead nodes Nodes that go offline and stay offline silently degrade coverage. Set up a monitoring system: Use a room server with MQTT output + a monitoring script to alert when a node stops advertising Or simply check the network map weekly and follow up on nodes that haven't been heard in 24+ hours Keep firmware updated Firmware updates fix bugs and improve performance. For each significant release, update your permanent infrastructure nodes. This requires either physical access (USB) or an OTA update mechanism if your firmware supports it. Channel and frequency discipline Every node on your community network must use the same channel and preset. If someone joins with the wrong settings, they can hear but not be heard by - or vice versa - the rest of the network. Provide new participants with: Exact preset name or frequency settings Channel name and PSK (if using a private channel) Recommended role settings (Client for personal devices, Router/Repeater for infrastructure) Community Operations Community Governance and Decision-Making Most successful community mesh networks are lightly governed but clearly structured. Too little structure leads to chaos; too much bureaucracy kills volunteer participation. Here's what works. Minimal viable governance Network coordinator(s): 3 - 5 people who make final decisions on network settings, new repeater standards, and community direction. Usually the founders or most active contributors. Discord or forum: Primary community space for announcements, help, and coordination. Wiki or docs: Written reference for setup guides, network standards, and node documentation. Network map: Visual representation of active nodes. Decisions that need explicit consensus Some decisions affect everyone and need community buy-in, not just coordinator fiat: Changing the default preset or frequency: Migrating an existing network to a new preset requires coordinating every node simultaneously - a major disruptive event. Don't do this casually. Adding a private or encrypted channel: If community nodes are being used to bridge a private channel, other participants should know. Hosting policies: What standards do infrastructure nodes need to meet? Who can call themselves part of the network? Managing contributions from outsiders As the network grows, people will want to add nodes. This is good - but uncoordinated growth causes problems: Wrong settings: New operators who configure incorrectly fragment the network Poorly placed nodes: A ground-level node in a bad location adds noise to the network without contributing coverage Abandoned nodes: Nodes that go offline and are never maintained degrade the perceived reliability Solution: Create a brief onboarding checklist for new node operators. It doesn't need to be formal - a Discord message template works. Cover: preset/channel settings, naming convention, role configuration, how to get on the network map, and who to ask for help. Handling network conflicts Occasional conflicts arise: two operators disagree on the right preset, a node is causing interference, someone deploys with wrong settings. Keep these principles in mind: The coordinator's job is to be a technical arbiter, not a bureaucrat. Make technically correct decisions and explain the reasoning. Document the standards. "The network uses X because Y" is much easier to enforce than "the coordinator said so." Be welcoming to newcomers who made honest mistakes. Getting the settings wrong is easy. Help them fix it rather than shaming them. Emergency Preparedness Integration A well-established community mesh is a natural complement to emergency preparedness programs. Many mesh networks find their most compelling use case in disaster response and preparedness exercises. Why mesh is valuable for emergency preparedness No infrastructure dependency: Works when cell towers are down, internet is out, or power is off (for solar-powered nodes) No subscription: Critical communications infrastructure shouldn't depend on a vendor's servers being up Group awareness: GPS position sharing gives everyone on the mesh situational awareness of where team members are Asynchronous: Messages are stored and forwarded - if a node goes momentarily offline, messages are re-delivered when it returns Low training burden: Text messaging is a skill everyone has Building relationships with ARES/RACES and CERT Amateur Radio Emergency Service (ARES) and Community Emergency Response Teams (CERT) are already organized around exactly the use case mesh networks address. Approaching these groups early builds the human infrastructure alongside the technical infrastructure. Practical steps: Attend a local ARES or CERT meeting and introduce the mesh network Offer to demo the network at a training exercise Provide devices to ARES section and club leadership at no cost (community investment) Run a mesh-integrated tabletop exercise with emergency management Emergency preparedness network design A preparedness-focused mesh should prioritize: Resilient power Infrastructure nodes should be solar-powered or have battery backup with 72+ hours of runtime. A repeater that fails when the grid goes down is worthless for disaster response. Review your power systems annually before storm season. Known coverage gaps Document where coverage fails. Know which valleys, neighborhoods, or facilities are in shadow from your current repeater network. Plan secondary coverage nodes for those areas before a disaster, not during one. Designated net control Identify which node serves as net control during an emergency (typically the best-connected infrastructure node or a dedicated gateway with internet uplink). Pre-establish procedures: how will net check-ins work? What's the reporting format? Paper backup procedures Mesh configuration should be documented on paper and stored physically at net control locations. If the operators who know the settings are unavailable, someone else must be able to deploy a node correctly. Include: preset/frequency, channel name and PSK, role settings, and the network map. Running a mesh-integrated exercise A simple first exercise to demonstrate value: Scenario: Simulated grid-down event; cell towers overloaded or offline Participants: 5 - 10 people, each at a different location across the coverage area Exercise: Each participant checks in with their GPS position and a status report; net control acknowledges and tracks all positions Evaluation: Which nodes didn't check in? What coverage gaps were revealed? What configuration issues appeared? After the exercise, write up the after-action report and share it with emergency management. This demonstrates real operational value and opens doors for formal integration. Connecting to existing emergency communication systems Mesh radio is not a replacement for existing emergency communication infrastructure - it's an addition. Key integration points: APRS: A gateway node running APRS bridge software can relay position data to the APRS network, making mesh positions visible on aprs.fi to operators with no mesh hardware WINLINK: Message forwarding between mesh and Winlink email is possible via scripting; consult your regional ARES coordinator ICS-213 forms: Many emergency management teams use ICS forms for structured reporting; a simple template-based approach for mesh messages can align with this Growing Your Network How to recruit hosts, run community events, document your network, and manage growth at scale. Running Mesh Events and Demonstrations The fastest way to grow a mesh community is to let people experience the network firsthand. Events and demonstrations convert curious bystanders into active participants in a way that no amount of documentation can match. The Mesh Meetup Format A mesh meetup requires no special venue and minimal equipment. The basic format: Gather 5 - 10 people at a park or open community space. Each participant brings or borrows a Meshtastic node. Power them on, watch the mesh form in real time. Run through the basics: send a message, observe who receives it, check the map to see each other's positions, walk to the edge of the park to test range. The goal is not to teach technical details - it's to create a "this actually works" moment that participants will describe to others. Keep it relaxed. Keep it short. Follow up with a Discord or group message so attendees can stay connected. Integration with Existing Events You do not need to organize a standalone event to demonstrate the mesh. Bring it to events that already draw the right audience: Ham radio field days - A natural fit. Many operators have never seen Meshtastic; a working demonstration at a field day generates more interest per hour than almost any other venue. CERT and ARES exercises - Emergency preparedness audiences respond strongly to a practical off-grid messaging tool. You do not need a full exercise; a side-table demo during setup or break time is enough. Maker faires - Technically curious attendees who enjoy seeing novel hardware in action. Outdoor clubs (hiking, camping) - Groups that go into areas with no cell coverage are immediately motivated by a reliable off-grid communication option. Bring 3 - 5 pre-configured nodes. Let people pick them up and try them. The hands-on experience is the entire pitch. EmComm Exercise Integration One of the highest-value moves for community credibility is proposing a mesh communications component to your county's next emergency management tabletop exercise or ARES drill. Contact your county emergency manager or ARES/RACES leadership and offer to run a Meshtastic messaging segment. Demonstrating value in a formal exercise context creates buy-in from officials who influence future infrastructure decisions. An emergency manager who has seen the mesh work in a controlled setting is far more likely to support permanent installations on municipal buildings. Demo Kit Maintain a dedicated loaner kit for events: 3 - 5 nodes, all pre-configured with your local channel settings Charged batteries or power banks for each node A one-page quick-start card: how to turn it on, how to send a message, what the map view shows A way to track who has each device (a simple sign-out sheet is enough) Get the kit back at the end of every event. Pre-configured nodes that leave your possession and are never returned are nodes that may end up causing interference or confusion on the network later. Online Presence A simple online presence makes it dramatically easier for newcomers to find your local mesh community, learn the channel settings, and get involved: Discord server - Many cities have active Meshtastic Discord channels. Search before creating a new one. If one exists, become active there; if not, a new server is easy to set up. Simple website - Even a single static page with your channel name, modem preset, and a contact link is sufficient. New participants should be able to find this without joining a private group first. The channel PSK should not be published publicly if channel security matters to your group. Share it via QR code to verified participants. Measuring Success Track concrete, observable metrics rather than relying on impressions: Node count on meshmap.net - Check month over month. A growing trend is the clearest indicator that the community is healthy. Active repeater count - Nodes that are consistently online over multiple weeks, not just at events. Set written goals - "10 active nodes in the metro area by year end, 3 hilltop repeaters." Goals create shared direction and make progress visible. Celebrate milestones publicly in your Discord or website. Recognition keeps volunteers engaged. Network Documentation Standards A community mesh network that isn't documented is one resignation or one hardware failure away from being unrecoverable. Documentation is not overhead - it's the infrastructure that makes the physical infrastructure maintainable. What to Document For every permanent repeater, record: Location - Address or GPS coordinates, plus a plain-language description (e.g., "roof of First Baptist Church, southwest corner") Hardware - Device model, enclosure type, antenna type and gain Firmware version - Current version and date of last update Channel configuration - Channel name, modem preset, and whether a custom PSK is in use (do not record the PSK in shared documentation) Power system - Solar + battery, wall power, PoE. Battery capacity if applicable. Maintainer contact - Name and contact method for the person responsible for this node Beyond individual nodes, document: Network topology - Which repeaters link to which under typical conditions. A simple diagram is worth pages of prose. Channel settings - The canonical record of your community's channel name and modem preset. This is what you share with newcomers. Coverage map - Based on tested range, not theoretical propagation. Mark areas where coverage has been verified by walking tests or field days. Using the Library Mesh America Library provides a repeater reference template. Fill one out for every permanent node in your network. Keeping this information in a shared wiki rather than a single operator's notes means the network survives personnel changes. Update the library entry whenever hardware changes, firmware is updated, or maintainer contact information changes. Stale documentation is worse than no documentation because it misleads the next person who needs to act on it. Repeater Naming Conventions Choose a consistent naming scheme before you deploy your first permanent repeater. Changing it later is painful - nodes appear on maps and in message logs, and inconsistency creates confusion. Common options: Location-based : MeshAmerica-WestHills-1 - Human-readable, easy to orient on a map Callsign-based : KD9XYZ-SiteA - Ties the node to a licensed operator, useful for EmComm accountability Sequential : PDX-Repeater-01 - Simple, scales cleanly Pick one scheme and document it. New nodes added by new community members should follow the same convention. Channel Documentation Publish your channel name and modem preset publicly - on your Discord, website, or wiki. New participants need this information to join the network. Do not publish the PSK publicly if your community uses a private channel for security. Share the PSK via QR code to verified participants only. The QR code contains the full channel configuration and is the standard mechanism for onboarding new nodes. Firmware Version Tracking Maintain a log of when each node was last updated. Meshtastic firmware is actively developed; nodes running outdated versions may miss bug fixes, compatibility improvements, or security patches. Schedule a quarterly firmware review: check each node's current version, identify which nodes need updates, and coordinate with site maintainers to get access for updates. A node that hasn't been updated in over a year should be treated as a maintenance priority. Incident Log When a node goes offline - whether due to weather, power failure, hardware failure, or vandalism - document: What happened When it was detected What was done to restore service What (if anything) changed to prevent recurrence This institutional knowledge prevents repeat failures. The second time a solar controller fails in a cold snap, the person responding should be able to find a record of what worked last time. Succession Planning Community networks outlast individual operators. Plan for turnover: Ensure at least two people have physical and administrative access to every critical node. Document access procedures (who has the key to the rooftop, who has the admin channel QR code). Store admin channel QR codes securely, with a trusted backup outside your own household. A fireproof envelope with a co-maintainer is a reasonable standard. Review the succession plan annually. People move, change jobs, and lose interest. The plan is only useful if it's current. Handling Network Growth and Congestion A Meshtastic network that works well with five nodes may behave poorly at fifty. Managing growth proactively - rather than reacting after congestion degrades performance - is what separates a durable community network from one that works great until it doesn't. Early Stage: 1 - 10 Nodes At this scale, almost any configuration works. Long Fast is a reasonable default - it has good range and is the most common preset, making it easy for newcomers to join. Focus at this stage belongs on placement, not optimization. A single well-placed repeater on a hilltop or water tower does more for network coverage than ten ground-level nodes. Get repeaters in good locations first. Growth Stage: 10 - 50 Nodes As the network grows, start monitoring channel utilization . The Meshtastic app displays this metric; check it periodically. Utilization consistently above 15% is a warning sign. Actions at this stage: Audit hop limits. High hop limits cause individual messages to generate multiple retransmissions across many nodes. A hop limit of 3 is appropriate for most community networks; higher values compound congestion. Review node density. Clusters of nodes in the same small area all hear and retransmit each other's traffic. Nodes that add density without extending coverage add congestion without benefit. Begin discussing a potential preset migration with the community before it becomes urgent. Scaling Stage: 50+ Nodes At this scale, Long Fast will likely show sustained high utilization. Seriously consider migrating to Medium Slow or Medium Fast, which use lower data rates (thus more airtime per message) in exchange for significantly better receiver sensitivity and range - the tradeoff that matters when node count is high and coverage gaps are the remaining problem. This migration must be coordinated as a community. All nodes must change simultaneously, or you split the network - nodes on different presets cannot communicate. Preset Migration Process Pick a date and time for the migration window. Announce in all community channels at least two weeks in advance. Post in Discord, on the website, and in any mailing lists. Include the specific preset being adopted. Document the change procedure - a step-by-step guide for changing the preset in the Meshtastic app, for both Android/iOS and the web client. Change infrastructure repeaters first. These are the reference points that participants will see when they join on the new preset. Ask all participants to update within the migration window. A specific two-hour window on a weekend afternoon works better than "sometime this week." Run a compatibility bridge temporarily. Leave one repeater on the old preset for 1 - 2 weeks after migration. This gives stragglers a way to see a message like "Network has migrated to Medium Slow - update your preset to rejoin" and self-serve the fix. Managing the Public Channel You cannot control what strangers do on the public channel. Trolling, spam messages, and misconfigured nodes that flood the network with repeated traffic are occasional realities on any open mesh. Mitigation strategies: Maintain a secondary private channel for your community's operational use, regardless of network size. The public channel is for newcomers and casual use; the private channel is for your community's serious coordination. Document and enforce a community hop limit recommendation . Infrastructure nodes can be configured to refuse to relay messages above a certain hop count, which limits cascading retransmissions. Treat persistent disruptive nodes as a maintenance issue, not a personal conflict. Document the node ID and behavior, and discuss with your community whether any technical mitigations are warranted. Tracking Growth Health Watch these indicators month over month: Node count visible on meshmap.net (total and always-online) Channel utilization during peak hours Ratio of infrastructure repeaters to client nodes (more repeaters relative to total nodes = better network health) Growth that outruns infrastructure is the most common failure mode for community meshes. Adding repeaters ahead of demand keeps the network healthy through growth phases.