Configuration and Network Behaviour

A practical guide to the settings that determine whether a public Meshtastic network remains interoperable, useful and sustainable.

Meshtastic equipment can communicate only when its radio settings are compatible, but compatibility alone does not create a healthy public network. Presets, frequency slots, channels, hop limits, rebroadcast rules and automatic broadcasts together determine who can hear whom, how far packets travel and how quickly shared airtime is consumed.

This section is a map of those decisions. It is written for community networks: installations intended to serve more than one owner, remain available over time and coexist with ordinary users. It does not propose one universal configuration for every country or landscape. Instead, it explains which settings must be shared, which can remain private and which should change only after measurement.

Start with radio compatibility

A node must use the correct regional profile and compatible modem parameters to exchange packets with another node. The modem preset defines bandwidth, spreading factor and coding rate. The frequency slot selects the actual part of the permitted band. Messaging channels sit above that radio layer: they organize messages and encryption but do not give each group a separate LoRa radio.

For the ordinary public Meshtastic mesh, LONG_FAST is the interoperability baseline. It is the firmware default and offers a practical range-to-airtime compromise. A community may deliberately choose another preset for a separate network, but a node on that preset no longer participates in the default LONG_FAST radio mesh.

Configuration is a network decision

A setting that looks harmless on one device can affect many other devices because packets are rebroadcast. Increasing a position rate, hop limit or telemetry rate multiplies work across the mesh. Declaring many nodes as routers or repeaters can also defeat the contention behavior that normally suppresses duplicate relays.

Public infrastructure should therefore have an agreed baseline, a small number of people authorized to change it, and a written record of exceptions. Change one variable at a time, observe channel utilization and delivery, then keep or reverse the change.

The eight guides in this section

Choosing the Right Meshtastic LoRa Preset compares range, data rate, airtime and interoperability. Channels, Encryption and Private Groups separates radio compatibility from message access. How Meshtastic Routing Actually Works explains managed flooding, acknowledgements and duplicate suppression.

Hop Limits and Rebroadcasting Explained covers packet lifetime and relay policy. Network Capacity and Congestion examines the finite airtime budget. Position, Telemetry and Node Information Broadcast Intervals deals with automatic traffic. Public Network Etiquette translates those mechanics into community behavior. Recommended Settings for a Public Meshtastic Network provides a conservative starting profile rather than an immutable standard.

A sensible order for operators

First confirm the legal region and antenna system. Next coordinate the modem preset and frequency slot. Then decide whether the primary channel remains the default public channel and add private secondary channels where needed. Keep ordinary nodes as CLIENT unless their real function justifies another role. Leave maximum hops at 3 initially and use normal rebroadcast behavior.

After deployment, measure actual paths and channel utilization. Reduce unnecessary automatic traffic before increasing hops or adding privileged repeaters. Public networks usually improve through better sites, cleaner links and fewer unnecessary transmissions—not through maximum values everywhere.

What a public standard should publish

Publish the regional profile, modem preset, frequency slot policy, public-channel policy, expected maximum hops, position-precision policy and recommended intervals. Also publish who coordinates changes and how an operator reports congestion or a misconfigured node.

Do not publish private channel keys, administration keys, exact coordinates of sensitive sites or credentials for remote management. Openness about interoperability does not require exposing security material.

Common configuration failures

The most common failure is not defective hardware but incompatible layers. Two nodes may use the same public channel name while transmitting on different presets or frequency slots. Conversely, nodes can share a radio layer and relay one another while displaying no messages because their channel keys differ. Troubleshooting should therefore proceed from region, preset and slot to messaging channels—not begin by repeatedly resetting devices.

Another failure is copying a successful mountain-node configuration to every device. A high site has a large radio horizon and can hear populations that low nodes do not. Aggressive intervals, privileged relay roles or large hop limits on that site have a much wider impact.

Managing a regional profile

Maintain a short versioned document containing the agreed settings, the date adopted and the firmware generation on which they were tested. Give changes a trial period and collect observations from more than one part of the region. Delivery success, channel utilization, duty-cycle events and user experience are more useful than the number of nodes visible in one application.

Compatibility should be the stable center of the network. Private groups, sensors and experiments can coexist around it as long as their operators understand that shared radio airtime remains communal.

How these settings work together

No setting should be evaluated in isolation. A slower preset increases packet airtime; a larger hop limit multiplies that airtime across more relays; frequent position and telemetry packets create a permanent load; and privileged repeaters can produce additional copies. Conversely, a well-sited node using ordinary CLIENT behavior may extend the mesh effectively without special privileges.

For a public deployment, document the complete profile and the reason for every exception. Test delivery in both directions, during quiet and busy periods, and retain a way to reverse remote changes. Revisit the profile as the network grows.

Related configuration guides

Official sources

Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.