If you’ve spent any time on the New Hampshire mesh, you’ve probably noticed that the health of our network depends far more on how everyone configures their nodes than on how many nodes we have. A handful of well-placed, thoughtfully configured radios will always beat a crowd of aggressive, misconfigured ones. This guide walks through the settings we recommend for a reliable, low-congestion NH mesh, with a focus on getting your roles right.
Optimal Device Settings at a Glance
Before we dig into roles, here are the baseline option settings we recommend for nodes on the NH mesh. If you set these and nothing else, you’ll already be a good mesh citizen:
| Setting | Recommended Value | Why |
|---|---|---|
| Region | US | Legal requirement — sets your frequency range and power limits. |
| Modem Preset | Group default (LongFast unless told otherwise) | Keeps you on the same channel and slot as everyone else. |
| Role | CLIENT, CLIENT_MUTE, or CLIENT_BASE | Covers 99% of users. See the roles section below. |
| Max Hops | 7 | NH is spread out — more hops helps packets bridge the gaps. (See note below.) |
| Rebroadcast Mode | ALL (default) | Standard mesh behavior; don’t change without a reason. |
| Node Info Broadcast | ~3 hours (default) or longer | Prevents needless chatter; your node is still discoverable. |
| Position Broadcast | Smart Position enabled, or a long interval | Cuts airtime for stationary nodes dramatically. |
| Telemetry Intervals | Long (30+ min) or off if not needed | Telemetry spam is a top cause of congestion. |
| MQTT | Off, unless you understand the privacy tradeoff | Public MQTT can publish your whole mesh’s locations online. |
A note on 7 hops: Meshtastic ships with a default of 3 hops because in dense networks a high hop count adds congestion. New Hampshire is not a dense network — we’ve got mountains, forests, and long distances between nodes. Setting your device to the maximum of 7 hops gives packets the room they need to travel across those gaps and reach the far corners of the mesh. This is a deliberate choice for our terrain. If you’re in a dense cluster (say, a downtown with lots of nearby nodes), be aware you’re contributing more rebroadcasts, and lean on CLIENT_MUTE for any co-located radios to balance it out.
With the baselines set, let’s get into the part that matters most: your role.
Start With the Roles That Matter
Meshtastic’s official guidance is blunt: keep your role set to CLIENT, CLIENT_MUTE, or CLIENT_BASE, and only reach for anything else if you have a specific, well-understood reason. For the vast majority of NH users, one of these three is all you’ll ever need.
Here’s the quick breakdown:
CLIENT– The default and the right choice for most people. It sends, receives, and intelligently rebroadcasts messages using smart delays to keep the network stable. This is the role for a node that can genuinely help the mesh: a rooftop or attic install, a high-visibility location, or a portable node out in remote terrain where every relay counts.CLIENT_MUTE– Behaves like a Client but never repeats or routes messages for others. It only sends and receives its own traffic.CLIENT_BASE– Behaves like a Client for general traffic, but gives priority to rebroadcasting packets going to or from its favorited nodes. This is the purpose-built role for a strong “base station” node supporting your own personal devices.
A quick word on ROUTER and REPEATER: please don’t use them unless you’ve coordinated with the group first. Improperly placed routers “hop gobble” — they consume a hop in a packet’s journey before it can reach a better-positioned node, which actually shrinks effective range, causes collisions, and creates asymmetrical links where one side can hear the other but can’t reply. A network of Clients with a small number of deliberately placed routers is the most stable configuration.
If You Run a Client Base, Mute Your Other Nodes
This is the single most important point for anyone running more than one radio.
If you’re a mesh enthusiast with multiple devices — which describes a lot of folks on 603Mesh.com — you should pick one node to be your CLIENT or CLIENT_BASE, and set the rest to CLIENT_MUTE. This keeps your own airtime usage responsible instead of having several of your co-located radios all fighting to rebroadcast the same packets.
Think about it from the mesh’s perspective: if you have three radios sitting in the same house, all within easy range of each other, there’s no benefit to all three repeating traffic. They’d just be adding redundant transmissions and noise. CLIENT_MUTE exists precisely to stop that. Clusters of nearby nodes that all rebroadcast are one of the most common ways people unintentionally overwhelm a mesh.
When a Client Base makes sense — and when it doesn’t
A CLIENT_BASE node should be your strong, well-positioned anchor — the attic or rooftop node with the good antenna and the clear view. Its job is to pull in the weaker signals from your indoor or less-well-placed personal radios and push them out to the wider mesh.
The flip side: a Client Base should really only be running when you are mobile, or when your node is a genuinely needed part of the network for relaying. Because a Client Base always rebroadcasts for its favorites with priority, leaving one running in a spot where it isn’t actually helping — or where it’s redundant with existing coverage — just adds traffic. There’s been real discussion in the community about Client Base nodes rebroadcasting traffic the network didn’t actually need, so treat the role as a tool for a specific job rather than a permanent “always on” upgrade. If your base node isn’t earning its keep as an anchor or a needed relay, a plain CLIENT (or CLIENT_MUTE if it’s co-located with another relay) is the more neighborly choice.
Favorite Both Ways for a Zero-Cost Hop
Here’s the piece that ties it all together, and it’s easy to miss.
The way CLIENT_BASE works is that it gives rebroadcast priority to nodes it has favorited. So when you set up a base station, you need to favorite your personal client node(s) on the Client Base. That’s the documented setup: set one node to CLIENT_BASE, and mark your other nodes (whether CLIENT or CLIENT_MUTE) as favorites on it.
But don’t stop there — favorite your Client Base on your personal client, too. By favoriting in both directions, you establish a priority relationship each way, giving you a reliable, zero-cost hop back to your own client. Your handheld’s traffic gets anchored out to the mesh through your base, and traffic coming back in gets prioritized straight to your handheld. Miss the reverse favorite and you can end up with that asymmetrical situation where your base relays your outbound messages beautifully, but replies struggle to find their way home.
Quick setup recipe for a two-node personal setup:
- Set your rooftop/attic node to
CLIENT_BASE. - Set your handheld/indoor node to
CLIENT_MUTE(it doesn’t need to repeat — your base handles that). - On the Client Base, favorite your handheld.
- On the handheld, favorite the Client Base.
That gives you a clean, prioritized link in both directions without either radio stepping on the wider mesh.
A Few Other Settings Worth Getting Right
While roles do the heavy lifting, these settings round out a good NH mesh citizen:
- Max Hops: 7 for NH. As covered above, our spread-out terrain benefits from the maximum hop count so packets can bridge long distances. If you’re in a dense cluster, keep an eye on congestion and mute co-located radios.
- Region: Make sure you’re set to US. This is a legal requirement, not a preference — frequency ranges and power limits are set by region.
- Modem preset: To stay part of the wider public mesh, use the default preset the group runs on. If you rename your primary channel, you’ll need to manually set the LoRa frequency slot back to the regional default so you stay on the same slot as everyone else.
- Muting the noise: If a chatty public channel or a particular node is driving your buzzer crazy, you can mute individual channels or specific nodes rather than changing your role to escape it.
- MQTT caution: Connecting your node to the public MQTT server can publish the location of every node in your mesh to the internet. Think before you enable it.
The One Rule to Remember
If you don’t have a specific reason to change a setting, don’t change it — the defaults exist for good reasons, and the few we do change (like hops for our terrain) we change on purpose. Most meshes don’t fail from a lack of nodes; they fail from too many aggressive nodes in the wrong places. Get your role right, position your anchor node thoughtfully, favorite both directions, and mute what doesn’t need to talk. Do that, and you’ll be making the NH mesh better for everyone around you.