Tracing Packets from Your Node

Your own node is the first place to look, and the MeshCore app has more diagnostic power in it than most people ever use. Between them, these tools can prove your radio transmits, prove it receives, and tell you exactly which hop in a route is failing, all without leaving your phone.

For the click-by-click steps for each tool, see MC Client Tools in the Newbie Guide. This page is about which tool to reach for when something is broken, and what its output actually proves.

All of these live under ⋮ → Tools in the app.

Contents

Trace Path: the One That Matters Most

Trace Path is the closest thing MeshCore has to traceroute, and it is the single most useful tool on this page. It sends a real test packet along a route you specify and reports the SNR and latency at every hop.

Two things make it powerful for RX/TX work:

It is round-trip. The packet goes out and comes back. That means a successful trace to a node proves both directions at once: it heard you, and you heard it. One test, both halves of your radio confirmed.

It localizes the break. If a trace dies partway along a route, the last hop that reported back is the last node that heard the packet. The break is right there. You have gone from "messages don't work" to "the link between these two specific repeaters is down" in one step.

The simplest useful test: ping one repeater

Select a single repeater and trace to it. That performs a plain ping and reports SNR and round-trip time.

Do this against your nearest repeater before anything else. It is a 10-second test that eliminates half the possible causes.

Tracing a full route

To test a multi-hop path, add repeaters in the order you want the packet to travel, either by picking them from the list or tapping them on the map.

Paths must be round-trip. If the far end cannot hear you directly, you have to append the return route in reverse, for example 1A,34,56,F2,56,34,1A. This catches people out and looks like a failed trace when it is really a malformed one.

Read the per-hop SNR down the list and look for the point where it collapses. Anything below -5 dB SNR is a marginal link and is your prime suspect. Cross-reference the numbers with the SNR and RSSI tables.

That weak hop is what you take to Discord, or what you fix if the repeater is yours.

RX Log: Proving You Can Receive

RX Log is your definitive answer to "can I hear the mesh?" It shows a live feed of every packet your radio receives, with packet type, SNR and RSSI.

Open it and watch for two or three minutes.

Make sure there is actually traffic to hear before concluding your receiver is dead. The mesh is not busy at 3am. Ask someone in Discord to send a flood advert while you watch the log.

On a T-Deck, the built-in diagnostics screen does the same job. Each line reads:

{hops} l:{packet-length}({payload-len}) t:{packet-type} snr:{n} rssi:{n}

The t: field is the packet type. Watching for type 0x04 (ADVERT) is a good way to confirm you are hearing the mesh announce itself.

Noise Floor: Finding Interference

A live dBm chart of the RF noise your radio is sitting in. This is the tool that explains a node which "should" work but hears nothing.

Noise is intensely local. Walk around with this chart open. Switch-mode power supplies, USB chargers, LED drivers, computers and cheap wall warts are all common offenders, and moving a node a metre away from one can drop the noise floor by 20 dB.

Use this tool when siting a new node, not just when fixing a broken one. The lowest reading you can find is the best place to put it.

Discover Nearby Nodes

Sends a discovery request over LoRa and lists the nodes that answer, with their signal strength.

This is a fast "is anything out there?" check. If Discover returns nodes, you are within range of the mesh and both halves of your radio are working, because discovery requires a request out and a response back.

If it returns nothing, either you are genuinely out of range, or one half of your radio is down. Again, RX/TX triage splits the two.

"Repeats Heard": the Free TX Check

When you send a message, the app reports the repeaters that relayed it, listed as repeats heard.

This is a free, no-effort proof that your transmit path works. If repeaters are listed, your packet got out into the network and was forwarded onward. You do not need CoreScope to establish that. Anyone reporting "nobody can hear me" while seeing repeats heard on their messages is not, in fact, having a TX problem, and their real problem is somewhere else entirely.

Get in the habit of glancing at it.

From the Client CLI

Connect the node over USB and use config.meshcore.io in Chrome for the things the app does not expose.

get radio

Must return 910.525,62.5,7,5 for the Inland NW Mesh. Any other value and you are not on the network.

get tx

Your transmit power. Easy to leave low by accident. Most Heltec V3 and RAK boards run 14 to 22 dBm.

get public.key

Your node's identity. You need the first few hex characters of this to find yourself in CoreScope, so grab it now if you are heading that way next.

ver

Firmware version. Check it before reporting a problem, since plenty of reported bugs are already fixed upstream.

Where to Go Next

If your own node checks out and the problem is still there, widen the search: