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 Preset Link Budget Data Rate Best For Avoid When Long Slow 158.5 dB 0.18 kbps Extreme range testing Network > 5 nodes; can saturate channel Long Moderate 156 dB 0.34 kbps Very sparse, maximum range needed Any network with moderate traffic Long Fast 153 dB 1.07 kbps Sparse/rural networks; new deployments Dense networks >50 nodes Long Turbo 150 dB 1.34 kbps Higher data rate at Medium-tier range When you need Long-Fast range (its 150 dB link budget is below Long Fast's 153 dB) Medium Slow 150.5 dB 1.95 kbps Medium to dense networks; recommended Absolute maximum range required Medium Fast 148 dB 3.52 kbps Dense networks; high message volume Long range links needed Short Slow 145.5 dB 6.25 kbps Very dense, high-throughput local nets Any nodes more than 5 km apart Short Fast 143 dB 10.9 kbps Highest throughput applications Any nodes more than 3 km apart Short Turbo 140 dB 21.9 kbps Maximum throughput Uses 500 kHz bandwidth, permitted in the US/Canada 902-928 MHz band but not legal in some other regions (e.g., parts of the EU) - check your region 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: Announce the planned change at least 1 week in advance Document the exact new preset value Schedule a cutover time (e.g., Sunday midnight when traffic is lowest) Have all operators change their nodes simultaneously Verify connectivity after the change 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.