LoRa vs Wi-Fi vs Bluetooth: range, power and data rate compared

People often ask which radio is "best". There is no best. Wi-Fi, Bluetooth LE and LoRa were each designed around a different corner of the same triangle: range, data rate and power. Push one corner out and the other two pull back. Once you see that triangle, the choice for any given project is usually obvious.

01Meet the three radios

Wi-Fi is the local-network radio. It runs mainly in the crowded 2.4 GHz band and, on newer gear, in 5 GHz and 6 GHz. It is built to move megabytes: web pages, firmware updates, camera streams. The price is power. A Wi-Fi transmit burst on a typical ESP32 draws a few hundred milliamps, so Wi-Fi nodes usually want mains power or a big battery.

Bluetooth Low Energy (BLE) also lives in 2.4 GHz, but it was designed from the start to run for months or years on a coin cell. It talks to things that are close by, most often a phone. Think fitness bands, thermometers, beacons and the wireless setup screen on a gadget. It moves far less data than Wi-Fi, and that is the point.

LoRa (short for "long range") is a sub-GHz radio, 868 MHz in Europe and 915 MHz in the US. Lower frequencies travel further and slip through walls and foliage better than 2.4 GHz. LoRa uses a spread-spectrum chirp that can be decoded even when it is buried below the noise floor. That buys enormous range, at a data rate measured in hundreds of bits per second, not megabits.

02Side by side

Here are the figures that matter, with realistic ranges rather than best-case marketing numbers. Treat every value as "typical", because antenna, environment and settings all shift them.

Read the table as a set of trade-offs, not a scoreboard. The "winner" in any row is a loser in another. LoRa wins range by throwing away speed; Wi-Fi wins speed by burning power over a short hop; BLE sits in between and optimises for a tiny energy budget.

03Range: theory versus reality

Datasheets love to quote line-of-sight numbers taken on a hilltop. Real buildings are full of concrete, metal, water (people) and other radios. Two things drive the difference.

• Frequency. Lower frequencies carry further for the same power and pass through obstacles more easily. This is the single biggest reason LoRa at 868/915 MHz outranges Wi-Fi and BLE at 2.4 GHz.
• Receiver sensitivity. LoRa's chirp spread spectrum lets a receiver pull a packet out from roughly 20 dB below the noise floor. A normal Wi-Fi or BLE receiver needs the signal above the noise. That sensitivity, not raw transmit power, is where most of LoRa's range comes from.

So in practice: BLE covers a room or an open space up to tens of metres; Wi-Fi covers a flat or a floor of an office; LoRa covers a neighbourhood, a farm or a valley. Put any of them behind enough concrete and the number falls hard.

04Data rate versus power

Data rate and power are tied together. Moving more bits per second means the transmitter is awake longer and working harder.

• Wi-Fi moves the most data and therefore costs the most energy per session. If a node only sends a few bytes an hour, Wi-Fi's overhead (associating, DHCP, TLS) wastes most of the energy on setup, not payload.
• BLE is built for short, frequent exchanges. A sensor can wake, advertise or connect, send a reading in a few milliseconds and sleep. On a coin cell that pattern lasts months to years.
• LoRa is slow on paper but very cheap over time. A packet with a few dozen bytes is on air for a fraction of a second, so even a long link costs little energy per message. Send one reading every ten minutes and a pair of AA cells can last a year or more.

The lesson: match the radio to how much data you actually send and how often. A doorbell camera needs Wi-Fi. A soil-moisture probe in a field 2 km away needs LoRa. A wrist strap talking to your phone needs BLE.

05Topology and typical use cases

How devices connect to each other is as important as the link itself.

Notice LoRa's flexibility. For a fleet of sensors reporting to the cloud you would run LoRaWAN through a gateway. For two hikers texting with no infrastructure at all, a LoRa mesh like Meshtastic forwards messages node to node. Wi-Fi and BLE almost always assume something (an access point, a phone) is there to talk to.

06Decision guide: which to pick

Work from the job, not the radio. A short checklist settles most projects:

1. Pick Wi-Fi when you need real internet access, move more than a few kilobytes at a time, or stream audio or video, and mains power or regular charging is available.
2. Pick Bluetooth LE when the other end is a phone or a hub within a room, the messages are small and frequent, and the device must run a long time on a tiny battery.
3. Pick LoRa when the link is longer than a Wi-Fi hop, there is no cellular or Wi-Fi coverage, and you only need to send small readings or short text now and then.
4. Combine them when the use case spans corners: collect data over LoRa, configure the node over BLE from your phone, and dump a daily batch over Wi-Fi when the device is back in range.

That last line is where a multi-radio board earns its place. Because the SGP Card Mini carries all three on one ESP32-S3, you can prototype a design that uses each radio for what it is good at, then decide later which ones the shipping product actually needs.

07LoRa's spreading factor, explained simply

LoRa has one dial newcomers trip over: the spreading factor (SF), from SF7 to SF12. Think of it as how slowly and clearly the radio speaks.

• Low SF (SF7) is talking fast. Each message is short and uses little airtime, so you send more often and spend less energy per packet, but the signal is easier to lose at distance.
• High SF (SF12) is spelling every word out slowly. The receiver can dig the message out of a much weaker, noisier signal, so it reaches farther and through more walls, but each packet takes far longer to send.

The catch is airtime. Moving from SF7 to SF12 can make the same message take roughly ten times longer on air. That drains the battery, fills the channel and runs into the duty-cycle limits on the 868 MHz band. So the habit is simple: use the lowest spreading factor that still reaches reliably, and only climb higher when packets start going missing.

08Send a LoRa packet with an ESP32

Here is the smallest useful LoRa transmitter, using the RadioLib library and a Semtech SX1262 radio. The pin numbers are an example wiring for an ESP32-S3 board; change them to match yours.

#include <RadioLib.h>

// SX1262 pins on this example board: NSS, DIO1, RST, BUSY
SX1262 radio = new Module(38, 48, 47, 26);

int count = 0;

void setup() {
  Serial.begin(115200);
  // 915.0 MHz for the US. Use 868.0 in Europe.
  int state = radio.begin(915.0);
  if (state != RADIOLIB_ERR_NONE) {
    Serial.printf("begin failed, code %d\n", state);
    while (true) delay(10);
  }
  radio.setOutputPower(14);        // dBm, within your region's limit
  radio.setSpreadingFactor(9);     // SF7 fast & short ... SF12 slow & far
  radio.setBandwidth(125.0);       // kHz
}

void loop() {
  String msg = "node1 #" + String(count++);
  int state = radio.transmit(msg);
  if (state == RADIOLIB_ERR_NONE) Serial.println("sent: " + msg);
  else                            Serial.printf("tx failed, code %d\n", state);
  delay(5000);                     // go slow: respect duty-cycle / fair-use limits
}

A matching receiver calls radio.startReceive() and reads with radio.readData(). Keep both radios on the same frequency, bandwidth and spreading factor, or they will not hear each other.

09FAQ

SGP Lab — written by the team that designs and builds SGP hardware in Europe. We test every example on our own boards before publishing.