<!--order=6-->


<h1>Introduction to Meshtastic</h1>
<p>Meshtastic is an open-source project that turns LoRa radio modules into a decentralized mesh network for text messages and telemetry data. No cell service required, no WiFi, no internet infrastructure. Nodes communicate directly with each other and relay messages to nodes further away — the mesh extends range by having intermediate nodes repeat packets. It's designed for hiking, emergency preparedness, and remote field communication. For sensor networks in areas without cellular coverage, it's a practical solution.</p>

<h2>How the Mesh Works</h2>
<p>Meshtastic uses a flooding mesh protocol. When a node transmits a packet, any node that receives it rebroadcasts it (up to a configurable hop limit). This extends range far beyond what a single LoRa radio link could cover:</p>
<pre>
Node A (field sensor)
  → transmits packet
  
Node B (relay, 2km away from A)
  → receives A's packet, rebroadcasts it
  
Node C (gateway, 2km from B, 4km from A — out of A's direct range)
  → receives B's relay, delivers to the network / internet

Total range: 4km+ with only 2km radio links at each hop.
Each hop adds latency (~1-2 seconds per hop at typical LoRa speeds).
Default hop limit: 3 hops.
</pre>

<h2>Key Concepts</h2>

<table>
  <thead><tr><th>Term</th><th>Meaning</th></tr></thead>
  <tbody>
    <tr><td>Channel</td><td>A named, encrypted radio channel. All nodes on the same channel use the same frequency/SF/encryption key. Multiple channels can coexist on the same frequency.</td></tr>
    <tr><td>Modem Preset</td><td>Pre-defined combinations of SF, bandwidth, and coding rate. LongFast, LongSlow, MediumSlow, etc. Nodes must use the same preset to communicate.</td></tr>
    <tr><td>Node ID</td><td>Unique 32-bit ID assigned at firmware flash time. Used for routing in the mesh.</td></tr>
    <tr><td>MQTT Bridge</td><td>A node connected to the internet that relays Meshtastic traffic to/from MQTT. Lets you see mesh traffic on a web dashboard.</td></tr>
    <tr><td>Primary Channel</td><td>The default channel; all nodes start with "LongFast" on the default key. Anyone with default settings can see this traffic — change the key for private networks.</td></tr>
    <tr><td>Telemetry</td><td>Periodic packets containing battery level, GPS position, temperature, and other sensor data from each node.</td></tr>
  </tbody>
</table>

<h2>Choose a Node Role Deliberately</h2>
<p>Not every node should relay. A mesh is healthier when always-powered, well-positioned nodes do the relay work and battery nodes send only the data they need to send.</p>
<table>
  <thead><tr><th>Role</th><th>Good fit</th><th>Tradeoff</th></tr></thead>
  <tbody>
    <tr><td>Client</td><td>Handheld or ordinary fixed node</td><td>Participates normally; not designed as dedicated infrastructure</td></tr>
    <tr><td>Client mute</td><td>Receive-focused or low-impact node</td><td>Does not help extend the mesh</td></tr>
    <tr><td>Router / router client</td><td>Powered, elevated relay with a good antenna</td><td>Consumes more power and airtime</td></tr>
    <tr><td>Sensor</td><td>Battery-powered field measurement node</td><td>Usually should not be relied on for relaying</td></tr>
  </tbody>
</table>
<p>Role names and available options can vary slightly by firmware version and hardware target. Check the configuration exported from the exact node before building automation around a setting.</p>

<h2>Modem Presets</h2>

<table>
  <thead><tr><th>Preset</th><th>SF</th><th>BW</th><th>CR</th><th>Range</th><th>Speed</th><th>Use case</th></tr></thead>
  <tbody>
    <tr><td>ShortTurbo</td><td>7</td><td>500kHz</td><td>4/5</td><td>Short</td><td>Very fast</td><td>Close-range, high-throughput (indoor)</td></tr>
    <tr><td>ShortSlow</td><td>8</td><td>250kHz</td><td>4/6</td><td>Short-medium</td><td>Fast</td><td>Short range</td></tr>
    <tr><td>MediumSlow</td><td>9</td><td>250kHz</td><td>4/7</td><td>Medium</td><td>Medium</td><td>Suburban, some obstacles</td></tr>
    <tr><td>LongFast</td><td>11</td><td>250kHz</td><td>4/5</td><td>Long</td><td>Slower</td><td>Default; good balance for most field use</td></tr>
    <tr><td>LongSlow</td><td>12</td><td>125kHz</td><td>4/8</td><td>Maximum</td><td>Slowest</td><td>Maximum range, difficult terrain</td></tr>
    <tr><td>LongModerate</td><td>11</td><td>125kHz</td><td>4/8</td><td>Very long</td><td>Slow</td><td>Long range with better error correction</td></tr>
  </tbody>
</table>

<h2>Supported Hardware</h2>

<table>
  <thead><tr><th>Device</th><th>Radio chip</th><th>Notes</th></tr></thead>
  <tbody>
    <tr><td>Heltec WiFi LoRa 32</td><td>SX1276/SX1262</td><td>Popular; built-in OLED display, WiFi/BT; easy to get started</td></tr>
    <tr><td>LILYGO T-Beam</td><td>SX1276</td><td>Has GPS built-in; battery management; popular for portable nodes</td></tr>
    <tr><td>LILYGO T-Echo</td><td>SX1262</td><td>E-ink display; GPS; extremely low power — best for field deployment</td></tr>
    <tr><td>RAK WisBlock</td><td>SX1262</td><td>Modular; very low power; good for custom sensor integration</td></tr>
    <tr><td>Raspberry Pi Pico / Pico W + SX1262</td><td>SX1262</td><td>RP2040-based; the W adds WiFi/Bluetooth, but USB serial is available on both</td></tr>
    <tr><td>Raspberry Pi Pico 2 / Pico 2 W + SX1262</td><td>SX1262</td><td>RP2350-based; use only when the installed Meshtastic release explicitly supports the board target</td></tr>
    <tr><td>nRF52840 boards</td><td>SX1262</td><td>Bluetooth native; pairs with phone easily</td></tr>
  </tbody>
</table>

<h2>Channels and Encryption</h2>
<pre>
Meshtastic uses AES-128 encryption on channels.
The "channel key" determines who can read your traffic.

Default channel:
  Name: LongFast (or your custom name)
  Key: AQ== (base64 for 0x01 — the public default)
  → Anyone with default Meshtastic settings can see this traffic

Private network setup:
  Generate a random key in the app or CLI:
  $ meshtastic --set-crypt-key random
  → Share this key with your nodes out-of-band (manually configure each node)

Multiple channels (up to 8):
  Primary channel: used for position and admin
  Secondary channels: for specific message groups or sensors
  Each channel can have different keys and settings
</pre>
<p>For a private field network, record the chosen region, modem preset, channel name, and key in a protected setup note. All of these must match before nodes can exchange useful traffic. A random key is only useful if it is backed up; losing it can mean rebuilding every node configuration.</p>

<h2>Connecting to a Node</h2>
<pre>
Three ways to interact with a Meshtastic node:

1. Phone app (iOS / Android)
   - Connect via Bluetooth
   - Send messages, see node map, view telemetry
   - Configure node settings

2. Python CLI (meshtastic package)
   $ pip install meshtastic
   $ meshtastic --info           # show connected node info
   $ meshtastic --sendtext "hello"  # send a message
   $ meshtastic --nodes          # list known nodes in the mesh
   $ meshtastic --export-config  # dump current config as YAML

3. Web UI (via WiFi on supported devices)
   - Heltec WiFi LoRa 32 and ESP32-based devices can run a web server
   - Access at http://192.168.x.x after connecting to the device's WiFi
</pre>

<h2>Telemetry and Sensors</h2>
<p>Meshtastic nodes automatically transmit telemetry packets on a configurable interval. Built-in telemetry includes battery voltage and node uptime. External sensors (I2C/SPI) can be added and their data included in telemetry packets — useful for field sensor networks:</p>
<pre>
Built-in telemetry:
  - Battery level (%)
  - Voltage
  - Channel utilization
  - GPS position (if GPS module present)

External sensor support (I2C):
  - BME280 / BME680: temperature, humidity, pressure
  - INA219: current/power monitoring
  - MLX90614: IR temperature
  - DS18B20: waterproof temperature probe

Configuration:
  $ meshtastic --set telemetry.device_update_interval 300  # seconds
</pre>
<p>Telemetry has a cost. Each periodic report uses airtime and battery capacity, and a flood mesh may relay it more than once. Start with a slow interval, verify that the information is useful, then shorten it only where the project needs fresher data.</p>

<h2>A Small Mesh Plan</h2>
<pre>
1. Build two nodes on the same private channel.
2. Prove direct communication on a bench and outdoors.
3. Add one elevated, powered relay only if the direct link needs it.
4. Add telemetry slowly and watch channel utilization.
5. Export and back up the working configuration before changing anything.
</pre>
<p>This approach makes faults easier to isolate. If a ten-node mesh does not work, it is hard to tell whether the problem is the channel, a single node, the terrain, or too much traffic.</p>

<h2>References</h2>
<ul>
  <li><a href="https://meshtastic.org/docs/" target="_blank" rel="noopener">Meshtastic Documentation ↗</a></li>
  <li><a href="https://meshtastic.org/docs/overview/mesh-algo/" target="_blank" rel="noopener">Meshtastic Mesh Algorithm ↗</a></li>
  <li><a href="https://github.com/meshtastic/firmware" target="_blank" rel="noopener">Meshtastic Firmware (GitHub) ↗</a></li>
</ul>
