How periodic packets affect privacy, battery life and public-network capacity.
Meshtastic devices generate traffic even when nobody is typing. Position reports, device metrics, environmental sensor data and NodeInfo announcements each have their own purpose and schedule. On a small private group the defaults may be unobjectionable. Across a public regional mesh, multiplying them by every node and every relay can consume a meaningful share of airtime.
Intervals should reflect how quickly the underlying fact changes. A person walking needs different position behavior from a rooftop node bolted to a mast. Battery voltage changes more slowly than motion, while a node name almost never changes.
Position broadcasts
Current documentation describes a 15-minute default broadcast interval when smart broadcast is off. Smart broadcast is enabled by default and may send more frequently after useful movement while throttling when stationary. Its default minimum-distance interpretation is 100 metres and its minimum-interval interpretation is 30 seconds when values are left at zero.
For a fixed infrastructure node, configure a fixed position, consider reducing precision for site privacy and use a conservative interval. There is no value in repeatedly announcing centimetre-scale coordinates for a rooftop that has not moved.
Device telemetry
Device telemetry can include battery voltage, utilization and related health information. The current telemetry documentation gives 1,800 seconds, or 30 minutes, as the default mesh update interval when enabled. The connected application may receive local metrics more frequently; that does not mean they must all be transmitted over LoRa.
For a solar relay, 30 to 60 minutes is often sufficient for public health awareness. Detailed power diagnostics can be collected locally or through another backhaul.
Environmental and other telemetry
Environment, air-quality, power and health telemetry have separate enable flags and intervals, commonly defaulting to 30 minutes when enabled. Enabling multiple categories creates multiple traffic streams. Choose a purpose before enabling each one.
Weather data changing slowly may tolerate 30 or 60 minutes. A high-rate scientific sensor should use another transport or store measurements locally and send summaries.
NodeInfo
NodeInfo contains the long name, short name and related identity information. The documented default interval is 10,800 seconds, or three hours, with a minimum configurable value of one hour. Devices can also exchange NodeInfo on demand when they encounter an unknown node.
Reducing this interval rarely improves a public mesh. Names do not require minute-level refreshes, and newly heard nodes have an ad-hoc discovery mechanism.
Privacy and precision
A public map does not need the exact coordinates of a private home, protected tower or restricted facility. Use position precision appropriate to discovery and coverage planning, and keep precise access records outside the public radio and map dataset.
Mobile participants should understand that sharing position is a social and safety choice, not merely a technical setting. Private-channel encryption does not make radio activity anonymous.
Recommended method
Inventory each automatic packet source, disable those without a defined use and select the longest interval that still supports that use. Test during the busiest expected period. If delivery degrades, periodic traffic is the first place to look.
| Data | Starting point | Question |
|---|---|---|
| Fixed position | 15–60 minutes, reduced precision where appropriate | Does the site move? |
| Device telemetry | 30–60 minutes | Who acts on the data? |
| Environment telemetry | 30–60 minutes | How quickly does it change? |
| NodeInfo | Default 3 hours | Why would names need faster refresh? |
Examples by node type
A hilltop solar node may publish approximate fixed position, battery telemetry every 30 or 60 minutes and NodeInfo every three hours. A hiker may use smart position while moving but disable environmental telemetry. A weather station may send summarized readings every 30 minutes while retaining high-rate samples locally. These are different workloads and should not inherit one copied profile.
An event tracker may temporarily need faster positions in a contained network. That does not make the same interval appropriate for the permanent regional mesh.
Reviewing whether data is useful
For every enabled metric, name the person or system that consumes it and the decision it supports. If nobody notices a low-battery report, faster reports do not improve resilience. If maintainers need early warning, establish an alerting method rather than expecting them to watch the public node list continuously.
Intervals are also a privacy retention decision. Broadcasting less frequently and with reduced precision limits exposure, although it cannot eliminate radio direction finding or traffic analysis.
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
- Choosing the Right Meshtastic LoRa Preset
- How Meshtastic Routing Actually Works
- Meshtastic Channels, Encryption and Private Groups
- Meshtastic Hop Limits and Rebroadcasting Explained
- Meshtastic Network Capacity and Congestion
- Public Meshtastic Network Etiquette
- Recommended Settings for a Public Meshtastic Network
Official sources
- Meshtastic LoRa configuration
- Meshtastic radio settings and preset table
- Meshtastic channel configuration
- Meshtastic mesh broadcast algorithm
- Meshtastic device roles and rebroadcast modes
- Meshtastic configuration tips
- Meshtastic position configuration
- Meshtastic telemetry configuration
Meshtastic firmware and documentation change over time. Confirm setting names, defaults and regional requirements in the current official documentation before changing live infrastructure.
