Reading the Signal

You’ve been watching the Live Packets stream long enough to have a feel for it. The timestamps, the node names, the SNR number attached to every observation. High numbers seem better than low ones — that much is obvious from the first day. But what does +11 dB actually mean? What’s the real difference between +3 and +7? And when a number goes negative, what’s the honest answer about whether that link is working?

This is the vocabulary.

What SNR actually measures

Signal-to-Noise Ratio is the difference, in decibels, between the signal your receiver hears and the background noise floor. A +10 dB reading means the signal is arriving 10 dB stronger than the noise. At +2 dB, it’s barely above it. At −5 dB, it’s technically below it.

That last case surprises people. LoRa, the radio modulation MeshCore uses, is engineered specifically to decode signals below the noise floor. It does this through spread-spectrum encoding: the signal is spread across a wide bandwidth in a way that lets the receiver correlate it out of the noise using techniques that simpler modulations can’t match. This is why MeshCore nodes can reach distances that look improbable on paper.

But there’s a ceiling to that capability. “The radio can decode it” and “this path is reliable for mesh operations” are different standards. As SNR approaches and crosses the noise floor, decodes become inconsistent — the link works eight times out of ten, or six, depending on local conditions. A link that works most of the time fails during a weather event, a high-interference moment, or the exact instant you need it. When you’re building community infrastructure, “mostly works” isn’t something you can plan around.

The zones are starting points, not hard lines. What doesn’t shift is the direction: every decibel of margin you add is more reliability under adverse conditions. A working MeshCore link generally wants at least +5 to +7 dB in typical conditions — that’s the figure cited in the coverage playbook and the one you’ll see flagged in Network Stats. Under that, plan for intermittency. Consistently negative, plan for failure.

Hop count: routing distance and health

Hop count is how many discrete radio legs a packet crossed from its source node to the observer that recorded it. A hop count of 1 means the source was heard directly. A count of 3 means the packet passed through two relay nodes along the way.

More hops mean more latency — each relay adds its own forwarding delay, which accumulates. They also mean more exposure to failure: each leg is an independent radio link that can drop a packet. For most deployments, 1–2 hops is the sweet spot. Three or four is reasonable for geographically spread networks. Consistently five or more starts trading away the reliability that makes mesh communications useful in the first place.

The more meaningful signal is change in hop count. A node that was reaching your observer in 2 hops at initial deployment and now shows 4 didn’t physically move. Something in the shorter path degraded — a relay went offline, a link became intermittent, terrain obstruction changed — and the mesh started routing around it. Hop-count creep is one of the earliest and most reliable early-warning signs of a coverage problem. It doesn’t mean the network is broken; it means something changed, and that change is worth understanding.

Reading them together

Neither number tells the full story alone. A high hop count on a path where every hop is strong — +10 dB, +11 dB, +9 dB across four legs — is a legitimate long-distance coverage solution. A low hop count on a single link at +2 dB is operationally marginal no matter how short the physical distance.

What matters is the combination, and the key principle is this: a path is only as reliable as its weakest hop. A packet has to survive every RF leg to get through — there’s no averaging, no compensating for a bad hop with good ones. One hop at +3 dB in an otherwise excellent path makes the whole path a +3 dB path.

This has a direct practical implication: improving the weakest hop is almost always more valuable than improving one that’s already strong. If you’re deciding where to add a repeater or tune antenna placement, find the weakest links in your critical paths first — not the longest ones, and not the most visible ones.

The four combinations you’ll encounter in the field:

The bottom-right quadrant is the most urgent. High hop count plus low SNR together is the diagnostic signature of a node at the edge of your coverage area, routing far around a gap over a marginal path. That’s the combination the Coverage Gap playbook is designed to address — and now you know what the numbers look like when you find it.

Where Waev surfaces the data

Three surfaces, each with a distinct role.

Live Packets shows per-hop SNR in real time as observations arrive. This is the fastest answer to whether a specific node is reaching your network and over how many hops. Packets appear within seconds of transmission; SNR is attached to each one.

Network Stats is the diagnostic layer. The path-quality view shows hop count and SNR together for every active node, with status flags for watchlist and degraded paths. The time series shows how these numbers move over hours and days, which is what distinguishes a transient weather event from a structural path failure.

Outpost is the per-node deep-dive: one node’s activity timeline, its heard-by log, and its SNR history over the past day or week. When a specific node is behaving strangely, Outpost is where you trace the cause.

---

The numbers are there on every packet that arrives. Learning to read them takes a few minutes, and then they stop being noise and start being signal — the difference between a network you’re watching and one you actually understand.

Questions about what you’re seeing on a specific node? Tell us — questions about real deployments are the most useful feedback we get.

Ready to see the numbers for your network? Connect your first observer at waev.app.