# MeshCore Repeater Diagnostics via Serial Console

The MeshCore serial console provides direct access to repeater state and diagnostic information. Connecting via USB to a deployed repeater is the most reliable way to diagnose problems that cannot be addressed remotely.

## Connecting to the Serial Console

On Windows: use PuTTY or the Arduino Serial Monitor. On Linux/Mac: use `screen` or `minicom` as a serial terminal.

```
# Linux/Mac
screen /dev/ttyUSB0 115200

# Windows (PuTTY): Connection Type = Serial, Speed = 115200, COM port varies
```

MeshCore boards use 115200 baud for the serial console, including RAK boards. (If you have configured an attached GPS module, that module's own UART may run at a different baud rate such as 9600 - but that is a separate interface from the console.)

## Key Diagnostic Commands

These are commands from the on-device MeshCore serial CLI (see docs.meshcore.io/cli\_commands). There is no single combined "status" command - health information is split across several `get ...` and `stats-...` commands.

<table id="bkmrk-commandoutputuse-for"><thead><tr><th>Command</th><th>Output</th><th>Use for</th></tr></thead><tbody><tr><td>`ver`</td><td>Firmware version</td><td>Confirm firmware build</td></tr><tr><td>`stats-core`</td><td>Battery voltage, uptime, queue depth</td><td>Overall health check</td></tr><tr><td>`get radio` / `get freq`</td><td>Radio config (frequency, bandwidth, SF, coding rate)</td><td>Verify radio settings match the network</td></tr><tr><td>`neighbors`</td><td>Up to the 8 most recently heard nodes, with timestamp and SNR</td><td>Verify which nodes are reaching this repeater</td></tr><tr><td>`stats-packets`</td><td>Packet counters: Received and Sent</td><td>Identify traffic/routing problems</td></tr><tr><td>`stats-radio`</td><td>Noise floor, last RSSI/SNR, airtime, receive errors</td><td>Signal quality of last received packet</td></tr><tr><td>`log`</td><td>Prints a captured rx log (must first be started with `log start`, stopped with `log stop`, cleared with `log erase`)</td><td>Capture and review received-packet activity</td></tr><tr><td>`reboot`</td><td>(restarts device)</td><td>Recover from hung state</td></tr></tbody></table>

Note: `contacts` and `list` are companion/client-side concepts, not repeater serial commands - on a headless repeater, use `neighbors` instead. The `log` command is a packet/rx capture you start and stop, not an always-on event log.

## Interpreting Stats Output

The `stats-packets` command is a useful diagnostic tool. The firmware exposes Received and Sent counters. A healthy repeater shows:

- **Sent count tracking received traffic** - the repeater is relaying packets it is meant to forward. (The documented counters are Received and Sent; there is no separate "forwarded" or "dropped" counter, so judge activity from the Sent counter rising alongside Received rather than from a "forward rate" metric.)
- **Drops in MeshCore** - MeshCore drops a flood packet when it exceeds the `flood.max` hop ceiling (default 64), and its loop detection (`loop.detect`) drops a packet whose path shows this repeater's own ID/hash repeated. This is not a Meshtastic-style per-packet hop counter decrementing to zero. In MeshCore's path-based routing, a repeater also intentionally does *not* retransmit packets whose embedded path does not include it - these appear as non-forwarded traffic but are correct behavior, not a loop. Distinguish this selective non-forwarding from a genuine duplicate-flood loop before acting.
- **Increasing received count over time** - Confirms the repeater is hearing traffic from the network

## Common Issues and Diagnostics

<table id="bkmrk-symptomcheckfix-rece"><thead><tr><th>Symptom</th><th>Check</th><th>Fix</th></tr></thead><tbody><tr><td>Received count stays at zero</td><td>Check antenna connection, verify radio settings match network</td><td>Reconnect antenna; verify radio parameters with `get radio` and `get freq` (frequency, bandwidth, SF, coding rate) and confirm they match the USA/Canada preset values shown in the app</td></tr><tr><td>Sent count zero despite receives</td><td>Verify device is running repeater firmware variant and that forwarding is enabled</td><td>Reflash with repeater firmware; confirm `set repeat on`</td></tr><tr><td>Battery voltage declining</td><td>Check solar panel output, charge controller LVD setting</td><td>Clean panel, verify charge controller settings</td></tr><tr><td>Rebooting frequently</td><td>Check for low battery voltage causing brownout</td><td>Size battery correctly; check charge controller</td></tr><tr><td>Not appearing in client node list</td><td>Repeater may not be sending flood adverts; check the flood advert interval with `get flood.advert.interval`</td><td>Send a flood advertisement with `advert` and confirm a flood advert interval is set, e.g. `set flood.advert.interval 12` (hours). Zero-hop adverts (`advert.zerohop` / `set advert.interval`) are local only. There is no `advert_hops` parameter.</td></tr></tbody></table>