Why Mesh Packets Disappear

You’re watching Live Packets and a node goes quiet. It was active an hour ago. The other nodes around it are still reporting normally. No alarm fired, no error message appeared. The node is simply gone.

This is the signature of silent packet loss — the most common and most misdiagnosed problem in a LoRa mesh. Understanding why packets disappear, and which of the four possible causes is responsible, is what separates a network you’re watching from one you actually understand.

How LoRa mesh delivers — and loses — packets

MeshCore uses flood routing: every node that hears a new packet and hasn’t already forwarded it retransmits it. There is no delivery acknowledgment at the mesh layer. A packet either arrives at an observer and shows up in Live Packets, or it doesn’t. There is no failure signal.

This means the only way to detect packet loss is to notice absence: a node that was reporting 30 packets per hour drops to zero, a path that showed 2 hops now shows nothing, a link that read +4 dB SNR last week doesn’t appear at all.

Failure mode 1: RF margin

The most common cause. LoRa uses chirp spread spectrum, which lets it decode signals below the noise floor. But that capability has a floor of its own: at typical MeshCore spreading factors and bandwidths, there is a minimum SNR below which the receiver simply cannot decode. According to Semtech’s specifications, the demodulation floor for SF9 (a common MeshCore setting) is approximately −12.5 dB SNR; for SF10 it’s −15 dB. A link running at +3 dB SNR may appear healthy but sits close to the thermal noise floor — modest SNR variability from weather, vegetation, or local interference can push the received signal below the demodulation threshold.

When a weather change, seasonal vegetation, a misaligned antenna, or increased local interference erodes those margins, the link falls silent. Packets arrive at the antenna and disappear.

The diagnostic clue: check whether the node’s last-seen SNR was marginal — below +5 dB in Waev’s Network Stats or Live Packets. If the final observations showed +1 to +4 dB, RF margin failure is the most likely cause. The fix is almost always a path improvement: a higher relay site, a better antenna, or an additional repeater positioned to provide a stronger intermediate hop.

Failure mode 2: collision

LoRa mesh nodes transmit without listening first. When two nodes transmit on the same channel at the same time, their signals overlap at any receiver that hears both. In most cases, neither packet survives.

The exception is the capture effect: if one signal is substantially stronger than the other — typically 6 dB or more stronger at the receiver — the stronger packet can be decoded despite the interference. However, this requires a consistent power difference and does not reliably apply to nearby nodes transmitting with similar power levels.

Collision probability is proportional to traffic density and to spreading factor. At SF10, an SF10 packet occupies the channel for roughly eight times as long as an SF7 packet over the same payload. A network carrying moderate traffic at SF12 handles far more collisions than the same network at SF7 with equivalent link margins.

The diagnostic clue: collision losses are usually intermittent, not permanent. A node losing packets to collisions typically shows strong SNR when it does arrive — the RF path is fine — but erratic packet rates. In Waev’s Network Stats, the pattern is variable delivery rate on a path that otherwise looks healthy.

Failure mode 3: duty-cycle hold

LoRa operates in unlicensed ISM bands that carry regulatory duty-cycle limits. MeshCore firmware respects these limits: after transmitting, a node or relay must stay quiet for a silence window proportional to the time it just spent transmitting. If a packet arrives during that window, the relay cannot forward it — the packet is silently dropped.

Higher spreading factors amplify this effect. At SF12, each packet takes far longer to transmit, so the post-transmission silence window is correspondingly longer. A relay forwarding high-volume traffic at SF12 may spend most of its time in the duty-cycle window, dropping most of the packets it should be forwarding.

The diagnostic clue: duty-cycle losses cluster. You’ll see a burst of normal activity followed by a gap — the relay transmits, then goes quiet, then transmits again. If a node’s arrival pattern in Live Packets shows regular burst-and-gap rhythms that align with the forwarding activity of a specific relay, you have found a duty-cycle bottleneck. Reducing the spreading factor (and thus time-on-air) on that path is the most effective fix.

Failure mode 4: coverage gap

No relay exists where one is needed. The transmitting node cannot reach an observer or the next relay on any path — not because the link failed, but because no link was ever there.

Coverage gaps appear when a network expands geographically, when a relay goes offline permanently, or when a node is placed at a location assumed to be in range but isn’t. They differ from the other three failure modes in being structural: there is no RF path to improve, only a physical gap to fill.

The diagnostic clue: nodes lost to a coverage gap go completely silent — no transmissions, no forwarded traffic, no topology edges in Waev’s Live Map. The gap is visible as an isolated node or cluster with no connections to the main network. The post on repeater placement and coverage gaps covers the decision: whether to add a relay or improve an antenna at an existing site.

Reading the four modes together

Most real-world packet loss involves a combination. A marginally in-range path is susceptible to RF margin failure when conditions degrade, and the high spreading factor that compensates for weak SNR simultaneously increases collision probability and duty-cycle hold frequency.

The post on reading SNR and hop count covers the path-quality numbers in depth. The post on network health baselines and single points of failure shows how topology structure makes these failure modes worse. Together, SNR readings and topology structure give you most of what you need to diagnose a silent loss — because none of these failure modes are truly silent once you know what to look for.

Questions about a silent node or erratic link? Tell us what you’re seeing — real deployment patterns are the most useful input we get.