Skip to main content

Advanced MeshCore Repeater Diagnostics

When basic troubleshooting hasn't resolved a repeater issue, these advanced diagnostic techniques help identify hardware failures, RF problems, and protocol-level issues.

Systematic RF Path Verification

Before concluding a repeater has failed, verify the RF path independently:

  1. Local RF check: Bring a test node within 1 meter of the suspect repeater. Can it hear the repeater's transmissions? If yes, the repeater is transmitting. If no, the repeater may not be transmitting.
  2. Antenna check: Disconnect the antenna from the repeater and check for physical damage (bent connector, water ingress at connector). Re-connect securely.
  3. Cable check: If using a remote antenna with coax, check the cable for damage, kinks, or water ingress at connectors. Substituting a known-good short cable bypasses cable issues.
  4. SWR check: If you have a NanoVNA, check antenna SWR. A sudden SWR change vs. baseline indicates antenna or cable change (ice loading, lightning damage, physical damage).

Firmware Diagnostic Commands

# Show detailed packet statistics:
stats detail

# Show all heard nodes and their last SNR/RSSI:
repeaters verbose

# Show free memory and uptime:
sysinfo

# Force a route discovery to a specific node:
# (Use this to test if the repeater can route to a specific destination)
ping !targetNodeId

# Check if firmware has panic logs:
logs errors

Power System Deep Diagnostics

Solar-powered repeaters frequently experience issues traced to power rather than RF:

# Check voltage history if logging is enabled:
# On Pi-based systems, check power monitoring data:
cat /var/log/power-monitor.log | tail -100

# Check if voltage dips correlate with transmission events:
# Low battery may cause brownout during TX (TX current spike drops voltage below
# regulator minimum, causing a reset)

Signs of power-related resets:

  • Repeater uptime counter resets during evening/night hours (low SOC)
  • Resets correlate with high-traffic periods (many TX events = high current draw)
  • Stable operation after adding a larger battery or bypass capacitor at the node power input

Isolating Radio Hardware Failure

If you suspect the SX1262 radio chip has failed:

  • Verify SPI communication: Most MeshCore firmware reports radio init status on serial boot. "SX1262 OK" confirms the radio chip initialized. "SX1262 FAIL" or no radio status = hardware problem.
  • Substitution test: Swap the suspect board with a known-good board. If the problem follows the board, it's a hardware failure.
  • Visual inspection: Check for cold solder joints on the LoRa module, corrosion on SPI pins, or physical damage to the radio module.

When to Declare Hardware Dead

Replace the hardware rather than continuing to debug when:

  • The board fails to initialize the radio after firmware reflash
  • The board has confirmed water ingress damage (corrosion on PCB, discolored/burned SMD components)
  • The board passes diagnostics but still fails in production consistently after replacing all external factors (antenna, cable, power)
  • The cost of continued debug time exceeds the cost of a replacement board ($30-60)

No comments to display

Back to top