How MeshCore Packets Become a Live Map

A MeshCore packet leaves a node’s antenna as a burst of radio energy. By the time it appears as a line on Waev’s Live Map, it has traveled through several transformations: from RF to IP, from a raw MQTT record to a parsed observation, from an observation to a verified edge. Each step either advances the packet toward the map or discards it. Understanding those steps is what lets you read the map honestly — and diagnose it when something’s missing.

What a MeshCore advertisement packet contains

MeshCore nodes periodically broadcast advertisement packets to announce their presence and maintain mesh routing. Each packet carries enough information to reconstruct the path it took: the originating node’s identifier, and a record of the nodes it passed through — each hop appending evidence of what it heard and at what signal quality.

When the packet reaches an enrolled observer, the observer captures this path record and publishes it to your MQTT broker as a structured JSON document. That published record is what Waev receives.

The path record is the key artifact. It tells Waev not just that a packet arrived, but which nodes it passed through and what the signal quality was at each step. That’s the raw material for topology — a list of claimed edges, each needing verification.

From a hop record to a claimed edge list

When Waev receives the published record from your observer, the first step is parsing the hop path into a set of candidate edges.

If a packet traveled from Node A to Node B to Node C (where C is the enrolled observer), the hop record contains two edges: A→B and B→C. The SNR reported at each hop is the signal quality as measured by the receiving node — Node B’s SNR for the A→B link, and the observer’s SNR for the B→C link.

Each candidate edge is now a claim: “Node A heard Node B at SNR −12 dB.” Before that claim becomes a map line, Waev needs to verify it.

The verification step

Claimed edges from the hop record only become map edges if they pass Waev’s source verification check. The rule is straightforward: an observation is trusted if and only if it came from an enrolled observer or an authenticated repeater.

An enrolled observer is a node you’ve connected to your MQTT broker — one you’ve explicitly linked to Waev. An authenticated repeater is a node whose identity Waev can trace back through the enrolled observer’s record.

A packet that reaches Waev through an unverified path — one that didn’t come from an enrolled observer — doesn’t produce edges, even if the hop record is complete and plausible. Waev does not draw inferred connections. If it can’t prove the observation came from a trusted source, it doesn’t draw the line.

This is the check that makes the map honest rather than optimistic. A node that announces it heard another node is making a claim. The map only records claims that were witnessed by sources you trust.

Why some nodes don’t appear on the map

The most common reason a node is on your mesh but absent from the Live Map: no enrolled observer has seen it. If all your observers are on one side of the mesh and a node is on the other, that node’s packets may be flowing through the mesh without ever reaching an observer that reports to Waev.

The Live Packets view is useful here. Live Packets shows all observations that cleared the privacy gate — including packets heard by enrolled observers from nodes that didn’t produce map edges. If a node shows up in Live Packets but not on the map, the hop record was incomplete or the observation didn’t trace back to a verifiable source.

The map shows exactly what enrolled observers have seen. It is neither pessimistic nor optimistic — it’s a direct record of verified observations. A blank spot on the map means one of two things: no observation, or an observation that couldn’t be verified. Both are honest answers. Either way, the path to resolving it is adding an observer that can see that part of the network.

---

The full five-stage pipeline covers the end-to-end flow from radio to browser. This post focused on the topology-drawing step specifically — the part where observations become edges. For the data that does reach the map, the signal metadata those observations produced — SNR per link, hop count, timing — is what Reading the Signal examines in more detail.