Status: evidence document · Data: two live packet captures, analyzed 2026-06-13 Companions: meshtastic-routing-analysis.md (code-level), meshtastic-meshcore-differentiation.md (design response), north-georgia-validation.md (sim calibration against this network)
This is a data-driven account of what a real, healthy, well-run Meshtastic network does on the air: what it is genuinely good at, where the measured behavior reveals structural limits, what could be improved while staying Meshtastic, and which problems no amount of iteration can fix without becoming a different protocol. The companion code analysis predicted most of these behaviors from source; this document shows them happening at scale.
| Local broker | mtnme.sh regional broker | |
|---|---|---|
| Window | 77.8 h continuous | first hours of access (growing) |
| Rows | 19,049 | 5,511 |
| Source nodes seen | 312 | 138 |
| MQTT gateways | 1 | 37 |
| Channel | MediumFast (SF9/BW250) | MediumFast dominant; LongFast, PKI minor |
Both captures log every MQTT-uplinked packet with per-reception SNR/RSSI, hop counters, port, and payload length. The regional broker is the more revealing instrument: with 37 gateways uplinking everything they hear, it shows each packet from every vantage at once.
Credit first; the data is unambiguous about these.
Unique-packet traffic mix over 77.8 hours, local capture:
| Type | Share |
|---|---|
| nodeinfo | 42.9% |
| position | 26.7% |
| telemetry | 18.9% |
| traceroute | 8.0% |
| text (the user payload) | 1.3% |
~89% of all packets are the network describing itself; under 2% is the messaging the network exists to deliver. This is not user misbehavior — it is the default-on cadence of NodeInfo/Position/Telemetry, multiplied by flooding. The regional capture agrees (text = 2.0%). Every scaling discussion must start here: the channel is not full of messages, it is full of presence.
The regional broker shows what flooding means physically: the median packet is uplinked by 16 gateways; p90 is 21 copies; 92% of the entire MQTT stream is redundant copies of something already received. Each of those copies corresponds to RF airtime somewhere — the same bytes occupying the channel across the whole metro at once, because flooding has no concept of "delivered."
Airtime accounting (computed from payload sizes at MediumFast):
- Source transmissions alone: 1.5% channel utilization (local, 3.2 days) — modest.
- Including the flood re-transmissions observable in hop counters: ≥4.7% local,
≥11.6% regional in the evening hour — and these are lower bounds, counting only relays
some gateway heard. The validation work (north-georgia-validation.md) measured peaks
near 36% on this same network. The flood multiplies a quiet network into a busy channel,
and the multiplier grows with node count — the v1 sim collapse curve, observed in vivo.
hop_start settings observed simultaneously on one channel: 3 (30%), 5 (31%), 7 (19%),
4 (15%), plus stragglers at 1, 2, 6. Every operator picks their own flood radius; nobody
owns the trade-off. The result: 11–14% of received packets arrive with their hop budget
fully exhausted — packets that died mid-network from the receiver's perspective, while
high-hop settings (7) flood the entire metro with every NodeInfo from one suburban node.
There is no mechanism — none — by which the network converges on a sane radius.
Routing-port packets (the ACK machinery) are 0.5% of traffic; traceroute — the manual "is anyone out there" probe — is 8%, sixteen times the ACK volume. Users compensate for the absence of delivery feedback by manually probing the network, with 200-plus-byte flooded diagnostics. The protocol's answer to "did it arrive?" is "send another flood."
The top two sources (both infrastructure-grade nodes) account for 32–38% of all packets in both captures. Flooding gives every node identical broadcast rights; position at elevation converts those rights into channel dominance. There is no admission control, no airtime fairness, no way for the network to push back.
Honest engineering: a motivated operator community could deploy all of the following without forking the protocol, and would get real headroom from it.
elevated-nodes.md — elevation is capability, role is configuration).Generously estimated, these recover 3–5× effective capacity. They are worth doing — the people on this network are friends of this project, and we should say so publicly.
The recommendations above tune the flood. They do not change what it is:
hidden-node-analysis.md
(and reproduced in sim v1) is permanent. The Stone Mountain hub — ~92% of heard nodes
mutually hidden — cannot be scheduled around within this MAC.That is the line. Below it, stay and tune; above it, a different protocol is required.
The quantified version of "above it" is the Loomwave design decision record
(design-decision.md), and every number in this case study is an input to it.
Captures: tools/capture_mqtt.py (subscribe-only) on a local broker (3.2 d) and
mtnme.sh (read access granted 2026-06-12; per-packet ServiceEnvelope metadata only).
Airtime computed from payload+header sizes via the standard LoRa ToA formula at each
channel's preset; flood re-TX estimated from per-packet max observed hops-traveled
(lower bound — relays no gateway heard are invisible). Gateway-copy statistics use
packet-id dedup across gateways. Encrypted packets (28% regional) contribute size and
hop data but not port classification. The mtnme capture continues to accumulate; numbers
here are its first hour and will be refreshed for the RFC paper.