# 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 the preset directly on each node:

```
meshtastic --get lora.modem_preset   # run this on each node
```

Both nodes must report 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 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) uses the well-known default PSK `AQ==` (a publicly known, weak key) - it is *not* an empty/no-encryption 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](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app), check if the node appears in the node list with any RSSI/SNR value. Do not assume a low or negative SNR means a bad link: LoRa decodes well below the noise floor, with per-spreading-factor demodulation limits running from about −7.5 dB (SF7) to about −20 dB (SF12). At Long Fast / Long Slow, an SNR of −10 to −18 dB 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 SX1262 is sensitive to roughly −137 dBm at SF12). If the 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 (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 a traceroute confirms the path genuinely needs more hops, raise it incrementally (for example to 4) and monitor channel utilisation:

```
meshtastic --set lora.hop_limit 4
```

See [Hop Limit Configuration for Repeaters](/books/meshtastic-repeaters/page/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)](/books/meshtastic-repeaters/page/designing-for-reliability-n1-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 (902-928 MHz) antenna in North America. An 868 MHz antenna will radiate at 915 MHz but with a 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.