# 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](https://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)