RX/TX Diagnostics: Start Here

Your radio is powered on, it is paired to the app, and the settings look right. But messages are not getting through.

The mistake almost everyone makes at this point is to treat "it's not working" as one problem. It is two. Transmit and receive are separate paths and they fail independently. A node can be shouting into the void while hearing everything perfectly, or hearing nothing while the rest of the mesh sees it just fine.

Until you know which half is broken, every fix you try is a guess. This page tells you how to find out in about five minutes.

Before you start: if you have not already, work through the hardware and quick fixes on the main troubleshooting page. Loose antennas and unpaired Bluetooth account for most reports, and this page assumes you are past them.

Contents

The Tool Map

You have three vantage points on a packet, and each one proves something the others cannot. Knowing which tool answers which question is most of the battle.

Vantage point Tool What it proves
Your node Trace Path Round-trip to a node, with SNR at every hop. Proves TX and RX at once, and localizes a broken link.
Your node RX Log You can receive. Also proves your radio settings are correct.
Your node Noise Floor Whether local interference has made you deaf.
Your node "Repeats heard" Your packet got out and was relayed. A free TX check on every message you send.
A repeater stats-radio Its noise floor, last RSSI/SNR, and receive errors.
A repeater neighbors Who it can actually hear. An empty list means it is deaf.
A repeater log start A full capture of everything it received. The tool for intermittent faults.
The network CoreScope Which repeaters heard your packet, in what order, at what signal strength. Where it actually went.

The rest of this page tells you which of these to pick up first.

The Two Questions

Everything reduces to these:

  1. Can the mesh hear me? That is your TX path.
  2. Can I hear the mesh? That is your RX path.

Answer both, then find yourself in the results table further down.

                    Can the mesh hear you?  (check CoreScope)
                         YES                    NO
                    ┌──────────────────┬──────────────────┐
   Can you      YES │   TX ok, RX ok   │  TX bad, RX ok   │
   hear the         │  Not a radio     │  "They can't     │
   mesh?            │  problem         │   hear me"       │
   (check       ────┼──────────────────┼──────────────────┤
   RX Log)      NO  │  TX ok, RX bad   │  TX bad, RX bad  │
                    │  "I hear         │  Antenna, or the │
                    │   nothing"       │  radio itself    │
                    └──────────────────┴──────────────────┘

Answering "Can They Hear Me?" (TX)

The quick test: send a message and look at repeats heard. If the app lists repeaters that relayed it, your packet got out. Done, TX works. Most people never look at this field and it answers the question for free.

The thorough test: send a flood advert from the app, wait 60 seconds, then look for your node's public key prefix in CoreScope.

Find your prefix with get public.key, or from the identity screen in the app. Then filter the CoreScope packet browser on it. Full instructions are on Using CoreScope.

Answering "Can I Hear Them?" (RX)

The test: open ⋮ → Tools → RX Log in the MeshCore app and watch for 2 or 3 minutes. On a T-Deck, use the built-in diagnostics screen instead. See Tracing Packets from Your Node.

The mesh is not always busy. Before concluding your RX is dead, make sure there is actually traffic to hear. If you are unsure, ask someone on Discord to send a flood advert while you watch.

Or answer both at once

Trace Path to a single nearby repeater is round-trip, so if it comes back you have proven TX and RX in one 10-second test. If it times out you have proven nothing yet, and you still need the two separate tests above to work out which half failed. It is the fastest possible way to pass this triage, just not to fail it.

Read Your Result

TX ok, RX ok: it is not a radio problem

Both halves of your radio work. Your problem is above the radio layer: routing, a stale path, or a clock.

This is the most common outcome for "it worked yesterday and now it doesn't", and the usual culprit is a stale stored path. MeshCore remembers the route to each contact and keeps using it until it breaks; when a repeater in that route goes away, your messages keep marching into a dead end. Clearing the path forces a fresh route discovery.

Go to: How Routing Actually Works, then scenarios 2, 3 and 4.

TX bad, RX ok: "I can hear them but they can't hear me"

You are receiving fine, so your antenna is connected and your frequency is correct (see the shortcut below). That narrows it a lot. Work through, in order:

  1. TX power. Check get tx. It is easy to leave this at a low value. Most Heltec V3 and RAK boards run 14 to 22 dBm.
  2. Duty cycle. A node that has hit its duty-cycle limit stops transmitting but keeps receiving, which produces exactly this symptom. Check get dutycycle.
  3. Antenna damage or high SWR. A bad antenna hurts transmit far more than receive, because reflected power has nowhere to go. A node with a damaged antenna or pigtail will often still hear the mesh while failing to reach it. Inspect both ends of the pigtail.
  4. You are simply too far out. Receiving a strong repeater does not mean it can hear your much weaker signal back. See scenario 6.

TX ok, RX bad: "I hear nothing"

The mesh can see you, so you are transmitting and on the right frequency. You have gone deaf. Almost always this is interference, not a fault:

  1. Check the noise floor. In the app, Tools → Noise Floor. On a repeater, stats-radio. Above -100 dBm means heavy local interference and your radio can no longer pull weak, distant signals out of the noise.
  2. If you are near a strong RF source (a cell tower, a TV transmitter, busy WiFi), the SX1262's automatic gain control can latch and stop hearing LoRa entirely. This is a known failure mode with a cheap fix: 
    set agc.reset.interval 4

    See Diagnosing Deafness.

  3. Move the node. Away from switch-mode power supplies, USB chargers, LED drivers, and computers. Noise floor is intensely local, and a metre can matter.

TX bad, RX bad: the radio is not on the network

Nothing in, nothing out. This is the easiest of the four to fix because the causes are few and blunt:

  1. The antenna. Loose, missing, wrong band (a 2.4 GHz WiFi antenna will not work at 915 MHz), or a broken pigtail. This is the number one cause. Never power a LoRa board with no antenna attached.
  2. The radio settings. Run get radio. It must return exactly 910.525,62.5,7,5. Any other value and you are not on the Inland NW Mesh at all, you are on a network of one. Fix and reboot: 
    set radio 910.525,62.5,7,5
reboot
  3. The firmware. Confirm you flashed Companion firmware for a client, or Repeater firmware for a repeater, and that you are using the MeshCore app rather than Meshtastic. They are different protocols and will never talk to each other.
  4. The board. If all of the above check out, reflash from flasher.meshcore.io and, failing that, suspect the hardware.

The Shortcut Nobody Tells You

Here is the deduction that saves the most time, and it falls straight out of the table above:

If you can receive, your frequency and modulation settings are correct.

You cannot hear a LoRa packet unless your radio is listening on the right frequency, bandwidth, spreading factor and coding rate. So the moment you see packets in your RX Log, you have proven your radio config matches the network, and you can stop checking it. The same works in reverse: if your packets show up in CoreScope, your settings are right.

This matters because "check your radio settings" is the advice everyone gives first, and it sends people round in circles re-reading a config that was never wrong. One glance at the RX Log rules it out for good and points you at the antenna, the power, or the path instead.

Where to Go Next