Freq51 - The Intermountain Mesh

Meshtastic® lets you use inexpensive LoRa radios as a long-range, off-grid communication platform where regular infrastructure is unreliable or unavailable. It’s community-driven and open source. Radios automatically form a mesh, forwarding packets to neighbors (up to 7 hops from origin). Phones are optional. The Freq51 community is building an open community mesh that anyone here can join. This network is intended as a tool for emergency/disaster response and off-grid coordination and hobbyist projects. No license is required to use Meshtastic (unless you intentionally enable Ham Mode). Meshtastic is under active development and not a life-critical service.

Joining

1. Get supported hardware from the Meshtastic list.
2. Join our Discord for local help and announcements.
3. Read the FAQ and Configuration pages below.
4. See Equipment for example builds / coverage once published, and Infrastructure for deployed nodes.

Links

• Supported Hardware: https://meshtastic.org/docs/hardware/devices/
• freq51 Discord: Official Meshtastic Discord –> Connect Forum –> US-Utah

MQTT and Maps

MQTT (Message Queue Telemetry Transport) is a lightweight pub/sub protocol. Meshtastic can uplink device info and messages to an MQTT server. This enables:

• Computer ↔ node integrations without using LoRa.
• Uplink/Downlink bridging so two distant nodes can exchange messages via internet when out of LoRa range. We ideally would like to avoid MQTT downlink at all costs. It floods the network.
• Maps & analytics (position/telemetry), delivery reports, and tooling. If you want your node on the map.

Our stance: We prioritize a healthy RF mesh first. MQTT is useful for mapping, analytics, but please avoid flooding RF with downlinked internet traffic.

Freq51 Map

• Public Map: (Placeholder)

Good practices

• If your node is directly connected to an MQTT server, do not enable downlink on public RF channels (e.g., MediumFast). That can spam RF. Nodes not on MQTT can use “Ignore MQTT,” and that setting is requested to be on by default when operating on our mesh unless you need MQTT.

Member Projects

Some cool freq51-adjacent projects we love to showcase (add yours!):

• TBD

Submit a PR to add your project here.

Other Local Groups

Meshtastic keeps a running list of local groups worldwide. If you’re traveling or collaborating across regions, check there and cross-link back to freq51 once we’re listed.

• Meshtastic Local Groups Directory: https://meshtastic.org/docs/community/local-groups/

Freq51 Onboarding Guide - Welcome to the Intermountain Mesh!

🎯 Quick Start - Get Connected in 15 Minutes

Welcome to Freq51! This guide will get you up and running on our Meshtastic network.

What You’ll Need

• Hardware: Any Meshtastic-compatible device
• App: Meshtastic mobile app (iOS/Android) or web client
• Time: 15-30 minutes for initial setup
• Location: Salt Lake City, Utah region for best coverage

📱 Step-by-Step Setup

1. Hardware Setup (5 minutes)

1. Get your device: We recommend starting with a RAK device, Seeed Tracker, Station G2, XIAO, or Raspberry Pi-based device from the supported hardware list
2. Power on: Some devices will create a WiFi hotspot on first boot

2. Connect via Meshtastic App (10 minutes)

1. Download: Get the official Meshtastic app from your app store
   • IOS Link
   • Android Link
2. Connect:
   • Bluetooth: Most devices connect via Bluetooth (recommended method)
   • WiFi: Some devices also support WiFi hotspot connection for web interface
3. Initial setup: Follow the in-app setup wizard

3. Configure for Freq51 (5 minutes)

Apply these essential settings for optimal mesh network participation: Keep in mind that the IOS/Android app settings layout may differ

Quick Setup Guide

Use this checklist to get your node configured and on the network as quickly as possible.

General Settings

• Region: This is normally set the first time you connect to the node.
  If it hasn’t been set yet, go to the LoRa Section and set it to US.

Node Configuration (Quick Setup)

1. User Section

   • Long Name: Choose something recognizable (avoid personal info).
   • Short Name: Set a short, unique identifier (usually 3–4 letters).

2. Device Section

   • Role: Set to CLIENT.

3. LoRa Section

   • Frequency Slot: Set to 51.
   • Preset: Set to MEDIUM_FAST.
   • Hop Count: Set it to 7 (recommended).

4. Channel Section

   • Set your Primary Channel (Channel ID: 0, typically the name is blank, unless you have changed it in the past, then it would be “LongFast”).
   • Channel Name: Freq51
   • Key: 1A==

5. Location Section

   • GPS: Enable if you’re comfortable sharing your location.

🏷️ Node Roles - Choose the Right One

Understanding roles is crucial for network health:

👤 CLIENT (Recommended for most users)

• Best for: Handheld devices, mobile setups, most users
• Behavior: General-purpose node that rebroadcasts packets only if no other node has already done so
• Visibility: Visible in nodes list/topology
• Use when: This is the default/normal choice

🔇 CLIENT_MUTE (Extra/local nodes)

• Best for: Additional handheld devices near better-placed nodes, Car-mounted devices, temporary deployments
• Behavior: Like CLIENT but does NOT forward other devices’ packets at all (no repeating/routing)
• Visibility: Visible in nodes list
• Use when: You have extra handheld/indoor nodes near a better-placed node and want to avoid adding needless rebroadcasts. This is particularly useful with indoor nodes.

🔄 ROUTER (Infrastructure - Advanced users only!)

• Best for: Strategically placed infrastructure (mountain/very tall tower with big line-of-sight)
• Behavior: Always rebroadcasts each packet once and is prioritized for routing (“cuts in line” vs other roles)
• Visibility: Visible in nodes list/topology
• Use when: Device is strategically placed to extend coverage for many others
• ⚠️ Important: Misplacing routers increases collisions and wastes hops. Contact the [Discord community] before deploying
• 📖 Detailed Guide: See our comprehensive Router Deployment Guide before considering setting up a router.

🔄 ROUTER_LATE (Infrastructure - Advanced users only!)

• Best for: Adding reliability/coverage for local clusters without stealing priority
• Behavior: Always rebroadcasts once, but only after all other modes have had their chance (not prioritized)
• Visibility: Visible in nodes list/topology
• Use when: You need a “safety net” for a small area or dead spots without stealing routing priority from better infrastructure

🚫 REPEATER (Not Used - Advanced users only!)

• Best for: Pure extenders in strategic spots
• Behavior: Always rebroadcasts each packet once with minimal overhead, turns off its own broadcast chatter
• Visibility: NOT visible in nodes list/topology
• Special: Only role that can use ALL_SKIP_DECODING rebroadcast mode
• Use when: You want a pure extender in a strategic spot and don’t need the node itself to appear in topology
• ⚠️ Important: This mode can cause serious issues with the mesh and it’s particularly hard to troubleshoot. Contact the [Discord community] before deploying repeaters
• 📖 Detailed Guide: See our comprehensive Router Deployment Guide for complete information

For more info on how roles work and what is suggested based on the node use case please watch this video by The Comms Channel

🗺️ Local Resources

Coverage Areas

• Primary: Salt Lake Valley
• Growing: Davis County, Weber County, Utah County
• Planned: See Infrastructure for planned node locations

Getting Help

• Discord: Official Meshtastic Discord → Connect Forum → US-Utah

Advanced Configuration

• Detailed settings: See Configuration guide
• Hardware recommendations: Check Equipment page
• Router deployment: See Router Deployment Guide for advanced users
• Firmware Updates: See Firmware Update Guide page
• Common issues: Review FAQ

❓ Quick Troubleshooting

Can’t see other nodes?

• Check region settings (must be “US”)
• Verify antenna connections
• Try different locations (higher elevation helps)
• Ensure role is CLIENT
• Location broadcasts are intentionally infrequent to reduce RF noise; it can take several hours for nodes to appear on your map

Messages not getting through?

• Check router placements and see if you’re near the mesh
• Network may be busy - try again later
• Check hop limit (default 3 is usually good, but 7 may give better results.)
• Verify channel settings match community standards

📞 Support and Community

Need help? The Freq51 community is here to support you:

• Meshtastic Discord: Most active support channel
• Utah Mesh Discord: A backup community in the event the main meshtastic discord doesn’t work out

Welcome to the mesh! 📡✨

This guide focuses on getting you connected quickly and safely. For detailed technical information, see our other documentation pages. Questions? Ask in Discord - we’re here to help!

Migrating Your Node from LONG_FAST (“LongFast”) to MEDIUM_FAST (“MediumFast”)

This guide will walk you through updating your Meshtastic node’s modem preset from LONG_FAST (often called “LongFast”) to MEDIUM_FAST (“MediumFast”) on both iOS and Android. These steps ensure a smooth transition and prevent channel name conflicts.

Why Migrate?

• Network Update: The community is moving to MEDIUM_FAST for improved balance between range and speed.
• Compatibility: Ensures your node stays in sync with the rest of the mesh.

iOS Instructions

1. Change the Primary Channel Name

• Go to Settings.
• Then select Channels.
• Tap your Primary Channel (Channel ID: 0, typically the name is blank, unless you have changed it in the past, then it would be “LongFast”).
• Change the Channel Name to “Freq51” (without quotes) then adjust the key size to 1byte, and lastly set the key to “1A==” (without quotes).
• Save and confirm the change.

Please note that the channel name has to match exactly, it will not work if it is incorrect.

This step allows us to set a private channel for all the other meshtastic features to function correctly.

2. Change the Modem Preset

• Go to Settings.
• Find LoRa.
• Find presets and select Medium Fast (sometimes shown as MEDIUM_FAST or MediumFast).
• Save your changes.

3. Reset Your Node Database (nodedb)

• In Settings, go to Device.
• Locate Reset NodeDB, and click it.
• Your node will restart and rebuild its database for the new modem preset.

Android Instructions

1. Change the Primary Channel Name

• Go to Settings.
• Then go to Channels.
• Tap your Primary Channel (Channel ID: 0, typically the name is blank, unless you have changed it in the past, then it would be “LongFast”).
• Change the Channel Name to Freq51 then set the key to “1A==” without quotes.
• Save and confirm the change.

Please note that the channel name has to match exactly, it will not work if it is incorrect.

2. Change the Modem Preset

• Go to Settings.
• Go to LoRa.
• Find presets and select Medium Fast (may be listed as MEDIUM_FAST or MediumFast).
• Save your changes.

3. Reset Your Node Database (nodedb)

• In Settings, under Administration find and select NodeDB Reset.
• Your node will reboot and rebuild its network database.

CLI instructions

• This configuration can be made with the Meshtastic Python CLI. Using the following commands:

meshtastic --set lora.modemPreset MEDIUM_FAST --set lora.channelNum 51
meshtastic --ch-set name "Freq51" --ch-set psk "base64:1A==" --ch-index 0
meshtastic --reset-nodedb

Troubleshooting

• If your node does not appear on the mesh after migration, double-check that the preset is MediumFast and that the primary channel name is Freq51 with the key size as 1byte and Key set to “1A==” No quotes.
• Reboot your node if changes do not appear to take effect.

Need Help?

If you get stuck, please reach out in the community Discord.

FAQ

New User Expectations

Meshtastic is rapidly evolving, not a fully polished product. Expect quirks. For best results with a fresh device: put it somewhere with decent LOS (a window works) and let it run overnight. It takes time for nodes to discover each other. Users who share their position (GPS or fixed coordinates) will show up on public maps. Its a good way to test a solar setup as well.

We currently recommend a local map (TBD: map URL) for nodes that opt in to share their position. You won’t see every node—only those that choose to appear or are heard by an MQTT-uplinking node nearby.

FAQ’s

• What firmware version should I flash?
  Ask in freq51 Discord; “latest” isn’t always best for local stability. We track known issues and local norms. We currently prefer 2.6.11 as of 8/16/2025 Please see our firmware update guide for help on that.

• Where’s the QR/URL to join the local mesh?
  We don’t recommend QR codes/URLs for public channels. They silently change additional LoRa settings (e.g., TX power, hop count). Enter channel names/keys manually and verify settings after import.

• Which role should I use: ROUTER or CLIENT?
  Usually CLIENT or CLIENT_MUTE. Router roles (ROUTER, ROUTER_LATE, etc.) rebroadcast everything they hear and can harm network health if overused or poorly placed. Use router roles only when coordinated with the group. The Comms Channel has created a great video on that.

  Device Roles

  Meshtastic devices can take on different roles depending on how you want them to behave on the mesh. Picking the right role is important for network health. Each role has a default rebroadcast mode (how it repeats messages) which you’ll see in the apps.

  • Client

    • Default role for most users.
    • Sends and receives messages normally.
    • Shows up on maps if you share GPS or fixed position.
    • Rebroadcast mode: All (repeats your own + direct messages when needed).
    • Best for portable or handheld nodes or roof nodes for relaying indoor nodes.

  • Client Mute

    • Same as Client, but does not rebroadcast messages.
    • Saves battery and avoids adding unnecessary traffic.
    • Still sends and receives messages for its owner.
    • Best for indoor nodes or mobile nodes
    • Rebroadcast mode: Local.

  • Client Hidden

    • Behaves like Client, but your node does not appear in other users’ node lists.
    • Useful for privacy or stealth use-cases.
    • You can still send and receive messages normally.
    • Best for extremely low traffic stealthy nodes
    • Rebroadcast mode: Known Only (like Client).

  • Router

    • A fixed, always-on node that rebroadcasts everything it hears.
    • Extends network reach and coverage for others.
    • Should only be used when:
      • The node is in a good location (elevation, clear and wide Line of Sight).
      • It has reliable power (mains power or solar-battery (large pack) ).
      • It has a stable, high gain, preferably lightning arrested antenna setup.
      • It has a filter on the RF chain
    • Rebroadcast mode: CORE_PORT_NUMS_ONLY. (we actually desire ALL so please switch. See configuration details)
    • Overuse of routers can cause congestion.
    • See Router Deployment Guide before deploying.

  • Router Late

    • A router that waits briefly before retransmitting messages.
    • Reduces “echo storms” when many routers are present.
    • Must posses a filter on the RF chain
    • Best used in dense networks with multiple routers to avoid collisions and connecting to geographically seperate areas
    • Should be coordinated with other router owners.
    • Rebroadcast mode: All (delayed).
    • See Router Deployment Guide for placement guidance.

  Choosing the Right Role

  • Most people - Outdoor: Client
  • Most people - Indoor: Client Mute, or Client Hidden
  • Fixed/always-on with power and good placement between 5500 ft and 8000 ft: Router Late
  • Fixed/always-on with power and good placement above 8000 ft: Router

  See Router Deployment Guide for deployment guidance.

  ⚠️ Tip: Too many routers (or routers in bad spots) can hurt the mesh. When in doubt, stick to Client.

Why Improperly Applying Router and Repeater Roles Is Harmful

If a poor location is chosen for Routers and Repeaters, it can cause some of these issues:

• Increased rate of packet collisions
  Because Routers, Router Lates and Repeaters always rebroadcast, when too many devices use these roles and are direct neighbors, packets will often be rebroadcast at the same time. This creates higher noise levels and packet error rates, frequently resulting in sporadic delivery failures.

• Decreased overall range
  An improperly located router may prematurely consume (“hop gobble”) packets routing through it. This uses up a hop before the packet can reach strategically placed nodes. For example, if many Routers are deployed in a valley, they can consume all available hops before the packet can reach a node placed on a peak above the valley, greatly limiting range. This is exactly what occurs on frequency slot 20 which is the default preset. We have moved for this reason. Please be polite

• Asymmetrical links
  Similar to decreased range, poor router placement can result in asymmetrical communication—where one part of the mesh can send messages to another group, but the reverse path fails. This happens because hops are consumed too early, blocking return messages. This is the classic hidden node problem. Users often react by increasing the hop limit to compensate, but this only worsens congestion by consuming more airtime. Your hop limit should be set to the lowest reasonable number of hops to reach your destination +1 for reliable links. If you do wish to see the entire mesh you can increase to 7 but be aware of what you are doing.

• What’s LongFast vs LONG_FAST?
  LongFast is the default channel name when using the LONG_FAST modem preset. LONG_FAST is a preset (like MEDIUM_FAST, SHORT_FAST, etc.) that bundles LoRa parameters.

• How do I know I’m connected?
  Seeing other nodes in your node list is a good sign. Try a message to MediumFast or a direct message to a known node.

📖 Freq51 Meshtastic Glossary

Welcome to the Freq51 Meshtastic Glossary! This page gathers key terms you’ll see when working with Meshtastic devices, channels, and Freq51 community practices — organized A to Z.

Jump to a section: A · B · C · D · E · F · G · H · I · J · K · L · M · N · O · P · Q · R · S · T · U · V · W · X · Y · Z

A

• App / Application / Client Application — An application that connects to a Meshtastic node to send and receive messages via the mesh. See also: Client.
• Airtime (Time on Air) — The length of time a LoRa transmission occupies the channel. Longer-range settings typically increase airtime and reduce throughput.
• APRS (Automatic Packet Reporting System) — A ham radio data system sometimes bridged to/from Meshtastic by communities. Check local regulations and Freq51 guidance before use. See also: Gateway, MQTT Bridge.

B

• Band (ISM Band) — The regional frequency range for LoRa (e.g., 915 MHz, 868 MHz). Devices must operate on the correct regional band.
• Bandwidth (LoRa) — LoRa radio parameter affecting data rate and range. Included in Modem Presets.
• BLE (Bluetooth Low Energy) — Short‑range wireless link commonly used by Meshtastic apps to connect to nodes.
• Bridge — See Gateway and MQTT Bridge.
• Broadcast — A message sent to all participants on the current channel.

C

• Channel — A logical grouping defining who can communicate; includes a name, encryption, and settings.
• Channel Key — See PSK (Pre‑Shared Key).
• Client — A node used primarily for user messaging; behavior depends on the assigned Role.
• CLI (Command Line Interface) — Text-based interface (usually over USB/Serial) to configure or interact with a node.
• Coding Rate (CR) — LoRa forward‑error‑correction setting that trades speed for robustness. Included in Modem Presets.

D

• Deduplication — Logic to avoid processing or rebroadcasting the same packet multiple times. See also: Rebroadcast Logic.
• Device — A Meshtastic‑compatible radio running the Meshtastic firmware.
• Device Role — See Role.
• DFU (Device Firmware Update) — Special mode used for firmware updates.
• Direct Message (DM) — Encrypted, point‑to‑point communication using public key cryptography. See also: PKC.

E

• Encryption — Channel messages secured with a Pre‑Shared Key (PSK). Direct messages can use public key cryptography.
• ESP32 — Espressif MCU used in many devices; higher power usage than NRF52; can support Wi‑Fi.
• EUI / EIRP — Regulatory power concepts sometimes referenced for compliance. Check regional rules and Freq51 onboarding.

F

• FAQ (Freq51) — Answers to common community questions and practices.
• FEC (Forward Error Correction) — See Coding Rate.
• Firmware — Low-level software that runs on a node’s microcontroller.
• Flash / Flashing — Installing or updating firmware on a device.
• Freq51 — Community coordination around stable deployments, recommended settings, and onboarding for a healthy mesh.

G

• Gateway — A node that bridges the mesh to external systems (often via MQTT). Requires careful configuration to avoid loops and flooding.
• GPIO (General Purpose Input/Output) — Digital I/O pins for sensors, buttons, etc.
• GPS — Global Positioning System; nodes can report position as telemetry.

H

• Hop — A relay through another node.
• Hop Limit — The maximum number of hops a packet may traverse; helps control congestion and airtime.
• Hidden Client — See Role (CLIENT_HIDDEN).

I

• ID (Node ID / Long Name / Short Name) — Identifiers for a node in the mesh and UI.
• Interval (Telemetry/Position) — Frequency at which telemetry or position is sent; balance visibility with airtime usage.

J

• — (No common entry)

K

• Key (Channel Key) — See PSK (Pre‑Shared Key).

L

• LoRa — Low‑power, long‑range radio used by Meshtastic.
• LoS (Line of Sight) — A clear, unobstructed RF path through air; best link quality typically requires LoS.
• Lost and Found — See Role (LOST_AND_FOUND).

M

• Mesh Network — Decentralized network where nodes can forward messages for others.
• Modem Preset — Bundled LoRa parameters (Bandwidth, Spreading Factor, Coding Rate). All nodes must match to communicate.

Modem Presets (summary)

• SHORT_TURBO — Highest bandwidth, shortest range.
• SHORT_FAST — High speed; short range.
• SHORT_SLOW — Moderate range; fairly high speed.
• MEDIUM_FAST — Balanced speed/range.
• MEDIUM_SLOW — More range; less speed.
• LONG_FAST — Default; long range, reasonable speed.
• LONG_MODERATE — More range/airtime; slower than LONG_FAST.
• LONG_SLOW — Very high link budget; very slow data rate.
• VERY_LONG_SLOW — Slowest; very high range; high airtime.

Note: As a general community default, use LONG_FAST unless coordinated otherwise.

• MQTT / MQTT Bridge — Protocol and bridge commonly used to link the mesh to servers/services. Configure topics, filters, and rebroadcast logic carefully to prevent loops.

N

• Node — A device on the mesh that can send, receive, and relay messages.
• NRF52 — Nordic MCU used in many low‑power devices.

O

• OTA (Over‑the‑Air) — Wireless firmware update capability (device/platform dependent).

P

• Packet — A unit of data sent over the mesh.
• PKC (Public Key Cryptography) — Used for direct, end‑to‑end messages with keypairs.
• Preset — See Modem Preset.
• Protobuf — Google’s serialization format used by Meshtastic protocols.
• PSK (Pre‑Shared Key) — Channel encryption key. All nodes on a channel must share the PSK to exchange messages.

Q

• Quiet Client (Muted Client) — Client variant limiting rebroadcast/chat behavior to conserve airtime. See Role (CLIENT_MUTE).

R

• Rebroadcast — Relaying a received packet. Behavior is controlled to minimize duplicates and loops. See: Rebroadcast Logic.
• Rebroadcast Logic — Rules/filters that determine whether and how messages are relayed (including deduplication). Critical when bridging (e.g., MQTT).
• Region — Regulatory domain determining allowed frequency band and power. See: Band.
• Repeater — Coverage‑extending node that is not shown in the standard node list.
• Role (Device Role) — The behavior mode of a node on the mesh. See the overview below.

Device Roles (overview)

• CLIENT — Standard user node for sending/receiving messages.
• CLIENT_MUTE — Client with reduced chat/rebroadcast behavior to conserve airtime.
• CLIENT_HIDDEN — Client that participates without appearing prominently in lists/UIs.
• TRACKER — Focused on position reporting (GPS), minimal chat.
• LOST_AND_FOUND — Special mode for recovery/identification scenarios.
• SENSOR — Publishes sensor/system data as telemetry.
• TAK — Integrates with Team Awareness Kit features.
• TAK_TRACKER — TAK‑focused tracking (position reporting).
• REPEATER — Extends coverage; not shown in standard node lists.
• ROUTER — Extends coverage; shown in node lists.
• ROUTER_LATE — Router variant tuned for later/delayed relays.
• Router — Coverage‑extending node visible in node lists.
• ROUTER_LATE — Role variant tuned for delayed/late relaying. See Role.
• rp2040 — Raspberry Pi microcontroller used in some boards.
• RSSI (Received Signal Strength Indicator) — Measure of received signal power.

S

• RX (Receive) — Receiving data on the radio.
• Sensor — A node role or device function publishing environmental/system data.
• Serial — USB/UART link used by CLI and for flashing firmware.
• SNR (Signal‑to‑Noise Ratio) — Measure of signal clarity vs. noise.
• Spread(ing) Factor (SF) — LoRa parameter controlling chirp length; higher SF increases range and airtime, reduces data rate.
• SWR (Standing Wave Ratio) — RF measure of antenna/feedline match quality.

T

• TAK / TAK Tracker — Roles supporting Team Awareness Kit integrations, typically focused on position reporting and limited chat.
• Telemetry — Periodic transmission of sensor, GPS, and/or system metrics from a node.
• TX (Transmit) — Sending data on the radio.

U

• UART — Hardware serial interface used for logging, CLI, and debugging.
• Uplink / Downlink — Directional terms sometimes used around gateways/bridges: uplink (mesh → server), downlink (server → mesh), especially with MQTT.

V

• VERY_LONG_SLOW — See Modem Preset.
• Voltage (Battery Voltage) — Telemetry metric many nodes advertise to indicate power status.

W

• Web UI — Some devices/platforms expose a local web-based configuration/status page (varies by hardware/firmware build).
• Wi‑Fi — On supported ESP32 devices, can be used for features like MQTT bridging or a web UI.

X

Y

Z

Meshtastic Configuration

These sections help you choose settings that work well for you and for the mesh. See the FAQ for troubleshooting. Locally we’re still building out on the FS51 with the default LongFast North America slot/preset (see below), but freq51 may coordinate short-term trials (e.g., ShortFast) as needed.

Freq51 Medium Fast (As of 10/05/2025):

• Medium_Fast preset, slot 51 → 914.625 MHz

Exact slot counts and defaults depend on preset; see Meshtastic docs for details.

Default Configurations (We are not using this)

By default, fresh Meshtastic radios on NA region can talk on LongFast (channel name) using the LONG_FAST preset and default slot. A typical setup is a radio paired to your phone via Bluetooth. No internet is required. When out of direct range, your messages hop across other nodes.

Understanding “hops”

A hop is a relay through another node. Use the lowest hop limit that reliably reaches your contacts. The default 3 hops can cover many miles in dense meshes, but higher hops increase airtime and congestion. If you wish to see the entire mesh, set your radio to 7 hops. We can handle the extra congestion for now.

Understanding Rebroadcast Logic and Role Priorities

Understanding how rebroadcasting works in Meshtastic helps avoid network congestion and explains why Router roles should be used carefully.

For more info on how roles work and what is suggested based on the node use case please watch this video by The Comms Channel

Contention Windows

• Clients and Routers/Repeaters do not share the same contention window.
• Clients and Router_Lates (RLs) do share a window — but RLs will defer to the end of the contention window if they hear another node.

Simplified Priority Order

1. Router & Repeater
   • Rebroadcast first.
2. Clients (Client, Client Hidden, Client Mute, Router Client)
   • Rebroadcast after Routers/Repeaters, but cancel if they overhear another rebroadcast.
3. Router Late (RL)
   • Rebroadcasts last, only if no one else has already done so.

Detailed Rebroadcast Logic

When a packet is received:

1. Check hop limit
   • If hop_limit = 0, do not rebroadcast.
2. If I am a Router or Repeater:
   • Wait a small random delay (shorter if SNR is poor).
   • Wait until the channel is clear.
   • Transmit.
3. If I am not a Router or Repeater:
   • Wait until after the maximum possible Router/Repeater delay.
   • Add a slightly longer random delay (scaled by SNR).
   • If another node rebroadcasted and I am not Router_Late → cancel rebroadcast.
   • Otherwise transmit.
4. If I am Router Late:
   • If another rebroadcast was heard:
     • Wait until after all other possible delays, then add another random delay (scaled by SNR).
     • Transmit only if the channel is still clear.

Why This Matters

• Routers and Repeaters go first → they form the backbone of coverage.
• Clients go second → they fill in only if no Router/Repeater is nearby.
• Router Lates go last → a safety net to ensure delivery without creating echo storms.

Implementation Notes

Most of this logic is implemented in:

• RadioLibInterface.cpp
• RadioInterface.cpp
• FloodingRouter.cpp

A flowchart would be an excellent addition here to visualize priority and timing.

Recommended Configurations

If you can’t find a setting in the app, check Meshtastic docs (each page has iOS/Android/CLI/Web tabs).

Router Nodes

Before configuring a router, review the Router Deployment Guide.

Use when node is a router

Paths to check (App tabs may vary):
Radio > User, Radio > Device, Radio > Position, Radio > LoRa, Radio > Bluetooth, Modules > Neighbor Info, Modules > MQTT

• Short name: Call sign; 4 Characters; Routers use a specific naming scheme, i.e FPR –> Francis Peak Router
• Long name: Routers use a specific naming scheme, i.e FPR –> Francis Peak Router
• Licensed amateur radio: FALSE (unless you’re operating in Ham Mode knowingly; encryption is disallowed on ham). HAM band operation is on Frequency Slot 45. Please do not use it on Frequency Slot 51.
• Role: Usually Router but can be Router Late depending on placement. Router roles only by coordination.
• Rebroadcast mode: ALL (We want routers to pass all traffic not be a filter)
• Node Info Broadcast Interval: 86400 s
• GPS Mode: ENABLED if present, else use Fixed Position.
• Fixed Position: Often TRUE for stationary nodes (set via CLI or phone). Unless GPS is desired for timekeeping. (really useful)
• Position Broadcast Interval: 86400 s
• Region: US
• Preset: Medium Fast
• Hop Limit: 7
• OK to MQTT: TRUE (helps appear on map via others’ uplinks)
• Telemetry: 1800 s per timing interval of attached peripheral
• Neighborinfo: ON, Transmit over Lora ON, 14400 Interval
• Required Channels: Freq51

Note: Neighbor Info is no longer shared across the mesh on an unencrypted primary channel, thus we require the Freq51 MQTT and Neighborinfo Channel.

Router Late Nodes

Before configuring a Router Late, review the Router Deployment Guide.

Paths to check (App tabs may vary):
Radio > User, Radio > Device, Radio > Position, Radio > LoRa, Radio > Bluetooth, Modules > Neighbor Info, Modules > MQTT

• Short name: Call sign; 4 Characters; Routers use a specific naming scheme, i.e FPR –> Francis Peak Router
• Long name: Routers use a specific naming scheme, i.e FPR –> Francis Peak Router
• Licensed amateur radio: FALSE (unless you’re operating in Ham Mode knowingly; encryption is disallowed on ham). HAM band operation is on Frequency Slot 45. Please do not use it on Frequency Slot 51.
• Role: Router Late
• Rebroadcast mode: ALL (We want routers to pass all traffic not be a filter)
• Node Info Broadcast Interval: 43200 s
• GPS Mode: ENABLED if present, else use Fixed Position.
• Fixed Position: Often TRUE for stationary nodes (set via CLI or phone). Unless GPS is desired for timekeeping. (really useful)
• Position Broadcast Interval: 43200 s
• Region: US
• Preset: Medium Fast
• Hop Limit: 7
• OK to MQTT: TRUE (helps appear on map via others’ uplinks)
• Telemetry: 1800 s per timing interval of attached peripheral
• Neighborinfo: ON, Transmit over Lora ON, 14400 Interval
• Required Channels: Freq51

Note: Neighbor Info is no longer shared across the mesh on an unencrypted primary channel, thus we require the Freq51 MQTT and Neighborinfo Channel.

Clent Nodes (Stationary or Outdoors)

Paths to check (App tabs may vary):
Radio > User, Radio > Device, Radio > Position, Radio > LoRa, Radio > Bluetooth, Modules > Neighbor Info, Modules > MQTT

• Short name: Call sign; 4 Characters;
• Long name: Whatever you wish;
• Licensed amateur radio: FALSE (unless you’re operating in Ham Mode knowingly; encryption is disallowed on ham). HAM band operation is on Frequency Slot 45. Please do not use it on Frequency Slot 51.
• Role: Client
• Rebroadcast mode: ALL
• Node Info Broadcast Interval: 21600 s
• GPS Mode: ENABLED if present, else use Fixed Position.
• Fixed Position: Often TRUE for stationary nodes (set via CLI or phone). Unless GPS is desired for timekeeping. (really useful)
• Position Broadcast Interval: 21600 s
• Region: US
• Preset: Medium Fast
• Hop Limit: 7
• OK to MQTT: TRUE (helps appear on map via others’ uplinks)
• Telemetry: 1800 s per timing interval of attached peripheral
• Neighborinfo: ON, Transmit over Lora ON, 14400 Interval
• Required Channels: Freq51

Clent Mute Nodes (Mobile or Indoors)

Paths to check (App tabs may vary):
Radio > User, Radio > Device, Radio > Position, Radio > LoRa, Radio > Bluetooth, Modules > Neighbor Info, Modules > MQTT

• Short name: Call sign; 4 Characters;
• Long name: Whatever you wish;
• Licensed amateur radio: FALSE (unless you’re operating in Ham Mode knowingly; encryption is disallowed on ham). HAM band operation is on Frequency Slot 45. Please do not use it on Frequency Slot 51.
• Role: Client Mute
• Rebroadcast mode: Local Only
• Node Info Broadcast Interval: 21600 s
• GPS Mode: ENABLED if present, else use Fixed Position.
• Fixed Position: Often TRUE for stationary nodes (set via CLI or phone). Unless GPS is desired for timekeeping. (really useful)
• Position Broadcast Interval: 21600 s
• Region: US
• Preset: Medium Fast
• Hop Limit: 7
• OK to MQTT: OFF
• Ignore MQTT: ON
• Telemetry: 1800 s per timing interval of attached peripheral
• Neighborinfo: OFF
• Required Channels: Freq51

Clent Hidden Nodes (Stealth Nodes)

Paths to check (App tabs may vary):
Radio > User, Radio > Device, Radio > Position, Radio > LoRa, Radio > Bluetooth, Modules > Neighbor Info, Modules > MQTT

• Short name: Call sign; 4 Characters;
• Long name: Whatever you wish;
• Licensed amateur radio: FALSE (unless you’re operating in Ham Mode knowingly; encryption is disallowed on ham). HAM band operation is on Frequency Slot 45. Please do not use it on Frequency Slot 51.
• Role: Client Hidden
• Rebroadcast mode: Known Only by default. If you have a fresh node stay on Local Only
• Node Info Broadcast Interval: 4294967295 s
• GPS Mode: ENABLED if present, else use Fixed Position.
• Fixed Position: Off
• Position Broadcast Interval: OFF
• Region: US
• Preset: Medium Fast
• Hop Limit: 7
• OK to MQTT: OFF
• Ignore MQTT: ON
• Telemetry: OFF s per timing interval of attached peripheral
• Neighborinfo: OFF
• Required Channels: Freq51

Get on the Map

To appear on the map:

Channels > Primary
Modules > MQTT

• Allow Position Requests: TRUE
• Precise Location: TRUE
• Approximate Location: choose a value you’re comfortable with

If Enabling MQTT

• Uplink Enabled: TRUE
• Downlink Enabled: FALSE (prevents pulling internet traffic into RF)
• Enabled: TRUE
• MQTT Server Address: Message on MediumFast for details or reach out on Discord
• Username/Password: Message on MediumFast for details or reach out on Discord
• Encryption: TRUE
• JSON: FALSE
• TLS: FALSE
• Root Topic: msh/US/UT
• Map Reporting Enabled: TRUE
• Map Report Publish Interval: Fixed Same as standard config broadcast interval s; Portable no more frequent than 600 s
• Approximate Location: set as desired

Local Channels

We will not be providing nor publish QR codes or Meshtastic URLs for public channels. They can also change LoRa settings (hop count, OK to MQTT, TX power) invisibly. Enter channel names/keys manually. If you would like to create a channel for a specific purpose but wish it to be public use; contact us and we will add it to the documentation as requested.

MediumFast

Default community channel on Medium_Fast. We use this channel to connect the mesh together on a unified unencrypted channel and also broadcast. This resides in our secondary channels

DC801

This is the local hackerspace channel. The key is only found at the hackerspace. Come join us!

Freq51 Infrastructure

This page lists deployed routers, router lates, and strategically placed clients. Each entry has a spec table followed by a Site survey with associated images. North views are shown first when both are available.

For deployment guidelines, see Router Deployment Guide.

Table of Contents

Utah Infrastructure

• Routers
  • FPR — Francis Peak Router
  • LMR — Lake Mountain Router
  • NPR — Nelson Peak Router
• Router Lates
  • AUR — Aurora Uranialis
  • POTM — Point of the Mountain
• Strategic Clients
  • 👽 — Alien Tower 🛸
  • C6C — Aurora Ceresia
  • WC1 — Wasatch Crest 1
  • WC2 — Wasatch Crest 2

Idaho Infrastructure

• Routers
  • MHR — Mount Harrison Router
  • ISR — Indian Springs Router
• Router Lates
  • KBS — Kimama Butte Station
• Strategic Clients
  • SSL — Second Star Labs

Utah Infrastructure

Infrastructure located within Utah.

Routers

FPR — Francis Peak Router

Location: Francis Peak (Tertiary Peak)

Possesses a BME680 for weather & air-quality telemetry every 1800 s.

Site survey

North

South

LMR — Lake Mountain Router

Location: Lake Mountain Radio Tower

Site survey

North/South

NPR — Nelson Peak Router

Location: Nelson Peak

Site survey

North

South

Router Lates

AUR — Aurora Uranialis

Location: Ensign Peak

Includes BME680 telemetry every 1800 s.

Site survey

North

South

POTM — Point of the Mountain

Location: North-facing ridgeline

Site survey

North

South

Strategically Placed Clients

👽 — Alien Tower 🛸

Location: Alien Tower - Draper

Site survey

C6C — Aurora Ceresia

Location: Hill AFB – Weber State overlook

Site survey

WC1 — Wasatch Crest 1

Location: Silver Peak

Site Survey

WC2 — Wasatch Crest 2

Location: Squaretop

Site Survey

Idaho Infrastructure

Infrastructure physically located within Idaho.

Routers

MHR — Mount Harrison Router

Location: Mount Harrison

Site Survey

East

West

ISR — Indian Springs Router v2

Location: South Hills

Site Survey

East

West

Router Lates

KBS — Kimama Butte Station

Location: Kimama Butte

Site Survey

East

West

Strategically Placed Clients

SSL — Second Star Labs

Location: Second Star Labs

Site Survey

Our Equipment

This page will host Freq51 Mesh builds and their approximate coverage maps. Use them to align your setup if you’re inside coverage areas (red). Note that different nodes may run different software. Some builds will run the meshing around BBS system. These are select router nodes with high remote power requirements and recommended to be spaced within 5 hops of each other for consistent relaying. Other nodes are low power. We currently prefer NRF52 based infrastructure nodes for <1W TX power or femtofoxes and Nebra custom miner nodes for 1W TX power. All routers must feature a filter. Filtering is optional on non infrastructure nodes.

NRF52 Node Example

• ABS 7.9“ x 3.9“ x 2.8“ enclosures are a great size/price/quality (or similar).
  • Amazon Link
• Butyl tape OR LEXEL seals antenna passthroughs and is great for making outer seals as lexel sticks to itself (don’t block included gaskets).
  • Amazon Link
• Adafruit bq25185 USB / DC / Solar Lithium Ion/Polymer charger modules are handy for charging packs while radios are disconnected/in storage and its a great small MPPT (remove charge LED for small solar if needed).
  • https://www.adafruit.com/product/6091
• “Soshine” solar panels with regulated 5 V output are convenient and include a mounting pole.
  • Amazon Link
• UV-protect plastics & seal passthroughs: LEXEL has worked well.
• Use the battery connector as a service “switch” inside; add an external waterproof switch only when tool-access enclosures demand it.
• Add a small weep hole on the bottom for pressure equalization and drainage. This is also useful if you have weather sensors. Add a small fabric baffle and place the sensor behind it. We like Bosch BME680’s for weather data.
• Lube gaskets (e.g., silicone grease) to reduce drying/cracking and improve seals.
• After many trials, Alfa 5 dBi omni antennas have been a solid value: short (less wind load), N-male fits through-panel connectors, reliable wide beam.

We are going to fill out standard builds as we improve the documentation. Feel free to drop by the discord and suggest yours

Femtofox Node Example

TBA

Nebra Node Example

TBA

PiZero Node Example

TBA

Bird House Node Example

TBA

Tips for placement

TBA

Nebra Miner (DietPi + meshtasticd)

Why repurpose a Nebra?

• Great enclosure & RF path: sturdy case, antenna feedthrough, easy to mount. Many miners are cheap on the used market.
• Linux-native reliability: running Meshtastic on a Pi with meshtasticd is rock-solid for infrastructure nodes (MQTT uplink, remote admin, logging).
• 1 W class radio option: with the community NebraHat (SX1262) from @wehooper4, you get a clean SPI radio layout and a drop-in hardware preset.

What to buy

Minimum parts

• Nebra Outdoor Hotspot enclosure from Ebay. Don’t spend more than $50. The nebra comes with:
  • Raspberry Pi CM3
  • 32 GB Emmc
  • Built-in POE
  • Wifi Card & Antenna
  • 915Mhz Antenna
  • Waterproof Aluminum Enclosure
• NebraHat (SX1262, 1 W) by @wehooper4 (community board). You have to build this yourself or buy from a group buy.
  • Right now @bashNinja has about 10 left from a previous group buy.

Nice-to-have

• AHT20 sensor for weather telemetry inside the enclosure.
• A better antenna, such as the a 5dBi Alfa from Rokland.
• A sealant for the enclosure such as Lexel or Permatex

⚠️ Heads-up on other HATs
The pinout on the nebra is different than the standard Raspberry Pi pinout. This makes most hats incompatible unless you fix the pinout.

Quick start (DietPi + meshtasticd)

We’ll use DietPi (Debian 12 base / Debian 13 base) and the official Meshtastic Debian repo for meshtasticd.

1. Flash DietPi
   Grab the DietPi image and flash it to your microSD. First boot, set your basics (hostname, SSH, etc.).

2. Enable hardware interfaces

   • dietpi-config → Enable SPI and I2C. Reboot.

3. Install dependencies & meshtasticd

   *** Debain 12 - Bookworm ***

   sudo apt update
   sudo apt install -y libgpiod-dev libyaml-cpp-dev libbluetooth-dev openssl libssl-dev libulfius-dev liborcania-dev
   curl -fsSL https://download.opensuse.org/repositories/network:Meshtastic:beta/Debian_12/Release.key \
     | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/network_Meshtastic_beta.gpg
   echo 'deb http://download.opensuse.org/repositories/network:/Meshtastic:/beta/Debian_12/ /' \
     | sudo tee /etc/apt/sources.list.d/network:Meshtastic:beta.list
   sudo apt update && sudo apt install -y meshtasticd
   

   *** Debian 13 - Trixie ***

   sudo apt update
   sudo apt install -y libgpiod-dev libyaml-cpp-dev libbluetooth-dev openssl libssl-dev libulfius-dev liborcania-dev
   curl -fsSL https://download.opensuse.org/repositories/network:Meshtastic:beta/Debian_13/Release.key \
     | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/network_Meshtastic_beta.gpg
   echo 'deb http://download.opensuse.org/repositories/network:/Meshtastic:/beta/Debian_13/ /' \
     | sudo tee /etc/apt/sources.list.d/network:Meshtastic:beta.list
   sudo apt update && sudo apt install -y meshtasticd
   

4. Add the NebraHat radio preset
   *** 1W NebraHat ***

   cd /etc/meshtasticd/config.d/
   sudo wget https://raw.githubusercontent.com/wehooper4/Meshtastic-Hardware/refs/heads/main/NebraHat/NebraHat_1W.yaml
   

   *** 2W NebraHat ***

   cd /etc/meshtasticd/config.d/
   sudo wget https://raw.githubusercontent.com/wehooper4/Meshtastic-Hardware/refs/heads/main/NebraHat/NebraHat_2W.yaml
   

   Preset sets SX1262 pins for the NebraHat:

   Module: sx1262
   DIO2_AS_RF_SWITCH: true
   DIO3_TCXO_VOLTAGE: true
   # CS: 8           # (uncomment if needed)
   IRQ: 22
   Busy: 4
   Reset: 18
   RXen: 25
   

5. Edit core config

   sudo nano /etc/meshtasticd/config.yaml
   

   Suggested minimum edits:

   General:
     MACAddressSource: eth0   # or wlan0, or use a fixed MACAddress
   
   WebServer:
     Port: 9443
   

6. First boot of the service

   sudo systemctl enable meshtasticd
   sudo systemctl start meshtasticd
   sudo journalctl -u meshtasticd -f
   

7. Optional: Python & CLI tools

   sudo apt install -y python3-pip
   pip3 install --upgrade pytap2 "meshtastic[cli]"
   

   Verify:

   meshtastic --host 127.0.0.1 --info
   

8. Use the Web UI

   • Visit https://<pi-ip>:9443/ (accept the self-signed cert).
   • Set Region = US, Short/Long Name, and your Primary Channel (Leave this blank).

Role & channel recommendations (local norms)

• Most users: These are usually static and outside so choose: CLIENT.
• Infra: Always add an RF filter on infrastructure nodes; always talk with the rest of the Freq51 community before setting a ROUTER.
• Primary: Leave The name Empty; Secondary: N/A

Fitting it in the Nebra enclosure

1. Remove the old lora module.
2. Remove the USB board on the 40-pin header; seat the NebraHat on the 40-pin header.
3. Route the short SMA pigtail from the hat to the enclosure’s bulkhead connector.
4. Add a small bandpass filter inline for infrastructure builds.

Troubleshooting

• Radio not detected / -707 init errors
  • Confirm SPI enabled; check /dev/spidev0.*.
  • Verify the preset pinout (IRQ/Busy/Reset/RXen/CS).
• Duplicate MAC complaints
  • Set MACAddressSource: eth0 (or pick a fixed MACAddress:).
• Web UI issues
  • Ensure WebServer.Port is set.

Verifying on the mesh

• From another node, send a direct message to your Pi node.
• In the CLI: meshtastic --host 127.0.0.1 --info and meshtastic --host 127.0.0.1 --nodedb to see neighbors.
• On maps/MQTT (if you opt in), confirm you appear and avoid turning on downlink.

Appendix: NebraHat preset (reference)

# Nebra SX1262 Pi Hat - 1W
Module: sx1262
DIO2_AS_RF_SWITCH: true
DIO3_TCXO_VOLTAGE: true
# CS: 8
IRQ: 22
Busy: 4
Reset: 18
RXen: 25

Zeus Protection: Protecting Your Meshtastic Node from Lightning Strikes

Lightning strikes are a serious threat to any outdoor electronics, including your Meshtastic node. While nothing can guarantee absolute protection (Zeus always has the last word!), you can dramatically reduce your risk by using proper hardware and best practices.

Why Worry About Lightning?

• Lightning can induce massive voltages in antennas and cables—even if it doesn’t strike directly.
• Damage can travel through antenna cables and power lines, destroying your radio and even other equipment.
• Well-chosen protection can save your gear and even prevent fires.

Core Protection Hardware

1. Lightning Arrestor (Coaxial Surge Protector)

   • Install an inline lightning arrestor between your antenna and your node’s radio.
   • Look for models rated for your frequency (e.g., 400-470 MHz for Meshtastic).
   • Example: PolyPhaser IS-B50LN-C2 or ALPHA DELTA ATT3G50U.
   • Arrestors need to be properly grounded to be effective!

2. Grounding Rod

   • Connect the lightning arrestor to a dedicated ground rod driven several feet into the earth.
   • Use thick copper wire (at least 10 AWG, or 6mm²) for the ground connection.
   • Keep the ground wire as short and straight as possible.

3. Antenna Placement

   • Mount antennas away from the highest points on a building if possible.
   • Avoid mounting directly atop metal masts unless properly grounded.

4. Ferrite Beads/Chokes

   • Add ferrite beads to power and data cables entering your node enclosure.
   • This helps suppress voltage spikes from nearby lightning.

5. Weatherproofing

   • Use weatherproof enclosures to protect against water ingress, which can worsen lightning damage.
   • Seal all cable entries.

Installation Example

1. Mount your antenna securely.
2. Attach one side of the lightning arrestor to the antenna cable.
3. Attach the other side to your Meshtastic node’s radio input.
4. Connect the arrestor’s ground terminal to your ground rod using thick copper wire.
5. Add ferrite chokes to the power cable before it enters the enclosure.

Additional Tips

• Disconnect during storms: If possible, unplug antennas and power during severe weather.
• Inspect periodically: Check ground connections and arrestors for corrosion or damage.
• Insurance: Consider insuring expensive network nodes or setups.

Can You Really Protect Against Zeus?

Nothing is foolproof—lightning is unpredictable and immensely powerful (just ask Zeus!). But good grounding and surge protection make a huge difference, turning a likely catastrophe into a survivable event.

Stay safe, and may your mesh be ever resilient!

Advanced Configuration

This section contains advanced configuration guides for experienced users who want to deploy more complex setups or take on additional responsibilities in the Freq51 Intermountain Mesh network.

Available Guides

• Router Deployment Guide - Comprehensive guide for deploying router nodes
• Firmware Update Guide - Comprehensive guide for updating Node Firmware

Router Deployment Guide - Freq51 Intermountain Mesh

🎯 Overview

This guide covers everything you need to know about deploying ROUTER nodes on the Freq51 Intermountain Mesh network. Router deployment is a critical responsibility that requires careful planning, community coordination, and technical understanding.

⚠️ IMPORTANT: Router deployment should only be undertaken by experienced community members with proper coordination. Contact the Discord community before deploying any router nodes.

🏷️ Understanding Router Roles

🔄 ROUTER Role

• Purpose: Optimized for message forwarding and network infrastructure
• Behavior: Stores messages longer, prioritizes routing over local communication
• Power: Requires reliable, continuous power source
• Coverage: Should provide strategic coverage for the network
• Coordination: MANDATORY community approval required

🚫 REPEATER Role

• ❌ NOT RECOMMENDED: Should be avoided by all users
• Why avoid: Can cause network congestion and interference
• Community policy: Only deployed by experienced members with specific approval
• ⚠️ Critical: Never use without explicit network coordinator permission

📏 Strategic Placement by Elevation

Where we place routers is very important.

🏔️ High Elevation Backbone Routers (~9,361’ - Nelson Peak Level)

Purpose: Major backbone infrastructure for maximum regional coverage

Characteristics:

• Elevation: 9,000+ feet above sea level
• Coverage: 50+ miles with clear line-of-sight
• Role: Primary ROUTER role only
• Power: Must have reliable, continuous power (solar + battery backup recommended)
• Antenna: High-gain directional and omnidirectional antennas
• Coordination: Requires extensive community planning and approval

Example Locations:

• Mountain peaks and ridges
• Tall communication towers
• Strategic high points with 360° visibility
• Existing radio infrastructure sites

Requirements:

• Community approval and coordination
• Reliable power infrastructure
• Weather-resistant housing
• Remote monitoring capabilities
• Regular maintenance access

⛰️ Regional Coverage Routers (~5,600’ - Point of the Mountain Level)

Purpose: Regional coverage bridging high backbone to local nodes

Characteristics:

• Elevation: 5,000-7,000 feet above sea level
• Coverage: 15-30 mile radius depending on terrain
• Role: ROUTER_LATE
• Power: Reliable power source (grid-tied or robust solar)
• Antenna: Medium to high-gain antennas
• Coordination: Community coordination recommended

Example Locations:

• Foothills and elevated neighborhoods
• Radio towers and communication sites
• Elevated commercial/residential buildings
• Strategic overlooks and ridges

Requirements:

• Community notification and approval
• Stable power source
• Weather protection
• Basic monitoring capabilities

🏠 Local/Ground Level (25-35’ - House Roofs/Ground Level)

Purpose: Local mesh participation and user access

Characteristics:

• Elevation: Ground level to 100 feet
• Coverage: 1-5 miles in typical terrain
• Role: CLIENT or CLIENT_MUTE (NOT router roles)
• Why CLIENT: Prevents network congestion from too many routers
• Power: Standard residential power

Example Locations:

• Home installations
• Portable setups
• Vehicle mounts
• Temporary deployments

Key Principle: Higher elevation = greater responsibility and coordination requirements. Most users should remain clients regardless of their installation height.

🔧 Technical Requirements

Hardware Specifications

Minimum Requirements:

• Meshtastic-compatible device (Heltec V3, T-Beam, etc.)
• Reliable power source (grid-tied or solar with battery backup)
• Weather-resistant housing/enclosure
• Appropriate antenna for coverage area
• Network connectivity for monitoring (optional but recommended)

Recommended for High-Elevation Routers:

• Industrial-grade device with extended temperature range
• Redundant power systems (solar + battery + grid backup)
• Professional antenna installation
• Remote monitoring and management capabilities
• Lightning protection and grounding

Power Requirements

Grid-Tied Systems:

• Uninterruptible Power Supply (UPS) for short outages
• Automatic restart capability
• Power monitoring and alerts

Solar Systems:

• Sufficient panel capacity for location and season
• Deep-cycle battery bank with 3-5 day autonomy
• Charge controller with low-voltage disconnect
• Battery monitoring and maintenance access

Hybrid Systems (Recommended):

• Primary: Grid power
• Backup: Solar + battery
• Automatic switching between sources
• Remote monitoring of power status

Antenna Considerations

High-Elevation Routers:

• High-gain omnidirectional antennas (6-12 dBi)
• Directional antennas for specific coverage areas
• Professional installation with proper grounding
• Lightning protection systems

Regional Routers:

• Medium-gain omnidirectional antennas (3-6 dBi)
• Directional antennas for targeted coverage
• Weather-resistant mounting
• Proper grounding and lightning protection

Antenna Placement:

• Clear line-of-sight to target coverage areas
• Above surrounding obstructions
• Proper grounding and lightning protection
• Accessible for maintenance

📋 Pre-Deployment Checklist

Community Coordination

• Contact Discord community for approval
• Discuss placement with network coordinators
• Review coverage maps and existing infrastructure
• Coordinate with nearby router operators
• Plan maintenance and monitoring responsibilities

Technical Preparation

• Test device configuration in lab environment
• Verify power system reliability
• Test antenna performance and coverage
• Set up monitoring and alerting systems
• Prepare backup equipment and spare parts

Site Preparation

• Secure mounting location and permissions
• Install power infrastructure
• Set up weather protection
• Install lightning protection and grounding
• Test all systems before final deployment

Documentation

• Document exact location coordinates
• Record antenna height and orientation
• Document power system specifications
• Create maintenance schedule
• Set up monitoring and alerting

⚙️ Configuration Guidelines

Essential Settings

Node Configuration:

• Role: ROUTER (only after community approval)
• Node Name: Descriptive name indicating location/function
• Location: Enable GPS for accurate positioning
• Power Management: Optimize for continuous operation

Channel Settings:

• Primary Channel: Use community standard (Leave the name empty)
• Region: Set to “US”
• Frequency: 915MHz band (automatic for US region)
• Hop Limit: Set to 7

Router-Specific Settings:

• Store & Forward: Enable for message relay capability
• Neighbor Info: Enable for network mapping
• MQTT: Configure based on community guidelines
• Power Management: Disable sleep modes for continuous operation

Advanced Configuration

Network Optimization:

• Message Routing: Optimize for network topology
• Store & Forward: Configure based on coverage area
• Neighbor Discovery: Enable for network health monitoring
• Channel Utilization: Monitor and optimize as needed

Monitoring and Management:

• Remote Access: Set up secure remote management
• Logging: Enable comprehensive logging
• Alerting: Configure alerts for system issues
• Backup: Regular configuration backups

🚨 Safety and Legal Considerations

Safety Requirements

• Electrical Safety: Proper grounding and electrical installation
• Lightning Protection: Essential for elevated installations
• Fall Protection: Safe access for maintenance
• Weather Protection: Adequate housing for environmental conditions
• Fire Safety: Proper electrical installation and fire prevention

Legal Considerations

• Permits: Check local requirements for antenna installations
• Zoning: Verify compliance with local zoning regulations
• Property Rights: Ensure proper permissions for installation
• FCC Compliance: Verify device compliance with FCC regulations
• Insurance: Consider liability and equipment insurance

Environmental Impact

• Wildlife: Consider impact on local wildlife
• Visual Impact: Minimize visual impact where possible
• Noise: Ensure equipment doesn’t create noise issues
• Maintenance Access: Plan for minimal environmental disruption

🔧 Maintenance and Monitoring

Regular Maintenance Schedule

Daily Monitoring:

• Check device status and connectivity
• Monitor power system performance
• Review network traffic and performance
• Check for any error messages or alerts

Weekly Tasks:

• Review system logs for issues
• Check antenna connections and mounting
• Verify power system operation
• Update community on status

Monthly Tasks:

• Physical inspection of equipment
• Clean antennas and equipment
• Check weather protection
• Review and update documentation

Quarterly Tasks:

• Comprehensive system testing
• Update firmware if needed
• Review and optimize configuration
• Plan for seasonal changes

Monitoring Systems

Essential Monitoring:

• Device connectivity and status
• Power system performance
• Network traffic and routing
• Environmental conditions

Recommended Monitoring:

• Remote access and management
• Automated alerting systems
• Performance metrics and reporting
• Community communication channels

🆘 Troubleshooting Common Issues

Connectivity Problems

• No Network Connection: Check power, antenna connections, and device status
• Poor Coverage: Verify antenna placement and orientation
• Intermittent Issues: Check power system stability
• High Packet Loss: Review antenna and environmental factors

Power Issues

• Battery Problems: Check battery health and charging system
• Solar Issues: Verify panel output and charge controller
• Grid Power: Check UPS and power monitoring systems
• Weather Impact: Plan for seasonal power variations

Network Performance

• Routing Issues: Review network topology and configuration
• Congestion: Monitor channel utilization and optimize
• Coverage Gaps: Coordinate with community for improvements
• Interference: Identify and mitigate sources of interference

📞 Support and Resources

Community Support

• Discord: Primary support channel for router operators
• Local Meetups: In-person support and coordination
• Mentorship: Experienced operators available for guidance
• Documentation: This guide and related resources

Technical Resources

• Meshtastic Documentation: Official technical documentation
• Hardware Guides: Equipment-specific setup guides
• Configuration Examples: Community-tested configurations
• Best Practices: Lessons learned from existing deployments

Emergency Procedures

• System Failure: Rapid response procedures
• Power Outage: Backup power activation
• Weather Events: Storm preparation and recovery
• Network Issues: Coordination with community

🎯 Success Metrics

Network Health Indicators

• Message Delivery: Successful message routing rates
• Coverage Area: Effective coverage radius
• Uptime: System availability and reliability
• Network Growth: Contribution to network expansion

Community Impact

• User Connectivity: Improved access for community members
• Emergency Preparedness: Enhanced emergency communication capability
• Network Resilience: Increased network redundancy and reliability
• Knowledge Sharing: Contribution to community knowledge base

Remember: Router deployment is a significant responsibility that directly impacts the entire network. Always coordinate with the community, follow best practices, and prioritize network health over individual preferences.

For questions or support, contact the Freq51 community through Discord or local meetups. We’re here to help ensure successful router deployments that benefit the entire network.

📻 Meshtastic Firmware Update Guide

This guide provides instructions for updating firmware on various Meshtastic-compatible devices.

📑 Table of Contents

• Prerequisites
• Using the Web Flasher
• Updating RAK19007/19003 Nodes
• Updating Heltec Nodes
• Updating Seedstudio T1000E
• Over-the-Air (OTA) Updates for RAK Nodes (Advanced Users Only)

📋 Prerequisites

Before beginning any firmware update, ensure you have:

• 🔌 A USB data cable (not just a charging cable)
• 🌐 For web flasher: A compatible browser (Chrome or Edge recommended)
• 💻 For CLI updates: The latest version of the Meshtastic CLI installed
• 📥 The appropriate firmware file for your device from the Meshtastic releases page
• 🐍 For wired updates with CLI: Python 3.x and esptool
• 📱 For OTA updates: An Android device with Bluetooth capabilities

🌐 Using the Web Flasher

The easiest way to update firmware on most Meshtastic devices is using the browser-based flasher tool:

1. 🔌 Connect your device to your computer using a USB cable
2. 🖥️ Visit flasher.meshtastic.org in a WebUSB compatible browser (Chrome or Edge recommended)
3. 📋 Select your device type from the dropdown menu:
   • 🔍 Auto-detect option: The web flasher can automatically detect many common device types - look for “Auto” or “Auto-detect” at the top of the device selection dropdown
   • If auto-detection doesn’t work, manually select your specific device model
4. 🔄 Choose the firmware version you want to install:
   • ✅ Select “Release” for stable firmware
   • 🧪 Select “Alpha” for testing new features (may be unstable)
   • 🎛️ Select “Custom” if you have a specific firmware file to upload
5. 🔗 Click “Connect” and select your device from the popup dialog:
   • On Windows: You’ll see your device listed with a COM port (e.g., “USB Serial Device (COM3)”)
   • On macOS: You’ll see your device with a /dev identifier (e.g., “usbmodem1101”)
   • On Linux: You’ll see your device with a /dev/ttyUSB or /dev/ttyACM identifier
   • Select the appropriate device from this list
6. ⚡ Click “Flash” to begin the update process:
   • The screen will show detailed progress information
   • 🔄 DFU Mode Prompt: Some devices may need to enter Device Firmware Update (DFU) mode during flashing
   • If prompted to enter DFU mode, follow the on-screen instructions which typically involve:
     • Pressing and holding specific button combinations on your device
     • For most ESP32 devices: Hold the BOOT button while pressing and releasing RESET
     • The web flasher will display specific instructions for your device model
   • Once in DFU mode, the flashing process will continue automatically
7. ⏳ Wait for the process to complete - you’ll see a progress bar and log messages
8. 🎉 Once finished, your device will automatically reboot with the new firmware

Note: The web flasher requires a browser that supports WebUSB, which is currently only Chrome, Edge, and other Chromium-based browsers. Firefox and Safari are not supported.

✨ Advantages of the Web Flasher:

• 📥 No software installation required
• 🔍 Auto-detection of device types
• 🙂 User-friendly interface
• 💻 Works on Windows, macOS, Linux, and ChromeOS
• 🤖 Automatically handles bootloader mode for many devices
• 📱 Interactive guidance for entering DFU mode when needed

** Video: **

📡 Updating RAK19007/19003 Nodes

The RAK19007 and RAK19003 can be updated using the following method:

1. 🔌 Connect your RAK device to your computer using a USB cable

2. 🔍 Identify the correct serial port:

   • Windows: Check Device Manager under Ports (COM & LPT)
   • macOS: Run ls /dev/cu.* in Terminal
   • Linux: Run ls /dev/ttyUSB* in Terminal

3. 🔄 Put the device in bootloader mode:

   • Press and hold the BOOT button
   • Press and release the RESET button
   • Release the BOOT button

4. ⚡ Flash the firmware using Meshtastic CLI:

meshtastic --device [PORT] --flash [PATH_TO_FIRMWARE]

Replace [PORT] with your device’s serial port (e.g., COM3 on Windows or /dev/ttyUSB0 on Linux) and [PATH_TO_FIRMWARE] with the path to your downloaded firmware file.

Alternatively, you can use esptool directly:

esptool.py --port [PORT] --baud 921600 write_flash 0x10000 [PATH_TO_FIRMWARE]

5. 🔄 After flashing is complete, press the RESET button to restart the device with the new firmware.

Note: The Web Flasher method described earlier is often easier and recommended for most users updating RAK devices.

📟 Updating Heltec Nodes

Heltec devices (like the Heltec WiFi LoRa 32 V2) can be updated with these steps:

1. 🔌 Connect your Heltec device to your computer via USB

2. 🔍 Identify the serial port as described in the RAK section above

3. 🔄 Put the device in bootloader mode:

   • Press and hold both the PROG and RESET buttons
   • Release the RESET button
   • Release the PROG button

4. ⚡ Flash the firmware using Meshtastic CLI:

meshtastic --device [PORT] --flash [PATH_TO_FIRMWARE]

Alternatively, use esptool:

esptool.py --chip esp32 --port [PORT] --baud 921600 write_flash 0x10000 [PATH_TO_FIRMWARE]

5. 🔄 Press the RESET button after flashing completes.

🛰️ Updating Seedstudio T1000E

The Seedstudio T1000E follows a similar update process:

1. 🔌 Connect the T1000E to your computer via USB
2. 🔍 Identify the serial port
3. 🔄 Enter bootloader mode (consult your device documentation for the exact button combination)
4. ⚡ Flash the firmware using the Meshtastic CLI:

meshtastic --device [PORT] --flash [PATH_TO_FIRMWARE]

5. 🔄 After flashing completes, reset the device.

For more detailed instructions, visit the Get Started with T1000-E Tracker

📱 Over-the-Air (OTA) Updates for RAK Nodes

⚠️ ADVANCED USERS ONLY: This procedure requires technical knowledge and carries risks including potential device bricking if interrupted. Beginners should use the Web Flasher method.

RAK devices with the RAK4631 chipset (nRF52840-based) can be updated over Bluetooth using an Android device. This method is perfect for nodes installed in hard-to-reach locations where physical access is difficult.

📲 Using the nRF Device Firmware Update App

1. 📥 Install the Required App:

   • Install the nRF Device Firmware Update app from the Google Play Store

2. 📥 Obtain the Correct Firmware:

   • Visit the Meshtastic Github Repository
   • For the latest beta: Select the “Meshtastic Firmware…” link at the top
   • For older versions: Select the “releases” link below that
   • Download the “firmware-nrf52840-(version).zip” file to your computer
   • Unzip the file and locate the “firmware-rak4631-(version)-ota.zip” file
   • Transfer this file to your Android phone

3. ⚙️ Configure nRF DFU App Settings:

   • Open the nRF DFU app
   • Go to Settings (gear icon)
   • Configure the following settings (recommended by Meshtastic developers):

     Packets receipt notification: On
     Number of packets: 5
     Reboot time: 5000ms
     Scan timeout: 10000ms
     Request high MTU: Off
     Disable resume: Off
     Prepare object delay: 500ms
     Force scanning: Off
     Keep bond: On
     External MCU DFU: Off
     

   • These specific settings help ensure a successful update process

4. 🔄 Perform the OTA Update:

   • Get within Bluetooth range of your RAK node (within 2-3 meters)
   • In the nRF DFU app, select the firmware file you transferred to your phone
   • The app will scan for available devices
   • Select your RAK node from the list of discovered devices
   • Click “Start” to begin the update process

5. ⏳ Update Process:

   • Keep your Android device near the RAK node during the entire update
   • The process may take 5-10 minutes to complete
   • Do not close the app or let your phone screen turn off
   • The app will display progress information during the update
   • Once complete, the device will automatically reboot with the new firmware

⚠️ Important Notes for OTA Updates

• 🚨 This process is for advanced users who understand the risks involved
• 🔋 Ensure your RAK device has sufficient battery power (at least 50% recommended)
• 📶 Do not move the Android device away from the RAK node during the update
• ⚠️ Interrupting the update process may render your device unusable
• 📱 Keep your phone screen on during the entire update process
• 🔄 If the update fails, you may need to retry or fall back to the wired update method
• 🌐 This method only works with RAK devices that use the nRF52840 chipset (RAK4631-based nodes)
• 📡 The device may show as “Offline” in your mesh network during the update process

⚠️ Disclaimer: Use OTA updates at your own risk. While this method has worked for many users, we cannot guarantee it will work in all situations. If your device is mission-critical or difficult to physically access should something go wrong, consider using the more reliable wired update methods described earlier in this guide.

🔍 Troubleshooting OTA Updates

• If the update fails to start, try restarting both the node and your phone
• Ensure no other apps are connected to your Meshtastic device during the update
• If you can’t see your device in the scan list, make sure it’s powered on and within range
• For persistent issues, verify you’re using the correct firmware file specifically for OTA updates
• The OTA zip file must be the one specifically prepared for OTA updating, not the regular firmware file

For more detailed instructions, visit the PV Mesh OTA Update Guide

🔧 Troubleshooting

🚨 Common Issues and Solutions

1. 🔎 Device Not Detected:

   • Try a different USB cable
   • Try a different USB port
   • Install or update device drivers

2. ❌ Flashing Fails:

   • Ensure the device is in bootloader mode
   • Try a lower baud rate (e.g., 115200 instead of 921600)
   • Make sure you’re using the correct firmware for your device

3. 📱 OTA Update Fails:

   • Ensure your Android device and RAK node are close to each other
   • Check that both devices have sufficient battery power
   • Try disconnecting and reconnecting before attempting again
   • Verify your OTA app settings match the recommended configuration
   • Try disabling battery optimization for the update app
   • For nRF DFU app: Make sure you’re using the correct -ota.zip file

4. 🔄 Device Doesn’t Boot After Update:

   • Perform a factory reset by holding the appropriate buttons for your device
   • Re-flash using the wired method

5. 🌐 Web Flasher Issues:

   • Make sure you’re using Chrome or Edge browser
   • Try different USB ports or cables
   • If the device isn’t recognized, manually put it in bootloader mode
   • If prompted to enter DFU mode but can’t get it to work, try manually entering bootloader mode first, then reconnect
   • Clear browser cache and try again
   • If auto-detection fails, try selecting your device model manually

6. 🔄 DFU Mode Issues:

   • If your device won’t enter DFU mode, try different button combinations
   • Some devices require timing the button presses precisely
   • Try disconnecting and reconnecting the USB cable before attempting again
   • Check that you’re using a data-capable USB cable, not just a power cable

📚 Additional Resources

• 📖 Official Meshtastic Documentation
• 💻 Meshtastic GitHub Repository
• 👥 Meshtastic Community Forum
• 🌐 Web Flasher Tool

🔄 Last updated: 2025-09-11