How MeshRank Reconstructs Routes (Current baseline)

1️⃣ Collect observations

For each message hash, we gather all observer captures and their hop-byte paths.

2️⃣ Expand each hop into real repeater candidates

Each hop is a 2-digit prefix.
Because multiple repeaters can share the same prefix (1 in 256 per byte), each hop expands into a list of possible real-world repeaters.

3️⃣ Score candidate repeaters per hop

Candidates are weighted using:

• Geographic plausibility (LoRa range constraints)
• Recency (last advert / last heard)
• Neighbour and repeated edge behaviour
• Observer position and sender anchor signals (when available)

4️⃣ Solve the most plausible path per observer

We use a dynamic programming path solver (Viterbi-style) to select the highest-likelihood repeater sequence that explains the observed hop path.

5️⃣ Apply physical plausibility constraints

The current model prioritises physical realism:

• Standard hop distance limits
• Long-range exceptions for validated high-site repeaters
• Implausible jumps are rejected

6️⃣ Build cross-observer consensus

We identify the most likely canonical start region and remove observer routes that conflict with that origin.

7️⃣ Render accepted routes

The mesh map is built from accepted observer reconstructions — not simple “join-the-dots” pairing.

Why It Can Still Be Imperfect

MeshCore uses flood routing. Packets spread in multiple directions with random delays.

We never see the full flood — only the subset captured by our observer network.

Additional constraints:

• 2-digit prefix collisions are unavoidable by design
• Sparse coverage windows reduce certainty
• Some paths are inherently ambiguous

In low-evidence scenarios, the system selects the most statistically consistent explanation — which may occasionally differ from the true physical sequence.

Why RSSI Alone Cannot Solve Multi-Hop Routing

RSSI/SNR only describe the final transmission received by an observer.

In a multi-hop path, commodity LoRa hardware does not expose per-hop RF metrics for earlier links.

So full route reconstruction cannot be achieved by sorting RSSI.

This is an inference problem, not a signal-strength gradient problem.

What MeshRank Uses as Evidence

• Observer-captured hop paths
• Repeated route behaviour over time
• Geographic and range constraints
• Candidate collision context
• Confidence and contested-route signals

What We’re Continuously Improving

• Better prefix clash detection
• Stronger repeated-route weighting
• Improved contested-route handling
• Increased observer density
• Clearer confidence signalling in the UI

Core Principle

MeshRank does not aim to invent routes.
It aims to display the most evidence-supported reconstruction possible — with transparent confidence constraints.