Getting Started An introduction to LoRa mesh networking: what it is, how to choose a platform, what hardware you need, and what it costs. 📖 Start Here — Getting Started Guide Welcome to the Mesh America Mesh Library. This book is your launchpad - whether you're completely new to LoRa mesh networking or just want to orient yourself before diving deeper. 🚀 New? Start With These Three Pages What is LoRa Mesh Networking? - The plain-English explanation of what this technology is and why it matters MeshCore vs Meshtastic: Quick Decision Guide - Which platform is right for you? Answered in under 5 minutes What You Need to Get Started - The minimum hardware and software to get on the mesh today 📚 What's In This Book Understanding the Technology How LoRa Works - Chirp spread spectrum, range, and the physics behind it LoRa Range: Realistic Expectations - Actual ranges by terrain, antenna height, and preset LoRa vs LoRaWAN: What's the Difference? The 915 MHz ISM Band - Why this frequency and what the rules are Your First Node Hardware Buyer's Guide for Beginners Where to Buy Hardware - Sources, prices, what to avoid Getting Your First Message Through: Meshtastic Getting Your First Message Through: MeshCore Day 1: Getting Your Node Online Day 2 - 7: Exploring the Mesh Legal, Licensing, and Ham Radio FCC Part 15 Compliance for LoRa Mesh - No license needed, but here are the rules Getting Your Ham Radio License - Why it's useful even though it's not required Operating in Canada: ISED Rules Comparing LoRa Mesh to Other Options LoRa Mesh vs Satellite Messengers (Garmin inReach, SPOT) LoRa Mesh vs FRS/GMRS Two-Way Radios LoRa Mesh vs Ham Radio (VHF/UHF) Maintaining Your Node Node Maintenance Schedule - Monthly, quarterly, and annual checks Updating Meshtastic Firmware Updating MeshCore Firmware ➡️ Where to Go Next Your Goal Go To I chose Meshtastic - now what? Meshtastic book I chose MeshCore - now what? MeshCore book I want to buy the right hardware Hardware Guide book I want to set up a solar repeater Solar & Power Systems book I have quick questions FAQ book About LoRa Mesh Networking What LoRa mesh networking is, how it works, and why it is useful. What is LoRa Mesh Networking? LoRa mesh networking lets people communicate over radio without any internet connection, cell towers, or central infrastructure. It works by linking together a collection of small, affordable radio devices - each one can receive a message and pass it along to others, forming a self-organizing mesh. The basics LoRa (Long Range) is a radio modulation technology designed for sending small amounts of data over long distances at very low power. Mesh networking means there is no single hub. Any device can relay messages to any other device, and the network routes around failures automatically. 915 MHz ISM band is the license-free frequency used in the US and Canada. No amateur radio license is required to operate. How a message travels You type a message on your smartphone and send it via Bluetooth to your LoRa device. Your device broadcasts the message over radio. Nearby devices receive it and - depending on the protocol - relay it onward toward the destination. The message arrives at the recipient's device and is delivered to their phone via Bluetooth. The network is entirely infrastructure-independent. It operates whether or not the internet is up, whether or not cell towers are functioning, and whether or not there is power at a central location. What it is good for Off-grid and backcountry communication Neighborhood and community coordination Communication during disasters or outages Privacy-conscious messaging without carrier involvement Experimenting with decentralized communications Limitations to understand Low data rate - LoRa is designed for short text messages, not voice, video, or large files. Range depends on terrain - line-of-sight from elevation is ideal. Ground level in a city may give just a few hundred meters; hilltop to hilltop can reach 20+ miles. Coverage requires community - the network only exists where people have deployed devices. In low-density areas you may be starting from scratch. Not a replacement for emergency services - always call 911 in an emergency. Why LoRa Mesh Networking Matters LoRa mesh networking addresses a fundamental problem with modern communications infrastructure: centralized systems fail at exactly the moment they're needed most. Cell towers go down in natural disasters. Internet service disappears in power outages. Commercial satellite services are too expensive for many users. LoRa mesh provides an alternative that is decentralized, affordable, and surprisingly capable. The Problem with Centralized Infrastructure Every phone call, text message, and internet connection you make today passes through infrastructure that someone else owns, powers, and maintains. This is convenient when it works. But: In 2005's Hurricane Katrina, more than 1,000 cell sites and over 3 million phone lines were knocked out, and of the 41 broadcast radio stations in the New Orleans area only 4 remained on the air (FCC testimony, Sept. 29, 2005). Survivors couldn't reliably call 911 or contact family. Important: LoRa mesh is not a substitute for 911 or a satellite SOS device. A mesh message only reaches other mesh nodes in range - there is no emergency dispatch service monitoring the mesh. Treat it as a community coordination layer, not a rescue beacon. In 2018's Camp Fire (Paradise, CA), cell towers were overwhelmed or destroyed. Some residents learned about the evacuation order only minutes before fire overtook their homes. In 2021's Texas freeze, millions lost power for days; some cell sites went dark as backup generators exhausted fuel that icy roads made hard to replenish, degrading coverage in parts of the state. These aren't edge cases. The question isn't whether centralized infrastructure will fail - it's when, and whether you'll have an alternative. What LoRa Mesh Provides A LoRa mesh network has no central server whose loss kills the network. Each node is both a client and a relay, and nodes relay according to their configured role. If a relay node fails, traffic can route around it - though coverage can still depend on individual relay nodes. The network requires no internet connection, no cell tower, no power grid - just small battery-powered devices with radio chips: Decentralized - No server to go down; the network exists as long as at least two nodes are powered on and within radio range of each other - though meaningful resilience (routing around failed nodes) requires several nodes with overlapping coverage Long-range - 1-30+ km per hop in open terrain, depending on antenna height and conditions Low power - Nodes run for days on a single battery charge; weeks or months on solar Affordable - Hardware costs $20-80 per node with no recurring subscription fees Open source - Meshtastic is fully open source; MeshCore's core firmware is open source while some companion/platform components are proprietary Real-World Deployments LoRa mesh networks are actively used today for: Neighborhood emergency communication networks in wildfire-prone communities Trail communication for hiking groups in areas without cell service Ranch and farm monitoring across large land parcels Amateur radio: some emergency communicators (ARES/RACES) are experimenting with LoRa mesh alongside traditional modes Search and rescue: LoRa mesh has been trialed for SAR coordination Environmental sensor networks (weather, soil, air quality) Off-grid communities and remote homesteads The technology works well for hobbyist and community use, but message delivery is best-effort: there is no guarantee a message arrives, and you should test your specific links before relying on them. It is not yet a substitute for proven emergency communication systems. It is also young enough that the community is actively shaping how it evolves - now is an excellent time to join. Choosing a Platform Comparing MeshCore and Meshtastic to help you decide which to use. MeshCore vs Meshtastic Two open-source protocols dominate the LoRa mesh networking space: MeshCore and Meshtastic. Both run on similar hardware, both are free, and both accomplish the same basic goal - but they make different design choices that affect performance, battery life, and network behavior. Both firmwares are free and open source; the official MeshCore phone app is freemium, with some optional features (such as certain T-Deck capabilities) behind a paid unlock. Side-by-side comparison Characteristic MeshCore Meshtastic Message routing Path discovery (targeted delivery) Managed flooding for broadcasts (nodes suppress redundant rebroadcasts); since v2.6, direct messages use next-hop routing Battery life Depends mostly on the board (nRF52 boards last far longer than ESP32) and settings; both firmwares support low-power operation Private messages End-to-end encrypted by default Channel messages AES-256-CTR encrypted (shared PSK); per-pair public-key (PKI) direct messages available since v2.5 Network load Low - messages go where needed Higher - broadcasts are rebroadcast by multiple nodes (with suppression of redundant rebroadcasts) High-traffic behavior Path-based routing generates fewer rebroadcasts per message than flooding, which can help under heavy traffic Community size Growing Very large, well-established App maturity Actively developed Mature, polished apps Interoperability MeshCore devices only Meshtastic devices only Which should you choose? There is no universally correct answer - it depends on your situation: Choose MeshCore if you prioritize battery efficiency, privacy by default, and intelligent routing that scales better as the network grows. Choose Meshtastic if you want a large existing community, more polished apps, more device support, and easier initial setup for beginners. MeshCore and Meshtastic devices cannot communicate with each other - they use different protocols. If you want to connect with others in your area, find out which platform your local community uses first. Compatibility note Most popular LoRa hardware (Heltec, LilyGo, RAK, etc.) can run either firmware. You are not locked in by hardware - you can reflash a device to switch platforms if you change your mind. MeshCore vs Meshtastic: Quick Decision Guide The two dominant LoRa mesh platforms - MeshCore and Meshtastic - are both excellent but designed for different priorities. Here's a quick guide to choosing the right one for your situation. Choose Meshtastic If... You're new to mesh networking - Meshtastic has a larger community, more documentation, and a more polished smartphone app experience for beginners. You want the largest existing community - Meshtastic nodes are deployed in many major North American cities - check a community node map for your area before assuming coverage. If people near you are already on mesh, they're probably on Meshtastic. You have mixed hardware - Meshtastic supports SX1276 and SX1262 chips. MeshCore primarily targets SX1262-based boards, but also supports several SX1276 boards (e.g., T-Beam SX1276, Heltec V2, T3-S3 SX1276) - check the MeshCore flasher device list. Some older boards have better support on Meshtastic; very old boards (such as the T-Beam v0.7) may be unsupported by both. You want smartphone-centric operation - The Meshtastic Android and iOS apps are polished and full-featured. Direct messaging, position sharing, and node management are all handled from your phone. You want IoT sensor integration - Meshtastic's Telemetry module has broad sensor support and MQTT bridge capability for home automation integration. Choose MeshCore If... You're building a private, managed community network - MeshCore room servers store posts and deliver up to the last 32 unseen messages when a client logs in - something Meshtastic channels do not offer. Recent firmware also adds access control (ACLs). Scalability and routing efficiency matter - MeshCore's path-based routing uses fewer rebroadcasts per delivered message than Meshtastic's flooding, which can reduce airtime congestion as networks grow denser. You want strong encryption by default - MeshCore uses ECDH key agreement between node identity keys to derive a pairwise shared secret for direct messages. Each conversation pair has its own encryption key derived from the two nodes' identity keys. You're deploying emergency communications infrastructure - MeshCore room servers store messages so intermittently-offline users can retrieve recent history (up to the last 32 unseen messages) when they reconnect. Note there is no end-to-end delivery guarantee over LoRa. You have nRF52840-based hardware - nRF52840-based boards (RAK4631, Heltec T114, T1000-E) are popular MeshCore choices because of their low power draw. The Honest Reality Both platforms work well for basic mesh communication. The differences matter most at scale and in specific use cases. Some communities run both - Meshtastic for public-facing nodes and community discovery, MeshCore for private infrastructure coordination. If you're unsure, start with Meshtastic. You can run MeshCore on additional nodes as a separate network alongside (not joined to) your Meshtastic mesh - the two protocols do not interoperate on the same mesh. The hardware investment for a second node is modest ($30-50). Hardware and Costs What hardware you need, what to look for, and what it costs. Hardware Overview LoRa mesh networking runs on compact radio devices - sometimes called "nodes" - that broadcast and receive radio signals in the 915 MHz band (US/Canada). All you need is a compatible device, a smartphone, and the appropriate app for your chosen platform. Types of LoRa devices Handheld / portable nodes Small devices (roughly deck-of-cards size) that pair with your phone via Bluetooth. These are the most common starting point. Some have a small screen; others are screen-less and rely entirely on the app. Keyboard devices Standalone devices with a built-in screen and keyboard, allowing you to send and read messages without a smartphone. More expensive but fully self-contained. Fixed / solar nodes Weatherproof nodes designed to be mounted outdoors - on a rooftop, tower, or hilltop - and powered by solar or mains power. These serve as repeaters, extending network coverage for everyone nearby. What to look for when buying 915 MHz support - required for the US/Canada. Some devices sold internationally are 868 MHz (EU) - verify before purchasing. MeshCore or Meshtastic compatible - check that your chosen firmware runs on the hardware. Most popular boards support both. Antenna connector - ensure the device has an external antenna connector or a good built-in antenna. A quality antenna makes a significant difference in range. Battery - built-in rechargeable batteries vary widely in capacity. Larger capacity means longer runtime without charging. What it costs Prices below are approximate and as of June 2026; hardware pricing changes often, so confirm against a current retailer listing. Item Typical cost Basic LoRa node (no screen) ~$25-50 Basic node with small OLED screen (e.g. Heltec V3) ~$18-30 GPS + e-ink handheld (e.g. T-Echo) ~$50-90 Keyboard/standalone device (e.g. T-Deck) ~$70-150 depending on model and bundle App (MeshCore or Meshtastic) Free (MeshCore offers optional paid feature unlocks) Firmware Free; open source (MeshCore's T-Deck build is free but closed source) Monthly network usage $0 There are no subscriptions, no airtime fees, and no carrier contracts. Hardware is a one-time cost. Is it legal in the US? Yes. Both MeshCore and Meshtastic operate on the 915 MHz ISM band, which is designated license-free by the FCC under Part 15 rules. No amateur radio license is required. Compliance is not automatic, though: buy a 915 MHz (US) variant - not an 868 MHz EU unit - from a reputable seller that carries FCC equipment authorization (check the label or the FCC ID database; many cheap imported dev boards ship without a clear FCC ID), set your region to US in the firmware, and use the supplied or a modest-gain antenna so your power and antenna combination stays within the FCC Part 15 (15.247) limits. LoRa Technology How LoRa Works LoRa (Long Range) is a proprietary wireless modulation technique developed by Semtech Corporation. It is the physical radio layer that both MeshCore and Meshtastic use to transmit messages over long distances without any infrastructure. The Physics: Chirp Spread Spectrum LoRa uses a modulation method called Chirp Spread Spectrum (CSS). Instead of transmitting a signal at a fixed frequency, LoRa encodes data in "chirps" - continuous sweeps across a range of frequencies. This has two major practical effects: Noise resistance: Chirps are extremely hard to destroy with narrowband interference. A signal can be decoded even when it is well below the noise floor - typically down to - 20 dB SNR (20 dB below noise). Multipath resilience: Reflected signals arrive slightly offset in time but still decode correctly, which is critical in urban environments. Key Radio Parameters LoRa performance is controlled by three main parameters that trade off between speed, range, and battery use: Parameter What It Controls Trade-off Spreading Factor (SF) How long each symbol is spread in time; each symbol carries SF bits using 2 to the power of SF chirps (SF5 - SF12 on modern chips; presets typically use SF7 - SF12) Higher SF = longer range & more noise resistance, but slower data rate and more airtime Bandwidth (BW) Width of the frequency channel (125, 250, or 500 kHz typical) Wider BW = faster data rate, shorter range Coding Rate (CR) Forward error correction ratio (4/5, 4/6, 4/7, 4/8) Higher CR = more redundancy and error correction, more overhead per packet MeshCore and Meshtastic both define preset channel configurations that bundle these parameters together. Most users never need to change the raw parameters - picking the right preset is sufficient. Frequency Bands LoRa devices operate in the ISM (Industrial, Scientific, and Medical) bands, which are license-free for compliant devices: 915 MHz - United States and Canada (902 - 928 MHz ISM band) 868 MHz - Europe 433 MHz - available in some regions; better building penetration per the physics, but tight power and duty-cycle limits often offset the range advantage In the US, 915 MHz operation is governed by FCC Part 15 rules: maximum 1 W (30 dBm) conducted power, and maximum 4 W (36 dBm) EIRP (conducted power plus antenna gain). No amateur radio license is required to operate a LoRa mesh node under these rules. Practical Range Range depends heavily on environment, antenna height, and channel settings: Urban, near ground level: 1 - 5 km node to node Rural, line-of-sight: 5 - 20 km node to node Elevated repeater (hilltop or tower): 20 - 50+ km Through a mesh network of repeater nodes, a single message can travel hundreds of miles, hopping from node to node across a region. Power Consumption LoRa radios use very little power, which is one of their key advantages: RF output power: typically 100 - 160 mW (20 - 22 dBm) at maximum on common nodes Total power consumption: roughly 50 - 150 mW for the radio while idle-listening, rising to 0.4 - 1 W or more for the whole node while transmitting, depending on the board Sleep mode: in deep sleep a node draws a fraction of a milliamp - weeks to months on a small LiPo - though mesh nodes are rarely fully asleep, since they must keep listening to relay Typical client node: 1 - 3 days on a 3000 mAh battery with moderate messaging activity E-ink display devices (T-Echo, Wireless Paper): 7 - 14 days on a charge Repeater nodes that must always be listening should be placed on continuous power (solar or mains) for reliable operation. Data Rate LoRa is designed for low data rate, low power communication - not for streaming or large file transfers. Depending on settings: Data rate ranges from approximately 0.3 kbps (slowest, longest range) to about 22 kbps (fastest LoRa preset, such as ShortTurbo, shortest range) Typical mesh presets are optimized for the 1 - 5 kbps range, balancing range and throughput for text messaging Each LoRa packet payload is limited to 255 bytes maximum This makes LoRa mesh ideal for text messages, GPS coordinates, and short sensor readings - and unsuitable for voice, images, or video. LoRa vs LoRaWAN: What's the Difference? This is one of the most common points of confusion for newcomers. LoRa and LoRaWAN are related but completely different things. MeshCore and Meshtastic use LoRa - not LoRaWAN. Understanding the distinction helps explain why mesh networking is fundamentally different from IoT sensor networks. LoRa: The Physical Radio Layer LoRa refers specifically to Semtech's Chirp Spread Spectrum modulation technology. It defines how bits are encoded onto radio waves. Any software protocol can use LoRa as its radio layer - LoRaWAN uses it, and so do MeshCore and Meshtastic. Think of LoRa as the engine. Multiple different vehicles can use the same engine. LoRaWAN: A Centralized IoT Network Protocol LoRaWAN is a specific network architecture built on top of LoRa, designed by the LoRa Alliance for IoT (Internet of Things) deployments: Topology: Star - devices talk to gateways; no peer-to-peer relaying (an optional single-hop Relay extension exists but is rarely deployed) Infrastructure required: Gateways and backend servers (The Things Network, Chirpstack, etc.) Internet dependency: Gateways connect to the internet to reach the network server Use cases: Smart meters, asset tracking, environmental sensors, industrial monitoring Encryption: AES-128 with separate network and application session keys, managed via the network/join server Messaging: Sensors send data to servers - not person-to-person communication If there is no gateway in range, a LoRaWAN device cannot communicate at all. It cannot mesh - at most an optional single-hop Relay extension exists, which is rarely deployed. LoRa Mesh (MeshCore & Meshtastic): Decentralized Peer-to-Peer MeshCore and Meshtastic use LoRa radio but implement their own peer-to-peer mesh networking protocols on top of it: Topology: Mesh - every node can relay for other nodes Infrastructure required: None - no gateways, no servers, no internet Works completely off-grid: Yes, by design Use cases: Off-grid messaging, emergency communications, outdoor recreation, community networks Encryption: Group channels use pre-shared keys (Meshtastic); direct messages use per-node public-key encryption (Meshtastic v2.5+, MeshCore) Messaging: Person-to-person text messages, group channels, GPS position sharing Side-by-Side Comparison Feature LoRaWAN LoRa Mesh (MeshCore/Meshtastic) Network topology Star (hub-and-spoke) Mesh (peer-to-peer) Requires internet Yes (at gateway) No Requires servers Yes No Works off-grid No Yes Node-to-node relay No (an optional single-hop Relay extension exists, rarely deployed) Yes Primary use case IoT sensors Off-grid communication Message type Sensor data to server Person-to-person text/GPS Managed by LoRa Alliance Open-source communities License required? No (ISM band) No (ISM band) What This Wiki Covers This wiki covers LoRa mesh networking using MeshCore and Meshtastic. LoRaWAN is a separate topic entirely and is not covered here. If you are reading about "The Things Network," "Chirpstack," or "LoRa gateways," you are reading about LoRaWAN - a different technology from what this wiki describes. When someone says they have a "LoRa device" that works with MeshCore or Meshtastic, they mean a device that uses LoRa radio with peer-to-peer mesh firmware - not a LoRaWAN end node. LoRa Range: Realistic Expectations Range is the most common question new users have, and the most complex to answer accurately. LoRa range depends on antenna height, terrain, preset configuration, and environmental conditions. Here's how to set realistic expectations for your deployment. The Honest Range Summary The figures below are community-reported estimates, not measured specifications. Real-world range varies widely with antenna height, terrain, preset, and line of sight, and the longer brackets assume clear line of sight between elevated antennas. Treat them as rough planning aids and confirm with an on-site range test. Environment Typical Range (stock antenna) Typical Range (good external antenna) Open flat terrain, low antennas 2-5 km 8-20 km Suburban (houses, trees) 0.5-2 km 2-6 km Dense urban (buildings) 200m - 1 km 1-3 km One node elevated (hilltop/tower), line of sight 5-15 km 15-50 km Both nodes elevated (mountain ridge), clear line of sight 20-80 km 50-200+ km The largest factor in real-world range is antenna elevation. Raising an antenna from ground level to 30 feet (10m) often improves range dramatically - largely by clearing local rooftops, trees, and other clutter so more of the path has line of sight. Getting up to 100 feet (30m) can extend useful range much further still. The exact gain depends entirely on the surrounding terrain and the height of the far end, so treat any multiplier as a rough rule of thumb rather than a fixed figure. This is why community networks invest in hilltop and water tower installations. Modem Preset vs. Range Meshtastic's modem presets trade speed for range. Slower presets = longer range (throughput figures below are from the official Meshtastic radio-settings table): Preset Relative Range Message Throughput Best For ShortTurbo Shortest ~21 kbps Dense urban, close range ShortFast Short ~10 kbps Indoor/urban MediumFast Medium ~3.5 kbps Suburban networks LongFast Long (default) ~1.1 kbps Community networks (best balance) LongModerate Very long ~0.34 kbps Rural sparse networks LongSlow (deprecated) Very long ~0.18 kbps Deprecated - prefer Long Moderate for sparse rural meshes VeryLongSlow (not recommended) Maximum (in theory) very low The Meshtastic project recommends against this preset - it does not form meshes well and is unreliable; avoid it Range Factors You Can Control Antenna height: The single biggest lever. Even a few extra meters of height can improve range substantially by clearing local obstructions; the exact improvement depends on the surrounding terrain. Antenna quality: A quality external fiberglass antenna can add several dB over the stock rubber-duck whip - often the single cheapest range upgrade. (Stock whips are typically ~0-2 dBi and consumer fiberglass antennas ~3-8 dBi; be skeptical of inflated gain claims from sellers. A decent external antenna ran about $30 as of 2026-06-07.) Modem preset: Switching from LongFast to a slower long-range preset can extend range at the cost of message throughput. TX power: In the US the legal limit is 1 W (30 dBm) conducted with up to 6 dBi antenna gain. Meshtastic already defaults to the maximum power your hardware and region allow ( tx_power 0 means "use default max"), so for range you should simply leave it at the default - the setting exists mainly to reduce power. Manually setting 30 usually does not extend range vs. the default, and most boards (e.g. SX1262-based) top out around +22 dBm regardless. Range Factors You Can't Control Terrain: Hills, buildings, and forests attenuate signal significantly. Even a single building in the path can cut range drastically - sometimes by half or more, sometimes blocking the link entirely - depending on the construction and geometry. Weather: Rain has negligible direct effect at 915 MHz (well under 1 dB even in heavy rain - meaningful rain attenuation only begins above roughly 5-10 GHz). The real wet-weather losses come from wet foliage and water sitting on antennas and connectors, not the rain in the path itself. Interference: Other 900 MHz ISM devices sharing the band can raise the noise floor and reduce effective range. Multipath fading: In urban environments, reflections from buildings create constructive and destructive interference that causes range to vary significantly over short distances. Your First Node What You Need to Get Started Getting on a LoRa mesh network requires minimal hardware and no ongoing costs. This page covers everything you need - and what is optional but recommended. Minimum Requirements To send and receive messages on a LoRa mesh network, you need: 1. A LoRa Device with Mesh Firmware A LoRa-capable microcontroller board flashed with either MeshCore or Meshtastic firmware. Cost: $20 - $90 depending on the device. Popular beginner choices: Heltec V3 (~$22) - Most popular beginner board overall; runs both Meshtastic and MeshCore. ESP32-based, built-in display, compact. Available on AliExpress or directly from Heltec. LILYGO T-Beam (~$35 - $45) - Includes GPS, good for position tracking. Works with both protocols. RAK WisBlock Starter Kit (~$40 - $60) - Modular system, nRF52-based, very low power. LILYGO T-Echo (~$45 - $65, as of June 2026) - E-ink display, nRF52, excellent battery life. Good for always-on pocket carry. LILYGO T-Deck / T-Deck Plus (~$55 - $80) - Built-in keyboard and screen. No phone needed for standalone operation. Check flasher.meshtastic.org (Meshtastic) or flasher.meshcore.io (MeshCore) for current compatibility lists before purchasing. 2. A Smartphone App For most devices, you need a phone to send and receive messages. The app is free: MeshCore app - iOS and Android, free Meshtastic app - iOS and Android, free The phone connects to your LoRa device via Bluetooth Low Energy (BLE). The phone provides the user interface; the LoRa device does the radio work. 3. A USB Data Cable You need this for the initial firmware flash and for future USB firmware updates (especially on ESP32 boards, where updates are typically done over USB). Day-to-day messaging is via Bluetooth, so you won't need the cable for normal use. It must be a data-capable cable - not a charge-only cable. Many cheap USB cables are charge-only and will not work for flashing. Use the cable that came with a known-good device, or buy a cable explicitly labeled as a data cable. 4. An Antenna Most devices ship with a basic stub antenna. This is adequate for initial testing but limits your range significantly. An antenna is required - never transmit with no antenna connected, as this can damage the radio. Optional But Recommended Higher-Gain External Antenna Upgrading your antenna is the single highest-impact improvement you can make to your range. The stock stub antenna on most devices is 2 - 3 dBi. A quality 5 - 6 dBi fiberglass whip antenna can noticeably extend your range - up to roughly 1.5x in open conditions (more if the stock antenna is poor), since the extra ~3 dB is about a 1.4x range gain in free space rather than a true doubling - for $15 - $30. Connector types vary by device - the Heltec V3 uses an IPEX (U.FL) connector with an SMA-female pigtail, LILYGO boards are typically SMA female, and some RAK enclosure products use RP-SMA. Match your antenna to your specific device before buying; an RP-SMA antenna will not mate properly with an SMA jack. Weatherproof Enclosure If you plan to mount a device outdoors (rooftop, hilltop, window exterior), a weatherproof enclosure protects against rain, humidity, and UV. IP65-rated plastic enclosures are available for $5 - $20. Many community members 3D-print custom enclosures. If the node contains a battery, mind the heat: a sealed enclosure in direct sun can exceed safe lithium charging temperatures (around 45 degC). Shade the box or use a light-colored enclosure, prefer LiFePO4 over LiPo for anything left outdoors, and make sure the battery's BMS has over-temperature protection. Avoid PLA 3D prints outdoors - they soften and deform in heat, which can break the seal or drop the battery against a hot surface. Battery or Solar Power For a portable field node: a USB power bank works well. For a permanent outdoor repeater: a small solar panel (5 - 10 W), a solar charge controller rated for LiFePO4, and a LiFePO4 battery. The right panel and battery size depends heavily on your node's average current draw (a low-power nRF52 node needs far less than a power-hungry ESP32 node), your latitude, and winter sun - 5-10 W is reasonable for an nRF52 node across most of the continental US but can be marginal for an ESP32 node in northern winters, so see the wiki's solar sizing page for a worked calculation for your specific node. Never wire a solar panel directly to the battery - the charge controller is not optional. A panel's open-circuit voltage exceeds the battery's safe charge voltage, and connecting them directly is an overcharge and fire hazard; the pack's BMS is a last-resort protection device, not a charge regulator. How Long Does Setup Take? From unboxing to sending your first message: approximately 30 minutes. The web-based flashers make firmware installation straightforward, and the apps guide you through initial configuration. Total Cost Estimate Component Minimum Recommended LoRa device $22 (Heltec V3) $35 - $70 (T-Beam, T-Echo) Antenna Included with device $15 - $30 (aftermarket) Enclosure - $10 - $20 Power (portable) USB power bank you already own $15 - $30 App Free Free Total ~$22 $60 - $150 There are no subscriptions, data plans, or recurring fees. First Steps After Getting Hardware You have your device. Here is how to go from unboxed hardware to sending your first message on your local mesh network. Before you start - attach the antenna first. Screw the antenna on before you power the device for testing. Never transmit with no antenna connected: transmitting into no load can damage the radio's power amplifier. Step 1: Find Out What's in Your Area Before flashing firmware, check whether there is an existing network near you. Joining an existing network is much more useful than operating a single isolated node. Meshtastic network map: meshmap.net - shows active Meshtastic nodes worldwide. Note: only nodes bridged to the official MQTT server appear, so an empty map does not mean there is no local mesh - most nodes never connect to MQTT. MeshCore network map: map.meshcore.dev - shows active MeshCore nodes If you see nodes in your area, great - you can join them. If not, you may be starting a network from scratch in your area, which just means you'll be the first node. Step 2: Find Your Local Channel / Preset For your messages to reach other nodes, your device must be on the same channel and preset as the local network. This is a very common reason new users cannot communicate with nearby nodes. Find out what your local network uses: Check the Meshtastic Discord or local Meshtastic groups for your region's channel settings Check the MeshCore Discord for MeshCore regional settings Look for local mesh groups on Reddit, Facebook, or community forums for your city or region If you cannot find specific local settings, most US networks default to the LongFast preset for Meshtastic or the default regional preset for MeshCore - but verify with your local community. Step 3: Flash the Firmware Use the official web-based flashers - no software installation required (Chrome/Edge recommended): Meshtastic: flasher.meshtastic.org MeshCore: flasher.meshcore.io Process: Make sure the antenna is attached (see the warning above), then connect your device via USB data cable Open the flasher in Chrome or Edge Select your device from the list MeshCore only: choose a firmware variant - Companion for personal handheld use, Repeater for a fixed infrastructure relay node, or Room Server for a shared message board. (Meshtastic has no firmware-variant choice here; you set the node's role in the app after flashing - see Step 4.) Click Flash and wait for completion (typically 1 - 3 minutes) Troubleshooting if your device doesn't appear: Try a different USB cable - charge-only cables are one of the most common causes of this problem Try a different USB port on your computer On Windows: install CH340 or CP2102 drivers if prompted (or if the port isn't detected) Force bootloader mode manually: for ESP32 devices, hold the BOOT button while plugging in USB; for nRF52 devices, double-tap the reset button to enter DFU mode Step 4: Initial Configuration After flashing, open the app (Meshtastic or MeshCore) on your phone and connect via Bluetooth. You'll need to configure a few basic settings: Set your region: Select US (or your region). This sets the correct frequency band. This is required before the radio will transmit. (Confirm the antenna is attached before the radio starts transmitting.) Set your name: A short display name so others can see who you are on the network. Set your channel/preset: Match the settings used by your local network (from Step 2). If you're starting fresh, leave at the default. Optional - set your role: For a personal device: Client. For a dedicated relay: Router or Repeater. Step 5: Test Once configured: Send a message to the default channel. If other nodes are in range, they will receive it. Check the node list in the app - you should see yourself, and any nearby nodes that have been active recently. If you have a second device or a friend with a device, test direct messaging. Step 6: Join the Community The mesh communities are active and helpful for new users: Meshtastic Discord: discord.gg/meshtastic - large global community, many regional channels MeshCore Discord: discord.gg/meshcore Reddit: r/meshtastic for Meshtastic discussions Local mesh groups often coordinate channel settings, share coverage maps, and organize repeater placement - worth finding yours. Quick Reference: Common First-Time Issues Problem Most Likely Cause Fix Device not recognized by flasher Charge-only USB cable Use a data cable; try BOOT button trick Cannot connect via Bluetooth Device not paired / app not seeing device Restart app; check device is powered on; re-pair No other nodes visible Wrong channel preset, or no nearby nodes Confirm channel matches local network; check meshmap.net Messages not received by others Region not set / wrong frequency Confirm region is set to US (or your region) in app Short range Stock antenna, obstructions Upgrade antenna; increase elevation if possible Glossary Full Glossary A–Z Full Glossary A - Z A reference guide to terms used in LoRa mesh networking, covering MeshCore, Meshtastic, hardware, radio concepts, and related protocols. Terms are listed alphabetically. A ACK Acknowledgment. A confirmation packet sent by the destination node to indicate that a message was successfully received. For direct messages, the acknowledgment confirms end-to-end receipt. For channel (broadcast) messages in Meshtastic, the checkmark only means another node was heard rebroadcasting the packet - not that any particular person received it. MeshCore provides delivery reports for direct messages. AGC (Automatic Gain Control) A circuit in a radio receiver that automatically adjusts sensitivity based on incoming signal strength. AGC helps receive weak signals but can be desensitized when a very strong nearby transmitter is present - a concern in high-density node environments. B Bandwidth (BW) The width of the radio frequency channel used for transmission - commonly 62.5 - 500 kHz in mesh use (Meshtastic's LongFast default is 250 kHz; MeshCore's recommended US preset uses 62.5 kHz). 125/250/500 kHz are the classic LoRaWAN values. Wider bandwidth increases the data rate but reduces effective range and noise resistance. Narrower bandwidth improves sensitivity but slows transmission. BLE (Bluetooth Low Energy) The wireless standard used to connect a phone or computer to a LoRa mesh node for configuration and messaging. BLE consumes minimal power compared to classic Bluetooth and is built into most modern smartphones. Most mesh devices use BLE as the primary interface to the companion app. C Chirp Spread Spectrum (CSS) The modulation method used by LoRa. Data is encoded in frequency chirps - continuous sweeps up or down across the channel bandwidth. CSS is exceptionally resistant to narrowband noise and interference, enabling reception of signals well below the noise floor. This is the core technology that gives LoRa its long-range characteristics. Coding Rate (CR) The forward error correction ratio applied to LoRa transmissions, expressed as 4/5, 4/6, 4/7, or 4/8. A higher coding rate (e.g., 4/8) adds more redundant bits per data bit, improving error correction and link reliability at the cost of increased airtime and reduced effective throughput. Most mesh presets use CR 4/5 for efficiency. D dBi Decibels relative to an isotropic radiator. A measure of antenna gain. An isotropic antenna (theoretical, radiates equally in all directions) is 0 dBi. Real antennas focus energy in specific directions - a 5 dBi vertical antenna focuses more energy toward the horizon, increasing horizontal range at the expense of coverage directly above and below. Higher dBi is generally better for ground-level mesh communication but can cause issues if nodes are at very different elevations. dBm Decibels relative to 1 milliwatt. The standard unit for transmit power in LoRa systems. Common values: 14 dBm = 25 mW, 20 dBm = 100 mW, 27 dBm = 500 mW, 30 dBm = 1 W. The FCC Part 15 limit for 915 MHz is 30 dBm conducted power (1 W) and 36 dBm EIRP (4 W including antenna gain). DFU (Device Firmware Update) The firmware update mode used by nRF52-based devices (T-Echo, T114, RAK4631). Entered by double-tapping the reset button, which causes the device to appear as a USB mass storage drive. Firmware is updated by dragging a .uf2 file onto this virtual drive. No separate flashing tool required. E EIRP (Effective Isotropic Radiated Power) The total radiated power accounting for both transmitter output and antenna gain. EIRP = TX power + antenna gain (in dBm and dBi respectively). FCC Part 15 sets the EIRP limit for 915 MHz at 36 dBm (4 W). A 30 dBm transmitter with a 6 dBi antenna reaches exactly this limit. ESP32 A popular microcontroller platform from Espressif Systems, used in many LoRa mesh devices including the Heltec V3, LILYGO T-Beam, and T-Deck. The ESP32 includes built-in Wi-Fi and Bluetooth. It consumes more power than nRF52-based platforms but is easier to develop for and generally less expensive. The ESP32-S3 variant is used in newer devices. F Flooding The routing method used by Meshtastic. Meshtastic uses managed flooding: when a node receives a message it rebroadcasts it, but it skips its own rebroadcast if it first hears another node relay the same packet. This continues until the hop limit is reached or all nodes have seen the packet. Since firmware 2.6, direct messages use learned next-hop routing instead of pure flooding. Flooding ensures high delivery reliability in sparse networks but creates significant channel congestion in dense networks. Contrast with Path Discovery (used by MeshCore). H Hop A single relay from one LoRa node to the next. Each time a message is forwarded by a relay node, it consumes one hop from the message's hop budget. A message that travels from Node A to Node B to Node C has made two hops. Hop Limit The maximum number of relay hops a message is permitted to make before being discarded. Prevents messages from circulating indefinitely. Meshtastic's default hop limit is 3 (configurable up to 7). MeshCore supports hop limits up to 64, enabling coverage across very large geographic areas through chains of repeaters. I ISM Band (Industrial, Scientific, and Medical) Radio frequency bands reserved internationally for industrial, scientific, and medical use, available license-free for compliant devices. In the United States, LoRa mesh devices operate in the 902 - 928 MHz ISM band. Operation under FCC Part 15 rules in this band requires no amateur radio license. L LiFePO4 (Lithium Iron Phosphate) A battery chemistry strongly preferred for outdoor and cold-weather LoRa deployments. LiFePO4 tolerates heat and physical abuse far better than LiPo and lasts many more cycles, but both chemistries lose capacity in deep cold and must not be charged below freezing. LiFePO4 has a longer cycle life (2,000 - 5,000+ cycles vs. 300 - 500 for LiPo), and is far more resistant to thermal runaway (onset ~270°C vs ~150-210°C for LiPo/NMC), though not immune - still use a proper BMS and fusing. Note: usable capacity drops sharply below freezing (manufacturers typically rate discharge only to about -20°C), so size winter battery banks with significant headroom. Critical: do not charge any lithium chemistry, including LiFePO4, below 0°C (32°F) - sub-freezing charging causes lithium plating, which permanently damages the cell and can create internal shorts. For winter solar deployments use a BMS or charge controller with low-temperature charge cutoff, or a self-heating/insulated battery. LiPo (Lithium Polymer) A common rechargeable battery chemistry used in many consumer electronics and LoRa devices. Energy-dense and lightweight, but sensitive to temperature extremes, overcharge, and physical damage. Not recommended for unattended outdoor deployments in climates with large temperature swings. See LiFePO4 for a safer outdoor alternative. LNA (Low Noise Amplifier) An amplifier placed before the receiver input to boost weak incoming signals while adding minimal noise. Some base station and repeater nodes include an LNA to improve receive sensitivity. Important consideration: an LNA improves reception of distant signals but can be overloaded by very strong nearby transmitters. LoRa (Long Range) A proprietary wireless modulation technology developed by Semtech Corporation, using Chirp Spread Spectrum (CSS). LoRa defines the physical radio layer - how bits are transmitted over the air. It is the radio technology underlying both MeshCore and Meshtastic, as well as LoRaWAN. See also: Chirp Spread Spectrum, LoRaWAN. LoRaWAN A centralized network architecture built on top of LoRa radio, designed by the LoRa Alliance for IoT (Internet of Things) deployments. LoRaWAN uses a star topology: devices communicate with gateways that connect to internet servers. It requires internet infrastructure and is not the same as LoRa mesh networking. MeshCore and Meshtastic do not use LoRaWAN. See the "LoRa vs LoRaWAN" page for a full comparison. M Mesh A network topology where every node can communicate directly with neighboring nodes and relay messages for other nodes. No central hub or server is required. Mesh networks are inherently redundant - if one node fails, messages can route around it through other paths. Both MeshCore and Meshtastic implement mesh topologies. MeshCore A LoRa mesh networking protocol and firmware developed as an alternative to Meshtastic. MeshCore uses path-discovery routing rather than flooding, making it more efficient in dense networks. It includes features such as Room Servers for store-and-forward messaging and support for large hop limits. MeshCore and Meshtastic are not cross-compatible. See the MeshCore vs Meshtastic comparison page. Meshtastic An open-source LoRa mesh networking project with a large global user base. Meshtastic uses managed flooding: relay nodes rebroadcast a message unless they already heard another node relay it; since firmware 2.6 direct messages use learned next-hop routing. It has extensive hardware support and a large, active community. Meshtastic and MeshCore are not cross-compatible. See the MeshCore vs Meshtastic comparison page. MQTT (Message Queuing Telemetry Transport) A lightweight publish/subscribe messaging protocol used to bridge Meshtastic nodes to internet services. Nodes with internet connectivity (via Wi-Fi) can publish mesh traffic to an MQTT broker, enabling out-of-area message delivery and integration with dashboards and mapping services. MQTT bridging is optional and requires infrastructure - the core mesh operates without it. N nRF52 A microcontroller platform from Nordic Semiconductor, used in lower-power LoRa mesh devices including the LILYGO T-Echo, T114, and RAK4631. The nRF52 does not have Wi-Fi, which reduces power consumption significantly compared to ESP32-based devices. nRF52 devices typically offer better battery life but have fewer connectivity options. Firmware updates use DFU mode (double-tap reset). O OTA (Over-The-Air) Firmware update delivered wirelessly, without connecting a USB cable. Some LoRa mesh devices support OTA updates via Bluetooth or Wi-Fi. OTA capability depends on the specific device and firmware version. P Path Discovery The routing method used by MeshCore. When a message needs to reach a destination, the network is initially flooded to discover a route. Once a path is found, subsequent messages to the same destination use the learned path directly, rather than flooding the entire network each time. This results in significantly less channel congestion than flooding in dense networks. Contrast with Flooding (used by Meshtastic). PSK (Pre-Shared Key) An encryption key distributed to all nodes that should be able to communicate on a given channel. Both MeshCore and Meshtastic use PSK-based encryption. All devices on the same channel must have the same PSK to send and receive messages. The default channel typically uses a publicly known default key (effectively no privacy); private channels use a custom PSK. R Repeater A node dedicated to relaying messages rather than originating them. Repeaters are typically placed at elevation (hilltops, rooftops, towers) to maximize coverage area. In MeshCore, "Repeater" is a specific firmware variant optimized for this role. In Meshtastic, the Router or Repeater role serves the same purpose. Repeater nodes should have continuous power (solar or mains). Room Server A MeshCore-specific node type that functions as a store-and-forward bulletin board on the mesh. A Room Server retains recent messages and delivers them to nodes that connect later - similar in concept to a message board. This is particularly useful for networks where not all nodes are online simultaneously. Room Servers are a MeshCore feature and do not exist in standard Meshtastic. RP-SMA (Reverse-Polarity SMA) A variant of the SMA RF connector where the center pin gender is reversed: the RP-SMA female connector has a center pin (male contact), while RP-SMA male has a socket. LoRa mesh devices most commonly use standard SMA (e.g., many LILYGO and Heltec boards), but some use RP-SMA - check your specific device before buying antennas. When purchasing antennas or adapters, verify whether RP-SMA or standard SMA is required - they look nearly identical but are not interchangeable. S Scope In MeshCore, the geographic or group region within which a message is intended to propagate. Scopes allow large networks to partition traffic so that local messages stay local and do not flood the entire regional network. SF (Spreading Factor) A LoRa parameter that controls how many chips encode each symbol (2^SF chips per symbol; each symbol carries SF bits), commonly SF7 (fastest, shortest range) to SF12 (slowest, longest range) in mesh presets - SF5 and SF6 also exist on newer radios. Higher spreading factors increase range and noise resistance exponentially but also increase time-on-air, battery consumption, and reduce channel capacity. Each step up in SF roughly doubles airtime and adds about 2.5 dB of link budget (about 30% more line-of-sight range). SMA (SubMiniature version A) A standard RF coaxial connector used widely in LoRa devices, antennas, and RF equipment. The standard SMA has a center pin on the male connector. Note the distinction between SMA and RP-SMA - they are not interchangeable. See RP-SMA. SWR (Standing Wave Ratio) A measure of impedance matching between the transmitter and antenna. A perfect match is 1:1; real antennas have some mismatch. SWR <1.5:1 is excellent; SWR <2:1 is acceptable; SWR >3:1 indicates a poor match and may cause reduced range and potential damage to the transmitter over time. Caused by wrong antenna type, damaged cable, or improper installation. T TX Power (Transmit Power) The power output of the radio transmitter, measured in dBm. Higher TX power increases range up to the regulatory limit but also increases battery consumption. Most LoRa mesh devices allow TX power adjustment in firmware settings. The FCC Part 15 limit for 915 MHz is 30 dBm (1 W) conducted power. Operating at 27 dBm (500 mW) rather than 30 dBm reduces battery consumption while sacrificing 3 dB of link budget (roughly 25-30% of line-of-sight range). Terms added or updated as the community identifies gaps. If a term is missing, please raise it in the community Discord. LoRa Mesh Networking Glossary Quick reference definitions for terminology used throughout this wiki. Terms are organized alphabetically. A ACK (Acknowledgment) A confirmation packet sent by the receiving node to confirm a message was received. Meshtastic uses ACKs for unicast (direct) messages; channel (broadcast) messages do not generate per-recipient ACKs - instead the sender gets an implicit ACK when it hears another node rebroadcast the packet. Advertisement MeshCore term for a broadcast packet that announces a node's name, position, and public encryption key (the advert is also signed to prevent spoofing). Client nodes send adverts manually when the user initiates it; repeaters and room servers send them periodically (every 12 hours by default). Similar in purpose to Meshtastic's NodeInfo broadcast. ARES (Amateur Radio Emergency Service) A volunteer organization affiliated with the ARRL that provides amateur radio communications support during emergencies. Some ARES groups have begun experimenting with LoRa mesh as a supplemental data layer. Airtime The duration a LoRa radio is transmitting a packet. Determined mainly by Spreading Factor, Bandwidth, and message length (coding rate and preamble length also contribute). Longer airtime = more range but lower network capacity. At SF12/BW125, a short message can take 1-2 seconds of airtime; at SF7/BW500, milliseconds. B Bandwidth (BW) The frequency width of a LoRa signal in kHz. Common values: 62.5, 125, 250, 500 kHz. Wider bandwidth = faster data rate, slightly less range. One of the three parameters that define a modem preset. BMS (Battery Management System) A circuit that protects a lithium battery from overcharge, overdischarge, overcurrent, and short circuit. Essential for bare lithium cells; many integrated battery packs include a BMS. Broadcast storm A network condition where packets are retransmitted indefinitely, consuming all available airtime. Prevented in LoRa mesh by hop count limits and packet deduplication. C Channel In Meshtastic: a named communication group with a shared Pre-Shared Key (PSK). Nodes on the same channel can communicate. Up to 8 channels can be configured on one node. In MeshCore: the public or private channel with shared encryption key. Channel utilization The percentage of time the LoRa channel is occupied by transmissions. Displayed in Meshtastic app. Values above 25% indicate congestion; above 50% the network becomes unreliable. Coding Rate (CR) A LoRa parameter that adds forward error correction overhead. Common values: 4/5, 4/6, 4/7, 4/8. Higher coding rate provides better noise immunity at the cost of reduced data rate. One of three parameters in a modem preset. Conducted power Transmit power measured at the antenna connector of the radio. FCC Part 15 limits this to 1W (30 dBm) for 902-928 MHz spread spectrum. D-E dBi Decibels relative to an isotropic radiator. A measure of antenna gain. Higher dBi means more focused signal in some directions. 0 dBi means gain equal to a hypothetical isotropic antenna that radiates equally in all directions; real antennas always have some directionality. dBm Decibels relative to 1 milliwatt. Used to express absolute power levels. 0 dBm = 1 mW; 30 dBm = 1W; -120 dBm = approximate LoRa sensitivity at low spreading factors, while at SF12 sensitivity reaches roughly -137 dBm (BW125) to -148 dBm. ECDH (Elliptic Curve Diffie-Hellman) A key exchange algorithm that allows two parties to derive a shared secret over an insecure channel without transmitting the secret. Used by MeshCore for all direct messages, and by Meshtastic DMs in firmware 2.5.0+. EIRP (Effective Isotropic Radiated Power) Total radiated power accounting for antenna gain and cable loss. EIRP = Conducted Power + Antenna Gain - Cable Loss. FCC 15.247 caps conducted power at 1 W (30 dBm) and requires dB-for-dB power reduction only for antenna gain above 6 dBi - with a 6 dBi antenna this works out to about 36 dBm (4 W) EIRP, though fixed point-to-point links are allowed higher EIRP. F-H Flood routing The routing method used by Meshtastic for broadcasts: it uses managed flooding, where a node rebroadcasts a packet unless it first hears another node rebroadcast it. Since firmware 2.6, direct messages use next-hop routing instead of flooding. Simple but can cause congestion at scale. Fresnel zone An elliptical region around the direct path between two antennas. For reliable communication, approximately 60% of the first Fresnel zone should be free of obstructions. Trees, buildings, and terrain within the Fresnel zone cause signal loss even if the visual line-of-sight is clear. Gateway A node that connects the local mesh network to the internet (via WiFi, cellular, or wired connection), enabling MQTT uplink/downlink and access to map services and remote monitoring. Hop One radio transmission between adjacent nodes. A message that travels from Node A to Repeater B to Node C has taken 2 hops. Hop limit The maximum number of hops a packet may take before being discarded. Decremented at each relay. Default 3 in Meshtastic; prevents broadcast storms. I-L ISM band Industrial, Scientific and Medical radio bands. In the US, license-free communications devices (FCC Part 15) may also operate in these bands. US bands include 902-928 MHz, 2.4 GHz (WiFi), and 5.8 GHz; in Europe, 863-870 MHz is used for LoRa. LiFePO4 (Lithium Iron Phosphate) A lithium battery chemistry with superior DISCHARGE temperature tolerance (-20°C to 60°C), long cycle life (2,000-4,000 cycles), and high thermal stability (far more resistant to thermal runaway than LiPo, though not immune). Charging below 0°C damages the cells, so outdoor solar nodes need a low-temperature charge cutoff or a heated/self-heating battery. Recommended for outdoor LoRa deployments. Link budget The accounting of all gains and losses in a radio link. Received power = TX power + TX antenna gain - cable losses - path loss + RX antenna gain. Link margin = received power - receiver sensitivity; a positive margin means a workable link. LMR-200 / LMR-400 Trade names for low-loss coaxial cable commonly used for LoRa antenna connections. LMR-200 is flexible and low-loss for runs under 10m. LMR-400 is larger, lower-loss, preferred for runs over 10m at 915 MHz. LoRa Long Range radio modulation technology using Chirp Spread Spectrum (CSS). Not a network protocol - just the radio layer. Used by Meshtastic, MeshCore, LoRaWAN, and other systems. LoRaWAN A centralized IoT network protocol that uses LoRa radio. NOT the same as Meshtastic or MeshCore. LoRaWAN requires gateways connected to a network server; it does not support peer-to-peer mesh networking. M-P MeshCore An open-source peer-to-peer LoRa mesh networking protocol using path-based routing (path discovery/acknowledgment) and ECDH encryption for direct messages. Distinct from and incompatible with Meshtastic. Meshtastic An open-source peer-to-peer LoRa mesh networking project using flood-based routing. The most widely deployed LoRa mesh protocol globally. MPPT (Maximum Power Point Tracking) A charge controller technique that continuously adjusts load to extract maximum power from a solar panel. MPPT typically harvests 10-30% more energy from the same panel than a PWM controller (vendor data; the exact gain depends on conditions), which matters most for small panel/battery systems. NodeInfo Meshtastic packet type that broadcasts a node's name, hardware type, and short name. Sent periodically and when the node first joins the network. Creates entries in other nodes' contact databases. nRF52840 A Nordic Semiconductor microcontroller with integrated Bluetooth 5 and low-power design. Used in RAK4631, T-Echo, and T114 LoRa boards. Draws substantially less power than ESP32-based boards (sleep behavior and the radio dominate the difference), making it preferred for battery-powered deployments. PSK (Pre-Shared Key) A cryptographic key shared among all members of a group before communication begins. Meshtastic channels use PSKs for AES-256-CTR channel encryption (the PSK itself may be 128- or 256-bit). All nodes on a channel must have the same PSK to decrypt messages. R-Z RAK4631 A WisBlock LoRa module based on nRF52840 and SX1262 radio. One of the most popular nRF52840-based boards for MeshCore and Meshtastic deployments, valued for its low power consumption and external antenna support. Room server A MeshCore node running room-server firmware that acts as a shared message board (BBS): it stores posts and forwards them to clients when they connect, enabling asynchronous delivery. It does not require internet connectivity. RSSI (Received Signal Strength Indicator) Measured in dBm (negative values). The power level of a received radio signal. More negative = weaker signal. LoRa can decode signals as weak as -120 to -148 dBm depending on Spreading Factor. SNR (Signal-to-Noise Ratio) The ratio of signal power to noise floor, measured in dB. LoRa can decode at negative SNR values (down to about -20 dB), which is why it achieves such long range despite low signal strength. Spreading Factor (SF) A LoRa parameter, typically 7-12 (newer SX126x radios support 5-12). Higher SF = longer range, more airtime, lower data rate. Each step roughly doubles airtime. SF12 has roughly 30x more airtime than SF7 (at the same bandwidth) but much greater sensitivity. T-Beam A popular ESP32-based LoRa development board by TTGO/LilyGO featuring an integrated GPS module and 18650 battery holder. The antenna connector varies by version (SMA on classic v1.x boards, U.FL on the T-Beam Supreme/S3-Core). Available in 915 MHz (US) and 868 MHz (EU) variants. T-Echo A nRF52840-based LoRa device by LilyGO with an e-ink display, integrated GPS, and excellent battery life. Recommended for portable/handheld Meshtastic use. UART Universal Asynchronous Receiver-Transmitter. A serial communication interface. Used to connect GPS modules, serial sensors, and external hardware to LoRa boards. Buying Your First Node Hardware Buyer's Guide for Beginners Philosophy Don't over-buy for your first node. Start with one device, get familiar with the software, learn what the network feels like in your area, and then expand. A $25 Heltec and your phone will teach you more in a weekend than reading specs for a month. Path 1 - I Just Want to Try It / Hiking / Personal Use (~$25 - 40) Recommended: Heltec LoRa 32 V3 Price: ~$20 - 25 | Available on Amazon and AliExpress USB-C charging, built-in OLED display (useful for seeing channel activity and your node's details without a phone), and broad firmware support. Flash with Meshtastic in about 5 minutes using the web flasher at flasher.meshtastic.org. What you'll need: A 915 MHz LoRa antenna - usually included in the box, but upgrading to a rubber-duck or small fiberglass antenna improves range A 3.7 V LiPo battery with a JST 1.25 mm connector (the Heltec V3 uses 1.25 mm, not the more common 2.0 mm - verify before ordering). Critical: JST connector polarity is NOT standardized. Before plugging in any battery, compare the battery wires to the +/- markings on the board - many aftermarket packs are wired reversed and will instantly destroy the board (and can short the pack). If reversed, re-pin the connector; never force it and hope. Or just power from USB if you're always near an outlet What you can do out of the box: Text messaging with anyone on the same channel within radio range GPS position sharing (uses your phone's GPS fed to the device via Bluetooth) Basic mesh relay - your node automatically extends the network for others Path 2 - I Want a Home Node / Low-Key Repeater (~$30 - 60) Option A: RAK WisBlock Starter Kit Components: RAK19007 base board + RAK4631 core module | Price: ~$25 - 60 depending on configuration (basic US915 kit ~$25 - 31; GPS and PoE/Ethernet variants up to ~$61) The RAK4631 uses an nRF52840 processor, which draws far less power than the ESP32 in the Heltec - nRF52-based nodes typically run several times longer on the same battery (the exact ratio depends on mode and configuration). A small 1000 mAh LiPo will run this node for several days. Add a GNSS module (~$15 - 25 extra, e.g. RAK1910 or RAK12501) if you want position reporting. Option B: T-Echo by LilyGO Price: ~$55 - 65 All-in-one nRF52840 device with integrated GPS (L76K), epaper display, and a comfortable form factor. Excellent battery life. Popular for both always-on home nodes and hiking use. Flashes to Meshtastic or MeshCore with no soldering required. Antenna note For a home node you want to do better than the stub antenna. A quality 915 MHz fiberglass antenna (~$10 - 20 from Rokland or Amazon) on a short cable can add 3 - 6 dBi of gain and meaningfully extend range. Check that your board's connector matches (most RAK and T-Echo boards use RP-SMA or U.FL - buy the right adapter). Path 3 - I Want a Permanent Outdoor Repeater (~$80 - 150) This path requires more assembly, weatherproofing, and planning, but the result is a node that can run indefinitely without attention. Before you climb: Survey the site first - keep yourself, the mast, and the antenna at least 10 ft from any overhead power line; if the antenna or mast could fall into a line, pick another spot. Use a properly footed ladder, don't work on wet/icy roofs, and have a second person present. Core hardware: RAK4631 on a Meshtastic-compatible base, or a T-Beam flashed to MeshCore repeater firmware Add-ons required: Weatherproof enclosure: IP65 or better ABS or polycarbonate enclosure (~$10 - 30). Run a short pigtail through a waterproof cable gland for the antenna connection. External antenna with mounting hardware: a 3 - 5 dBi fiberglass omni on a mast or eave mount (~$20 - 40 including hardware). Height matters more than gain - prioritize elevation. Grounding/lightning protection: a coax surge arrestor (antenna discharge unit) bonded to the building grounding electrode system, and the mast grounded per NEC Article 810. Budget ~$20 - 40. Do not run coax from an outdoor antenna into your home without this. Power system: solar panel + MPPT charge controller + LiFePO4 battery, plus an inline fuse at the battery positive terminal sized to the wiring (~$2). Budget ~$40 - 80 depending on sizing. For installs with freezing winters, use a controller or BMS with a low-temperature charge cutoff - lithium batteries must not be charged below 0°C. See the Solar & Power Systems book for sizing guidance. Platform Choice Meshtastic is beginner-friendly, with polished iOS and Android apps, a web flasher, and extensive community documentation. It uses a flooding mesh with some optimizations. Best choice if you're new and want things to just work. MeshCore uses path-based routing, which is more efficient for infrastructure repeater deployments and scales better in larger networks. Preferred by some network operators building out regional infrastructure. The tradeoff is a steeper learning curve and less polished consumer apps. Your hardware choice is largely independent of platform - most modern SX1262-based 915 MHz boards (Heltec V3, RAK4631, T-Beam, T-Echo) can run either firmware. Note that MeshCore requires an SX1262 radio, so older SX1276-based boards (some early T-Beam and Heltec V1/V2 units) run Meshtastic only. Where to Buy Amazon - fastest delivery, usually ships 915 MHz unless the listing specifies otherwise, but verify before purchasing AliExpress - cheapest prices, 2 - 4 week shipping, watch carefully for 868 MHz versions (labeled for EU) - they are not legal for use in the US Rokland.com - US-stocked LoRa hardware specialist. Excellent source for antennas, cables, and accessories. Good customer service. What NOT to Buy LoRa devices tuned and certified for the EU 868 MHz band - the SX1262 silicon can often be set to 915 MHz in firmware, but an EU-market unit has the wrong RF filtering and antenna for the US band, so performance suffers and the device is not FCC-certified for US operation. Buy the 902 - 928 MHz (US915) version. Counterfeit or no-name boards without confirmed compatibility - always verify against the Meshtastic hardware compatibility list or the MeshCore hardware page before purchasing LoRaWAN gateways and hotspots (e.g. indoor hotspots, Helium-style miners) - these are single-purpose infrastructure for a different protocol, not mesh nodes. Note that many node dev boards advertise both Meshtastic and LoRaWAN compatibility and are perfectly fine; check the Meshtastic/MeshCore device lists rather than rejecting a board just because it mentions LoRaWAN. Where to Buy Meshtastic and MeshCore Hardware LoRa mesh hardware is available from multiple sources. Here's a guide to finding the right hardware at the right price, with notes on reliability and availability as of 2025-2026. Prices and stock change frequently - verify current pricing at the source before ordering. Official and Recommended Sources RAK Wireless (rakwireless.com) The official source for RAK WisBlock modules. RAK4631 core, base boards, and sensor modules are all available directly. Shipping from Hong Kong (5-14 days to US) or via US distributors. Quality is consistently excellent - RAK products are used in industrial deployments. LILYGO (lilygo.cc) Official source for T-Beam, T-Echo, T-Deck, and other LILYGO boards. Ships from China (1-3 weeks to US), though LILYGO also stocks US/EU/CA warehouse variants for many models - pick the regional variant for faster shipping. AliExpress LILYGO store is also official. Avoid third-party sellers with generic product images. Heltec Automation (heltec.org) Official source for Heltec WiFi LoRa 32 and LoRa Node boards. Ships from China. US Amazon listings exist and are faster, though slightly more expensive. US-Based Distributors (Faster Shipping) Amazon - Many boards available with Prime shipping. Verify you're buying from the brand's official Amazon store or a reputable reseller. Read reviews carefully. Rokland Technologies (rokland.com) - US-based LoRa/IoT specialist. Carries Heltec, antennas, and accessories. Good customer service. Digi-Key - The documented authorized distributor for RAK WisBlock components and modules; excellent for bulk orders. Mouser Electronics - Large industrial distributor. Verify current stock before ordering, as RAK WisBlock availability on Mouser is limited; Digi-Key is the more reliable RAK source. Budget Options AliExpress - Direct from Chinese factories. 2-4 week shipping. Significantly cheaper than US sources. Risk: occasional counterfeits or poor QC. Stick to official brand stores (LILYGO Official Store, Heltec Automation, RAK Wireless Store). eBay - Used and new boards; good for finding older hardware or discontinued models. Verify the seller has solid feedback. Community Swap/Buy Reddit r/meshtastic - Occasional community buy/sell/trade threads. Good for getting pre-configured hardware from experienced operators. Local mesh community groups - Your local community Discord or Signal group may have loaner programs or group buys that reduce shipping costs. What to Buy: 2025-2026 Recommendations Budget Board Source Notes $18-25 Heltec WiFi LoRa 32 V3 Amazon or Heltec.org Best bang-for-buck starter; USB-C; OLED $35-45 LILYGO T-Beam v1.2 Amazon Prime or lilygo.cc GPS included; great portable node ~$25-61 RAK WisBlock Starter Kit RAKwireless.com, Rokland, or Digi-Key Best quality; modular; preferred for infrastructure (varies by variant; see the "what you need" page) ~$55-80 T-Deck / T-Deck Plus lilygo.cc Built-in keyboard and screen; standalone communicator (the pricier T-Deck Pro is a separate model) Maintaining Your Node Updating Meshtastic Firmware Why Update? Meshtastic releases updates frequently, delivering bug fixes, new features, and performance improvements. For best compatibility with other nodes on the mesh, keep nodes on the current major version (2.x) and within a few minor releases of the latest stable. Note that nodes running the old 1.x firmware cannot communicate with 2.x nodes at all - the two major versions are not radio-compatible. Running a very old firmware version may cause incompatibility with nodes that have updated. Checking Your Current Version Open the Meshtastic app and navigate to the Node Info panel for your node. The firmware version string is displayed there (e.g., 2.5.12.abcdef). Finding the Current Release Meshtastic releases firmware regularly on GitHub at github.com/meshtastic/firmware/releases. Each release includes a changelog. The web flasher at flasher.meshtastic.org always offers the latest stable release automatically - you do not need to find the binary yourself when using it. Update Methods 1. Web Flasher (Easiest) Open flasher.meshtastic.org in Chrome or Microsoft Edge (WebSerial is required; Firefox does not support it). Connect your device to your computer via USB. Select your board type from the dropdown. Click Flash. The flasher downloads and writes the latest stable release. Configuration is preserved in most updates: a standard Update flash leaves your saved configuration intact, while the "Full Erase and Install" option wipes it. However, major version upgrades occasionally reset configuration - see the section below. 2. Bluetooth OTA (Over-the-Air, nRF52 boards) Some nRF52 hardware supports over-the-air firmware update via Bluetooth - but this is not done from the Meshtastic app itself. It uses Nordic Semiconductor's DFU apps and an -ota.zip firmware file. RAK boards such as the RAK4631 support OTA; the T-Echo only supports OTA if it has an updated bootloader (older T-Echo bootloaders lack OTA support). Steps: Download the firmware package for your board ending in -ota.zip from the Meshtastic releases page. On Android, install Nordic's nRF Connect app (the OTA procedure currently requires an older release, version 4.24.3). On iOS/iPadOS, install Nordic's nRF Device Firmware Update (nRF DFU) app. In the Nordic app, connect to your node, select the DFU option, and choose the -ota.zip file to push it over Bluetooth. Many ESP32 boards do not support Bluetooth OTA and must be flashed over USB. 3. Arduino / PlatformIO (Developers) Developers who want to build from source or apply custom patches can use PlatformIO with the Meshtastic firmware repository. This method requires a development environment and is not needed for routine updates. Configuration Preservation Most firmware updates preserve your configuration. However, major version upgrades (e.g., 2.x → 3.x) occasionally include breaking changes that reset config. Before updating any critical infrastructure node, record: Channel name and PSK (or export the QR code) Modem preset (e.g., LONG_FAST, MEDIUM_SLOW) Device role (Router, Repeater, Client, etc.) Any custom position or telemetry settings Check the release notes for your target version before updating. Updating a Remote Node If your node is an nRF52 board with Bluetooth OTA support and is within Bluetooth range, you can update it remotely using Nordic's nRF Connect / nRF DFU app (see the Bluetooth OTA section above) without a USB connection. Caution: a failed OTA can leave the device non-working (bricked) until you can physically reach it and reflash over USB, so avoid OTA for hard-to-reach infrastructure nodes. For headless nodes deployed out of Bluetooth range, or boards that do not support OTA, physical access and USB are required. Rolling Back If a firmware update causes problems, you can flash the previous version using the web flasher - select the exact version from the version dropdown instead of accepting the default latest. Keep a note of the version that was working on your infrastructure nodes so you can return to it quickly if needed. Updating MeshCore Firmware Update Frequency MeshCore releases firmware periodically. Major releases introduce new features and architecture improvements; point releases fix bugs. Check the changelog at github.com/meshcore-dev/MeshCore/releases before updating to understand what has changed. Checking Your Current Version You can find your MeshCore firmware version in two ways: MeshCore app (Bluetooth): Connect to the node via the companion app and check the node info panel. Serial console: Connect via USB serial at 115200 baud. The device outputs its firmware version string on boot. Update Methods 1. MeshCore Web Flasher (Easiest) Open flasher.meshcore.io in Chrome or Edge (WebSerial required). Connect your device via USB. Select your board and firmware variant (Companion, Repeater, or Room Server). Click Flash. The flasher downloads the latest release automatically. This is the recommended method for most users. Ensure you select the correct variant for your node's role. 2. Manual Binary Flash Download the appropriate binary from the GitHub releases page. The process differs by chip: nRF52840 devices (RAK4631, Heltec T114, etc.) These devices expose a USB mass storage drive when in bootloader mode (double-tap the reset button on most boards). Simply drag and drop the .uf2 file onto the drive. The device reboots automatically after the copy completes. No additional software required. ESP32 devices Use esptool.py from the command line, or use the web flasher. The web flasher is simpler for most users. 3. OTA (Over-the-Air) MeshCore supports over-the-air firmware updates, so most updates can now be done without a USB connection: nRF52 boards (RAK, T114, Seeed XIAO): update over Bluetooth using the nRF DFU app. ESP32 boards: run the start ota command to bring up a Wi-Fi hotspot named MeshCore OTA, then upload the firmware from a browser at http://192.168.4.1/update. USB remains the fallback and is required for first-time flashing. See the MeshCore FAQ section 7 for the current step-by-step OTA procedures. Configuration After Update MeshCore stores configuration in flash. Most updates preserve existing settings, but you should: Read the release notes for any breaking configuration changes before updating. After updating, connect to the node and verify your preset, channel key, and role settings are intact. If settings were reset, re-apply your configuration before returning the node to service. Firmware Variants - Flash the Correct One MeshCore ships multiple firmware variants for the same hardware, each tuned for a different node role: Companion: For end-user devices paired with a phone or computer app (available as BLE Companion and USB Serial Companion builds). Repeater: Optimized for infrastructure repeater nodes. Disables unnecessary client features to reduce overhead. Room Server: Runs a shared message board (BBS-style) that stores posts and forwards them to clients when they connect. Important: If you accidentally flash Companion firmware onto an infrastructure Repeater node, its behavior will change. Always double-check the variant selection before flashing a deployed node. Node Maintenance Schedule A simple maintenance schedule keeps your node reliable and avoids the surprise of a failed battery or corroded antenna during an emergency. Regular checks take 10-15 minutes per node and catch most common failure modes early. Safety note - work at height: Rooftop and mast work involves fall hazards. Use a properly footed ladder (maintain 3-point contact), avoid wet/icy roofs, never work at height alone, and consider binoculars or a camera pole for visual checks that do not require touching the node. If the node is on a tower, leave climbing to trained/certified climbers. Monthly Checks (5 minutes) App connection: Connect to your node and verify it responds. Check firmware version. Battery level: For solar nodes, verify battery is charging (should be near full by midday). For USB-powered nodes, verify power is stable. Neighbor count: Are you seeing the same neighbors as before? A suddenly empty neighbor list may indicate an antenna failure or a major change in the local network. Channel utilization: Keep utilization under 25% - this is the action threshold. Treat sustained readings above 15% as an early warning to investigate before they climb toward 25%. Quarterly Checks (15 minutes) Visual inspection: For outdoor nodes - inspect the enclosure for water ingress, cracks, UV damage. Inspect antenna mount for rust or loosening. Check cable entry points for sealant integrity. Firmware update: Check meshtastic.org for new stable releases. Update if more than 2 versions behind. Back up config before updating. Configuration backup: Export config to file. Store in a cloud backup location. Range check: Verify RSSI to 2-3 reference nodes. Compare to your baseline. A 5+ dB drop indicates antenna or cable degradation. Annual Checks (30-60 minutes) Battery capacity test: For solar systems, run a controlled capacity test: discharge at a known load to the manufacturer's cutoff voltage (for example, about 10.5 V for a 12 V lead-acid battery), then recharge promptly. Avoid full discharges on lead-acid chemistry, as deep discharges measurably shorten its life. Capacity fades with age, temperature, and cycling - expect noticeable fade after roughly 2-3 years on lead-acid and 3-5+ years on lithium, faster in heat or with deep cycling. Plan replacement when measured capacity drops to about 80% of rated - the standard end-of-life threshold - especially for nodes that must survive long winter nights. Connector re-torque: Check all SMA/N connector connections and re-torque to specification. Use a calibrated torque wrench: ~5 in-lb (0.56 Nm) for brass SMA, ~8 in-lb (0.9 Nm) for stainless SMA; follow the manufacturer's spec for N connectors (typically ~15-20 in-lb / 1.7-2.3 Nm). Never use pliers; finger-tight is acceptable only for temporary bench setups. Lightning protection inspection: Verify the coax surge arrestor is intact and the mast and arrestor ground/bond connections are tight and corrosion-free (NEC Article 810 requires a listed antenna discharge unit and mast grounding for outdoor antennas). If the install has no grounding at all, add it before the next storm season. Re-weatherproof connectors: Remove old self-amalgamating tape, inspect connector for corrosion, reapply fresh tape. Solar panel cleaning: Wipe panels with damp cloth. Bird droppings and dust accumulation can reduce output 5-15%. Maintenance Log Template Keep a simple maintenance log for each node: Node: WH01-WestHillsRepeater Node ID: !ab12cd34 Location: 3214 Hill Ave rooftop Last firmware: 2.6.1 (updated 2026-03-15) Battery: LiFePO4 20Ah (installed 2025-06) Maintenance Log: 2026-05-01: Quarterly check. RSSI to Summit -87dBm (baseline -85), within normal. Enclosure dry. Antenna secure. FW up to date. 2026-02-01: Quarterly check. Updated FW from 2.5.9 to 2.6.1. Backed up config. Checked solar: 13.8V at noon, good. 2025-11-01: Annual check. Replaced self-amalgamating tape on N connector. Cleaned solar panel (bird droppings). Battery 98% capacity. Understanding the Technology What Is LoRa? (For Beginners) LoRa stands for "Long Range." It is a radio modulation technique from Semtech that enables very long range wireless communication at very low power, at the cost of low data rates - the physical layer beneath Meshtastic and MeshCore. How it works LoRa uses chirp spread spectrum - the signal is spread across a wide frequency band using a continuously sweeping chirp tone. This spreading gives LoRa extraordinary resilience to noise. A receiver can decode a packet even when the signal is far below the background noise floor - a capability few low-cost radio systems offer. (Other spread-spectrum schemes, such as GPS, also operate below the noise floor.) Key characteristics Range: 1 - 15 km typical; 30 - 50+ km achievable with elevated antennas Data rate: 0.2 - 22 kbps depending on preset - slower than a 1990s modem, but sufficient for text and GPS Power: Nodes run days to weeks on a small battery; active current is roughly 10 - 30 mA for nRF52-based boards and 40 - 100+ mA for ESP32-based boards. Days-to-weeks battery life applies mainly to nRF52-class hardware; size your battery for your specific board. No subscription: Operates in the unlicensed 902 - 928 MHz ISM band in North America. No SIM, no carrier fees. License-free: Standard operation under FCC Part 15.247 requires no amateur radio license What LoRa is NOT Not WiFi: Far slower, far longer range. No web browsing or streaming. Not cellular: No towers, no coverage maps, no subscription. Works anywhere two nodes are within radio range of each other. Not LoRaWAN: LoRaWAN is a specific hub-and-spoke IoT architecture. Meshtastic and MeshCore are peer-to-peer mesh networks. Same radio hardware, completely different protocols. See the LoRa Mesh vs. LoRaWAN page for the full comparison. Not Bluetooth or Zigbee: Those are short-range (meters). LoRa is long-range (kilometers). Why 915 MHz? The 902 - 928 MHz ISM band is the North American LoRa mesh standard because it is unlicensed under FCC Part 15, has better building and vegetation penetration than 2.4 GHz, and yields practical antenna sizes (~8 cm quarter-wave). The fundamental tradeoff LoRa's extreme range comes at the cost of speed. A 50-byte text packet takes several hundred milliseconds to transmit. This is fine for messaging and GPS tracking - and impossible for voice, video, or large files. Design your use case around this constraint and LoRa delivers remarkable results. LoRa Mesh vs. LoRaWAN Both use the same LoRa radio chips but operate completely differently. This is the most common source of newcomer confusion. LoRaWAN A hub-and-spoke network designed for IoT sensors reporting to the cloud. End devices transmit to fixed gateways; gateways forward over the internet to a server. No direct device-to-device communication. No gateway in range = no connectivity. Examples: The Things Network, Helium. LoRa Mesh (Meshtastic, MeshCore) A peer-to-peer network where nodes communicate directly and relay each other's messages. Works completely offline - no internet required. Messages hop: A → B (relay) → C → D. Adding nodes usually extends coverage and adds redundant paths, though very large or chatty meshes can congest the shared channel. Examples: Meshtastic, MeshCore. Comparison table Feature LoRaWAN LoRa Mesh Architecture Hub-and-spoke Peer-to-peer Network server required Yes (usually internet-hosted; private offline servers are possible but uncommon) No Direct messaging No Yes Multi-hop relay No Yes Works without infrastructure No Yes Typical use case Sensor data to cloud Off-grid comms, group coordination They cannot communicate with each other. Different packet formats, addressing, and network stacks - they share hardware but speak different protocols. Important: LoRaWAN gateways won't build a mesh LoRaWAN gateways ($100 - $300) are internet-backhaul radios, not mesh relays - they pass traffic between devices and a network server (in both directions, including downlinks to devices) but never peer-to-peer. To build a LoRa mesh network you need Meshtastic- or MeshCore-compatible devices, not LoRaWAN gateways. How Mesh Routing Works When two nodes are too far apart to communicate directly, intermediate nodes relay the message. Meshtastic and MeshCore solve this differently. Flooding (Meshtastic) When a node receives a new packet it rebroadcasts it once - unless it first hears another node relay the same packet, in which case it stays quiet (managed flooding). Duplicate detection prevents loops. The message floods outward until it reaches its destination or exhausts its hop count (default 3, configurable up to 7). Simple and robust: No routing tables. New nodes work immediately. Self-healing if relay fails. (Since Meshtastic 2.6, direct messages additionally use a learned next-hop relay, with automatic fallback to flooding, so some routing state does exist for DMs.) Limitation: In a dense mesh, a single message can trigger dozens of rebroadcasts. This is why faster presets such as MediumFast are preferred in dense networks. Path-based routing (MeshCore) MeshCore discovers explicit routes before sending data: Node A's first message is flood-routed; each repeater that relays it appends its ID to the packet's path Destination D sends back a delivery report listing the repeaters the message traversed; this report is flood-routed back to A and becomes the basis for the future direct path Node A caches the route A → B → C → D and uses it for all subsequent messages to D More efficient at scale: Messages travel only the established path - much less airtime than flooding in large networks Limitation: The first message to a new contact is flooded (using more airtime); the efficient direct path only kicks in from the second message onward. Topology changes require re-discovery. Which is better? Both work well in practice. Flooding is simpler and more resilient for small-to-medium networks. Path-based routing scales better for large infrastructure deployments. In practice, your choice is determined by which protocol your local community uses. The mesh advantage In Meshtastic, every node is a potential relay; in MeshCore, only nodes flashed as repeaters relay - client nodes deliberately do not. A hilltop repeater that can hear both a valley and a distant mountaintop effectively bridges those two coverage zones for all messages. A few well-placed infrastructure nodes have outsized impact on total network reach. Understanding LoRa Mesh Networking Core concepts: what mesh networking is, how LoRa works, platform comparisons, and US frequency regulations. What Is a Mesh Network? If you have ever used Wi-Fi at home, you are already familiar with the most common type of wireless network: the star topology. Every device in your house - your phone, your laptop, your smart TV - talks to one central access point (your router), and the router connects everything to the internet. It is simple, it works well indoors, and it is fine as long as that one router keeps working. But what happens if the router goes offline? Every device loses connectivity at the same instant. The whole network collapses around a single point of failure. Now imagine you are in a disaster zone, or deep in a national forest, or at a community event with no cellular service. A star network is useless. There is no router to plug in, and even if there were, its failure would silence everyone. A mesh network solves this by making every single device both a user and a router. Instead of everyone talking through one hub, every node talks to the nodes near it, and those nodes pass the message onward, hop by hop, until it reaches its destination. Remove any one node - or even several - and traffic finds another path around the gap, provided another path exists - in a sparse mesh, losing a single well-placed relay can still partition the network. There is no central authority and no central server that can take the whole network down; however, a sparse mesh can still depend on individual relay nodes. How a Message Travels in a Mesh Picture five hikers spread across a mountain trail, each carrying a LoRa radio. Alice is at the trailhead; Echo is at the summit. Between them, out of direct radio range of each other, are Bob, Carol, and Dave. Alice wants to send Echo a message: "Summit still clear?" Alice's radio broadcasts the packet. Bob and Carol can both hear it. Bob rebroadcasts it. Carol rebroadcasts it. (Duplicate suppression logic prevents infinite loops - each packet carries a unique ID that nodes remember and discard if seen again.) Dave hears one of those rebroadcasts and passes it along. Echo receives the packet, having never been able to hear Alice's original transmission directly. Echo's reply travels back by whatever path is available at that moment. This is called multi-hop packet forwarding. Each intermediate node is sometimes called a relay or a repeater. The exact path a message takes is not fixed - it depends on which nodes are currently powered on and within radio range of each other. The network continuously self-heals: if Dave's battery dies mid-hike, messages between Carol and Echo simply reroute through whoever is still on the air. Self-Healing Topology The term self-healing means the network does not need a human administrator to reconfigure routes when a node disappears. Routing happens automatically. The flooding-based protocols this wiki covers (Meshtastic, MeshCore) do not maintain explicit routing tables - nodes simply rebroadcast and the surviving nodes carry traffic along whatever paths remain. When a node disappears, the mesh stops depending on it without any user intervention; how quickly traffic reroutes depends on the protocol and how the network is configured. This is why mesh networks are so valuable for emergency communications, outdoor adventures, festivals, and anywhere you cannot rely on existing infrastructure. Star Topology vs. Mesh Topology at a Glance Feature Star (Wi-Fi, cellular) Mesh (LoRa mesh) Central hub required? Yes - everything depends on it No - every node is equal Single point of failure? Yes No central one (but a sparse mesh can still hinge on one key relay) Range extension Buy another access point, manually configure Add any node; routing is automatic Works off-grid? Only if you have power and hardware Yes - battery-powered nodes, no internet needed Works during infrastructure failure? No Yes - if nodes have independent power and remain in radio range Setup complexity Plug in the router and done Flash firmware, configure - slightly more involved Why Mesh Is Ideal for Off-Grid Communications In situations where commercial infrastructure is unavailable or unreliable - wildfires, earthquakes, backcountry recreation, sailing, amateur radio events - a mesh network can be a useful supplemental option for short- to medium-range text communications, alongside (not instead of) proven tools like two-way radios or satellite messengers with SOS for life-safety use. Here is why: No subscription fees. There is no carrier, no monthly bill, no account needed. No internet connection required. The mesh works entirely peer-to-peer. The nodes themselves are the network. Incrementally deployable. Even two nodes form a functioning (if very small) mesh. Every node you add extends the network further. Low power. LoRa radios can run for days or weeks on a small battery. Nodes can be solar-powered for permanent outdoor deployment. Long range. A single LoRa hop can span several kilometers in open terrain. With a few well-placed elevated relay nodes a multi-hop mesh can cover a county - though each added hop consumes shared channel capacity, and Meshtastic's default hop limit (3, configurable up to 7) must be considered. The next page explains the radio technology that makes all of this possible at such low power and over such long distances: LoRa. LoRa Technology Explained LoRa stands for Long Range. It is a wireless radio modulation technique invented by a French startup called Cycleo and acquired by Semtech in 2012. LoRa chips appear in millions of devices worldwide today, from smart utility meters to wildlife trackers to community mesh nodes. To understand why LoRa is so effective for mesh networking, you need to understand the core technique it uses: Chirp Spread Spectrum. What Is Chirp Spread Spectrum? Most radio systems transmit data on one fixed frequency. A chirp spread spectrum (CSS) system does something different: it sweeps the signal continuously across a range of frequencies, rising or falling in pitch over time (like a bird's chirp - hence the name). The receiver looks for this specific sweep pattern rather than listening at one spot. Why does this matter? Several reasons: Noise rejection. Man-made interference tends to be concentrated at specific frequencies, while a CSS signal is spread across the whole channel. Because the signal is spread across a wide band, any noise at one frequency only affects a small fraction of the signal. The receiver can mathematically reconstruct the original data even when much of the band is noisy. Multipath resistance. Radio signals bounce off buildings, hills, and trees. These echoes arrive at the receiver slightly delayed and can cancel out the original signal. CSS is much more resilient to this effect than narrowband modulation. Low detectability. A spread-spectrum signal looks almost like background noise to anyone not specifically looking for it, making it robust in RF-noisy environments. Processing Gain and Extraordinary Sensitivity The key metric for a radio receiver is its sensitivity - the minimum signal power it can decode. A conventional FM radio might have a sensitivity of around - 100 dBm (decibel-milliwatts). LoRa achieves sensitivities around - 134 to - 137 dBm at the bandwidths used for mesh (BW125-250 kHz, SF12), and as low as ~- 148 dBm only at very narrow bandwidth (7.8 kHz) not used by Meshtastic/MeshCore. That is roughly 50 dB better than FM, which means LoRa can receive signals tens of thousands of times weaker. This extraordinary sensitivity comes from processing gain: the mathematical process of correlating the received sweep against an expected template. The more time and bandwidth the receiver spends correlating, the more gain it recovers. LoRa lets you tune this trade-off with a parameter called the Spreading Factor. What Spreading Factor Actually Does The Spreading Factor (SF) is a number from 5 to 12 on modern LoRa chips (SX126x); older SX127x chips are used with SF7-12. It controls how many chips are used to encode each symbol (and each symbol carries SF bits). Low SF (e.g., SF7): fewer chips per symbol → faster data rate → shorter range → lower battery use per packet. Used when nodes are close together. High SF (e.g., SF12): more chips per symbol → very slow data rate → very long range → more battery use per packet. Used when you need maximum range. Think of it like this: shouting a word once at normal speed (SF7) versus repeating every syllable ten times very slowly (SF12). The slowly repeated version can be understood even with a lot of background noise, but it takes much longer to say. A common community mesh preset uses SF10 or SF11, which balances range and throughput for typical text messaging workloads. Meshtastic's default "LongFast" channel uses SF11 on 915 MHz. The Range / Speed / Power Triangle In radio, you almost never get something for nothing. LoRa is no exception. The three variables - range, data rate, and power consumption - are always in tension: To go farther (more range), you must slow down (lower data rate) or transmit louder (more power). To go faster (higher data rate), you must accept shorter range or higher power. To save power, you must accept either shorter range or slower speed. LoRa's key achievement is that it pushes this triangle to extremes: it can achieve very long range at very low power, but only by accepting a very slow data rate. A LoRa packet might carry 50 - 250 bytes of useful data. The raw over-the-air data rate at SF12 is about 250 bits per second. That is slower than a 1990s dial-up modem. But for text messages, GPS coordinates, and sensor readings, it is entirely sufficient - and few technologies match that range at that power level in unlicensed spectrum. LoRa vs. FSK vs. GFSK To appreciate LoRa, compare it with the modulation techniques used by competing low-power radios: Modulation How it works Typical sensitivity Typical range (open field) Used in FSK (Frequency Shift Keying) Switches between two fixed frequencies for 0 and 1 - 112 dBm ~1 - 2 km Many 433/915 MHz modules, older APRS GFSK (Gaussian FSK) FSK with a Gaussian filter to reduce bandwidth - 105 to - 115 dBm ~1 - 3 km Bluetooth, ANT, older Nordic proprietary radios LoRa (CSS) Frequency sweep across entire channel bandwidth - 137 to - 148 dBm 5 - 15+ km Meshtastic, MeshCore, LoRaWAN The ~30 - 40 dB sensitivity advantage is large: in ideal free space a 30-40 dB advantage corresponds to 30-100x the distance of FSK at the same transmit power. Over real terrain the practical gain is smaller (several times the range) but still dramatic. This is why LoRa took over the low-power, long-range wireless market. Link Budget: The Simple Version A link budget is just an accounting exercise: you add up all the gains and losses between transmitter and receiver and check whether the signal is still strong enough at the end. Here is a simplified example: Transmit power: +30 dBm (1 watt) Transmit antenna gain: + 2 dBi Path loss (10 km): -120 dB (including ~8 dB excess/ground loss over the ~112 dB free-space value at 915 MHz) Receive antenna gain: + 2 dBi ----------------------------------------------- Received signal: -86 dBm LoRa sensitivity (SF11, 250 kHz as used by LongFast): -131 dBm Link margin: +45 dB (plenty of headroom) A positive link margin means the link can work; in practice you want 10-20 dB of spare margin for fading. A larger margin means you have room to lose (walls, foliage, less-than-perfect antenna placement). The extraordinary sensitivity of LoRa gives you a huge margin even for difficult paths through vegetation or inside buildings. LoRa Is Not LoRaWAN One important clarification: LoRa is just the physical-layer radio modulation. It says nothing about how multiple devices share the channel, how data is addressed, or how the network is organized. LoRaWAN is one specific network protocol built on top of LoRa - but it is not the only one. Meshtastic and MeshCore are entirely different protocols, also built on LoRa. The next page compares all four of these in detail. LoRa vs LoRaWAN vs Meshtastic vs MeshCore One of the most common sources of confusion when starting out is the alphabet soup of acronyms: LoRa, LoRaWAN, Meshtastic, MeshCore. People use them interchangeably, but they are four very different things operating at four different layers. This page explains each one clearly and shows you when each is the right choice. The One-Line Summary of Each LoRa - a radio modulation technique (the physics of the signal) LoRaWAN - a centralized IoT network protocol built on top of LoRa Meshtastic - an open-source, peer-to-peer mesh protocol built on top of LoRa MeshCore - another open-source, peer-to-peer mesh protocol built on top of LoRa LoRa is the foundation. Everything else is a different architecture built on top of that foundation. Comparison Table LoRa LoRaWAN Meshtastic MeshCore What is it? Radio modulation (physical layer only) Network protocol + cloud infrastructure Open-source mesh firmware + apps Open-source mesh firmware + apps Network topology N/A - just the radio signal Star-of-stars: end nodes → gateways → cloud server True peer-to-peer mesh True peer-to-peer mesh Requires gateway? N/A Yes - a LoRaWAN gateway is mandatory No No Requires internet? N/A Yes - gateway must reach a network server No No Who manages it? Semtech (chip maker) LoRa Alliance (standards body) + network operators Open-source community Open-source community (created by Scott Powell; clients by Liam Cottle) Primary use case Any LoRa-based application IoT sensor reporting (meters, trackers, sensors) Community mesh, off-grid text + GPS Community mesh, off-grid text + GPS Typical data payload Anything LoRa can carry (up to ~250 bytes) Small sensor readings (10 - 50 bytes) Text messages, GPS, telemetry Text messages, GPS, telemetry Works off-grid? N/A No in practice - requires a gateway plus a network server (almost always internet-hosted) Yes - fully off-grid Yes - fully off-grid Encryption N/A - you implement it AES-128 end-to-end (mandated by spec) AES-256 channel encryption Elliptic curve, per-message encryption App ecosystem None (raw hardware) Industry dashboards (The Things Network, etc.) Android, iOS, web client Android, iOS, web client Beginner-friendly? Hardware only - requires firmware development Moderate - requires gateway setup and TTN account Yes - free flasher tool, polished apps Yes - free flasher tool, active community LoRa: The Physical Foundation LoRa is implemented inside a Semtech radio chip (such as the SX1276 or SX1262). The chip generates and receives the chirp-spread-spectrum signal. By itself, a LoRa chip does nothing useful - it is like having a blank radio transmitter with no protocol to tell it what to say or how to talk with others. You always need a higher-level protocol on top of it. LoRaWAN: Built for IoT, Not for People LoRaWAN was designed to connect large numbers of low-power sensors to the internet. The architecture is deliberately star-shaped: sensors (called "end nodes") are not allowed to talk to each other directly. They can only talk upward to a gateway, and the gateway forwards data to a cloud-based "network server." LoRaWAN is excellent for reading water meters, tracking shipping containers, or monitoring soil moisture across a farm - all cases where data flows in one direction toward a central server. LoRaWAN is not designed for: Direct person-to-person messaging Off-grid use (without a powered gateway with internet access) Community resilience networks (a device loses connectivity when no reachable gateway or the network server is down - the network is only as resilient as its infrastructure) Meshtastic: Open-Source Mesh for the People Meshtastic is a free, open-source project that turns cheap LoRa hardware into a fully off-grid text and GPS mesh network. Developed since 2020 and now maintained by a large open-source community, it is the most widely deployed LoRa mesh platform in the world. Key characteristics: Nodes communicate directly with each other using a flooding-based mesh routing algorithm called Managed Flood. Users control the network via polished Android and iOS apps connected to the node over Bluetooth or Wi-Fi. There are no gateways required. Any node automatically acts as a relay for other nodes. Large community, extensive documentation, active development. Best choice if you want to join the largest existing mesh community or buy from the widest hardware selection. MeshCore: A Newer Alternative with Different Trade-offs MeshCore is a newer open-source mesh platform with a slightly different design philosophy. Rather than simple message flooding, MeshCore uses a more structured routing approach that can reduce channel congestion on larger, busier networks. Key characteristics: Roles are explicit: nodes are configured as clients, repeaters, or room servers (group chat hubs). This clarity reduces unnecessary retransmissions. Strong encryption using elliptic-curve cryptography. Also has Android, iOS, and web clients. Growing community, particularly in areas building more deliberately structured networks. Good choice if you want more control over how traffic is routed or if you are building infrastructure (repeaters, room servers) rather than just carrying a node. Which One Should You Use? You want to buy sensors and report data to the cloud: Use LoRaWAN with The Things Network. You want to join the biggest community mesh and get started as fast as possible: Use Meshtastic. You want a more structured network with explicit roles and you do not mind a slightly steeper learning curve: Use MeshCore. You want to build your own custom firmware from scratch: Use raw LoRa hardware and write your own protocol on top of it. For most beginners, Meshtastic is the right first step. MeshCore is an excellent second platform to explore once you have a feel for how mesh networking works in practice. Both are covered in detail throughout this wiki. The 915 MHz ISM Band Nearly all LoRa mesh devices sold for North America operate in the 915 MHz ISM band (902 - 928 MHz). (A few 433 MHz LoRa devices also exist and are usable here, but they are uncommon.) Understanding what that means - and what the rules are - will help you choose the right hardware, set the right channels, and avoid interference with your neighbors. What Is the ISM Band? ISM stands for Industrial, Scientific, and Medical. These bands are designated internationally (ITU Radio Regulations) for industrial, scientific and medical RF applications. They are not, strictly, "set aside for unlicensed communications" - rather, in the US the FCC additionally allows unlicensed communications devices (like LoRa) to share them under Part 15 rules, on a non-interference, secondary basis. (Note: 902-928 MHz is an ISM band only in ITU Region 2, the Americas.) The trade-off is that these bands are open to many users, and everyone has to play nicely together by following power limits and other technical rules. In the United States, the band used by LoRa spans 902 to 928 MHz (commonly referred to as the "900 MHz band" or "915 MHz band"). It is regulated by the FCC under Part 15 of the Code of Federal Regulations. FCC Part 15 Power Limits The FCC imposes strict limits on how much power you can transmit in this band: 1 watt (30 dBm) conducted power - this is the maximum power at the antenna connector of the radio. 4 watts (36 dBm) EIRP (Equivalent Isotropically Radiated Power) - this is the derived ceiling that results from the gain-reduction rule, not a separate flat allowance. The 1 W conducted limit assumes an antenna gain of up to 6 dBi. If your antenna gain exceeds 6 dBi, you must reduce conducted power dB-for-dB by the amount the gain exceeds 6 dBi (per 47 CFR 15.247(b)(4)). An antenna of 6 dBi or less requires no power reduction. What does this mean in practice? Most LoRa modules transmit at 20 - 27 dBm (0.1 - 0.5 watts). A typical 3 dBi gain antenna is perfectly legal at full transmit power. A 10 dBi antenna (4 dB above 6 dBi) requires reducing conducted power by 4 dB, to 26 dBm - the reduction is keyed to antenna gain, not to any EIRP arithmetic. (For fixed point-to-point links the reduction is more lenient, 1 dB per 3 dB of gain above 6 dBi.) Almost no consumer LoRa hardware comes close to these limits, so for most users, this is a non-issue. No License Required (With Caveats) Because LoRa operates under Part 15, you do not need an amateur radio license or any other license to operate a Meshtastic or MeshCore node in the United States. This makes community mesh networks accessible to everyone, not just licensed ham radio operators. However, Part 15 devices must accept all interference and must not cause harmful interference to any authorized radio service - whether in-band (including primary and government users of 902-928 MHz) or in adjacent bands. In practice, the 900 MHz band is busy with cordless phones, baby monitors, some Wi-Fi equipment, and other ISM devices - but LoRa's spread-spectrum nature makes it naturally robust against narrowband interference from these sources. Duty Cycle Considerations In the United States, digitally modulated systems in the 902 - 928 MHz band - the category that covers LoRa mesh devices - have no duty-cycle limit. (Frequency-hopping systems, by contrast, do have per-channel dwell-time limits under 15.247(a)(1)(i).) LoRa itself does not frequency-hop (it stays on one channel per packet), and the Part 15 rules permit continuous operation as long as power limits are respected. That said, good network citizenship means keeping your transmit duty cycle low. If every node on a channel is transmitting constantly, collisions will degrade performance for everyone. Meshtastic and MeshCore both implement built-in duty cycle management and back-off algorithms to prevent nodes from saturating the channel. Channel Selection and Frequency Hopping Within the 902 - 928 MHz band, LoRa devices can use many different center frequencies (channels). Meshtastic does not use a single fixed frequency for its default LongFast preset; instead it computes the exact channel frequency from the selected region, preset (modem config), and channel name, dividing the band into numbered slots. For the US region, the LongFast primary slot lands near 906 - 907 MHz, but the precise value is derived by the firmware rather than being a hard-coded number - see the Meshtastic frequency-slot documentation. MeshCore's USA/Canada preset uses similar frequencies. Frequency hopping (rapidly jumping between channels) is permitted and used by some competing technologies (like the older FHSS radios), but it is not required for LoRa and is not used by Meshtastic or MeshCore in their standard modes. Instead, they use a fixed channel, relying on LoRa's spread-spectrum nature to handle interference. Channel selection matters when: You want to create a private channel separate from the public mesh. You want to avoid interference from other mesh users or industrial equipment. You are deploying multiple networks in the same area and need them to coexist. What About Europe and Other Regions? The 915 MHz band is specific to the Americas. In Europe, LoRa community mesh devices typically use the 868 MHz ISM band (863 - 870 MHz), regulated by the ETSI under different rules including duty-cycle limits on many sub-bands. Other regions have their own band plans: Region LoRa Band Frequency Range Key Rule USA / Canada 915 MHz 902 - 928 MHz 1W conducted / 4W EIRP, no duty cycle limit Europe / UK 868 MHz 863 - 870 MHz 25 mW ERP and 0.1-1% duty in most sub-bands; 500 mW ERP / 10% duty in 869.4-869.65 MHz (the Meshtastic EU_868 default) Australia / NZ 915 MHz 915 - 928 MHz 1W EIRP Asia (varies widely) Varies by country Varies e.g. China 470-510 MHz, India 865-867 MHz, Japan/Korea ~920-923 MHz, Southeast Asia 920-925 MHz (AS923) This is critical: a European 868 MHz LoRa device will not work on a US 915 MHz mesh, and vice versa. Always check that the hardware you buy is rated for your region's frequency band before purchasing. Hardware sold in the US is built for the 915 MHz band, but Meshtastic firmware ships with the region UNSET and will not transmit until you select your region (US) in the app on first setup. If you are buying from overseas vendors, double-check the product listing. Some newer hardware (such as devices using the Semtech SX1262 chip) can be configured in software to cover both 868 MHz and 915 MHz, as the chip supports a wide frequency range. However, the antenna is typically tuned for one band or the other, so even if the chip can transmit on the wrong frequency, performance will be degraded. Your First Node — Step by Step Practical walkthroughs for getting your first LoRa mesh message through on Meshtastic and MeshCore, and how to connect with your local community mesh. Getting Your First Message Through: Meshtastic This guide will take you from zero to sending a LoRa mesh message on Meshtastic, step by step. No prior RF or networking experience is required. If you get stuck, the What to Check sections at the end will help you diagnose the most common problems. Step 1: Buy the Right Hardware You need a LoRa development board with the Meshtastic firmware flashed onto it. The two most popular beginner choices are: LILYGO T-Beam (v1.1 or v1.2) - a combined LoRa radio, GPS module, and ESP32 microcontroller with an 18650 battery holder. It is the classic Meshtastic node. Costs $25 - 40 on AliExpress or Amazon. Heltec LoRa 32 v3 - a compact board with a small built-in OLED display, LoRa radio, and ESP32. No built-in GPS, but lighter and cheaper ($20 - 25). A good choice if you want a pocket-sized node. Make sure the board you buy is rated for 915 MHz (for the USA). This should say "915MHz" or "US915" in the product listing. A 868 MHz EU version will not work on US community meshes. You also need a short USB cable (usually USB-C or micro-USB depending on the board) to connect the device to your computer for flashing. Step 2: Flash the Meshtastic Firmware Meshtastic provides a web-based flashing tool so you do not need to install any software. Open Google Chrome or Microsoft Edge (the tool requires a browser with Web Serial support, and Chrome or Edge is what the Meshtastic project recommends). Desktop Firefox added Web Serial support in version 151 (2026), but the Meshtastic project does not yet recommend it; Safari does not support Web Serial at all. Go to flasher.meshtastic.org. Connect your LoRa board to your computer with the USB cable. Click Get Started. The site will prompt you to select a serial port - choose the one that appeared when you plugged in your device (usually labeled "USB Serial" or "CP210x" or "CH9102"). Select your device model from the dropdown list. Click Flash. The tool will download the latest stable firmware and write it to the device. This usually takes a minute or two. When flashing is complete, the device will reboot automatically. You should see the Meshtastic boot screen on the OLED display (if your board has one) or a blinking LED. If the serial port does not appear, you may need to install a USB-to-serial driver for your board's USB chip. Recent LILYGO T-Beams use a WCH CH9102 chip (install the WCH driver; some early units used a CP2104). The Heltec v3 uses a Silicon Labs CP2102 chip (install the Silicon Labs CP210x driver). Search for the chip name + "driver" to find the official installer. Step 3: Install the Meshtastic App Meshtastic is controlled through a phone app that communicates with the node over Bluetooth or Wi-Fi. Android: install Meshtastic from the Google Play Store (it is free and open source). iPhone / iPad: install Meshtastic from the Apple App Store. There is also a web-based client at client.meshtastic.org if you prefer to manage the node from your computer. Step 4: Pair via Bluetooth Open the Meshtastic app and tap the + button to add a new device. The app will scan for nearby Bluetooth devices. Your node should appear, named something like "Meshtastic_XXXX" (where XXXX is a short ID derived from your device's MAC address). Tap on it. The app will prompt you for a pairing PIN. Look at the OLED display on your node - the PIN is shown there. Enter it in the app. Once paired, the app will sync with the device and show you the main interface: a map, a messages tab, and a node list. Step 5: Configure Your Region and Channel Before the radio will transmit, you must set your region: In the app, go to the device configuration (the wrench/gear icon). Find LoRa Config → Region and set it to US. Tap Save (or the checkmark). The device will reboot briefly. By default, Meshtastic uses the LongFast channel, which is the standard public channel used by community meshes across the US. Leave it on LongFast for now. Step 6: Send Your First Message Tap the Messages tab in the app. Tap Primary Channel (or the LongFast channel name). Type a message in the text box at the bottom and hit Send. Your node will transmit the message over LoRa. If you are alone and there are no other Meshtastic nodes within range, the message will still appear in your chat history - it was sent, but there was no one to receive it. To verify two-way communication, you need either a second node or a nearby community mesh member. With only a single node there is no way to send a message "to yourself" over the radio - the app and the node are the same endpoint, so nothing meaningful is transmitted or received over RF, and Meshtastic acknowledgments come from another node rebroadcasting or a recipient ACKing, never from a node hearing its own transmission. To sanity-check a single isolated node, instead confirm that the region is set, watch the channel-utilization / airtime statistics in the app to see the radio is active, and look for any nearby community node to appear in the node list. A genuine end-to-end radio test requires a second device or a nearby mesh member. Step 7: Join the LongFast Channel The LongFast channel is the default public channel. If there are other Meshtastic users within a few kilometers (or connected through relay nodes), your messages will reach them and theirs will reach you. The node list in the app will show you who is currently visible on the mesh. What to Check If Nothing Works The serial port never appeared in the flasher Install the USB-to-serial driver for your board's chip: the CH9102 (WCH driver) for recent T-Beams, or the CP210x (Silicon Labs driver) for the Heltec v3 and older T-Beams. On Windows, check Device Manager for a yellow warning icon on an unknown USB device. Flashing failed with an error Some boards need to be put into "bootloader mode" before flashing. Hold the BOOT button while pressing RESET (or while plugging in the USB cable). Then try flashing again. The Bluetooth device doesn't appear in the app Grant the app its requested Bluetooth permissions (on Android 11 and earlier, Location permission was also required for BLE scanning; on Android 12 and later, scanning uses the BLUETOOTH_SCAN permission and Location is not inherently required). The app may still ask for Location for position features. Try toggling your phone's Bluetooth off and back on. Messages show "Waiting to send" indefinitely The region is not set. Go to LoRa Config and set it to US. The radio will not transmit until a region is configured. Messages sent but no acknowledgement received This is normal if you are alone on the mesh - there is no one to acknowledge. Try moving outdoors and away from buildings for better range. Check meshmap.net (next chapter) to see if there are community nodes near you. Getting Your First Message Through: MeshCore MeshCore is a newer peer-to-peer LoRa mesh platform that differs from Meshtastic in some important ways. This guide walks you through buying hardware, flashing firmware, and sending your first message - including a plain-language explanation of what makes MeshCore distinct from a beginner's perspective. Step 1: Buy Compatible Hardware MeshCore runs on many of the same LoRa development boards as Meshtastic, including: Heltec LoRa 32 v3 - compact, inexpensive ($20 - 25), has a built-in OLED display. LILYGO T-Echo - a sleek device with an e-ink display and GPS, popular for MeshCore "client" nodes. LILYGO T-Deck - has a built-in keyboard, making it usable without a phone for messaging. RAK WisBlock - modular system popular for building infrastructure repeater nodes. Most boards using the nRF52840 or ESP32 + SX1262 chip combination. As with all North American mesh hardware, make sure your board is rated for 915 MHz. Check the product description for "915MHz", "US915", or "ISM 915". Step 2: Flash MeshCore Firmware MeshCore provides its own web-based flashing tool: Open Google Chrome or Microsoft Edge. Go to flasher.meshcore.io. Connect your board to your computer via USB. Click Connect and select the serial port for your device. Select your board model from the device list. Select the firmware variant you want. For most beginners, choose the Companion (client) variant - this is the mode you use when connecting a phone app to the node over Bluetooth - or Repeater if you are building a fixed relay node. (Note: the exact label for the companion/client variant can vary slightly between the flasher and app versions.) Click Flash and wait for the process to complete (usually a minute or two). If the serial port does not appear, the same driver fix applies as for Meshtastic: install the CP2102 or CH340 driver depending on your board's USB chip. Step 3: Install the MeshCore App Android: Search for MeshCore on the Google Play Store, or sideload the APK from files.liamcottle.net/MeshCore (the official download location linked from the MeshCore FAQ). iPhone / iPad: Search for MeshCore on the App Store. Web client: Available at app.meshcore.nz. Step 4: Configure the USA/Canada Preset MeshCore uses channel presets to configure frequency, spreading factor, and bandwidth. For North America, you want to set the region/frequency to North America (915 MHz): Open the MeshCore app and connect to your node via Bluetooth (the pairing process is similar to Meshtastic - the node's name will appear in the Bluetooth scan list). Go to the node settings (gear icon). Find the Channel or Radio Config section. Select the North America / US-Canada (915 MHz) preset. The exact wording varies by app version. This configures the node for 915 MHz operation with appropriate spreading factor and bandwidth settings for community mesh use. Save the settings. The node will apply the configuration and restart the radio. Step 5: Pair and Send Your First Message In the MeshCore app, go to the Contacts or Chat tab. Nearby nodes appear in Contacts after they send an advert - so your own node will not appear as a contact, and you need at least one other node in range to populate the list. To test with just a single device, post a message to a public channel. To test the radio path end-to-end (a direct message), you need a second node or another MeshCore user within range. Type a message and tap Send. Your node will transmit it. You will see it appear in the conversation. Because MeshCore uses a more structured routing approach than Meshtastic, it distinguishes clearly between direct messages (private, sent to a specific node), channel messages (broadcast to everyone on the same channel), and room server messages (routed through a dedicated hub node). For your first test, a broadcast channel message is the easiest way to confirm your node is transmitting; to test a direct message you will need a second node or a nearby community node in range. How MeshCore Feels Different from Meshtastic (Beginner's Perspective) If you have used Meshtastic before, you will notice a few differences: Explicit node roles. In Meshtastic, every node implicitly relays for every other node. In MeshCore, you explicitly configure a node as a client (your personal node, does minimal relaying), a repeater (infrastructure node that forwards traffic), or a room server (a hub for group chat). This makes the network's behavior more predictable and reduces unnecessary transmissions, but requires a bit more intentional planning. Different discovery model. Meshtastic nodes automatically announce themselves and appear in a node list. MeshCore's discovery works slightly differently - you may need to add contacts manually or enable node broadcasting to see nearby nodes. Stronger encryption by default. MeshCore uses elliptic-curve Diffie-Hellman key exchange for direct messages, giving each conversation unique encryption keys. Note that Meshtastic also uses public-key cryptography for direct messages (since firmware 2.5.0); both systems use shared keys for channel (group) messages, so the comparison is really about implementation details rather than one being broadly "more robust" than the other. Less plug-and-play for newcomers. Meshtastic has more polished beginner documentation and a larger US-based community, so it is often easier to get your first message through quickly. MeshCore rewards the extra learning investment with a more controlled network architecture. What to Check If Nothing Works The flasher does not detect the device Try a different USB cable (many cables are charge-only and lack data wires). Try a different USB port. Install the USB-to-serial driver for your board's chip. The app cannot pair with the node via Bluetooth Make sure the node is fully booted (wait a few seconds after flashing for it to finish booting). Grant the app Bluetooth and Location permissions on Android. If pairing fails, put the node in pairing mode if required (consult the MeshCore documentation for your board). Messages are queued but not transmitted If your radio settings (frequency / spreading factor / bandwidth) don't match your region's preset, you won't be able to hear or reach anyone - verify the North America (915 MHz) preset is applied. You cannot find other MeshCore users nearby MeshCore has fewer deployed nodes than Meshtastic in many areas. Check the MeshCore Discord (linked in the app's help section) for your region's activity level, or invite a friend to flash a second node for testing. Connecting to Your Local Community Mesh Having a single node transmitting into the void is technically functional, but the real magic of a mesh network only appears when you are connected to other people. This page explains how to find out whether there is already an active mesh in your area, what to do if there is not, and how to behave as a good citizen when you join an existing community network. How to Find an Existing Local Mesh meshmap.net meshmap.net is a community-maintained map of active Meshtastic nodes worldwide. Nodes that are configured to share their GPS position (or have a manually set location) appear as pins on the map. Zoom into your city or region and see if there are any active nodes nearby. A cluster of pins usually indicates an active local community. Note: meshmap.net only shows nodes whose packets reach the public MQTT server - either because the node itself uplinks via MQTT or because a nearby MQTT-connected node heard it over LoRa - and that share a position. There may be active mesh users in your area who simply are not showing up on the map. The absence of pins does not necessarily mean no one is on the mesh. Local Ham Radio Clubs Many early adopters of LoRa mesh technology are also licensed hams. Some ham radio clubs run Meshtastic or MeshCore infrastructure as an emergency communications resource. Search for your nearest amateur radio club and check their website or newsletter for mentions of "LoRa mesh", "Meshtastic", or "digital emergency comms." Many clubs hold regular nets or meetings where you can meet local mesh operators in person. Reddit Communities Two subreddits are particularly useful for finding local activity: r/meshtastic - the primary community for Meshtastic users. Post a message asking if there are users in your metro area. Many local community threads exist. r/MeshCore - the community for MeshCore users. (For broader mesh-networking discussion, look for an active general mesh subreddit and confirm it is current before posting.) Search for your city name within these subreddits before posting - there may already be a thread or weekly check-in from your area. Discord Servers Both Meshtastic and MeshCore have official Discord servers: The Meshtastic Discord has community channels including regional discussion. It is searchable and very active. The MeshCore Discord is smaller but growing, with channels for regional coordination. Many local groups also run their own Discord servers. Searching Discord for "[your city] + mesh" or "[your state] + Meshtastic" often turns up active local servers. Facebook Groups and Nextdoor In some regions, mesh community organizing happens on Facebook rather than Reddit or Discord, particularly in less tech-oriented areas. Searching Facebook for "Meshtastic [your state]" or "LoRa mesh [your city]" may surface local groups. What to Do If There Is No Local Mesh Yet If you look around and find no existing local community - do not be discouraged. Someone has to go first. Here is how to start a mesh from nothing: Get two nodes running. Even a two-node mesh is a functioning network. Ask a friend or family member to flash a second device and test with you. Put a node somewhere high. A well-placed node with clear line of sight on a rooftop, hilltop, or tower can dramatically extend the mesh's reach - a well-placed node can cover several kilometers, but actual range depends heavily on height, terrain, and obstructions. Before placing a node on any rooftop or tower, get the property owner's written permission, confirm any insurance the site owner requires, and never climb a tower without proper training and equipment - hire a qualified climber for tower work. Post on local channels. Post in your local Reddit, Nextdoor, or Facebook group. "Anyone else in [city] on Meshtastic?" is a simple, effective opener. Contact your local ARRL club. Ham radio operators often have the infrastructure access (towers, power, internet backhaul) to anchor a community mesh and an existing interest in emergency communications. Be patient. Most thriving mesh communities started with one or two people who set up a few nodes and told their friends. Growth is gradual. Network Etiquette: How to Be a Good Mesh Citizen Mesh networks are a shared commons. The channel bandwidth is limited, every transmission affects everyone nearby, and the community is built on mutual goodwill. Follow these guidelines when joining or operating on an existing network: Do Not Spam Resist the urge to send test messages every few minutes. Every transmission you send uses up channel airtime for everyone on the mesh. Send messages when you have something to say, not just to confirm the radio is working. If you need to test, use the Traceroute feature sparingly instead of broadcasting text messages - but remember that all test traffic still uses airtime too. Match the Community Preset Community meshes converge on a shared channel preset (most commonly Meshtastic's LongFast or a locally agreed preset). If you use a different frequency, spreading factor, or channel name, your node will not be able to communicate with others - it will be on a different "frequency" even if physically nearby. Check with local mesh operators or look at meshmap.net to confirm what preset your community uses before you configure your node. Set a Sensible Node Name Your node's short name and long name are visible to everyone on the mesh. Give your node a recognizable name - your callsign if you are a ham, or a memorable handle. "Node-1234" is anonymous and unhelpful. "KD9ABC-Home" or "TJ-Backpack" tells people who to contact if they have questions or want to connect. Introduce Yourself If there is an active local community, send a brief introduction over the mesh when you first connect: your name (or handle), your rough location, and what you are interested in. Most mesh communities are welcoming and will appreciate knowing a new node has joined. Do Not Enable Router Mode Unless Needed In Meshtastic, you can configure your node with the Router role (the older "Router and Client" role was removed in firmware 2.3.15). This causes the node to forward more traffic and with higher priority than a regular node. Only enable this if you have an elevated, well-connected node specifically intended to serve as network infrastructure. Running router mode on a mobile or indoor node often creates more interference than benefit. Respect Private Channels If you learn of a private channel key being used by a specific group, do not join that channel unless you are invited. Private channels are used for coordinated groups (emergency response teams, event staff, hiking clubs) who need a clean channel away from public traffic. Building Toward a Resilient Regional Mesh The long-term vision of community mesh networks is a resilient communications layer that functions independently of commercial infrastructure. Every node you add, every hilltop you reach, and every neighbor you recruit brings that vision closer to reality. The best meshes are built by communities - not by any single organization - and they grow through the same word-of-mouth enthusiasm that brought you here. Welcome to the mesh. Legal and Regulatory FCC Part 15 Compliance for LoRa Mesh Meshtastic and MeshCore operate in the 902-928 MHz ISM band under FCC Part 15 in the United States. This section explains what the rules require, what they allow, and what you need to know for compliant operation. FCC Part 15 Basics Part 15 covers unlicensed intentional radiators - devices that deliberately emit radio frequency energy. The key rules for 902-928 MHz spread spectrum: Maximum conducted power: 1 watt (30 dBm) - Measured at the radio's antenna connector, before any external antenna Antenna gain above 6 dBi: reduce conducted power dB-for-dB - For antenna gain above 6 dBi, the rule (15.247(b)(4)) requires reducing conducted power by the number of dB the gain exceeds 6 dBi. This reduction is keyed to antenna gain alone; feedline (cable) loss does not offset the required reduction. With a 6 dBi antenna at full 1 W conducted, this works out to a 36 dBm (4 W) EIRP - but the 4 W figure is a derived result of the gain-reduction rule, not a separate flat EIRP allowance you can "spend" cable loss against. No license required for operation within these limits Non-interference - Part 15 devices must accept interference and cannot cause harmful interference to licensed services No protection from interference - You have no recourse if a licensed service interferes with your mesh The 1W + Antenna Gain Calculation Most LoRa hardware ships configured at or below 1W (30 dBm) conducted power. Note that the 1 W limit under 15.247 applies to digitally-modulated systems whose minimum 6 dB bandwidth is at least 500 kHz; many Meshtastic/MeshCore presets use 125-250 kHz bandwidth, which may be certified under different provisions - so treat 1 W as an upper ceiling, not a guaranteed allowance for every preset. If you add a high-gain external antenna, you must reduce conducted power for any antenna gain above 6 dBi. Example calculation: First example: Antenna gain: +6 dBi (at the 6 dBi threshold - no reduction required) Conducted power: 30 dBm (1W) - COMPLIANT (Resulting EIRP works out to about 36 dBm / 4 W, the derived ceiling.) Second example: Antenna gain: +9 dBi (3 dB above 6 dBi) Rule: reduce conducted power by (9 - 6) = 3 dB Maximum conducted power: 30 - 3 = 27 dBm (500 mW) Running 30 dBm conducted into a 9 dBi antenna is NON-COMPLIANT. Note: feedline (cable) loss does NOT offset this 3 dB reduction - the reduction is based on antenna gain alone. For typical community deployments with 5-6 dBi antennas and short coax runs, full 1W conducted power is generally compliant (gain is at or below the 6 dBi threshold). With 8-9 dBi antennas, you must reduce conducted power by the dB of gain above 6 dBi - e.g. to 27-28 dBm for a 8-9 dBi antenna. Point-to-Point Operations (Fixed Infrastructure) Important: at 902-928 MHz there is no special power allowance for fixed point-to-point links. The relaxed point-to-point rule that some guides cite applies only to other bands: Under 47 CFR 15.247(b)(4), if you use a directional antenna with more than 6 dBi of gain at 915 MHz, you must reduce conducted output power by 1 dB for every 1 dB of gain above 6 dBi (dB-for-dB). This holds EIRP at the 36 dBm (4 W) ceiling whether the link is point-to-point or area coverage. The relaxed "reduce power 1 dB for every 3 dB of gain above 6 dBi" point-to-point allowance in 15.247(c)(1)(i) applies only to the 2400-2483.5 MHz (2.4 GHz) band, and the 5725-5850 MHz band (15.247(c)(1)(ii)) allows extra gain with no power reduction at all. Neither applies to the 902-928 MHz band that Meshtastic and MeshCore use. Bottom line for 915 MHz: plan around the 36 dBm (4 W) EIRP ceiling regardless of antenna type or link geometry - there is no higher point-to-point limit to unlock. Pre-Certified Hardware Reputable mesh hardware sold in the US should carry an FCC ID - check the device label or the FCC ID database. Verify this before deploying: some imported hobbyist dev boards are not properly certified, or carry only module-level certification rather than full device authorization. This certification confirms Part 15 compliance when used with the included antenna and at the specified power levels. Using third-party antennas or modifying conducted power beyond the certified levels may affect compliance status. For community mesh operations, using hardware within its certified parameters is the simplest path to compliance. What Part 15 Does NOT Require No license - operators need no FCC authorization No station identification - Part 15 devices do not require ID (unlike Part 97 ham radio) No frequency coordination - you may operate anywhere in the 902-928 MHz band without coordination No notification of your installation Operating in Canada: ISED Rules In Canada, LoRa mesh networking in the 902-928 MHz band operates under Innovation, Science and Economic Development Canada (ISED) regulations, primarily RSS-247 (Digital Transmission Systems, Frequency Hopping Systems and Licence-Exempt LAN Devices) together with RSS-Gen. Key Canadian Rules License-exempt operation - The 902-928 MHz band is license-exempt under RSS-247 for frequency-hopping and digitally-modulated devices meeting power limits Maximum conducted power: 1 watt (30 dBm) - Same as US FCC Part 15 Maximum EIRP - 4 W e.i.r.p. for digitally modulated devices, effectively equivalent to FCC Part 15 limits - see RSS-247 section 5.4 for specific values and conditions Hardware certification - Devices must be certified under ISED (previously IC) marking. Most hardware certified for the US (FCC) market also carries ISED certification. Canadian ISM Band Availability The 902-928 MHz band is available across Canada for license-exempt operation, making it directly compatible with US equipment and networks. Canadian and US mesh operators using 915 MHz hardware can interoperate seamlessly near the border. Interference Considerations Canada shares the 902-928 MHz ISM band with various Part 15 equivalent users. The non-interference and no-protection rules apply equivalently: you must not cause harmful interference, and you have no protection from interference by other users. Quebec/French Language Considerations Canada's Official Languages Act applies only to federal institutions and certain federally regulated businesses - it does not cover hobbyist mesh groups or typical nonprofits publishing software documentation. Organizations doing business in Quebec should instead be aware of Quebec's Charter of the French Language. For individual hobbyist operation, no language requirements affect technical operation of mesh networks. ARES Canada In Canada, the Amateur Radio Emergency Service (ARES) is organized by Radio Amateurs of Canada (RAC); its volunteers operate on amateur frequencies under their individual ISED (formerly Industry Canada) Amateur Radio Operator Certificates, not under organization-held spectrum licenses. When MeshCore or Meshtastic is used on ISM frequencies (902-928 MHz), ARES volunteers operate under the same license-exempt rules as all other Part 15 equivalent operators - no additional authorization is required. Operating Outside North America LoRa mesh hardware designed for North America operates on 902-928 MHz, which is an ISM band in the US and Canada but is not an ISM band in most of the rest of the world. Traveling or deploying internationally requires care. European Union: 868 MHz Europe uses 863-870 MHz for LoRa operations, under ETSI EN 300 220 harmonized standards. EU regulations differ from US Part 15: Frequency: 863-870 MHz - 915 MHz hardware will not meet EU spectrum regulations and may cause interference with other licensed services Duty cycle limits - EU regulations impose maximum duty cycle limits (e.g., 1% in some sub-bands) that are not required in the US. This significantly limits how frequently nodes can transmit Power limits - Most EU sub-bands are limited to 25 mW ERP, but the 869.4-869.65 MHz sub-band used by Meshtastic's EU_868 default allows 500 mW ERP with a 10% duty cycle - still far below the US 4 W EIRP CE marking required for devices placed on the EU market US hardware (915 MHz) must not be operated in EU countries. If you are deploying in Europe, purchase EU 868 MHz hardware specifically. Australia and New Zealand Australia (ACMA) and New Zealand (Radio Spectrum Management) allow LoRa operation on 915-928 MHz under license-exempt rules broadly equivalent to US Part 15. US-band hardware covers the AU/NZ 915-928 MHz range (set region to ANZ), but check that the device carries Australian/NZ RCM compliance marking - FCC certification alone does not authorize sale or use. Asia-Pacific Regulations vary significantly by country: Japan - 920-928 MHz is available under the ARIB STD-T108 standard. Power limits differ from US. South Korea - 920-923 MHz available under MSIT/RRA regulations (Meshtastic KR region). China - 470-510 MHz and 779-787 MHz LoRa bands; 915 MHz is NOT a license-exempt band in China. India - 865-867 MHz for LoRa under WPC guidelines. General International Guidance Before operating in any country, verify local spectrum regulations for the frequency band of your hardware Do not assume US-certified hardware is legal to operate in other countries When traveling, check the destination country's rules before bringing or operating LoRa gear; FCC certification does not authorize operation outside the US. Consider not transmitting at all unless you confirm legality. Consider purchasing locally-certified hardware for extended international deployments Ham Radio and LoRa Mesh The intersection of amateur radio and LoRa mesh networking: licensing, identification, APRS integration, and why hams make natural mesh builders. Ham Radio Operators and Mesh Networking Amateur radio operators - "hams" - have been among the earliest and most enthusiastic adopters of LoRa mesh networking. The overlap is no accident. Decades of experience with emergency communications, antenna theory, radio propagation, and community-oriented operating makes licensed amateur operators uniquely well-suited to deploy, maintain, and extend mesh networks. This page explores that overlap in depth. Why Ham Operators Gravitate Toward LoRa Mesh Emergency Communications Experience Many amateur radio operators are active in ARES (Amateur Radio Emergency Service), RACES (Radio Amateur Civil Emergency Service), CERT teams, Red Cross communications units, or local emergency management organizations. These groups train to provide communications when conventional infrastructure fails - exactly the scenario where a decentralized, infrastructure-free mesh network excels. Ham operators already think in terms of off-grid radio links, battery backup, portable deployments, and redundant paths. LoRa mesh extends that capability to long-range digital data - text messages, GPS positions, sensor readings - without requiring any centralized infrastructure. Antenna Knowledge Antenna performance is perhaps the single largest variable in LoRa mesh link quality. A node with a well-built, properly tuned, and correctly mounted antenna can dramatically extend its effective range - often by multiples - compared to the same hardware with a stock stub antenna mounted poorly; actual gains vary widely with terrain and antenna height. Ham operators understand antenna gain, feed-line loss, polarization, ground plane effects, and the value of height above average terrain (HAAT). This knowledge translates directly: a licensed ham who has built a 2-meter J-pole already understands why mounting a 5.8 dBi 915 MHz collinear on a roof peak outperforms leaving the device on a windowsill. License-Free Operation Is Not a Barrier A counterintuitive point: LoRa mesh on the 915 MHz ISM band operates under FCC Part 15, meaning no license is required at all. Some hams initially assume that radio experimentation requires a license. In the case of LoRa mesh, it doesn't - and this is a feature, not a limitation. A licensed ham can share mesh networking with family members, neighbors, or community organizations without any licensing barrier. The technical expertise that comes with a license is an advantage; the license itself is simply not required for ISM-band operation. Alignment with Ham Radio Values The FCC's basis-and-purpose rule (47 CFR 97.1) lists five principles for the amateur radio service - including its value to emergency communications, advancing the radio art, and training a pool of skilled operators - which align well with mesh networking. Several of those principles map directly onto LoRa mesh: Self-sufficiency: A mesh network functions with zero internet infrastructure. Nodes relay messages peer-to-peer across potentially miles of terrain. Community service: Mesh networks are designed for use in disaster zones, underserved communities, and rural areas lacking cellular coverage, to provide basic text communication and position reporting. Technical experimentation: LoRa is a genuinely interesting radio technology - spread-spectrum chirp modulation, link budgets exceeding 150 dB, and receive sensitivity around -130 to -148 dBm. It rewards the kind of technical curiosity that drives amateur radio licensing in the first place. FCC Part 15 vs Part 97: How the Rules Interact Part 15 - Unlicensed ISM Band Operation LoRa mesh (Meshtastic, MeshCore, and similar systems) operates in the 902 - 928 MHz ISM (Industrial, Scientific, and Medical) band in the United States, regulated under FCC Part 15. Key characteristics of Part 15 operation: No license required for any operator Maximum transmit power limits apply: up to 1 watt (30 dBm) conducted output for digitally-modulated or ≥50-channel frequency-hopping systems under 15.247, with antenna gain up to 6 dBi. Above 6 dBi you must reduce conducted power dB-for-dB by the amount the gain exceeds 6 dBi. (The relaxed point-to-point antenna allowance in 15.247(c) applies only to the 2.4 GHz and 5.7 GHz bands - there is no point-to-point exception in the 902-928 MHz band.) Devices must not cause harmful interference and must accept any interference received No station identification requirement No third-party traffic restrictions No prohibited content rules beyond general FCC regulations (no obscenity, etc.) Your amateur license does not change any of these rules when you operate on Part 15. You are operating as an unlicensed Part 15 user, the same as anyone else. Part 97 - The Amateur Radio Service Part 97 governs licensed amateur radio operation. It allows much higher power levels, operation on exclusive amateur frequencies, limited one-way transmissions such as beacons and telecommand (broadcasting to the public is prohibited under 47 CFR 97.113(b)), and a range of other privileges - in exchange for stricter rules. Key Part 97 requirements include: Station identification: every 10 minutes during operation and at the end of a communication, using your callsign Restrictions on pecuniary interest: with narrow exceptions, you may not transmit communications in which you or your employer has a pecuniary interest (47 CFR 97.113(a)(3)) - organizations with paid staff should review this rule before assigning amateur-radio duties to employees No music, obscenity, or intentional interference Third-party traffic restrictions apply to some countries Encryption rules: messages may not be encoded to obscure meaning (though there is a narrow exception for control of remote stations) Important: Meshtastic channels use AES256-CTR encryption; MeshCore channels use AES-128. Both also use public-key cryptography for direct messages. This encryption is used for confidentiality and channel separation. With its default encryption enabled, LoRa mesh cannot run under Part 97, because Part 97 prohibits encoding transmissions to obscure their meaning. This is not a problem for everyday use: a standard encrypted mesh simply operates under Part 15 instead, where encryption is perfectly legal. Note, however, that Meshtastic offers a documented "ham mode" for licensed operators - enable the licensed setting, use your callsign as the node name, and clear the PSK to disable encryption - under which the node can operate within Part 97 rules. That mode steps outside the normal community mesh. The Licensed Ham Running Mesh: Practical Implications When a licensed amateur operates a standard (encrypted) LoRa mesh node: Their mesh operation is entirely under Part 15 - their license is not implicated They do not need to identify their mesh node with their callsign (though many choose to as a courtesy) Running the standard encrypted mesh, they cannot claim Part 97 power privileges for their mesh transmissions. (A ham who disables encryption and identifies per Part 97 - see Meshtastic's ham mode above - may operate under amateur rules, but is then outside the standard community mesh.) If they simultaneously run APRS or other Part 97 modes (e.g., a dual-radio node with a separate VHF radio for APRS), those Part 97 transmissions must comply fully with Part 97 identification requirements The practical takeaway: operate your mesh on Part 15 ISM band, and the presence or absence of your ham license changes nothing about what you can do. Your license brings knowledge and community - not additional rights on the ISM band. Common Ham Radio + Mesh Scenarios ARES Supplemental Mesh Deployment ARES teams increasingly deploy LoRa mesh alongside their traditional VHF/UHF voice infrastructure during activations and exercises. The mesh provides: A persistent digital channel for text messages, freeing voice channels for coordination traffic GPS position reporting for all team members visible in real-time on the map Sensor data (weather, power status) from fixed sites A redundant path that works even if repeaters fail (mesh is peer-to-peer, not repeater-dependent) Typical ARES mesh deployments use Router-role nodes at high elevation (repeater sites, hilltops, tall buildings) to provide backbone coverage, with Client nodes carried by operators. The mesh coexists with VHF/UHF voice and does not interfere with it. Mesh as APRS Supplement APRS (Automatic Packet Reporting System) on 144.390 MHz has been the primary vehicle tracking and position reporting tool for hams since the 1990s. It works well but has limitations: digipeater coverage is incomplete in rural and mountainous areas, and the 1200-baud AX.25 channel can be congested in urban areas during events. LoRa mesh with APRS bridging provides a complementary system: Mesh nodes can relay position reports to APRS-IS via an internet-connected gateway node In areas where APRS digipeaters don't reach, mesh extends position reporting capability Position reports from unlicensed mesh participants stay on Part 15 within the mesh. But if a gateway bridges those reports onto APRS (whether onto RF directly, or into APRS-IS where an IGate may gate them back to RF), they become third-party traffic transmitted under the gateway operator's callsign - the licensed operator is responsible for that traffic under 47 CFR 97.103 and 97.115, and should decide deliberately whether to gate non-licensed participants' positions. For the APRS bridging component specifically (the Part 97 radio side of the gateway), a Technician class license or higher is required. See the page on APRS and Meshtastic Integration for technical details. Portable/SOTA/POTA Operations Some Summits on the Air (SOTA) and Parks on the Air (POTA) activators carry small LoRa mesh nodes alongside their HF or VHF equipment. The mesh node allows family members or chasers to see real-time position while the operator focuses on radio operation. nRF52-based nodes can run for days per charge, and small trackers (for example the Seeed T1000-E) weigh only tens of grams - bare boards are lighter, while complete nodes with battery and case weigh more - which makes them practical for backpacking activations. Summary Licensed amateur radio operators bring a unique combination of technical knowledge, operational experience, and community orientation to LoRa mesh. The regulatory framework is simple: a standard encrypted mesh runs on Part 15 ISM band regardless of whether the operator holds an amateur license. The license brings expertise, community, the ability to run complementary Part 97 systems alongside the mesh, and - via ham mode - the option to run an unencrypted, identified node under Part 97. But the standard mesh itself needs no license at all. Callsign and Identification in Mesh Networks One of the most common questions from licensed amateur radio operators entering the LoRa mesh world is: do I need to identify my mesh node with my callsign? The short answer is no - but the longer answer involves understanding why, when identification is still a good practice, and the one important exception. The Legal Framework: Part 15 and Identification No Callsign Requirement Under Part 15 LoRa mesh networks operating on the 902 - 928 MHz ISM band in the United States are regulated under FCC Part 15. Part 15 governs unlicensed intentional radiators - devices that intentionally transmit radio frequency energy. Part 15 imposes no station identification requirement whatsoever. There is no rule requiring an ISM band device to identify itself with any callsign, serial number, or other identifier. This is in contrast to Part 97 (amateur radio), which requires identification every 10 minutes during transmission and at the end of each communication. But because LoRa mesh is not operating under Part 97, Part 97's identification rules do not apply. Why This Matters for Operators Many licensed hams instinctively reach for their callsign when configuring any radio transmitter. For LoRa mesh, this habit is not legally required. You can name your node anything - your name, a location, a handle - and be fully compliant with FCC rules. Operators who are not licensed radio amateurs face no different standard: they also have no identification requirement. Best Practices: Using Your Callsign Anyway The Courtesy Tradition While not legally required, many licensed amateur operators choose to include their callsign in their mesh node name as a matter of courtesy and community norms. This practice: Makes it easy for others to identify who operates a node and contact them through normal ham radio channels if needed Contributes to accountability in shared community networks Aligns with the general ham radio culture of identification and transparency Makes it easier to coordinate with ARES, RACES, or other ham radio emergency groups who maintain contact lists by callsign Recommended Naming Formats If you choose to use your callsign in your node name, common formats in the Meshtastic and MeshCore community include: Format Example Use Case CALLSIGN W6ABC Simple, short - best for node short name display CALLSIGN-location K5XYZ-rooftop When operator has multiple nodes in different locations CALLSIGN-mesh W6ABC-mesh Distinguishes mesh node from other callsign uses (APRS, etc.) CALLSIGN-type N7QRT-router Indicates node role to other operators Meshtastic's long name field (up to 39 characters) accommodates descriptive names well. The short name field (4 characters) is typically used for a short identifier - many operators use the suffix of their callsign (e.g., "ABC" for W6ABC) or a regional code. When Operators Choose Not to Use Callsigns There are legitimate reasons an operator might not include their callsign in their node name: Privacy: A callsign is a public record linked to your name and address in the FCC ULS database. Operators who prefer not to be identified by strangers on a community mesh may use a handle or location-based name instead. Non-ham participants: Mesh networks often include participants who are not licensed amateurs. A community mesh might have nodes named after locations, businesses, or personal handles rather than callsigns. There is no requirement for consistency. Organizational nodes: Nodes deployed by ARES groups, public safety auxiliaries, or businesses may use organizational identifiers rather than individual callsigns. When Identification Is Required: The APRS Exception APRS Operates Under Part 97 APRS (Automatic Packet Reporting System) on 144.390 MHz is a Part 97 amateur radio system. When a Meshtastic node acts as an APRS gateway - bridging position reports from the mesh onto the APRS network via a VHF radio transmitter - that VHF transmission is Part 97 operation and full Part 97 identification requirements apply. This means: The APRS gateway must transmit under a valid amateur callsign The operator must hold at least a Technician class license (APRS on 144.390 MHz is a VHF system; the Technician class includes full privileges on 144 MHz) The station must identify every 10 minutes of transmission and at the end of each communication sequence APRS position packets automatically include the source callsign as part of the AX.25 packet format, so identification is inherent in the protocol Practical Guidance for APRS Gateway Operators If you run an APRS gateway node that bridges your mesh to APRS-IS (the internet-based APRS backbone) rather than directly transmitting on 144.390 MHz, the rules are different from RF, but obligations still apply. Connecting to APRS-IS requires a valid amateur callsign and passcode - this is a condition of access, not merely a courtesy. Also note that data you inject into APRS-IS may be retransmitted on RF (Part 97) by third-party IGates, so only inject traffic you could lawfully originate on amateur frequencies under your own callsign. Improperly identified or unlicensed injections can result in Part 97 transmissions under other stations' callsigns, creating compliance exposure for both you and the gating stations. The Question of Mesh Encryption and Part 97 A related identification question sometimes arises around encryption. Part 97 §97.113(a)(4) prohibits transmissions in which the meaning is obscured to others. Meshtastic uses AES256-CTR encryption on channels (the channel PSK can be 128- or 256-bit); direct messages use public-key cryptography since firmware 2.5.0. Because Meshtastic operates under Part 15 (not Part 97), this prohibition does not apply. However, it does mean that you cannot claim to be operating under Part 97 while running standard encrypted Meshtastic channels - the two regulatory frameworks are separate and you must stay in Part 15 for encrypted mesh operation. The practical upshot: stay on the ISM band, operate under Part 15, and identification is entirely optional. Run APRS bridging? Full Part 97 compliance required for that component. Summary LoRa mesh on 902 - 928 MHz ISM band operates under FCC Part 15 - no callsign or identification required Many licensed hams use their callsign in node names as a courtesy - this is a good practice but not a legal obligation Common formats: W6ABC, K5XYZ-rooftop, N7QRT-router Privacy concerns and non-ham participants are valid reasons to use names other than callsigns APRS gateway operation (the VHF radio side) is Part 97 and requires a valid callsign and full identification APRS and Meshtastic Integration APRS (Automatic Packet Reporting System) and Meshtastic are complementary systems that serve overlapping but distinct communities and use cases. Bridging them extends the reach of both networks and gives mesh operators access to decades of ham radio infrastructure. This page explains what APRS is, how Meshtastic can bridge to it, the licensing requirements, and the practical benefits for both communities. What Is APRS? Overview APRS is an amateur radio protocol developed by Bob Bruninga (WB4APR) in the late 1980s and early 1990s. It provides real-time tactical digital communications over amateur radio frequencies, with a particular focus on position reporting and short messaging. In the United States, the primary APRS frequency is 144.390 MHz - a nationwide coordinated frequency where virtually all APRS-capable radios monitor and transmit. What APRS Does APRS carries several types of packets: Position reports: GPS coordinates, optionally with speed, heading, altitude, and a symbol icon. This is what most people think of as "APRS" - dots on a map showing vehicles, fixed stations, and mobile operators. Messages: Short text messages (67 characters maximum) addressed to specific callsigns. APRS messages support acknowledgment. Objects and items: Fixed or moving landmarks placed on the map by any station - useful for event waypoints, severe weather markers, or infrastructure locations. Weather data: Temperature, wind speed, rain accumulation, and other meteorological data from amateur weather stations. Telemetry: Numeric values from sensors, reported on the APRS network. Status and announcements: Text broadcasts not addressed to a specific station. APRS Infrastructure APRS on 144.390 MHz uses a network of digipeaters (digital repeaters) that receive packets and retransmit them, extending range. It also uses I-gates (internet gateways) that bridge the RF network to APRS-IS (APRS Internet Service), a real-time internet backbone that aggregates all APRS traffic globally. The website aprs.fi provides a real-time map of all APRS traffic visible on APRS-IS, widely used by hams worldwide for tracking vehicles, events, and emergency operations. Licensing APRS operates on 144.390 MHz, which is in the 2-meter amateur band. A Technician class license or higher is required to transmit on this frequency. Reception requires no license. The APRS protocol uses AX.25 packet radio, which is legal under Part 97 (APRS is an unencrypted, meaning-clear protocol - every packet is readable by anyone with an APRS receiver). Meshtastic APRS Gateway: How It Works The Bridge Concept A Meshtastic node that is connected to the internet (via WiFi or Ethernet) can act as an APRS gateway, forwarding position reports from the mesh network to APRS-IS. The gateway receives Meshtastic position packets (sent by any node on the mesh channel), converts them to APRS format, and uploads them to APRS-IS using the gateway operator's callsign. The result: any Meshtastic node on the mesh appears as a dot on aprs.fi, visible to anyone in the world tracking that area. Be aware this makes the location of every bridged node public on the worldwide internet. Do not bridge nodes whose owners have not agreed to have their position published. Gateway Architecture Options There are two main approaches to Meshtastic-APRS bridging: Option 1: APRS-IS Software Gateway (Internet Only) A Meshtastic node with WiFi/Ethernet connects to APRS-IS directly, without any VHF radio. Position packets from the mesh are forwarded to APRS-IS over the internet. This approach: Requires an APRS-IS login (which requires a valid callsign) Does not transmit on 144.390 MHz - no VHF radio needed Does not transmit on RF, so no FCC license is legally required for the IS-only software path itself. However, APRS-IS terms of service require a valid amateur callsign and passcode to upload packets, so in practice you need a licensed callsign to participate. Best practice: use your own callsign and hold at least a Technician license Option 2: RF Gateway (Direct VHF Transmission) A gateway node is paired with a VHF radio (such as a Baofeng or dedicated TNC) that actually transmits on 144.390 MHz. This is full Part 97 operation: Requires a Technician class license or higher Must comply with all Part 97 rules including identification (APRS packets carry the source callsign automatically) Provides true RF presence on the APRS network, so even operators without internet access on that frequency can receive the bridged position Python Bridge Software Community projects provide ready-made bridge software - for example aprstastic ( pip install aprstastic) and meshtastic-bridge (jaredquinn/meshtastic-bridge on GitHub). Check each project's repository for current setup instructions. A typical software-only gateway setup: Warning: the block below is illustrative pseudocode, NOT a runnable script. The callsign W6ABC and the passcode 12345 are placeholders. Replace W6ABC with your own callsign and 12345 with the real passcode generated from your callsign, or it will fail authentication. # Install dependencies pip install meshtastic aprslib # Example bridge concept (simplified) import meshtastic import meshtastic.serial_interface import aprslib # Connect to local Meshtastic node via USB iface = meshtastic.serial_interface.SerialInterface() # Connect to APRS-IS AIS = aprslib.IS("W6ABC", passwd="12345", host="rotate.aprs2.net", port=14580) AIS.connect() # Subscribe to position packets from the mesh def on_receive(packet, interface): if packet.get("decoded", {}).get("portnum") == "POSITION_APP": pos = packet["decoded"]["position"] lat = pos.get("latitude") lon = pos.get("longitude") node_id = packet.get("fromId", "UNKNOWN") # Format and send APRS position packet aprs_packet = f"W6ABC-GW>APRS,TCPIP*:={lat:.2f}N/{lon:.2f}W> Mesh node {node_id}" AIS.sendall(aprs_packet) iface.localNode.setOwner("W6ABC-mesh") pub.subscribe(on_receive, "meshtastic.receive") Note: This is a simplified illustration. Production bridge software handles coordinate formatting (APRS uses DDmm.mm format), SSID assignment, symbol codes, and duplicate suppression. Requirements Summary Gateway Type License Required VHF Radio Required Internet Required APRS-IS software gateway Technician (best practice) No Yes RF gateway (direct 144.390 TX) Technician (required) Yes Optional What the Mesh Gains from APRS Bridging Global visibility: Meshtastic node positions appear on aprs.fi, accessible to anyone without needing the Meshtastic app or a mesh node Integration with existing SAR systems: Search and rescue teams, ARES groups, and emergency managers who already monitor APRS gain visibility into mesh operator positions automatically Long-distance tracking: A vehicle traveling through an area with no local mesh coverage but good APRS digipeater coverage can still be tracked via APRS, and the APRS track history provides continuity with the mesh position data APRS message integration: Some bridge implementations allow APRS messages addressed to the gateway callsign to be forwarded back into the mesh as text messages What APRS Gains from Mesh Bridging Extended coverage: LoRa mesh reaches into areas where APRS digipeaters don't - deep valleys, buildings with poor RF penetration, areas without active ham infrastructure Non-ham participants: Mesh nodes can be operated by unlicensed users whose positions still appear on APRS via the gateway's callsign (the gateway operator is responsible for the transmission) Resilience: In a disaster scenario where VHF repeaters and digipeaters may fail, mesh + APRS-IS provides a fallback path for position reporting if internet connectivity survives Operational Considerations APRS-IS Passcode APRS-IS requires a numeric passcode generated from your callsign to upload packets. The passcode is not secret - it is generated by a well-known algorithm - but it does require a valid amateur callsign. Receive-only connections do not require a passcode. SSID Assignment APRS uses SSIDs (suffix numbers after the callsign, e.g., W6ABC-9) to distinguish different stations operated by the same callsign. Per the official APRS SSID recommendations (aprs.org/aprs11/SSIDs.txt): W6ABC-9: mobile (vehicle) W6ABC-10: internet, I-gates, EchoLink, Winlink, etc. W6ABC-15: generic additional station (digi, mobile, weather, etc.) For a Meshtastic-APRS internet gateway, W6ABC-10 (the recommended SSID for I-gates and internet stations) or a custom SSID is appropriate. Individual mesh nodes forwarded through the gateway might use their node short name as a display name within the APRS comment field. Avoiding APRS Channel Congestion APRS 144.390 MHz is a shared channel used nationwide. A Meshtastic gateway should implement smart beaconing or rate limiting to avoid flooding the APRS channel with high-frequency position updates from many mesh nodes. A beacon interval of 2 - 5 minutes per node is generally appropriate; fixed nodes may beacon less frequently (10 - 30 minutes). Summary APRS and Meshtastic are natural partners. Meshtastic nodes can be bridged to APRS via a gateway node with internet connectivity, making mesh positions visible on aprs.fi and integrating with decades of amateur radio emergency infrastructure. The APRS-IS software gateway approach requires a valid callsign (Technician recommended); direct RF transmission on 144.390 MHz requires a Technician or higher license. The bridge extends coverage in both directions: mesh reaches where APRS doesn't, and APRS provides global visibility that mesh alone cannot offer. Getting Your Ham Radio License for Mesh Networking You do not need a ham radio license to use Meshtastic or MeshCore - both operate on the FCC Part 15 ISM band, which is license-free. However, getting your Technician license opens up significant advantages for mesh network operators. Why a License Helps (But Isn't Required) Higher power: 902-928 MHz is also the amateur 33 cm band, so licensed operators may run LoRa mesh under Part 97 at higher power than Part 15 ISM allows - but only with encryption disabled and full callsign identification (this is Meshtastic's "licensed ham mode"). Most mesh users stay on Part 15 instead so they can keep encryption, in which case a license does not raise your allowed power. Community credibility: Many emergency management agencies, ARES, and CERT programs prefer working with licensed operators Broader skill set: The license exam covers RF propagation, antenna theory, and electrical safety - directly applicable to mesh network work Club liability insurance: ARRL-affiliated radio clubs can purchase liability insurance (commonly around $1M per occurrence) through the ARRL-sponsored club insurance program - useful for club-run community network infrastructure installations. Individual ARRL membership does NOT by itself include liability coverage; the coverage is a policy that affiliated clubs buy. Community: Ham radio clubs are natural partners for mesh network expansion; a license makes you a full member of that community The Technician License The entry-level FCC amateur radio license requires passing a 35-question written exam. No Morse code is required (the code requirement was eliminated in 2007). The exam covers: Basic radio regulations (FCC Part 97) Basic electronics and RF theory Antenna fundamentals Operating practices and safety Study time to pass: 10-20 hours for most people with basic electronics background. Mesh network operators often find they already know much of the RF theory content from their practical experience. Study Resources HamStudy.org - Free to use on the web, with adaptive learning that tracks what you've gotten wrong and focuses practice there. The companion iOS/Android mobile app is a small paid purchase. Highly recommended. The ARRL Ham Radio License Manual - The official Technician study guide; roughly $25-33 in print (check arrl.org for current pricing). Very thorough. KB6NU's "No-Nonsense" Technician Study Guide - Free PDF download; 50 pages, focused and practical. HamWhisperer YouTube channel - Video explanations of exam questions. Finding an Exam Session Technician exams are administered by Volunteer Examiner (VE) teams. Find a session: arrl.org/find-an-amateur-radio-license-exam-session - ARRL exam session database by zip code hamstudy.org/sessions - Searchable list of upcoming in-person and online exam sessions Local amateur radio clubs - Most clubs hold regular exam sessions, often free or low-cost Exam session fees are set by the coordinating VEC (Volunteer Examiner Coordinator), not by each VE team - typically $0-15 (the ARRL VEC charges $15; some coordinators such as GLAARG charge little or nothing). The FCC charges an additional $35 for processing your license application (as of 2022). After You Pass Your license will be issued within 1-10 days of passing. Your callsign will be assigned automatically. Use your callsign: As your Meshtastic node long name (e.g., "KG7XYZ-Mobile") For identification when operating on ham bands For joining ARES or other emergency communications programs (ARES participation requires an amateur license but not ARRL membership) and, if you wish, ARRL membership LoRa Mesh vs Other Off-Grid Technologies LoRa Mesh vs Satellite Messengers Satellite personal communicators (Garmin inReach, SPOT, Zoleo, ACR Bivy Stick) are widely used for off-grid emergency communication. LoRa mesh fills a different niche - understanding the differences helps you choose the right tool for each situation. Summary Comparison Feature LoRa Mesh (Meshtastic/MeshCore) Satellite Messenger (inReach etc.) Coverage Depends on local mesh density Global (where satellite visible) Monthly cost $0 $12-65/month subscription Hardware cost $20-65 $150-450 (as of 2026) Two-way messaging Yes (unlimited within mesh) Yes (limited by plan) Works where no infrastructure Only if other nodes nearby Yes, worldwide Group messaging Yes, to all nodes on channel Yes (to SMS/email contacts) Real-time position sharing Yes (within mesh) Yes (to contacts with MapShare) SOS/Emergency signal No dedicated SOS Yes - dedicated SOS monitored 24/7 by the provider's response center (e.g., Garmin Response, formerly GEOS/IERCC) Battery life Days-months (nRF52840) 5-14 days typical under tracking use; weeks in low-power/expedition modes Message latency Seconds (if nodes in range) Seconds-minutes (satellite) Range limitation Must be within mesh coverage None (global coverage) When LoRa Mesh Wins Group coordination in a known area - If your whole hiking group, bike race, or event team has LoRa nodes, real-time position sharing and messaging within the group is essentially free, with second-scale latency and no per-message cost Community emergency preparedness - A neighborhood or community with LoRa mesh infrastructure can coordinate during a disaster without any per-message cost No per-message billing - LoRa mesh has no per-message fee or plan limit, unlike a satellite plan capped at (say) 40 messages/month. Be aware, though, that the shared LoRa radio channel has very limited capacity: every message is rebroadcast by relay nodes, a busy mesh congests quickly, and heavy traffic causes dropped messages. It suits low-volume tactical texts, not high-volume operational traffic. Cost sensitivity - $0/month vs roughly $150-$780/year depending on plan, for the duration of the device's life When Satellite Wins True wilderness with no other nodes - If you're the only person in 50 miles, there's no mesh. A satellite messenger or a 406 MHz personal locator beacon (PLB) is your realistic option for emergency signaling. Emergency SOS to rescue services - inReach SOS connects to Garmin Response (formerly GEOS/IERCC), a 24/7 coordination center that contacts local rescue agencies. LoRa mesh has no equivalent capability. Communicating with non-mesh contacts - Satellite messengers can send messages to any SMS or email address. LoRa mesh reaches only other mesh nodes. International travel - Satellite works globally; LoRa mesh depends on local community adoption and correct frequency hardware. Using Both Together Many serious outdoor and emergency preparedness operators use both: LoRa mesh for unlimited-message-count local group coordination (low data rate, but no per-message cost), satellite messenger as a backup for genuine out-of-coverage emergencies and for connecting to the outside world when the mesh can't reach internet. The two systems are complementary, not competing. LoRa Mesh vs FRS/GMRS Two-Way Radios FRS (Family Radio Service) and GMRS (General Mobile Radio Service) handheld radios are among the most common off-grid communication tools for recreational groups. LoRa mesh provides capabilities that complement - and in some cases exceed - traditional radios. Summary Comparison Feature LoRa Mesh FRS/GMRS Radio Voice communication No Yes (primary use) Text messaging Yes Limited (GMRS permits short text/data messaging on some models; FRS is voice-centric) GPS position sharing Yes (automatic) No on most models (some GMRS radios such as the Garmin Rino share GPS position over GMRS; APRS is a ham-radio system, not GMRS) Message storage Yes No License required No (Part 15) No for FRS; GMRS requires an FCC license ($35, 10-year term) Range (similar conditions) 0.5-3 km typical handheld-to-handheld in cluttered terrain; 2-30+ km via an elevated relay node 0.5-5 km typical; up to 30+ km with GMRS repeater Message encryption Yes (AES-256, but the default channel uses a publicly known key - set a custom PSK for private traffic) No (radio messages are public) Hardware cost $20-65 per node $25-80 per radio pair Battery life Days-months 8-20 hours typical Key Differentiators Voice vs Text FRS/GMRS excels at voice - instant, intuitive, full-bandwidth human communication. LoRa mesh cannot transmit voice. If you need "press to talk" communication, FRS/GMRS is the right tool. For text-based coordination, position sharing, and structured data, LoRa mesh wins. Position Tracking LoRa mesh automatically shares GPS coordinates from every enabled node, displaying all group members' last-reported positions on a map (positions update periodically - typically every few minutes - not continuously, so treat them as last-known, not live, especially in a hazard area). Most FRS/GMRS radios have no GPS capability. Some GPS-equipped GMRS/FRS radios (e.g., the Garmin Rino series) can share position over GMRS data channels, but this is a proprietary system, not APRS (APRS is amateur radio). Range with Infrastructure Both systems benefit enormously from repeaters/repeaters. A GMRS repeater on a hilltop extends coverage by 20-50 miles. A LoRa mesh repeater on the same hilltop provides similar coverage extension, with the added benefit that any message from any node in range is automatically relayed. Complementary Use The most effective outdoor communication setups combine both: FRS/GMRS for immediate voice coordination ("turn left at the junction"), LoRa mesh for position awareness and text messaging ("I'm at the summit, GPS grid: 47.234N 121.456W, meet you here"). LoRa Mesh vs Ham Radio (VHF/UHF) Licensed amateur radio operators have a wide range of VHF and UHF options for off-grid communications. LoRa mesh fits into this landscape as a complementary technology rather than a replacement. Where LoRa Mesh Fits in the Ham Toolkit Amateur radio offers multiple communication modes - voice (FM, SSB, digital), digital text (Winlink, APRS, JS8Call, Vara FM), and data networks. LoRa mesh adds: License-free operation on ISM band (no ham license needed to use) Automatic multi-hop mesh routing (no repeater coordination needed) Built-in GPS position sharing (comparable to APRS) Strong encryption for private messages Long battery life (especially nRF52840 hardware) Where Ham VHF/UHF Wins Voice communication - FM voice on 2m/70cm is irreplaceable for emergency operations; no text-only mesh can substitute Wide area repeater networks - Many metros have linked 2m repeater systems with 50-100 mile coverage; LoRa mesh coverage depends on local deployment density Winlink/email - Formal message traffic, ICS forms, file attachments over the radio - Winlink capabilities far exceed LoRa mesh message capacity No range limit with satellite - EME, OSCAR satellites, or HF extend ham communications to global range Established infrastructure - Many communities have established ham repeaters; LoRa mesh may have zero local infrastructure Where LoRa Mesh Wins for Hams Auto-updating position map - The Meshtastic app's live map is more intuitive than APRS tracking for non-ham team members No licensing barrier - Non-ham team members (CERT volunteers, event staff, family members) can use LoRa mesh without licensing Encryption - Part 97 prohibits transmissions encoded for the purpose of obscuring their meaning (47 CFR 97.113(a)(4)), which effectively bars encrypted content; LoRa mesh on the Part 15 ISM band has no such restriction Battery life - An nRF52840 LoRa node running for weeks vs a dual-band HT running for hours Cost - $25 Heltec vs $200+ for a quality HT How Licensed Hams Use Both One sensible way to layer these tools is to assign each a distinct role rather than treating them as interchangeable: Voice (VHF/UHF) - Good for tactical coordination, net control, and served-agency interface LoRa mesh - A supplemental data layer: position tracking, short message routing through terrain shadows, sensor telemetry Winlink - Formal message traffic: ICS forms, resource requests, situation reports Your First Week on the Mesh Day 1: Getting Your Node Online Welcome to the mesh. Today's goal is simple: get your node powered on, flashed with current firmware, and visible to other nodes in your area. Follow this checklist from top to bottom. If you hit a snag, the troubleshooting notes at the bottom cover the most common problems. Setup checklist Unbox and identify your hardware. Common beginner boards include the Heltec LoRa 32 (v2 or v3), the LILYGO T-Beam, the RAK Wisblock 4631, and the Seeed WIO Tracker. Identify your board model - you will need it to select the correct firmware variant. Look for a model number printed on the PCB or check the packaging. Attach the antenna. Always connect the antenna before powering the board - transmitting without an antenna can damage the radio. Download the Meshtastic app. Available on the Google Play Store (Android) and the Apple App Store (iOS). Install it before proceeding - you will need it to configure your node via Bluetooth. Connect the node to your computer via USB. Use the cable that came with your board (usually USB-C or Micro-USB). Some boards require a data-capable cable, not just a charging cable - if the device is not recognized, try a different cable. Open the web flasher. In a Chromium-based browser (Chrome or Edge), navigate to flasher.meshtastic.org. Firefox is not supported - it lacks the Web Serial API required by the flasher. Select your board. In the flasher interface, choose your board from the dropdown. If you are unsure of the variant (e.g., Heltec v2 vs v3), check the Meshtastic hardware compatibility page or the back of your PCB. Flash the latest stable firmware. Click Flash and follow the prompts to select your serial port. The process takes 1 - 3 minutes. Do not disconnect the USB cable during flashing. When complete, the board will restart automatically. Connect via Bluetooth. Open the Meshtastic app on your phone. Tap the + icon or New node to scan for nearby devices. Your node should appear - tap it to pair. Pairing PIN: boards without a screen use the fixed default PIN 123456; boards with a screen display a random PIN on the screen for you to enter (typing 123456 there will fail). Change the default PIN after setup for security. Set your name and short name. In the app, go to Settings → User. Enter your long name (e.g., Jane - K5ABC) and a short name (4 characters max, e.g., JANE). The short name appears on the map and in the node list. Set your channel to match your local community. Go to Settings → Channels. The default channel is LongFast - this is what most North American community meshes use. If your local group uses a custom channel key, your administrator will provide it. Do not change the channel key unless instructed - nodes on different keys cannot see each other. Verify region is set to US. Go to Settings → Radio → Region and confirm it is set to US (for North American users). This sets the legal frequency range and transmit power limits. An incorrect region setting can cause your node to transmit on illegal frequencies. Verify your node appears on the map. If your board has GPS (T-Beam, RAK Wisblock, etc.), wait a few minutes for a GPS fix outdoors. Once you have a fix, your node appears in the app map view. To appear on meshmap.net you must also enable OK to MQTT and have an MQTT-connected path (your node or a neighbor) to the public server. Troubleshooting Day 1 issues No Bluetooth connection: In your phone Bluetooth settings, find the node name and tap Forget to clear any stale pairing. Then re-scan in the Meshtastic app and pair fresh. Node not seen by other nodes: Verify the channel key matches your community channel exactly. Also confirm your region setting is correct - a wrong region can put you on a slightly different frequency. Flasher does not see the device: Install the CP210x or CH340 USB-serial driver for your OS. Many LoRa boards use these chips, and Windows sometimes lacks the driver by default. Node starts but shows no display: Some boards have no screen. Check the app - if it connects via Bluetooth, the node is working normally even without a visual indicator. Day 2-7: Exploring the Mesh Now that your node is online, spend the rest of your first week learning what the mesh can do and how to read what it is telling you. Each day below has a focused activity - nothing takes more than 15 - 20 minutes. Day 2: Send your first message Open the Meshtastic app and tap the Messages tab. Select the primary channel (LongFast or whatever your community uses). Type a short greeting and send it. Your message will be received by every node on the same channel within radio range and hop count. Do not be discouraged if no one replies immediately - many nodes run headlessly without a human at the other end. The important thing is confirming your message is transmitted without error. Day 3: Browse the node list Navigate to the Nodes tab. You will see a list of every node your network has heard recently, along with their last-heard time, distance (if both nodes have GPS), RSSI, and SNR. Note which nodes are nearby vs far away. Pay attention to whether you are hearing nodes directly (0 hops) or via relays (1, 2, or 3 hops). This gives you your first picture of the local mesh topology. Day 4: Try a direct message Pick a node from the list that shows as recently heard and close by. Tap it, then tap Direct Message. Send a short message. Direct messages are addressed specifically to that node and encrypted separately from channel traffic. Note whether you receive an ACK (acknowledgement) - a checkmark or delivery indicator in the app. ACKs confirm the destination node received and processed your message, which is a stronger signal than just a broadcast going out. Day 5: Explore the map view Switch to the Map tab. Zoom out progressively to see how many nodes are visible in your area, your city, your region. On a well-developed mesh, you may see dozens of nodes spread across a county or metro area. Tap individual nodes to see their details. The phone app map shows node positions without connection lines. On meshmap.net, selecting a node may show lines indicating LoRa communication (these are not necessarily direct links). Either way, you are looking at a live picture of the community mesh you are now part of. Day 6: Check channel utilization Check channel utilization in your node's device metrics (Nodes → your node → Device Metrics) or on the device's own screen. Healthy meshes run well below 25%. If you see utilization above that, your channel is congested - messages will increasingly collide and fail to deliver. Lightly-used community meshes typically sit at low single-digit percentages, so knowing your baseline now will help you notice if something goes wrong later. Day 7: Try the range test module Enable the Range Test plugin in Settings → Modules → Range Test. Set it to transmit a short ping packet every 60 seconds. Then take your phone and node for a walk or drive around your neighborhood, monitoring the Nodes tab as you go. Watch how RSSI and SNR change as you move farther from infrastructure nodes. This gives you intuitive understanding of LoRa propagation characteristics - how buildings attenuate the signal, how elevation matters, and where the coverage edges are. Joining your local community The mesh is more useful when you know who else is on it. Most regional mesh communities maintain a presence on Discord or Signal groups where members coordinate channel keys, share node placement tips, and help troubleshoot issues. The node map at meshmap.net shows where other nodes are located and can help you spot active areas to find local groups. Reaching out introduces you to the people behind the nodes you have been hearing all week. Understanding What You're Seeing in the App The Meshtastic app surface area can seem dense at first. This page decodes the most important numbers and indicators you will encounter day-to-day, so you can read the mesh like a map instead of a wall of jargon. SNR (Signal-to-Noise Ratio) SNR is displayed in dB (decibels) and measures how much stronger your desired signal is compared to the background noise. In LoRa: Positive SNR (e.g., +5 dB): Strong signal, well above the noise floor. Excellent conditions. Slightly negative SNR (e.g., -5 to -8 dB): Normal for LoRa. The spread-spectrum modulation allows LoRa to decode packets even when the signal is below the noise floor - this is one of LoRa key advantages over conventional radios. Very negative SNR (e.g., -15 dB or worse): The signal is barely decodable. Packets at this level will have high error rates. Increasing distance or obstacles will push it past the decoding threshold entirely. On the default LongFast preset, better than about -10 dB SNR is comfortable for reliable communication; the usable floor depends on the preset's spreading factor (slower presets decode lower SNR). Below about -15 dB on LongFast, expect occasional dropped packets. RSSI (Received Signal Strength Indicator) RSSI measures the absolute power of the received signal in dBm (decibel-milliwatts). Unlike SNR, RSSI does not account for background noise - it is just the raw signal level. -90 dBm or better: Excellent for LoRa. Short to medium range with good antenna alignment. -100 to -110 dBm: Typical for medium range or one hop through a building. -120 dBm: Approximately the noise floor. Packets at this level are at the edge of decodability. -130 dBm or worse: only the slowest presets (high SF, narrow bandwidth) can decode signals this weak. LoRa sensitivity goes down to around -137 dBm under ideal conditions with high spreading factors, which is why it achieves multi-kilometer range with milliwatt transmit power. Via 2 hops - what does this mean? When a message shows via 2 hops, it means the packet traveled through 2 intermediate relay nodes to reach you. A direct connection (0 hops) means your node heard the sender radio transmission directly. Hops increase latency slightly and are subject to the hop limit (default 3), meaning a packet can traverse at most 3 intermediate nodes before being dropped. Battery icon The battery percentage shown for each node in the node list is reported by that node itself and transmitted as telemetry. It represents the battery voltage converted to a percentage by the remote node firmware. Nodes on external/USB power report a battery level above 100 (shown as a plug icon in the apps). A persistent 0% usually means no battery is attached or battery sensing is not working. A 0% reading does not necessarily mean the node is dead - boards without a battery attached (running on USB) often cannot read a battery voltage at all. Last heard timestamp This is when your node most recently received any packet from that node - whether a message, a position report, or a telemetry update. Nodes that broadcast position or telemetry on a schedule will update this timestamp even when no messages are being sent. If last heard is more than an hour ago, the node may be out of range, powered off, or on a slow telemetry interval. Channel utilization percentage This is the fraction of airtime on your channel that has been used by transmissions in a rolling window of roughly the last minute. It includes your own transmissions and every packet your node hears from others. The Meshtastic project recommends keeping this below 25%. Above that, collision probability rises quickly because LoRa radios are half-duplex, and if two nodes transmit at once the packets usually collide and are lost - nodes listen before transmitting (CSMA/CA) to reduce this, but there is no collision detection. High utilization means a growing share of packets is being lost to collisions and deferred sends. Node ID format - what is !ab12cd34? Every Meshtastic node has a unique node ID in the format !xxxxxxxx where the eight hex digits represent the last 4 bytes of the device hardware MAC address. For example, !ab12cd34 means the MAC address ends in AB:12:CD:34. This ID is permanent and tied to the hardware - it does not change when you re-flash firmware or change settings. It is used internally for routing addressed messages and for deduplication in the mesh protocol.