Skip to main content
Pitch In Subscribe

Diagnosing Meshtastic Network Problems

This guide covers systematic diagnosis of common Meshtastic network issues: nodes that can't hear each other, poor range, network congestion, and routing failures.

Diagnostic framework

Work from the bottom up: radio layer first, then routing, then application.

  1. Radio layer: Can the nodes physically hear each other? Check RSSI/SNR.
  2. Configuration: Are both nodes on the same preset and channel?
  3. Routing: Is the path between nodes working? Use Trace Route.
  4. Application: Is the app connected properly? Is the message actually sending?

Problem: Two nodes can't communicate

Check 1: Same preset?

Nodes on different presets cannot hear each other. Verify:Verify the preset directly on each node:

meshtastic --nodesget lora.modem_preset   # Checkrun modem_presetthis inon theeach outputnode

Both nodes must showreport the same preset (e.g., LONG_FAST or MEDIUM_SLOW). You generally cannot read a remote node's modem preset from a node-list dump - check each node on its own connection. If different:they differ: change one to match the other.

Check 2: Same channel and PSK?

Nodes must be on the same channel with the same PSK. The default public channel (LongFast) hasuses the well-known default PSK AQ== (a publicly known, weak key) - it is not an emptyempty/no-encryption PSK.key. If you've customized your channel, the other node needs the same configuration.

meshtastic --info # Shows channel list with PSK hashes

PSK hash mismatch = nodes won't communicate even if physically in range.

Check 3: Physical range and line of sight

In the Meshtastic app, check if the node appears in the node list with any RSSI/SNR value. IfDo itnot appearsassume a low or negative SNR means a bad link: LoRa decodes well below the noise floor, with RSSIper-spreading-factor <demodulation limits running from about −1207.5 dBmdB or(SF7) to about −20 dB (SF12). At Long Fast / Long Slow, an SNR <of −10 dB,to the−18 signaldB is routinely decodable, not "at the noise floor." A link only becomes marginal as SNR approaches the per-SF demod limit (for example below about −17 dB at SF11/Long Fast), or as RSSI approaches the receiver sensitivity floor -(the unreliableSX1262 communication.is sensitive to roughly −137 dBm at SF12). If itthe node doesn't appear at all, no packets are being received.

Test: bring both devices to within 100 feet of each other (no obstacles). If they communicate at that distance, it's a range/obstruction problem. If they still can't communicate at 100 feet, it's a configuration problem.

Problem: Intermittent message delivery

Check: Hop count

Messages requiring more hops have higher failure rates. Check your hop limit setting:

meshtastic --get lora.hop_limit

Default is 3.3 (the maximum is 7). Before raising it, verify with a traceroute that the path actually needs more hops. Raising hop_limit increases airtime and channel utilisation and can worsen congestion rather than fix dropped messages — the preferred fix for a long path is usually to add infrastructure to shorten it. If messagesa aretraceroute beingconfirms droppedthe acrosspath longgenuinely paths,needs trymore increasinghops, raise it incrementally (for example to 5:4) and monitor channel utilisation:

meshtastic --set lora.hop_limit 54

See Hop Limit Configuration for Repeaters for the full caveats on high hop counts and channel utilisation.

Check: Network congestion

In dense networks (20+ nodes), Long Fast preset can cause congestion. Symptoms: high message drop rate even with good RSSI, large delays. Solution: migrate to Medium Slow or Medium Fast preset. Requires coordination with all network participants - all nodes must change at the same time.

Check: Router node availability

If a critical router node goes offline, messages that depended on that path fail. This is a design red flag, not just a diagnostic finding: if a single router node failing kills delivery for part of your network, that node is a single point of failure — see Designing for Reliability (N+1 Redundancy). For emergency use, no incident-critical route should depend on one node. Use Trace Route before and after to confirm the path change:

meshtastic --traceroute !nodeId

Problem: Poor range from a new repeater

  1. Antenna connected? An unconnected antenna transmits into the PCB and can damage the radio front-end. Verify the antenna is finger-tight. Some boards have a separate BLE antenna and LoRa antenna - ensure both are connected.
  2. Correct antenna type? Most boards use SMA or u.FL connectors. Verify your antenna has the correct connector type and is rated for your operating band - use a 915 MHz.MHz (902-928 MHz) antenna in North America. An 868 MHz antenna will workradiate at 915 MHz but atwith reduceda efficiency.shifted resonance and elevated VSWR; for a broadband whip the penalty is usually small (a fraction of a dB), but for a narrowband tuned antenna the loss and reflected power can be significant, and high VSWR stresses the power amplifier. Note that antenna gain also bears on legal power limits — antennas over 6 dBi require a dB-for-dB reduction in conducted power per FCC 47 CFR 15.247(b)(4).
  3. TX power set correctly? Check that TX power hasn't been set to an unusually low value: meshtastic --get lora.tx_power
  4. Obstructions: Even a metal enclosure, HVAC equipment, or tree canopy directly around the antenna can reduce range significantly. Test with the antenna in the clear before committing to a location.
Back to top