# LoRa Radio Configuration # Meshtastic LoRa Settings Reference The LoRa settings control every aspect of your radio's physical layer configuration. These are the settings that determine whether your node can communicate with the rest of the network - get them right and everything works; get them wrong and you're invisible. ## The Golden Rule **All nodes on a channel must use identical LoRa settings: same modem preset (or same SF/BW/CR), same frequency (derived from channel name hash or explicitly set), and same region.** One misconfigured node silently disappears from the network. ## Accessing LoRa Settings In app: **Radio Config → LoRa** Via CLI: `meshtastic --get lora` ## Region ``` meshtastic --set lora.region US ``` Region sets the legal frequency range and power limits. Always set this correctly for your country. Options: `US` (902-928 MHz), `EU_868` (863-870 MHz), `EU_433`, `AU`, `NZ`, `KR`, `TW`, `RU`, `IN`, `JP`, `ANZ`, `LORA_24` (2.4 GHz), `UA`, `MY_919`, `MY_433`, `SG`, `UNSET`. **Canada is not a separate option** — Canadian operators select `US` (same 902-928 MHz band). Do not use `TW` for Canada. If you see "please set region" on your node's display, this is the setting to configure first. ## Modem Preset ``` meshtastic --set lora.modem_preset LONG_FAST ``` The most important LoRa setting. Match whatever preset your local community uses. Do not change this without coordinating with your network. Valid values: `SHORT_TURBO`, `SHORT_FAST`, `SHORT_SLOW`, `MEDIUM_FAST`, `MEDIUM_SLOW`, `LONG_TURBO`, `LONG_FAST` (default), `LONG_MODERATE`, `LONG_SLOW`. Note: `LONG_TURBO` appears in the official Meshtastic radio-settings preset table, but whether it is exposed as a selectable `ModemPreset` may depend on your firmware/app build. Confirm it is available in your firmware version before relying on it. ## Hop Limit ``` meshtastic --set lora.hop_limit 3 ``` Maximum relay hops before a packet is discarded. Default 3, maximum 7. Increase to 4-5 for larger networks where edge nodes aren't reliably reached. Higher hop limits increase network load — raise it only when you understand the implications. ## Transmit Power ``` meshtastic --set lora.tx_power 0 # 0 = use the region maximum (recommended default) ``` Power in dBm. Leave `tx_power` at 0, which tells the firmware to use the region maximum (the firmware applies the correct per-region and per-board cap). Only set an explicit dBm value if you must reduce power for EIRP compliance with a high-gain antenna. The firmware enforces the maximum for your region; setting higher than the max is silently clamped. For US/Canada (47 CFR 15.247): the conducted maximum is **1 W (30 dBm)**, referenced to an antenna gain of up to 6 dBi — which yields 36 dBm EIRP only at exactly 6 dBi. For every dB of antenna gain **above 6 dBi you must reduce conducted (transmitter) power by the same number of dB**, so 36 dBm EIRP is a derived ceiling, not a flat allowance you can fill with any antenna. Note also that most Meshtastic LoRa radios (e.g. SX1262 modules) physically cap conducted output near ~22 dBm, so 30 dBm is the regulatory limit, not what the hardware actually emits. ## Channel Number and Frequency Override ``` # Set to channel 7 (specific frequency slot) meshtastic --set lora.channel_num 7 # Override frequency directly, in MHz (advanced users only) meshtastic --set lora.override_frequency 906.875 ``` By default, Meshtastic derives the frequency from a hash of your channel name, automatically aligning nodes on the same channel. Channel 0 (default hash-based slot) is correct for most deployments. `override_frequency` is specified in **MHz**. **Warning:** setting `override_frequency` disables the channel-name hash and takes the node off the community frequency silently — a single node set this way goes deaf to everyone else. Do not combine `override_frequency` with `channel_num`; use one or the other. Only change either setting if your community has standardized on a specific slot. ## Bandwidth, Spreading Factor, Coding Rate (Advanced) To set these individually, first disable the preset, then set the values. Not recommended unless you are an RF engineer or are matching a specific non-standard deployment: ``` meshtastic --set lora.use_preset false meshtastic --set lora.bandwidth 250 meshtastic --set lora.spread_factor 11 meshtastic --set lora.coding_rate 5 ``` Bandwidth values (kHz): 31.25, 62.5, 125, 250, 500. The CLI accepts the integers 31, 62, 125, 250, 500 (the device interprets 31 → 31.25 kHz and 62 → 62.5 kHz). Spreading Factor 7-12. Coding Rate 5-8 (represents 4/5 through 4/8). ## Use Preset vs Ignore MQTT ``` # Ignore incoming packets from MQTT downlink meshtastic --set lora.ignore_mqtt true ``` When downlink is enabled, nodes rebroadcast packets received via MQTT. In a large network with many MQTT-connected nodes, this can cause significant packet amplification. Setting `ignore_mqtt true` on repeaters that don't need to rebroadcast MQTT traffic reduces this load. # Choosing the Right Modem Preset The modem preset is the single most impactful LoRa setting - it determines range, data rate, and network capacity. This page provides a decision framework for choosing the right preset for your deployment. ## Step 1: Ask Your Community First Before anything else: what does your local mesh network use? Ask on the community Discord, check meshmap.net, or contact local operators. Using a different preset isolates your node from the existing community network. This is the most important step. ## Step 2: If Building a New Network - Choose by Size ### Sparse / Rural Networks (under 30 nodes in range) Use **Long Fast** (the Meshtastic default). At low node density, network capacity is not a concern. Maximizing range ensures the widest possible coverage from each node. Long Fast provides excellent range while keeping data rate high enough for reasonable message latency. ### Medium-Density Networks (30-60 nodes) Consider **Medium Fast** or **Medium Slow**. At this density, Long Fast's airtime per packet starts contributing to congestion, especially with position telemetry from many nodes. Medium presets carry data faster (Medium Fast is about 3x quicker than Long Fast, Medium Slow about 2x), which reduces airtime while maintaining similar range in most terrain. ### Dense Urban Networks (60+ nodes) Use **Medium Fast** or **Medium Slow**. Some large community networks have reported success migrating away from Long Fast to faster presets - for example, the Bay Area Group (150+ nodes) moved to Medium Slow, and the Wellington Region Mesh in New Zealand migrated its mesh to Short Fast - and report reliability improvements. At high node counts, a full-length Long Fast packet (SF11/BW250) occupies roughly 1-2 seconds of airtime, creating constant background congestion; faster Medium presets cut airtime substantially and free up channel capacity. Actual airtime depends on payload size - a small (~50 byte) Long Fast packet is roughly 400-700 ms. ## Preset Selection Matrix Note: Long Turbo's 150 dB link budget is essentially the same as Medium Slow (150.5 dB) and below Long Fast (153 dB). It trades Long-Fast range for a higher data rate by using 500 kHz bandwidth, so treat its coverage as Medium-tier, not Long-tier. (Long Turbo's status as a current firmware enum should be confirmed against the firmware protobuf.) ## Migrating a Network to a Different Preset Changing presets on an active community network requires careful coordination: 1. Announce the planned change at least 1 week in advance 2. Document the exact new preset value 3. Schedule a cutover time (e.g., Sunday midnight when traffic is lowest) 4. Have all operators change their nodes simultaneously 5. Verify connectivity after the change 6. Update all network documentation with the new preset Nodes that don't update in time will be invisible to the network until their operator updates. Plan for 2-4 weeks of dual-operation where some users are still on the old preset.