Meshtastic proposal would move portable nodes later in contention windows

Meshtastic is weighing a small timing change with a big field effect: move portable nodes to a later contention window so stronger fixed stations get first crack at rebroadcasting. The proposal, opened in meshtastic/firmware issue #10687 on June 10, 2026, argues that handheld nodes often sit at ground level, fight through obstacles, and rely on antennas of 2.5 dBi or less, which makes them poor candidates for carrying mesh traffic compared with attic, roof, or short-mast nodes.

At the center of the request is a fairness question that is really about airtime. Portable nodes currently share the same contention window as CLIENT_BASE nodes, even though CLIENT_BASE is meant for a stronger, well-positioned base station. In a mixed mesh, that can let a body-blocked handheld win a rebroadcast slot before a better-sited relay, consuming battery and channel capacity without offering the best path through the network.

That tension fits the way Meshtastic already describes managed flooding. Since version 2.6, the project has treated broadcasts and direct messages differently, and its broadcast logic is influenced by RadioHead, using SNR-based timing and random delays to suppress redundant rebroadcasts. In one discussion, contributors described managed flooding as cutting roughly 40% to 50% of rebroadcasts, which shows how much performance depends on who speaks first and who stays quiet.

The proposal also lands in the middle of a long-running role debate. Meshtastic’s official guidance says CLIENT_BASE is for a stronger attic or roof station, while a September 25, 2025 post said ROUTER_LATE is meant for infrastructure sites with significant obstacles nearby, such as the far side of a hill or the bottom of a canyon. That same ROUTER_LATE post warned that overuse can significantly increase airtime and congestion, a reminder that the project has already learned the hard way that more rebroadcasting is not always better.

A November 10, 2024 post went further, saying CLIENT_BASE has priority in rebroadcasting messages from or to favorited nodes. By October 2025, users were already arguing in discussion #8367 that CLIENT_BASE preferential routing should use a later part of the client window, not the Router_Late window. In discussion #8280, a maintainer said the hidden-node-style limitation described by a user was expected behavior and pointed to ROUTER or ROUTER_LATE as possible fixes in some topologies.

What makes issue #10687 different is its target. Rather than asking portable nodes to be smarter, it asks the network to be less eager to trust them. That is a subtle shift, but it could help Meshtastic do what hobby operators need most: let the best-sited node win airtime, and keep the handheld from becoming the bottleneck in a mesh built to survive the real world.