How modem presets trade speed and airtime for link budget—and why a public mesh normally standardizes on LONG_FAST.
The LoRa preset is one of the most consequential Meshtastic settings. It controls bandwidth, spreading factor and coding rate as a tested combination. Those parameters determine data rate, time on air, receiver sensitivity and compatibility. Two nodes using different presets are effectively on different radio networks even if they use the same regional band and channel name.
The tempting interpretation is that a slower preset is simply a stronger one. It can provide more link budget, but every packet occupies the channel longer. In a public mesh, that packet may also be relayed several times. The longest-range preset can therefore make a busy network less reliable than a faster, apparently less capable preset.
What the presets change
Spreading factor controls how long each LoRa symbol lasts. Increasing it can improve decoding of weak signals, but roughly doubles airtime at each step. Narrower bandwidth can improve link budget while reducing throughput. A stronger coding rate adds redundancy at the cost of more transmitted symbols.
Meshtastic packages these into presets including SHORT_TURBO, SHORT_FAST, SHORT_SLOW, MEDIUM_FAST, MEDIUM_SLOW, LONG_TURBO, LONG_FAST, LONG_MODERATE and LONG_SLOW. VERY_LONG_SLOW may appear in tooling or older material, but current documentation warns that it is not suitable for normal mesh use.
Why LONG_FAST is the public baseline
LONG_FAST is the default and is intended as a strong balance between speed and range. More importantly, it is where an unmodified public Meshtastic node is expected to listen. A regional public network that selects another preset gains a private radio layer but loses automatic interoperability with visitors and default-configured users.
LONG_FAST uses spreading factor 11, 250 kHz bandwidth and coding rate 4/5 in the current radio-settings table. It is not literally fast compared with Wi-Fi or mobile data; the name is relative to other long-range LoRa modes.
When a faster preset helps
In dense areas, event networks or fleets that generate frequent packets, MEDIUM_FAST or SHORT_FAST can substantially reduce airtime. The trade is reduced link budget, so the network may require better sites or shorter links. This is reasonable for a deliberately coordinated local network, not as an undocumented change to a public backbone.
SHORT_TURBO and LONG_TURBO use 500 kHz bandwidth and are not permitted in every regulatory region. Never infer legality from the fact that firmware exposes an option.
When a slower preset helps—and when it does not
LONG_MODERATE can be useful for a sparse, controlled network with unusually difficult point-to-point links and very low traffic. It should be evaluated with a link budget and real testing. LONG_SLOW consumes still more airtime and should not be adopted merely because a map contains a long line.
If a weak link fails because an antenna is indoors, coax is lossy or the path is obstructed, a slower preset treats the symptom. Moving the antenna, improving the site or adding one well-placed relay is often a better network-wide solution.
How to choose
Start with the public interoperability requirement. If the node should join the default community mesh, choose LONG_FAST. If the network is isolated and controlled, estimate the number of nodes, automatic packets, expected messages and hop count. Test the fastest preset that reliably closes the critical links, because faster reliable packets leave more capacity for everyone.
Change the preset only as a coordinated migration. Update documentation, stage nodes, keep recovery access and verify that all infrastructure moved. A half-migrated network is two disconnected meshes.
Preset comparison
| Preset family | Typical strength | Main cost | Public-network use |
|---|---|---|---|
| Short / Medium | Low airtime, more capacity | Less link budget | Coordinated dense or local networks |
| LONG_FAST | Compatibility and balanced range | Moderate airtime | Default recommendation |
| LONG_MODERATE | More link budget | Lower capacity | Special sparse networks after testing |
| LONG_SLOW or slower | Maximum sensitivity | Very high airtime | Experiments, not routine public mesh |
A practical comparison exercise
Suppose a town has a strong hilltop node and twenty users. LONG_MODERATE might make the weakest edge readable, but every position and relay packet lasts longer for all twenty users. If moving one edge antenna or adding a modest intermediate site closes that link on LONG_FAST, the entire network retains more capacity. The correct optimization is the one that improves total service, not the single most difficult link.
For a temporary festival inside one park, MEDIUM_FAST may provide ample range and lower airtime. That network should use a deliberately coordinated profile and should not expect default public nodes to join automatically.
Migration and rollback
Never change a remote backbone preset without a recovery plan. A preset change takes the node off the old radio network immediately. Stage the destination settings on accessible devices, verify direct access and move critical nodes in an order that preserves a management path.
Record the original profile and define a rollback time. If operators cannot reach the changed node through the new profile, local access may be the only recovery method.
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
- How Meshtastic Routing Actually Works
- Meshtastic Channels, Encryption and Private Groups
- Meshtastic Hop Limits and Rebroadcasting Explained
- Meshtastic Network Capacity and Congestion
- Position, Telemetry and Node Information Broadcast Intervals
- 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.