Troubleshooting Guide
- My node cannot connect to others
- My messages are not getting through
- My battery drains too fast
- My solar node keeps going offline
My node cannot connect to others
Work through these checks in order.
- Verify antenna is connected. Most common cause. Never transmit without an antenna attached - it can permanently damage the radio's power amplifier (the PA, the transmit chip).
- Verify modem preset matches. Two nodes on different presets are invisible to each other. On Meshtastic, check the Meshtastic app - Radio Config - LoRa - Modem Preset; on MeshCore, check the radio/preset settings in the MeshCore app. Ask your local community which preset they use.
- Verify channel name and PSK match. Wrong credentials mean your messages are encrypted to a key nobody else has. Verify against local network documentation.
- Verify frequency band. US/Canada = 915 MHz hardware. EU = 868 MHz hardware. These cannot interoperate. Many AliExpress boards ship as 868 MHz by default.
- Check if other nodes are in range. Meshtastic users: visit meshmap.net to see nearby nodes. MeshCore users: use the MeshCore map at map.meshcore.io. In rural areas you may genuinely be out of range.
- Verify the radio is transmitting. Check for LoRa init errors in the serial console. A working node shows increasing packet counts in the app.
- Factory reset and reconfigure. If all else fails, reset and start configuration fresh.
My messages are not getting through
First: identify the failure mode
- Node visible in list but messages do not arrive: routing or range issue
- Node does not appear in list at all: preset, channel, or range issue (see previous page)
Hop limit too low
If your hop limit is set to 1, you can only reach nodes in direct radio range. Increase it (Meshtastic: Radio Config → LoRa → Hop Limit; default 3 is fine for most networks). Note: "hop limit" is the cap you set, while "hop count" is the number of hops a packet has already taken.
Network congestion
If channel utilization exceeds 25% (visible in Meshtastic app), collisions become more likely. 25% is a soft "green/optimal" ceiling rather than a hard collision cliff — Meshtastic firmware defers transmissions until channel utilization drops back below roughly 25%. Reduce your broadcast intervals for position and telemetry to ease congestion.
ACK failures
Meshtastic uses ACKs to confirm delivery. No ACK means the destination node may be offline or out of range. Check its last-heard timestamp. Important for life-safety traffic: a received ACK does not guarantee the intended recipient got the message. On a multi-hop path the ACK you see may be an implicit ACK from a relay rebroadcasting the packet, not a confirmation from the final destination. The mesh also has a hard shared-airtime ceiling with no message prioritization (no QoS), so urgent traffic competes with everything else and congestion spikes exactly when volume rises. For any critical message, require an explicit human reply rather than trusting the ACK indicator.
Recently joined node
New nodes may not have propagated throughout the mesh yet. Wait 5-10 minutes after joining before expecting full connectivity.
MeshCore specific
MeshCore requires successful route discovery before first contact. If intermediate repeaters are offline, the route cannot be established. Check that all repeaters in the expected path are online.
My battery drains too fast
Step 1: Measure actual power draw
Use a USB inline power meter to measure real current draw. This immediately shows whether you have a software config problem or a hardware issue.
Expected draw by hardware
The figures below are approximate field measurements and vary with firmware, settings, and transmit duty cycle - measure your own device for an accurate number.
| Hardware | Typical active draw (approximate) |
|---|---|
| ESP32 (T-Beam, Heltec), no display, no BT | ~40-55 mA |
| ESP32 with OLED display on | +10-20 mA |
| nRF52840 (RAK4631, T-Echo, T114) | ~8-15 mA |
Power drain checklist
- Screen on all the time? Set a short screen timeout (e.g. 10-30 seconds) so the display sleeps. Note: a timeout of 0 usually means never sleep - avoid it on battery.
- Bluetooth enabled? Disable if not needed.
- GPS polling? Disable or set a long interval.
- WiFi enabled (ESP32)? Disable.
- Position broadcast interval too short? Set to 30+ minutes on battery.
Battery sizing
Battery (mAh) divided by draw (mA) = hours of runtime. 1000 mAh at 40 mA = 25 hours; at 10 mA = 100 hours. Switching from ESP32 to nRF52840 hardware typically gives roughly 4x longer life on the same battery (approximate; the exact ratio depends on your settings and usage).
My solar node keeps going offline
Systematic diagnosis in order of likelihood:
- Undersized battery or panel. Goes offline at night or on cloudy days? Review the Solar System Sizing Guide and resize.
- Panel obstruction. Bird droppings, snow, or vegetation growth. Verify the panel is clean with clear sky access.
- Charge controller LVD setting. If the low-voltage disconnect threshold is too high, the controller cuts power while charge remains. For LiFePO4, 3.0V/cell (12.0V for a 12V system) is a conservative LVD; the typical BMS cutoff is lower (~2.5V/cell, ~10V). Set the LVD per your specific battery and charge-controller specification.
- Water ingress. Goes offline after rain = water ingress. Inspect all cable glands, connector weatherproofing, and enclosure seals.
- Thermal shutdown. Sealed enclosures in direct sun can exceed safe operating temperatures (often reported in the 70-80 degrees C range internally). Add venting, shading, or a radiation shield.
- Firmware hang. Check for firmware updates. Enable hardware watchdog if supported.
- Remote monitoring. Watch battery voltage trend via Meshtastic telemetry. Declining trend = insufficient harvest. Sudden drop to zero = hardware failure.