Network Troubleshooting 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. Radio layer: Can the nodes physically hear each other? Check RSSI/SNR. Configuration: Are both nodes on the same preset and channel? Routing: Is the path between nodes working? Use Trace Route. 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, 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 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 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. 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). TX power set correctly? Check that TX power hasn't been set to an unusually low value: meshtastic --get lora.tx_power 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. Repeater Performance and Maintenance A deployed repeater requires periodic attention to maintain performance. This page covers the key maintenance tasks and performance metrics for Meshtastic infrastructure nodes. Throughout, "infrastructure node" means the general concept; ROUTER and REPEATER refer to the specific device roles (which behave differently - a ROUTER appears in the node list, a REPEATER does not). Key performance indicators The targets below are recommended operational goals set by the author, not official Meshtastic or manufacturer specifications. Treat them as starting points, not hard specs. Metric Healthy range Action if outside range Node uptime >95% over 30 days (baseline only) >95% is a baseline health indicator, not a reliability guarantee - it still allows ~36 hours/month offline, and says nothing about when the downtime falls. For nodes an emergency operator depends on, investigate ANY unexplained downtime and treat repeated outages as disqualifying for sole-path infrastructure. Redundancy, not a high uptime number, is what guarantees coverage during an incident. Average RSSI to neighbors −70 to −100 dBm typical RSSI down to roughly −120 to −130 dBm can still be decodable depending on spreading factor (SX1262 sensitivity ~−137 dBm at SF12). Judge link health by SNR margin and packet success, not RSSI alone; a sudden RSSI drop versus a known baseline is the useful warning sign, not a fixed −110 dBm threshold. SNR to nearest neighbor SNR margin above the per-SF demod limit LoRa decodes well below 0 dB SNR - demod limits run from ~−7.5 dB (SF7) to ~−20 dB (SF12). What matters is SNR margin above the per-SF limit. For Long Fast (SF11, limit ~−17.5 dB), SNR down to about −12 dB is comfortable and approaching −17 dB is marginal. A backbone link at −10 to −12 dB SNR is normal and healthy, not a fault - do not treat SNR < 0 dB as "noise floor / unreliable." Battery voltage (solar) Depends on pack configuration State your battery configuration before reading these numbers. A single LiFePO4 cell has a working range of roughly 3.2 - 3.6 V; a 4S LiFePO4 pack is ~12.8 V nominal; a single Li-ion runs 3.0 - 4.2 V. Use the per-chemistry, per-configuration cutoff for your pack and align it with the cutoffs on the remote-monitoring page (e.g. ~11.5 V for a 12 V lead-acid pack, ~3.0 V per cell for LiPo). Repeated readings near the low end of your pack's range indicate an undersized power system. Packets forwarded per hour Varies by location Sudden drop to 0 = node possibly offline Routine maintenance checklist (quarterly) Check the node appears on a current community/third-party map (such as the official Meshtastic map or a community MQTT-based map) - verify the service is still live, as these third-party maps come and go. Note that a node set to the REPEATER role will not appear on node maps (it is hidden from the nodes list); a ROUTER will. These maps only show nodes reporting to a public MQTT server and are not authoritative. Verify RSSI/SNR to neighboring nodes hasn't significantly degraded versus your baseline Check battery voltage logs if monitoring - look for downward trend Inspect solar panel: clean off debris, verify no shading from new growth Check antenna connector for corrosion or loosening (especially after winter) Verify firmware version - update if significantly behind current release Check enclosure for water intrusion - condensation inside is an early warning sign Firmware update process for deployed nodes Flashing new firmware (reflashing the binary) on a deployed repeater requires physical USB/serial access. Configuration changes can be made remotely via Remote Admin over the mesh, but a firmware reflash cannot be done remotely. Prepare: Before taking ANY repeater offline for a firmware update, confirm an alternate path covers its users (run traceroutes from both sides). NEVER update the only repeater serving an area without a tested spare on hand or a deployed temporary relay - a failed flash can leave the firmware in a crash loop, knocking out coverage with no rollback. Bring a known-good spare and a copy of the prior firmware so you can roll back on-site if the flash fails. Schedule a maintenance window and notify the community (the node will be offline during update) Bring: laptop, USB cable for your device type, and the firmware binary or web browser access Before disconnecting: record current configuration (region, TX power, role, channel settings, position) with a restorable backup: meshtastic --export-config > config_backup.yaml. (Do not rely on meshtastic --info - that is only a human-readable status dump and cannot be re-imported.) Flash new firmware via web flasher (flasher.meshtastic.org) Verify settings after flash - firmware updates occasionally reset some settings to defaults Confirm node reappears on the network before leaving the site Common hardware failures Symptom Likely cause Fix Node gone offline after storm Water intrusion, lightning strike, blown fuse Inspect enclosure, check fuse, examine for burn marks on PCB Range suddenly reduced Antenna connector loosened or corroded Re-seat antenna, check connector for oxidation, replace if needed Frequent reboots Power supply instability (low battery/solar) Check battery voltage, check charge controller output Firmware crash loop Corrupted flash or incompatible firmware Factory reset and reflash BLE not discoverable BLE antenna loose (V3 only); software issue For V3: reseat u.FL BLE antenna. Otherwise reflash. When to replace vs. repair LoRa boards are inexpensive ($15 - 75). General guidance: Physical damage to SMA connector or RF front-end: replace board. Repair costs often exceed replacement. Software issue (firmware bugs, configuration corruption): reflash before considering hardware replacement. Battery degradation (LiFePO4): replace battery after 5+ years or when capacity drops below 70% of original. Solar panel degradation: typical panels lose 0.5% efficiency per year. Replace if output is more than 20% below original spec after 10+ years.