← RFC

MeshCore Network — Census Characterization & Traffic-Source Scoping

Status: Stage 1 data-scoping (pre-sim). Characterizes the MeshCore real-world data as a potential second, independent calibration/validation network alongside the North Georgia Meshtastic data (north-georgia-*). Covers (1) the open node-census API — pulled and characterized — and (2) scoping of the packet-traffic sources (MeshCore Analyzer / MQTT). Pull: /workspace/reference/meshcore.map/nodes_<stamp>.json (snapshot 2026-06-05).

⚠ DATA-USE STANCE (read first). The LetsMesh maintainer is opposed to data mining and does not offer an API suited for bulk collection. We will not scrape the Analyzer or build an automated MQTT collector against LetsMesh/MeshMapper. Manual browsing by a human is fine; automated pulling is not. The only data collected here is a one-time census snapshot from the separate official map.meshcore.io (§2) — no ongoing polling. If real MeshCore traffic is ever needed, the right move is to ask the maintainer's permission / contribute as an observer, not to mine the feed. This note governs everything below.

Update (2026-06-05): the maintainer's forum thread explicitly invites people to ask, and a request for a possible data dump has been sent through that channel — pending response. Any use of LetsMesh data waits on an explicit yes; until then the stance above stands unchanged.

---

0. Why a second network

MeshCore is the other reference stack Loomwave analyzed (meshcore-routing-analysis.md). Real MeshCore data is valuable in ways the Meshtastic data is not:

• Cross-validation: a PHY/propagation model that reproduces both a Meshtastic and a MeshCore network is far more credible than one fit to a single network.
• Structurally different & closer to Loomwave: repeater-heavy, path-routed, EU-band — a different operating point that stress-tests the airtime model.
• Protocol-independent substrate: seeing two protocols lets us separate topology / link quality / user demand (transferable) from protocol-specific machine-cadence.

1. Sources & access (the important practical part)

Source	Data	Access	Usable now?
map.meshcore.io/api/v1/nodes	node census + real freq/bw/cr/sf + pubkeys	open JSON	✅ pulled
analyzer.letsmesh.net/packets	real packet traffic	Cloudflare JS-challenge (browser-only)	👀 manual browse only
MeshCore MQTT (LetsMesh / MeshMapper)	live packet feed (what the analyzer ingests)	WS+TLS:443, auth token	🚫 off-limits — do not mine

• The census API (map.meshcore.io, official map, separate operator from LetsMesh) is open; a single snapshot was taken for characterization — no repeated polling.
• The Analyzer web UI is bot-protected (cf-mitigated: challenge) — fine to browse by a human, not scriptable. We will not attempt to defeat the challenge.
• The MQTT feed exists but is off-limits for automated collection — the LetsMesh maintainer opposes data mining (see stance note above). It is documented in §5 for completeness only.

2. Census characterization (47,379 nodes; 16,621 active <7 d)

	total	active (<7 d)
nodes	47,379	16,621 (35%)
Repeater	35,443 (75%)	15,334 (92%)
Client	9,457	532
Room Server	2,479	755

• Positioned: 100% (every node advertises lat/lon) — better than Meshtastic's 73–86%.
• Self-certifying identity: 47,379 unique public_keys for 47,379 nodes — confirms MeshCore's pubkey-as-identity model in the wild, which supports Loomwave's self-certifying address choice (borrowed from Reticulum/MeshCore).
• Global: ~62% Europe, ~30% N. America, ~4% Australia. Like mtnme, this is many separate regional RF networks aggregated into one map — model clusters, not one mesh.

⚠ Repeater-dominance is partly an observability artifact. The map is built from adverts, and MeshCore Repeaters advertise persistently (always-on infrastructure) while Clients (companion/BLE, often mobile) advertise rarely. So "75% repeaters (92% of active)" means the repeater backbone is well-mapped, not that real deployments are 92% repeaters. Treat the Client count as a severe under-count. The true role ratio is unknown from this source — but even discounted, MeshCore is clearly far more repeater/infrastructure-heavy than Meshtastic's ~8% relay ratio, which is the structurally interesting point for Loomwave's INFRA model.

3. Real modulation parameters (the standout value)

Unlike mtnme (which exposed only a preset name), MeshCore publishes per-node freq/bw/cr/sf. Active-node distribution:

• SF: SF8 (53%) + SF7 (43%) dominate; small SF9/SF6 tails.
• BW: 62.5 kHz (96%) — narrow-band, very different from Meshtastic's 250 kHz.
• CR: split 4/8 (robust) and 4/5 (fast).
• Freq: 870 MHz (EU, 55%), 911 MHz (US, 28%), plus 433/915/923/928.

Top active modulation combos:

count	combo
6,577	SF8 / BW62.5 / CR4-8 / 870 MHz (EU robust)
3,015	SF7 / BW62.5 / CR4-5 / 911 MHz (US fast)
1,775	SF8 / BW62.5 / CR4-5 / 870 MHz
1,059	SF7 / BW62.5 / CR4-8 / 911 MHz

Why this matters: these are operating points the US-Meshtastic data never touches. Narrow 62.5 kHz BW makes symbols ~4× longer than BW250 at the same SF, so airtime is very different — a direct, real-world stress test of the airtime model (mac-layer-options.md §1) across the parameter space operators actually use. The sim PHY should validate against these combos, not just the Meshtastic presets.

4. Candidate sim clusters (dense, active metro areas)

Densest ~37 km cells among active nodes — ready-made real "dense" scenarios:

active nodes	locale (approx)
194	Seattle (47.67, −122.33) — PugetMesh
166	Moscow (55.67, 37.67)
149	Netherlands/Randstad (52.0, 4.33)
104	Portland (45.67, −122.67)
91	Warsaw (52.33, 21.0)
90	Lisbon (38.67, −9.33)

Seattle/Portland (PugetMesh) are large, active, well-documented MeshCore communities — a strong candidate for a meshcore_metro sim scenario, complementing the north_georgia Meshtastic one.

5. Traffic via MQTT — documented, but NOT to be collected

For completeness: the packet feed behind the Analyzer is MQTT (LetsMesh mqtt-{us,eu}-v1.letsmesh.net / MeshMapper mqtt.meshmapper.net, WS+TLS:443; topics meshcore/{IATA}/{PUBLIC_KEY}/packets; auth token required).

We are not building a collector against it. The LetsMesh maintainer opposes data mining and the access is gated accordingly (Cloudflare on the web UI, auth tokens on MQTT) — that is a clear signal to respect. Automated harvesting would be both against the maintainer's wishes and poor community citizenship. Decision: do not pull MeshCore traffic. If, much later, real MeshCore traffic genuinely becomes necessary for validation, the path is to ask the maintainer directly and/or run our own observer node contributing back — not to scrape the shared feed.

6. How it feeds Loomwave & recommended priority

• Now (done, and the extent of it): the one-time census + real PHY params → enrich modulation realism; the (advert-biased) repeater-heavy topology loosely informs INFRA/relay-density thinking; pubkey identity validates the addressing choice. This is qualitative/structural input, used respectfully and without ongoing collection.
• Traffic: not pursued (§5). Propagation calibration will come from the mtnme PacketSeen export (already requested) or our own measurements — not from mining LetsMesh.
• Priority: MeshCore stays a light, census-informed cross-reference, not a data pipeline. The primary real-data calibration source remains the North Georgia Meshtastic network, where the data is openly offered and a request is already in flight.

7. Caveats

• Census = adverts, so repeater-biased (§2) and traffic-blind. Node count is a snapshot that drifts (saved with timestamp).
• Analyzer is Cloudflare-walled — browse manually; not collectible programmatically.
• MQTT needs an auth token and gives forward-only data; payload schema unconfirmed.
• Positions are advertised (may be coarse/spoofable); same relative-geometry caveats as mtnme.