• TL;DR; ELI5
• Mesh networking in 30 seconds
• Default roles & behavior
• Hop Limits
• Telemetry & airtime
• Radio presets, throughput & interference
• When to use each
• Comparison table

TL;DR; ELI5

ELI5

Think of sending a whisper across a playground. With Meshtastic, everyone passes your whisper along, so the "chain" can move and grow as people move around, but they stop sharing your message after it's passed through 7 people. With MeshCore, only special helpers (repeaters) pass the whisper, but they can pass it to up to 64 more helpers.

By default, with MeshCore those helpers also talk faster and there are fewer side conversations that might delay your whisper. On Meshtastic, the other people talk slower and are having side conversations that have to finish before your whisper can be shared, slowing down the rate at which your whisper makes its way through the crowd.

TL;DR;

Meshtastic works well when people and links are moving (friends at an event, a hike, a bike ride). Regular nodes help by rebroadcasting, so coverage can shift and grow as people move. MeshCore works well when you can place fixed repeaters on rooftops or hills. Phones connect through companion radios; companions do not rebroadcast, so repeaters are what grow the mesh.

Main differences

• Hop limits: Meshtastic default 3 (max 7); MeshCore up to 64.
• Who rebroadcasts: Meshtastic clients help relay; MeshCore companions do not. Only repeaters relay.
• Telemetry(battery, temperature, etc): Meshtastic pushes data regularly; MeshCore pushes rarely, and allows manual pulling.
• Responsiveness: MeshCore feels considerably faster with default config; Meshtastic can be manually tuned to similar results.

Mesh networking in 30 seconds

• Self-healing + multi-hop: Messages can traverse multiple radios (“hops”). If one link disappears, the mesh finds another path.
• Flood routing: On low-power radios, many systems use a simple “managed flood” where nodes selectively rebroadcast packets without maintaining big routing tables.^[1]
• Direct paths: Some systems learn a path during the first flood, then send future messages via a more efficient “next-hop” route, falling back to flood if the path breaks.^[2][3]

Default roles & behavior

• Meshtastic: Default role is CLIENT, which does take part in rebroadcasting in most cases. This helps ad-hoc, moving groups connect even without fixed infrastructure.^[4]
• MeshCore: Default end-user firmware is Companion (USB/BLE app companion). Companions do not rebroadcast other people’s packets; Repeaters handle forwarding. This concentrates airtime on purpose-built, well-placed infrastructure nodes.^[5][6][7]

Meshtastic shines for non-geostationary groups (e.g. a ski hill or a bike ride with moving parties). MeshCore is optimized for large scale meshes with infrastructure nodes (repeaters) placed on high points.

Routing strategies

• Meshtastic: Managed flood. Since v2.6, Direct Messages use next-hop routing: flood to discover, then optimized relays for subsequent DMs.^[1][2]
• MeshCore: Flood-then-direct by design: first message floods to learn a path; later messages embed the learned path; if that route fails after a few retries, the node automatically falls back to flood.^[3]

Hop limits

• Meshtastic: Default Max Hops = 3 (configurable to max 7)^[8]
• MeshCore: Internal max hop limit = 64^[9]

Implication for AustinMesh: Hill/valley terrain often needs many relays. Seven hops can be a hard ceiling for Meshtastic across the whole metro, while MeshCore's higher limit gives more headroom.

Telemetry & airtime

• Meshtastic periodically transmits device telemetry, position, and node info on timers (defaults ~30 min, 15 min*, and 3 hours). As meshes grow, the firmware auto-backs off these intervals to reduce congestion.^[10] This is good for tracking/telemetry, but on very large meshes the background traffic can consume valuable airtime.
• MeshCore avoids frequent network-wide telemetry by default. Repeaters can send periodic adverts (local or flood) on long intervals, and you can tune or disable them to conserve airtime.^[7][16]

For Austin Mesh—where the goal is region wide messaging (not sensor telemetry)—MeshCore’s default traffic profile typically leaves more airtime for actual messages.

Radio presets, throughput & interference

Both systems use LoRa (Chirp Spread Spectrum), where bandwidth, spreading factor (SF), and coding rate (CR) trade range for speed and airtime.^[11]

• Meshtastic defaults: The standard preset is LongFast, which (in US) uses 250 kHz bandwidth and a conservative SF/CR mix. It's robust, but airtime per message is relatively high, especially over multiple hops.^[12][13]
  NOTE: You can switch Meshtastic to faster presets (e.g., MediumFast/ShortFast) or even custom narrow bandwidths; Meshtastic supports special narrow values like 31.25 kHz and 62.5 kHz when manually configured.^[14]
• MeshCore defaults: In the US, the default preset is a narrower bandwidth (62.5 kHz) with moderate SF/CR to slot between noisy parts of the US 902–928 MHz ISM band, improving SNR and airtime efficiency while maintaining city-scale coverage.^[15][17]

In real Austin-area testing, the narrower default MeshCore configs have produced noticeably snappier delivery (often sub-second for nearby peers, and sub-2 second for 9 hop routes) compared to default Meshtastic presets. Your mileage will vary by terrain, antenna quality, and infrastructure density, but the airtime math generally favors higher data rates + less background traffic.

When to use which

• Choose Meshtastic if you want a "bring-a-radio, it just works" experience for roaming groups, mapping, and rich telemetry modules, with minimal setup and no guaranteed infrastructure.
• Choose MeshCore if your aim is a resilient, city or region scale messaging network with fixed repeaters, where end-users don’t rebroadcast by default.

Quick comparison

Footnotes

1. Meshtastic uses Managed Flood Routing for broadcast messages to avoid heavy route maintenance on low-bandwidth radios. Meshtastic blog: “Why Meshtastic Uses Managed Flood Routing.” link ↩ ↩
2. Meshtastic v2.6 adds next-hop routing for Direct Messages (DMs): flood to discover, then optimized relays. Docs (“Mesh Algorithm”) & 2.6 preview post. Docs: link · Blog: link ↩ ↩
3. MeshCore flood-then-direct routing: flood to learn → embed path → fallback to flood if direct fails. (Concept pages & explainer.) Deep dive: link · Packet handling: link · Explainer: link ↩ ↩
4. Device roles — default role is CLIENT; CLIENT “rebroadcasts packets when no other node has done so.” Meshtastic Device Configuration. link ↩
5. “Repeaters route; edge nodes don’t pollute the airwaves.” MeshCore Philosophy. link ↩
6. Companion Radio Protocol (USB/BLE) connects apps to radios; it is an edge/client firmware, not a repeater. MeshCore Wiki. link ↩
7. Repeater/Room Server CLI (e.g., set repeat on, set flood.max {hops}, set advert.interval {minutes}, set flood.advert.interval {hours}). MeshCore Wiki. link ↩ ↩
8. Max Hops defaults to 3 and “can’t be greater than 7.” Meshtastic LoRa Configuration. link ↩
9. MeshCore internal max hop limit = 64. MeshCore Wiki (FAQ). link ↩
10. Regular broadcast intervals (defaults) and auto-backoff as meshes grow. Meshtastic “Mesh Algorithm” overview. link · Telemetry module reference: link ↩
11. LoRa = Chirp Spread Spectrum (CSS); SF/BW/CR drive data rate vs. range/airtime. Semtech AN1200.22 “LoRa Modulation Basics.” link ↩
12. Meshtastic modem presets (LongFast, MediumFast, ShortFast, etc.). Protobuf enum docs. link ↩
13. Comparative preset table (BW, SF, approximate kbps) and why LongFast isn’t ideal for dense meshes. Meshtastic blog. link ↩
14. Special bandwidth values supported in Meshtastic custom modem settings (e.g., 31.25 kHz, 62.5 kHz). Meshtastic LoRa Configuration. link ↩
15. MeshCore docs note that narrower BW + lower SF can fit between ISM-band interference and yield better SNR/airtime. MeshCore FAQ. link ↩
16. MeshCore communities commonly configure long flood-advert intervals (e.g., ~12 h) to conserve airtime; tooling and issues reflect this direction. CLI reference (adverts): link · Issue: link · FAQ note: link ↩
17. Example community settings (US/CAN): 910.525 MHz, 62.5 kHz BW, SF7/CR5. Ottawa Mesh. link ↩
18. Meshtastic docs caution against over-using infrastructure roles and hop counts on dense meshes; a network of CLIENTs with a small number of well-placed ROUTER/REPEATERs is usually best. Configuration Tips. link ↩

Questions or edits? Open a PR on austinmesh.org’s repo or ping the Austin Mesh chat.