← RFC

North Georgia Network — Node List Characterization

Status: Stage 1 data-scoping (pre-simulation). Characterizes the node-list export from view.mtnme.sh/nodelist (saved at /workspace/reference/mtnme.sh/nodelist.csv) to assess its usefulness as a real sim input. This is a node census, not a connectivity or traffic measurement — those need the packet/PacketSeen data (see north-georgia-data-request.md).

1. Summary

~244 nodes, 86% (211) have usable coordinates. Columns: Short, Long Name, HW Model, Firmware, Role, Last Latitude, Last Longitude, Channel, Last Seen, Favorite.
This is a regional aggregation spanning ~244 km × 266 km — NOT a single RF mesh. It is the union of many local RF clusters bridged by MQTT into one logger view. The sim must model clusters, not all 244 nodes as one network.
Modulation is predominantly MediumFast (SF9/BW250), not LongFast — a meaningful baseline difference from the analysis docs (§4).

2. Role distribution (maps to Loomwave roles)

Meshtastic role	count	%	Loomwave analogue
CLIENT	111	45.3%	CLIENT
CLIENT_BASE	52	21.2%	CLIENT (favorited-relay submode)
CLIENT_MUTE	41	16.7%	CLIENT (non-relaying)
ROUTER_LATE	23	9.4%	REPEATER (late-rebroadcast)
ROUTER	17	6.9%	REPEATER / INFRA candidate
(blank)	1	0.4%	—

~83% client-class, ~16% router-class (40 nodes). This is a real-world ratio to use instead of guesses: roughly 1 relay per ~5–6 clients. Note CLIENT_MUTE (17%) never rebroadcast — a non-trivial fraction that consumes airtime (their own traffic) but adds no relay capacity.

3. Hardware (informs radio assumptions)

Dominated by standard ESP32/nRF52-class boards: RAK4631 (65), Heltec V3 (39), Heltec V4 (25), Portduino (23, i.e. Linux/INFRA-like nodes), T1000-E tracker (13), Seeed solar (10). This matches Loomwave's assumed CLIENT/REPEATER hardware class directly, and the 23 Portduino nodes are real examples of the Linux-host (INFRA-like) deployments the design assumes.

4. Modulation — the network runs MediumFast, not LongFast

Channel/preset	nodes
MediumFast (SF9/BW250)	224
LongFast (SF11/BW250)	19
ShortFast (SF7/BW250)	1

Implication for the sim and the analysis baseline. My analysis docs use LongFast (SF11) as the reference point; this real network runs MediumFast (SF9), which is ~3.4× faster on air (32 B: 140 ms vs 477 ms). That changes the headline numbers for a "north_georgia" scenario:

Metric (32 B)	LongFast (analysis baseline)	MediumFast (this network)
Airtime per packet	477 ms	140 ms
Raw channel capacity	~2.1 pkt/s	~7.2 pkt/s
Flood collapse point (1 msg/min, util 0.37)	~6.8 nodes	~12.6 nodes
TDMA collision-free rate, 47-node cluster	2.5 msg/node/min	9.2 msg/node/min

That a real, growing network has already moved to a faster preset is itself corroboration of the capacity-pressure argument in mac-layer-options.md — operators trade range for throughput as density rises. The sim should run the north_georgia scenario at MediumFast and report both.

5. Topology — many clusters, not one mesh

Connected-component analysis on the 211 positioned nodes, using distance thresholds as a proxy for RF range:

RF-range threshold	components	largest clusters	isolated singletons
3 km	110	31, 7, 5, 5, 5, …	73
5 km	68	47, 16, 12, 10, 8, 7, …	38
8 km	45	74, 31, 14, 11, 9, …	23

The largest 5 km-connected cluster = 47 nodes over ~31 × 16 km (metro Atlanta area), role mix CLIENT 22 / CLIENT_BASE 13 / CLIENT_MUTE 9 / ROUTER_LATE 3. This is an excellent real "dense/neighborhood" sim scenario.
Many singletons (38 at 5 km) are nodes far from any RF neighbor — reachable only via MQTT, not RF. They confirm the dataset is a logger aggregation, and they should be excluded from RF-mesh modeling (or modeled as separate islands).
Local density is moderate-suburban: avg 5.0 neighbors within 5 km, 11.0 within 10 km, nearest-neighbor median 1.75 km. Plausible RF connectivity exists within clusters.

6. What this unlocks now vs. what still needs packet data

Buildable now (real topology skeleton): - A "north_georgia_metro" scenario = the 47-node largest cluster, placed at real coordinates, MediumFast preset, real role mix — with modeled propagation (path-loss) to derive the connectivity graph. Plus a few mid clusters (16/12/10) as smaller scenarios. - Empirical role ratios and hardware/preset assumptions for all scenario classes.

Still requires the DB / PacketSeen export (see north-georgia-data-request.md): - Link calibration — turning modeled propagation into measured connectivity using real rx_snr/rx_rssi per gateway. Until then, connectivity is "realistic geometry, assumed propagation." - Real traffic — message mix, rates, sizes, and the channel-utilization validation run.

7. Caveats

Positions are last-known; mobile nodes may have moved. Last Seen is relative text ("2 hr ago"), so precise activity filtering needs the absolute timestamps in the DB.
14% of nodes have no position and cannot be placed geographically.
A node census over-represents nodes that uplink to MQTT; non-uplinking RF-only nodes may be absent, so local clusters may be denser in reality than shown.
The artifact map (/workspace/reference/mtnme.sh/node_map.png) shows all positioned nodes colored by role class.

Bottom line: the node list is a strong, immediately-usable input — it gives us a real topology skeleton, real role/hardware/preset distributions, and a concrete 47-node metro cluster to model — and it sharpens the baseline (MediumFast, not LongFast). It gets us ~60% of the way; the packet/PacketSeen export completes it with link calibration and traffic.