Recommended Settings

These are community-proposed defaults — not official Meshtastic project defaults, and not a substitute for current firmware documentation. Where a setting depends on firmware behavior that changes over releases, that’s called out explicitly.

The interval and role guidance below starts from values other Meshtastic community networks have already field-tested, adapted as a baseline for Puerto Rico. They’re a starting point, not a finished PR-specific recommendation — expect these numbers to get tuned as more Puerto Rico operators report back on what actually works for our terrain and mesh density.

Region and Frequency

Meshtastic requires every device to declare a LoRa region, which sets the legal frequency band, power limits, and duty cycle for where the radio operates. Verified

meshtastic --set lora.region US

Puerto Rico falls under United States frequency allocation for the unlicensed ISM band that Meshtastic uses. Set your region accordingly, and confirm against the official Meshtastic region list — this list is maintained upstream and is the authoritative source, not this page.

Do not guess a region or copy one from another country’s community. An incorrect region setting can transmit outside legal limits and won’t reliably talk to correctly-configured local nodes.

Region isn’t the only thing that sets your frequency. The primary channel’s name hashes to a frequency slot, so renaming it, reordering channels, or importing a channel QR can silently move a node off the regional frequency — see The Channel You Moved Wasn’t a Channel — It Was Your Frequency for how that happens and when to pin lora.channel_num on purpose.

Node Roles

Choosing the right role matters more for the health of the shared mesh than almost any other setting.

meshtastic --set device.role CLIENT

Proposed — mobile/handheld nodes default to Client Mute; home nodes default to Client; a rooftop node relaying mainly for your own gear should run Client Base with your indoor nodes favorited, not Router Late; Router/Router Late reserved for rooftop or ridge sites confirmed to extend coverage, agreed on with other local operators first.

For the full reasoning behind Client Base vs. Router Late — including why a rooftop set to Router Late usually adds congestion instead of coverage — see Puerto Rico’s Mesh Has No Backbone.

If a site genuinely does qualify as infrastructure, the next question is which of the three infrastructure roles it should run — ROUTER preempts its neighbors, ROUTER_LATE never does, and REPEATER is invisible to the nodes list, the map, and traceroute. See Router, Router Late, or Repeater.

Max Hops

A node can’t transmit and receive at the same time — every hop a message takes is airtime every other node has to wait through. The hop limit caps how many times a message can be relayed before the mesh gives up on it (see Hops). Higher isn’t safer; it just means a lost or looping packet burns more shared airtime before it’s dropped.

meshtastic --set lora.hop_limit 3

Proposed — never go higher than 5. A node set to 6+ “just in case” doesn’t get better reach, it just makes every failed delivery more expensive for the whole mesh.

Favoriting Nodes

Favorites aren’t just a shortcut in the app’s node list — on the roles above, they change how two separate mechanisms behave. Both key off the same favorites list, but on different fields, so it’s worth being deliberate about who you favorite and why.

• Client Base’s priority relaying looks at who a packet is from or to. On a rooftop Client Base node, favorite your own indoor gear — handhelds, base radio — so their traffic gets first priority through the one radio that actually has a clear view of the sky.
• Zero-Cost Hops (firmware 2.7.11+) looks at which node relayed the packet just before you. It preserves the hop counter when that previous relay is a favorited Router or Router Late. Favorite the legitimate infrastructure Router/Router Late sites near you so their traffic doesn’t burn one of its seven hops just crossing your roof on the way in.

Favoriting a Router does not turn a Client Base node into something that repeats all of its traffic — that’s the first mechanism’s job, and it only applies to your own favorited gear. The two lists overlap in the UI but not in effect.

meshtastic --set-favorite-node !a1b2c3d4

Same action is available in the app: long-press a node in the node list → Favorite.

Proposed — on a Client Base rooftop node: favorite every node you own that lives indoors, plus any legitimate local Router/Router Late sites, then run a traceroute before and after to confirm it actually changed the path.

Broadcast Intervals

How often a node announces its position and telemetry directly trades off freshness against airtime — every broadcast is airtime every other node has to wait through. The baseline below uses smart-position broadcasting for mobile nodes (send on movement, not just on a timer) and long, lean intervals for anything stationary.

For why a fixed rooftop node on default timers quietly degrades everyone’s range, and how to walk each interval out to the baseline, see Your Stationary Node Is Talking Too Much.

# Mobile nodes
meshtastic --set position.position_broadcast_secs 3600
meshtastic --set position.gps_update_interval 300
meshtastic --set position.broadcast_smart_minimum_distance 100
meshtastic --set position.broadcast_smart_minimum_interval_secs 60
meshtastic --set position.position_broadcast_smart_enabled true
meshtastic --set telemetry.device_update_interval 3600
meshtastic --set telemetry.environment_update_interval 3600

# Stationary nodes
meshtastic --set position.position_broadcast_secs 43200
meshtastic --set position.gps_update_interval 21600
meshtastic --set position.position_broadcast_smart_enabled false
meshtastic --set telemetry.device_update_interval 21600
meshtastic --set telemetry.environment_update_interval 21600
meshtastic --set telemetry.power_update_interval 3600

Proposed — a field-tested starting baseline, not yet re-tuned for Puerto Rico’s terrain or mesh density. Coordinate with nearby operators before broadcasting more frequently than this on a shared channel.

# Mobile
meshtastic --set position.position_flags ALTITUDE,ALTITUDE_MSL,SPEED,HEADING,SATINVIEW

# Fixed
meshtastic --set position.position_flags ALTITUDE,ALTITUDE_MSL,GEOIDAL_SEPARATION
meshtastic --set position.fixed_position true

Neighbor Info

Neighbor Info lets a node report which other nodes it can directly hear, along with signal quality — this is what turns the mesh from a black box into something you can actually visualize and debug. Enabling it on stationary and rooftop nodes helps build a real picture of Puerto Rico coverage over time (see Puerto Rico Mesh).

Requires Meshtastic app/firmware 2.2.0 or newer. Enable both the module and “Transmit Over LoRa” — the iOS app can’t currently configure this module, so use the web client or CLI instead.

meshtastic --set neighbor_info.enabled true
meshtastic --set neighbor_info.transmit_over_lora true
meshtastic --set neighbor_info.update_interval 39600   # 11h, stationary — use 14400 (4h) for mobile

Impact on channel congestion is minimal at these intervals — enable it, but don’t set it aggressively low on relay-heavy nodes. Proposed

MQTT

MQTT is a way to bridge mesh traffic to the internet — a node with an internet connection can publish what it hears to an MQTT server, which lets tools like coverage dashboards and node maps show mesh activity without every viewer needing their own radio.

This is separate from the radio mesh itself. Two Meshtastic nodes with no internet access at all can still talk to each other over LoRa — that’s the whole point of the network, and it keeps working through internet and cell outages regardless of MQTT. MQTT only affects whether that activity is also visible online. It carries diagnostic metadata — position, battery, signal metrics, channel utilization — not the content of encrypted channels or private messages.

If you do bridge a node to MQTT, settings matter beyond the broker credentials themselves.

For a step-by-step walkthrough of the whole chain — root topic, OK to MQTT, uplink-only, and the position settings that decide whether you show up at all — see Getting Your Node Onto the Puerto Rico Mesh Map.

If you run your own MQTT bridge, treat the credentials the same as any other server login: don’t reuse them, and don’t commit them to a public repo or config export.