Skip to main content

Choosing a Modem Preset

Your modem preset is one of the most consequential configuration decisions for your repeater. It must match every other node on your channel - and different regional communities have standardized on different presets.

What a preset controls

Each preset is a named combination of three LoRa parameters:

  • Spreading Factor (SF): Higher SF = longer range, longer airtime per packet. Range from 7 (fastest) to 12 (longest range).
  • Bandwidth (BW): Wider bandwidth = faster data rate, slightly less range.
  • Coding Rate (CR): Higher CR adds forward error correction overhead.

The full preset table

PresetSFBWCRData RateLink Budget
Short Turbo7500 kHz4/521.9 kbps140 dB
Short Fast7250 kHz4/510.9 kbps143 dB
Short Slow8250 kHz4/56.25 kbps145.5 dB
Medium Fast9250 kHz4/53.52 kbps148 dB
Medium Slow10250 kHz4/51.95 kbps150.5 dB
Long Turbo11500 kHz4/81.34 kbps150 dB
Long Fast11250 kHz4/51.07 kbps153 dB Long Moderate11125 kHz4/80.34 kbps156 dB Long Slow12125 kHz4/80.18 kbps158.5 dB

Step 1: Ask your local community

Before choosing a preset, check what your local or regional network has standardized on. All nodes on a channel must use the same preset to communicate. If your area already has an established mesh, deploying on a different preset will isolate your repeater from it entirely.

Check local Discord servers, third-party tools such as the community Meshtastic network map at meshmap.net (unofficial; only shows nodes reporting to the public MQTT server), or regional mesh community pages for your area's standard.

Step 2: Match your network density

If no local standard exists, choose based on your expected network density:

Sparse / rural networks (under ~3060 nodes in range)

Long Fast (the firmware default) is a reasonable default.choice. Range is maximized and the lower data rate is not a problem when relatively few nodes are generating traffic.

Medium densityLarger networks (30more -than ~60 nodes)

Consider Medium Slow or Medium Fast. The official guidance is to consider moving away from Long Fast once a mesh exceeds roughly 60 nodes. The 3 - 4x higher data rate significantly reduces collision probability while still maintaining comparablerespectable, only slightly reduced range compared to Long Fast in most deployments.Fast.

Dense urban networks (60+well over 60 nodes)

Faster presets are strongly preferred. Long Fast in a 100+ node network can cause congestion as packet airtime accumulates. Medium Slow has becomebeen reported as the standard for severalat least one large community meshes.mesh: Thethe Meshtastic Bay Area community (reportedly 150+ nodes)nodes, as of 2025) is reported to have migrated to Medium Slow with improved reliability, and reports significant improvement in reliability.the Wellington Region Mesh (New Zealand,Zealand) 150+is nodes)reported usesto use Short Fast. These community figures are unsourced and change over time - check your local community's current standard rather than relying on these examples.

Presets to avoid for repeater deployment

  • Long Slow / Very Long Slow - maximum range but extremely long airtime per packet. Can saturate a network even at low message rates. NotLong Slow and the even slower, deprecated VERY_LONG_SLOW are not recommended for regular use by the Meshtastic project.
  • Short Turbo - highest throughputthroughput, but theit uses 500 kHz bandwidthbandwidth. This is not permittedlegal in allthe regulatoryUS regions.902-928 MHz band, but some narrower regional bands (for example EU 868 MHz) do not permit it. Verify legality for your region before use.

Setting the preset via CLI

meshtastic --set lora.modem_preset MEDIUM_SLOW

Valid preset names: SHORT_TURBO, SHORT_FAST, SHORT_SLOW, MEDIUM_FAST, MEDIUM_SLOW, LONG_TURBO, LONG_FAST, LONG_MODERATE, LONG_SLOW, VERY_LONG_SLOW (VERY_LONG_SLOW is deprecated / not recommended).

Frequency slot and channel name

Meshtastic derives the transmit frequency from the channel name hash by default (frequency slot 0). This means two nodes with the same channel name and same preset will automatically land on the same frequency. You can override this with a specific slot number if needed, but the default hash-based behavior is correct for most deployments.