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:
 
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.
 
Antenna check: Disconnect the antenna from the repeater and check for physical damage (bent connector, water ingress at connector). Re-connect securely.
 
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.
 
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
These commands are entered over the device's serial/terminal CLI (the same console used elsewhere in this book). The authoritative command reference is docs.meshcore.io/cli_commands — the commands below match it. A MeshCore repeater runs firmware on a microcontroller (nRF52840 or ESP32); there is no Linux shell or filesystem on the device, so only these serial CLI commands work.
# Show packet counters (received / sent):
stats-packets
# Show radio statistics (RSSI, SNR, airtime, RX errors):
stats-radio
# List nearby neighbors heard via advert, with SNR.
# Output is the 8 most recent adverts, each line encoded as
# {pubkey-prefix}:{timestamp}:{snr*4}  (SNR only, not RSSI):
neighbors
# Show core stats (battery, uptime, queue length, debug flags):
stats-core
# Print the captured RX log to the serial terminal.
# Use "log start" / "log stop" to control capture, then read it
# back and look for error lines:
log
MeshCore has no serial 
ping command and no per-node forced route-discovery command. To exercise routing to a specific destination, send a message to that contact from a client and observe whether a path establishes. Zero-hop neighbor discovery (on firmware that supports it) is 
discover.neighbors.
Power System Deep Diagnostics
Solar-powered repeaters frequently experience issues traced to power rather than RF:
# Check battery, uptime and queue length over the serial CLI:
stats-core
# On boards with power management, the last reset cause and boot
# voltage can be read (where supported by your firmware build):
get pwrmgt.bootreason
get pwrmgt.bootmv
# Low battery can cause a brownout during TX: the TX current spike
# drops voltage below the regulator minimum and the board resets.
# There is no Linux log file on the device to read; use stats-core
# (or an external voltage logger) to track voltage history.
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 a radio-init status line on the serial boot log. A successful SX1262 init is logged; an init-failure line or no radio status at all suggests a hardware problem. The exact wording varies by firmware version — check your boot log rather than searching for one fixed string.
 
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)