LoRa vs LoRaWAN: How LoRa Modulation Works in Industrial IoT

1. What Is LoRa?

LoRa is a wireless modulation technique used to move small amounts of data over long distances at very low power. It is a physical-layer (PHY) technology from Semtech, built on Chirp Spread Spectrum (CSS), and it works in licence-free sub-GHz ISM bands such as 433, 470, 868 and 915 MHz, with 2.4 GHz variants available for shorter links. It is used widely in utility metering, agriculture, building automation, logistics and industrial monitoring.

Core characteristics:

• Chirp spread spectrum modulation: every symbol is a frequency sweep, and the receiver correlates the whole sweep instead of sampling a single tone. That processing gain lets a LoRa receiver decode signals that sit below the noise floor, which is why a LoRa link closes at distances where a narrowband FSK link at the same output power cannot.
• Licence-free sub-GHz operation: longer wavelength means better penetration through walls, vegetation and metal clutter than 2.4 GHz, and no spectrum licence or subscription is required.
• Low data rate by design: a LoRa payload is typically tens of bytes, and the configurable data rate ranges from well under a kilobit per second up to a few tens of kilobits per second depending on spreading factor and bandwidth.
• Low energy: because a transmission lasts milliseconds and the radio sleeps in between, a duty-cycled LoRa sensor can run for years on a single battery.
• A tunable range-versus-speed trade-off: spreading factor and bandwidth are not fixed. The same module can be configured for maximum range or for faster, shorter links without changing hardware.

2. How Does LoRa Work?

LoRa does not simply key a carrier on and off. Data is encoded into chirps whose rate of change carries the information, and the receiver's demodulator does the heavy lifting. In practice a transmission looks like this:

1. Symbol encoding with a spreading factor: each symbol is transmitted as a chirp sweeping the chosen bandwidth, and the spreading factor (SF7 to SF12 on most sub-GHz LoRa radios) sets how many chips represent one symbol. Higher SF means more chips per symbol and more processing gain.
2. Bandwidth and data rate selection: the bandwidth (typically 125, 250 or 500 kHz) and the spreading factor together define the air data rate. A narrow bandwidth with a high spreading factor gives the longest range and the slowest link; the reverse gives speed at the cost of sensitivity.
3. Packet assembly: the transmitter builds a preamble for synchronisation, an optional header that declares payload length and coding rate, the payload itself, and a CRC. LoRa packets are deliberately short, which keeps airtime and energy consumption low.
4. Transmission with duty-cycle awareness: the radio is half-duplex, so it cannot receive while it transmits. In the European 868 MHz band, regional rules impose duty-cycle limits on many sub-bands, so a node cannot transmit continuously even if the hardware allows it.
5. Reception and link margin: any gateway in range can demodulate the packet, and it reports both RSSI and SNR. A negative SNR is normal and healthy for LoRa, which is a useful diagnostic detail when you are comparing links.
6. Application-layer acknowledgement: LoRa itself defines no acknowledgement. Confirmed delivery, retries and downlink commands belong to the protocol above it, which is exactly where LoRaWAN comes in.

3. What Is LoRaWAN?

LoRaWAN is an open network protocol defined by the LoRa Alliance that runs on top of the LoRa physical layer. It is a media access and networking layer: it specifies the network architecture, how devices join, how downlinks are scheduled, and how data rates are managed. The relationship is the same as the one between an Ethernet PHY and TCP/IP — LoRa moves the bits, LoRaWAN decides who talks, when, and to which server.

Core characteristics

• Star-of-stars architecture: end devices talk to gateways, and gateways forward packets to a network server over an IP backhaul. A gateway is a transparent bridge with no application logic; the same uplink can be received by several gateways without duplication at the application server.
• Device classes A, B and C: Class A opens two short receive windows after each uplink and is the baseline for battery devices; Class B adds scheduled beacon slots for predictable downlink latency; Class C keeps the receiver open almost continuously for mains-powered actuators.
• Activation and security: devices join by OTAA or ABP and use separate network and application session keys, with AES-128 encryption at both layers.
• Adaptive data rate and regional parameters: the network server can instruct a device to change spreading factor and bandwidth as link conditions change, and the regional parameter documents fix the channel plan, duty cycle and payload limits per region.

4. LoRa vs LoRaWAN: What Is the Difference?

LoRa and LoRaWAN are not alternatives you pick between at the same layer. They are two layers of one stack, and the confusion comes from vendors using the names interchangeably on product pages.

The practical rule: if you are connecting a handful of devices you control end to end, LoRa modules with your own protocol are simpler. If you are deploying hundreds of nodes that must be managed, joined and updated centrally, LoRaWAN is worth the extra layer.

5. LoRa Configuration and Key Parameters

Two groups of parameters have to line up before a LoRa link behaves: the radio side, where both ends must use the same modulation settings, and the serial side, which is how your controller talks to the module.

Radio side

• Frequency and sub-band: 433, 470, 868 or 915 MHz depending on region and local regulation. Both ends must be on the same band, and the antenna must match it — a 915 MHz antenna on an 868 MHz radio costs range.
• Spreading factor (SF7 to SF12): the single most influential setting. A higher spreading factor increases sensitivity and range but multiplies airtime, so it also increases energy per packet. Both ends must use the same value in a raw LoRa link.
• Bandwidth (125, 250 or 500 kHz): wider bandwidth means higher data rate and shorter airtime but lower sensitivity. 125 kHz is the default for long-range links.
• Coding rate (4/5 to 4/8): the forward error correction overhead. 4/5 is the fastest, 4/8 is the most resilient; uplinks often use 4/5 and downlinks 4/8.
• Output power: configured in dBm, for example 22 or 30 dBm on Ebyte's E22 and E220 series modules, and always within local limits. Raising power is not a substitute for antenna height and a good ground plane.
• Synchronisation word / network ID: keeps two LoRa networks on the same band from demodulating each other's packets. Mismatched sync words are a classic reason a link looks dead.
• Payload length and airtime: keep payloads short. Long packets raise the probability of collision and, with duty-cycle limits, eat your transmission budget.

Serial side, between the module and the controller

• Baud rate: 9600, 19200, 38400 or 115200 bps are the common settings. The UART rate must match your controller, and the air data rate must be able to keep up with it.
• Data bits, parity and stop bits: 8-N-1 is the near-universal default; it must match the device on the other end of the line.
• Flow control: usually none. If your controller cannot buffer a burst, slow the UART rather than enabling hardware flow control the module may not implement.
• Air data rate versus UART rate: if the UART is much faster than the air data rate, the module's buffer overflows and packets are silently dropped. Size the buffer or pace the transmission in firmware.
• Transparent versus packet mode: transparent mode forwards bytes as they arrive and is simplest for Modbus RTU bridging; packet mode lets you frame data yourself and takes over the timing.

6. When LoRa Fits and When It Does Not

Good fit

• Battery-powered sensors that report a few dozen bytes every few minutes or hours.
• Sites with no mains power and no cellular coverage, such as farms, water networks, mines and remote tanks.
• Bridging an existing RS485 or Modbus RTU segment to a remote cabinet without trenching cable.
• Deployments where the data rate requirement is genuinely low — temperature, level, status, counters, alarms.

Poor fit

• Streaming, video, firmware over the air to many nodes, or anything needing sustained throughput.
• Control loops that need low, deterministic latency; duty cycle and retransmission make the timing unpredictable.
• Dense networks with many nodes transmitting at high power on the same channels — collisions rise quickly.
• Indoor campus deployments where an existing Wi-Fi or wired network already reaches every node; LoRa adds cost without adding value.

7. LoRa in Real Industrial and IoT Systems

In industrial automation, energy and environmental monitoring, LoRa usually appears in one of two shapes: a module inside a product, or a radio station bridging a serial bus.

Modules inside a product. A device that already has a microcontroller needs only a transceiver and an antenna. The E220-400T30S covers the 433 and 470 MHz bands with 30 dBm output over a UART interface, which suits long-range telemetry where a small amount of data has to travel a long way. Where the design needs a lower power budget or a different band, the E22-400T22D-V2 (SX1268, 22 dBm, UART TTL compatible with 3.3 V and 5 V logic) and the E22-230T30S-V2 (SX1262, 230 MHz, 30 dBm) cover the same job at different frequencies.

Radio stations on the bus side. When the sensors are RS485 or Modbus RTU devices that must keep working as they are, a DTU turns the wired endpoint into a wireless one. The E95-DTU(433L20-485)-V8 pairs an RS485 port with 20 dBm LoRa output and Modbus support for links up to roughly 3 km in open conditions, and the E95-DTU(400SL30-485) adds multi-level relay networking, which is the practical answer when a single hop does not clear the site.

Antennas deserve the same attention as the radio. A matched antenna such as the TX915-JKS-20 (915 MHz, 2.5 dBi, SMA-J) or the outdoor TX868-BLG-26 fiberglass omni for 868 and 915 MHz often improves a marginal link more than any configuration change.

The pattern that works: pick the band and the antenna for the physical path, pick the spreading factor for the required range, and keep the interface to the existing device transparent.

8. FAQ: Common LoRa Problems and Field Troubleshooting

Q1: Is LoRa being replaced by NB-IoT or satellite IoT?

No, and the three cover different ground. NB-IoT needs cellular coverage and a subscription, so it wins where a mains supply and an operator network exist. Satellite IoT is unmatched for truly remote assets but carries a much higher cost per message. LoRa remains the cheapest way to cover a site you control, with no subscription and no dependency on a third-party network — which is why it still dominates private telemetry.

Q2: How do I decide between raw LoRa and LoRaWAN for a private network?

Count the nodes and the operational burden. Under roughly a few dozen devices that you own end to end, raw LoRa modules with your own simple protocol are easier to debug and have no server to maintain. Once you need centralised key management, over-the-air configuration, roaming between gateways, or hundreds of nodes, LoRaWAN's extra layer pays for itself.

Q3: My LoRa link works at 100 m but not at 2 km. Where should I look first?

• Antenna and band match — a 433 MHz antenna on an 868 MHz radio, a damaged pigtail or a missing ground plane will cut range long before the radio settings matter.
• Spreading factor and bandwidth — if the link was tuned for speed with a low SF and 500 kHz bandwidth, sensitivity is much lower than at SF12 with 125 kHz.
• Fresnel zone and height — raising either antenna by a metre often does more than raising output power, particularly in urban or vegetated sites.
• Output power within regulation — check that the configured dBm is actually what the region permits and what the module delivers at your supply voltage.
• Interference — survey the band with RSSI before assuming the problem is distance.

Q4: Packets arrive occasionally, or arrive corrupted. What should I check?

• Spreading factor, bandwidth and coding rate mismatch between the two ends — this is the most common cause and it produces partial reception rather than complete silence.
• Synchronisation word or network ID mismatch — the receiver may hear the packet and discard it.
• UART speed versus air data rate — if the serial side is faster than the radio can transmit, the module buffer overflows and packets are lost silently.
• Power supply sag during transmit — a 30 dBm module draws a current spike; an undersized regulator resets the radio mid-packet.
• Duty cycle and collision — two nodes transmitting at the same time on the same channel will lose packets, and more retries make it worse.

Q5: The LoRa link is healthy but my RS485 Modbus device does not answer through it. Why?

• Serial parameters on the radio station — the DTU's baud rate, parity and stop bits must match the device exactly; a mismatch often looks like an occasional timeout rather than a clean failure.
• Turnaround time — the radio adds airtime on both directions. If the master's timeout is shorter than a round trip at the current spreading factor, the response arrives after the master has given up. Increase the timeout before increasing the data rate.
• Transparent versus packet mode — Modbus RTU depends on silent intervals to delimit frames. A station that fragments or buffers the stream can break frame timing, so keep it in transparent mode.
• Addressing and half-duplex collision — two masters polling the same bus, or a repeater that forwards its own traffic, will produce errors that look like device faults.