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 variesMeshCore 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.
| Command | Output | Use for |
|---|---|---|
ver | Firmware version | Confirm firmware build |
stats-core | Battery voltage, uptime, queue depth | Overall health check |
get radio / get freq | Radio config (frequency, bandwidth, SF, coding rate) | Verify radio settings match the network |
neighbors | Up to the 8 most recently heard nodes, with timestamp and SNR | Verify which nodes are reaching this repeater |
stats-packets | Packet counters: Received and Sent | Identify traffic/routing problems |
stats-radio | Noise floor, last RSSI/SNR, airtime, receive errors | Signal quality of last received packet |
log | Prints a captured rx log (must first be started with log start, stopped with log stop, cleared with log erase) | Capture and review received-packet activity |
reboot | (restarts device) | Recover from hung state |
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.maxhop 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
| Symptom | Check | Fix |
|---|---|---|
| Received count stays at zero | Check antenna connection, verify radio settings match network | 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 |
| Sent count zero despite receives | Verify device is running repeater firmware variant and that forwarding is enabled | Reflash with repeater firmware; confirm set repeat on |
| Battery voltage declining | Check solar panel output, charge controller LVD setting | Clean panel, verify charge controller settings |
| Rebooting frequently | Check for low battery voltage causing brownout | Size battery correctly; check charge controller |
| Not appearing in client node list | Repeater may not be sending flood adverts; check the flood advert interval with get flood.advert.interval | 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. |