The ERSN Mesh Comms Working Group explores off-grid text and data communications that can supplement our GMRS voice net. We're not tied to a single product—our focus is on whatever LoRa mesh technology gives the most reliable coverage across our terrain. Today that means MeshCore.
ERSN has migrated its repeaters and personal nodes over to MeshCore, and we're now participating as part of the SIERRA MeshCORE Network. MeshCore is an alternative LoRa mesh project whose routing method has proven significantly more reliable for our terrain.
Since making the switch we've seen good connectivity between Dorrington, Murphys, and Columbia, and on out to the Central Valley and beyond. We've even relayed traffic from San Francisco to Murphys over LoRa—a reach that Meshtastic never managed to achieve in our network.
On the network you'll see our repeaters prefixed with SIERRA. We
currently have repeaters at:
One current downside is that Pinebrook and the Moran Road corridor are cut off from the rest of the mesh, so the Pinebrook repeater isn't yet linking back to the wider network. We're actively looking for additional repeater locations to close that gap and extend coverage. If you have a good high site, we'd love to hear from you.
You can see war-driving results for the current mesh on the MeshMapper coverage map.
#motherlode and #sierras:
hashtag channels worth following for regional traffic
If you're interested in helping expand the mesh—or in participating in the private SIERRA channel—please contact us.
The ERSN Mesh Comms Working Group exists to:
Our long-term vision is a robust, semi-persistent mesh that can serve as a backup communications method that supplements our GMRS net.
ERSN's Meshtastic nodes are currently not operational—the network has moved to MeshCore (see above). The material below is retained as background for those still running Meshtastic devices, and for anyone interested in the history of the working group.
Meshtastic is an open-source project that turns inexpensive LoRa radios into a powerful, off-grid mesh communication system. With a Meshtastic device, you can send short text messages and GPS locations to others without the need for cellular or internet access—perfect for emergencies, hiking trips, or rural communities.
Meshtastic devices form a mesh network, meaning your messages can hop between radios to reach their destination, even if you're not directly within range. This makes it ideal for decentralized communication in areas with limited infrastructure.
New to Meshtastic? Here's how to begin:
ERSN[Click to reveal] Check out Meshtastic's detailed Getting Started Guide for more detailed instructions.
Meshtastic devices leverage LoRa (Long Range) radio technology, which offers impressive coverage compared to other license-free options:
Factors affecting range include:
The mesh architecture means that even with limited individual node range, a network of devices can cover larger areas as messages hop from node to node.
MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for constrained devices and low-bandwidth, high-latency networks—perfect for IoT applications.
MQTT bridging allows separated Meshtastic mesh networks to connect over the internet. For example, two mesh networks in different valleys that can't directly communicate via radio can still exchange messages when at least one node from each network has internet access.
mqtt.bayme.sh[Click to reveal] [Click to reveal] msh/US/CA/MotherlodeonYou should also update the ERSN channel configuration to have all options enabled (uplink, downlink, position).
WiFi-enabled Meshtastic nodes (like the T-Beam) can act as internet gateways, connecting your local mesh to the wider network. These gateways are typically stationary devices set up at home with permanent power and WiFi, but can also be mobile when connected to hotspots or Starlink in the field.
MQTT Broker (Cloud)
┌─────────┐
┌─────────│ MQTT │─────────┐
│ │ Broker │ │
│ └─────────┘ │
│ │
MQTT Bridge via Internet/Grid │
│ │
┌─────────┴──────────┐ ┌─────────┴──────────┐
│ Stationary Gateway │ │ Stationary Gateway │
│ (Pinebrook) │ │ (Murphy's) │
└─────────┬──────────┘ └─────────┬──────────┘
│ │
│ (wireless mesh) │ (wireless mesh)
┌─────────┼─────────┐ ┌─────────┼─────────┐
│ │ │ │ │ │
┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐
│ Mobile│ │ Mobile│ │ Mobile│ │Mobile │ │Mobile │ │Mobile │
│ Node │ │ Node │ │ Node │ │Node │ │Node │ │Node │
│ A1 │ │ A2 │ │ A3 │ │ B1 │ │ B2 │ │ B3 │
└───────┘ └───────┘ └───────┘ └───────┘ └───────┘ └───────┘
Note: Bridging requires grid or internet access, so it's not a replacement for true off-grid use. It's best thought of as a way to “stitch” together multiple local meshes when internet is available.
Not all nodes in your mesh need the same MQTT configuration. Understanding the different roles and the critical "OK to MQTT" setting helps ensure proper message propagation between separated mesh networks.
Location: The "OK to MQTT" setting is found under LoRa settings in your Meshtastic device configuration, not in the MQTT Module section. This is separate from the MQTT Module settings that gateway nodes use for broker connection details.
This setting controls whether your node's messages can be uploaded to MQTT brokers by gateway nodes in your mesh:
falseImportant: This is not a cryptographic security feature but a "polite request" enforced by official firmware. It only applies to channels using the default PSK keys—channels with custom encryption keys ignore this setting.
Consider this five-node setup across two separate mesh areas:
Area 1 (Pinebrook) MQTT Cloud Area 2 (Murphy's)
│
Alpha ────┐ │ ┌──── Echo
(Portable) │ │ │ (Portable)
│ │ │
Beta ──────┼─── Gamma ────────┼────────── Delta ──┤
(Solar) │ (Gateway) │ (Gateway) │
│ WiFi: Yes │ WiFi: Yes │
│ MQTT: Config │ MQTT: Config
│
Area 1 Local Mesh Bridge Area 2 Local Mesh
Configuration breakdown:
true: Alpha's messages reach Echo via Gamma →
MQTT → Delta
false: Alpha's messages only reach Beta and
Gamma locally
Key insight: Only gateway nodes need MQTT Module configuration, but all nodes that want their messages to cross mesh boundaries need "OK to MQTT" enabled.
If you're interested in joining the ERSN Mesh Comms Working Group:
Together, we'll build a resilient, decentralized communication fabric for the mountains.