Skip to main content
Pitch In Subscribe

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

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 detailed packet statistics:counters stats(received detail/ sent):
stats-packets

# Show allradio statistics (RSSI, SNR, airtime, RX errors):
stats-radio

# List nearby neighbors heard nodesvia andadvert, theirwith lastSNR.
SNR/RSSI:# repeatersOutput verboseis the 8 most recent adverts, each line encoded as
# {pubkey-prefix}:{timestamp}:{snr*4}  (SNR only, not RSSI):
neighbors

# Show freecore memorystats (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 uptime:look sysinfofor #error Forcelines:
alog
route

MeshCore has no serial ping command and no per-node forced route-discovery command. To exercise routing to a specific node:destination, #send (Usea thismessage to testthat ifcontact the repeater can route tofrom a specificclient destination)and pingobserve !targetNodeIdwhether #a Checkpath ifestablishes. Zero-hop neighbor discovery (on firmware hasthat panicsupports logs:it) logsis errorsdiscover.neighbors.

Power System Deep Diagnostics

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

# Check voltagebattery, historyuptime ifand loggingqueue islength enabled:over the serial CLI:
stats-core

# On Pi-basedboards systems, checkwith power monitoringmanagement, data:the catlast /var/log/power-monitor.logreset |cause tailand -100boot
# Check if voltage dipscan correlatebe withread transmission(where events:supported by your firmware build):
get pwrmgt.bootreason
get pwrmgt.bootmv

# Low battery maycan cause a brownout during TXTX: (the TX current spike
# drops voltage below #the regulator minimum,minimum causingand athe reset)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 radioa radio-init status line on the serial boot.boot "log. A successful SX1262 OK"init confirmsis thelogged; radioan chipinit-failure initialized. "SX1262 FAIL"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)
Back to top