What LoRa Actually Is
LoRa — short for Long Range — is a proprietary physical-layer radio modulation developed and patented by Semtech. Semtech owns the IP on the modulation itself and manufactures the transceiver silicon (the SX126x family is the current generation you’ll find on every Heltec V3, LILYGO T-Beam, and RAK WisBlock board sold into the Meshtastic ecosystem). Credit where it’s due: every mesh radio running on a Meshtastic node today is riding Semtech’s chirp-spread-spectrum design.
The confusion most plebs hit is that LoRa and LoRaWAN get mashed together. They’re not the same thing. LoRa is the physical layer — the radio modulation. LoRaWAN is a network protocol on top of LoRa that assumes centralized gateways and a network server. Meshtastic throws LoRaWAN out and builds a peer-to-peer mesh directly on raw LoRa frames. That distinction is the entire reason Meshtastic fits the sovereign stack — more on that below.
The Physical Layer: Chirp Spread Spectrum
Most radios you’ve used — Wi-Fi, Bluetooth, cellular — push a carrier at a fixed frequency and modulate amplitude, phase, or both to encode bits. LoRa does something different. Every LoRa symbol is a chirp: a signal that sweeps linearly from one end of the bandwidth to the other (either up-chirp or down-chirp). The receiver correlates incoming energy against the expected chirp shape to decode bits.
This matters for three reasons:
- Processing gain. Because the receiver is correlating against a known sweep, it can pull signal out of noise that sits below the noise floor — we’re talking sensitivities of −137 dBm and lower. That’s how a 22 dBm (~158 mW) transmitter gets multi-kilometer range.
- Doppler and clock tolerance. Chirps are robust to frequency offsets. Your cheap crystal oscillator drifting a few ppm is fine. So is a moving transmitter.
- Co-channel coexistence. Different spreading factors are orthogonal — two LoRa transmissions on the same center frequency with different spreading factors don’t collide at the demodulator. That’s a big deal for dense networks.
Nothing about chirp-spread-spectrum was invented for Bitcoin or IoT. It’s an old military radar and comms technique that Semtech commercialized for low-power long-range links. But the properties — cheap silicon, long range, low power, robust to noise — are exactly what a sovereign communications layer needs.
Spreading Factor: The Range-Versus-Throughput Dial
The knob you tune on LoRa is spreading factor (SF), which ranges from SF7 to SF12. Higher spreading factor means each bit takes longer on air, which buys processing gain and range at the cost of throughput.
- SF7: shortest time-on-air, highest data rate (~5.5 kbps at BW=125 kHz), shortest range. Good for dense urban meshes where nodes are close together.
- SF8 / SF9 / SF10: the mid-range sweet spots. SF10 at 125 kHz gives you roughly ~1 kbps and a several-kilometer reach — this is the neighborhood you live in for most Meshtastic defaults.
- SF11: long-range, slow. Around ~500 bps at 125 kHz bandwidth. Useful for very sparse or fringe links.
- SF12: maximum range, minimum speed. Around ~250 bps at 125 kHz. Every symbol takes about a second. This is the mode you set when you’re trying to bridge 20+ km of line-of-sight.
Meshtastic encodes a few common SF/BW combinations as named presets — LongFast, LongSlow, VeryLongSlow, MediumFast, ShortFast, and so on. All nodes on a channel must use the same preset; otherwise they literally can’t hear each other. Pick a preset that matches the density and range of your mesh and stick with it.
The tradeoff to internalize: every step up in spreading factor roughly halves your throughput and roughly doubles your range. You can’t cheat the physics. If you want to carry more data, you’re shortening range. If you want to reach further, you’re carrying less data per second.
Bandwidth: The Other Half of the Equation
LoRa also lets you pick the channel bandwidth. Common options are 125 kHz, 250 kHz, and 500 kHz. Wider bandwidth means faster data rates at the same SF but also means worse sensitivity (noise floor scales with bandwidth). The default almost every mesh runs is 125 kHz — it’s the best compromise between throughput and range, and it’s what the Meshtastic presets target.
One subtle thing: regional regulations in some jurisdictions effectively force 125 kHz by capping dwell time. Others allow 500 kHz for short high-throughput bursts. Meshtastic picks bandwidth per preset; you don’t tune it independently unless you know exactly what you’re doing.
Regional Regulation
LoRa runs on license-free ISM bands. That’s what makes it accessible to plebs. But each regulator lays down its own rules on the band.
US and Canada: 902–928 MHz (FCC Part 15 / ISED)
The 900 MHz ISM band in North America gives LoRa a big chunk of spectrum to play in. Typical channel centers land around 903–915 MHz. The regulator — FCC in the US, ISED in Canada — caps effective isotropic radiated power (EIRP) but does not impose a strict duty cycle limit. Meshtastic’s US region setting picks a 64-channel plan inside 902–928 MHz.
EU: 863–870 MHz (ETSI EN 300 220)
Europe runs on the 868 MHz band with much tighter spectrum allocation. Crucially, ETSI imposes a duty cycle limit — typically 1% per hour on the main sub-bands. In practice that caps how often your node can legally transmit. Meshtastic’s EU region setting handles the channel plan, but plebs in Europe need to be aware that a chatty mesh can run into the duty-cycle ceiling and be forced to back off.
Other Regions
Semtech publishes regional guidance, and Meshtastic’s firmware has entries for ANZ (Australia/New Zealand, 915–928 MHz), JP (Japan, 920–928 MHz), KR, TW, TH, IN (865–867 MHz), RU, CN, and others. Pick your region in the firmware and the channel plan is handled for you. What the firmware can’t do is import the right antenna — buy one tuned to your band.
LoRa vs LoRaWAN: The Decentralization Fork
This is the cruxed-up distinction plebs need to understand, because it’s the exact fork where the sovereign stack diverges from the corporate IoT stack.
LoRaWAN is the protocol most commercial LoRa deployments run. It works like this:
- Your LoRa end device (a sensor, a tracker, whatever) transmits to centralized gateways.
- The gateways backhaul over the internet to a network server.
- The network server handles deduplication, authentication, and routing, and forwards application data to an application server.
- Devices authenticate with pre-shared keys issued by the network operator.
It’s a good protocol for metering, asset tracking, and agriculture. It’s a terrible fit for sovereignty because the gateway-and-server model recreates exactly the ISP-and-platform choke points that we’re trying to escape. If the network server is offline, your devices are silent. If the operator banishes you, you’re off the network.
Meshtastic throws LoRaWAN away and builds a peer-to-peer mesh directly on raw LoRa frames. Every node is a peer. Every node relays traffic for every other node. There is no central server, no gateway, no operator. Messages hop from node to node until they reach their destination or expire. It’s slower than LoRaWAN. It’s not as efficient. But it has no central point to capture, kill, or subpoena. That’s the sovereign choice.
Both protocols run on the same Semtech silicon. The only difference is the software stack above the PHY. The plebs pick Meshtastic.
Practical Range Math
Plebs want numbers. Here’s what actually happens in the field with a stock Heltec V3 or T-Beam running the Meshtastic LongFast preset (SF11, BW=250 kHz at the time of writing) and a decent antenna:
- Dense urban with buildings: 300m to 1.5 km per hop, depending on obstructions. Multiple hops stitch together city-wide coverage.
- Suburban, one-story obstructions: 1.5 to 5 km per hop is typical.
- Line-of-sight across a valley or open water: 10 to 20+ km per hop. Not a typo. LoRa is a line-of-sight protocol and thrives on clear air.
- Extreme setups: community records with balloon-lifted nodes, mountain-peak relays, and directional Yagis have demonstrated 300+ km single-hop links. That’s not your backyard, but it shows the headroom.
Three rules of thumb to keep handy:
- Every 6 dB of added antenna gain roughly doubles distance (in free space). So upgrading from a 2 dBi whip to an 8 dBi collinear is a ~2x range improvement — if your terrain allows it.
- Doubling transmit power adds 3 dB and buys you ~40% range. Power is rarely the limiting factor; height and antenna are.
- Dropping one spreading factor (e.g., SF10 → SF11) adds about 2.5 dB of link budget, at half the throughput.
The link-budget math is the gift of chirp-spread-spectrum. Plebs who build 10+ km links on a shoestring can thank Semtech’s engineers, not their own transmit power.
Why This Matters for Sovereign Comms
If you zoom back out, LoRa’s physical properties line up almost too well with what the sovereign pleb needs from the comms layer:
- License-free: no regulator to grant or revoke permission for everyday pleb use.
- Cheap silicon: $5 radios, $25 dev boards. Mass accessibility.
- Long range, low power: solar-friendly, battery-friendly, no grid dependence.
- Peer-to-peer friendly: when layered with Meshtastic instead of LoRaWAN, no central gateway, no operator, no kill switch.
- Line-of-sight physics: rewards elevation and antenna craft, which are skills plebs can learn and improve over time.
Stack all of that and you get the foundation for broadcasting Bitcoin transactions without the internet, for running a Hashcenter site that talks to you when the ISP dies, and for reaching neighbors when the tower is down.
LoRa is one more layer decentralized in the most literal sense: a physical layer that no one owns after you buy the chip, on a band no one can kick you off of, with a mesh that has no gateway to seize. Semtech built the radio; the plebs built the sovereign use case.
Further Reading
- Meshtastic getting started — the practical companion to this theory post.
- Bitcoin over Meshtastic — signing and broadcasting transactions over the mesh.
- Off-grid Hashcenter comms — applying the mesh to remote mining sites.
- /sovereignty/ hub — the full sovereign stack.
