# Two meshes, one Valley

Compare the protocols, find Arizona participants, and choose the network your radio can actually reach.

Research draft · October 29, 2026

## Why are there two systems?

Meshtastic and MeshCore are separate projects with different routing and product choices. They often support the same LoRa hardware, but their packet formats and software ecosystems differ. A supported board can often be reflashed from one to the other. That does not make the two networks directly interoperable, and ordinary single-radio setups run one firmware at a time.

The most useful question is not which project wins a worldwide argument. It is which network supports your destinations, which interface your household prefers, and who will help maintain the infrastructure.

## The practical differences

| Aspect | Meshtastic | MeshCore |
|---|---|---|
| Personal radio | Role determines whether it relays | Standard companion firmware does not relay other users' traffic |
| Infrastructure | Clients and selected high-site router roles | Deliberately configured repeaters |
| Broadcast/group traffic | Managed flooding with duplicate suppression | Group-channel traffic still floods |
| Direct messages | Learns a next hop after initial discovery | Learns a route and includes the path in later messages |
| Ecosystem emphasis | Messaging, mapping, positions, sensors, integrations | Messaging, repeaters, room servers, and routing controls |
| Software availability | Open-source project and clients | Open-source core; some clients/standalone software have closed or paid components |

Sources: [Meshtastic routing](https://meshtastic.org/docs/overview/mesh-algo/) · [MeshCore FAQ](https://docs.meshcore.io/faq/)

**An important correction to older comparisons:** Meshtastic has used next-hop routing for direct messages since version 2.6. Describing it as flooding every message gives a misleading comparison. MeshCore's separate repeaters remain a real architectural distinction, but good placement and configuration matter for both networks. [Meshtastic 2.6 announcement](https://meshtastic.org/blog/meshtastic-2-6-preview/)

## Is Meshtastic the most popular?

Its public development footprint is larger than MeshCore's in the snapshot reviewed for this series: roughly 8,500 versus 3,900 GitHub stars. Stars measure interest, not installed radios or active users. This supports a cautious statement that Meshtastic is the larger public project of these two, not a definitive global market-share ranking. [Meshtastic firmware](https://github.com/meshtastic/firmware) · [MeshCore firmware](https://github.com/meshcore-dev/MeshCore)

For a Phoenix household, a reachable and maintained local network is more useful than a larger global audience. There is no verified Phoenix active-node census in this research.

## Where to meet Arizona participants

| Community/resource | Use it for |
|---|---|
| [Arizona Meshtastic Community](https://azmsh.net/) | Local introduction and network guidance |
| [AZMSH contact and Discord](https://azmsh.net/reach_out.html) | Current local radio settings, placement discussion, help |
| [AZCOREMSH](https://azcoremsh.net/) | Arizona MeshCore community project |
| [Arizona Mesh directory](https://arizona-mesh.org/community/) | Links to both groups and regional discussions |
| [MeshCore map](https://map.meshcore.io/) | Discovering reported infrastructure |
| [Meshtastic community map](https://meshtastic.liamcottle.net/) | Exploring nodes that have been reported online |

The Arizona directory listed approximately 1,650 AZMSH Discord members and 450 AZCOREMSH members, with its links checked October 18, 2026. These are a **secondary directory's membership estimates**, not independently verified active radios, Phoenix residents, or coverage. The numbers are evidence of interest, not a buying guarantee. [Directory](https://arizona-mesh.org/community/)

## Get the settings before judging reception

AZMSH directs newcomers to Discord for its current Arizona modem preset and frequency slot. Do not assume factory defaults match. Its published role advice is `CLIENT_MUTE` for moving devices, `CLIENT` for ordinary home/roof nodes, and a discussion before configuring a high-site router. It also advises keeping MQTT downlink disabled unless coordinated. [Arizona settings](https://azmsh.net/docs/recommended-settings.html)

Published settings can change. Ask for the current profile, supported firmware, and preferred test procedure. Retain a configuration export so a test can be repeated rather than remembered approximately.

## Maps are leads, not proof

An online map can omit private or disconnected nodes and retain stale entries. A displayed distant node can also reflect internet forwarding rather than a direct RF path. For a useful comparison, label every test as direct RF, relayed RF, or internet-assisted; disable internet bridging for the RF baseline.

At this stage, no path survey has verified a particular roof or White Tanks link. Introduce the proposed site to both communities before buying a mountain installation. Suggested message: “We are evaluating a neighborhood node and a possible White Tanks site. Which existing paths need help, and what settings and role would you recommend?”

That outreach text is a draft for the operator to send; no contact was made during this research.