What Is LoRa and LoRaWAN?

Detailed Explanation

LoRa and LoRaWAN address a specific gap in wireless connectivity: the need to send small amounts of data over long distances, reliably, from a device running on a primary battery for years. No other widely available protocol achieves multi-kilometre range with sub-5 µA average current consumption — that combination is what makes LoRa the dominant choice for large-scale IoT deployments in agriculture, utilities, logistics, and environmental monitoring.

For background on RF signal concepts — frequency, wavelength, ISM bands, and dBm — see what are RF signals and how are they used in electronics?. For a comparison of LoRa against Bluetooth LE, Wi-Fi, and Zigbee across use-case dimensions, see Bluetooth vs Wi-Fi vs LoRa vs Zigbee: which protocol should you use?.

LoRa Modulation

LoRa uses chirp spread-spectrum (CSS) modulation, a technique originally developed for military radar. A chirp is a signal that continuously sweeps from one frequency to another (either upward or downward) over a defined bandwidth. Binary data is encoded by selecting from a set of chirp starting offsets.

The key parameters that control the RF link are:

Spreading Factor (SF) — an integer from 7 to 12. Each increase in SF doubles the chips per symbol (the number of chirp sweeps per bit of data), which halves the data rate but improves the receiver's sensitivity by approximately 2.5 dB. At SF12, the receiver can decode a signal 20 dB below the noise floor — the same margin that makes the signal appear as noise to a conventional narrowband receiver.

Bandwidth (BW) — the frequency range swept by each chirp: 125 kHz, 250 kHz, or 500 kHz in standard LoRaWAN configurations. Wider bandwidth increases data rate (more chirp sweeps per second) but reduces sensitivity by 3 dB per doubling of bandwidth.

Coding Rate (CR) — forward error correction overhead: 4/5, 4/6, 4/7, or 4/8. CR 4/5 adds 25% overhead; CR 4/8 adds 100% but provides the most robust error correction. LoRaWAN typically uses CR 4/5 in normal operation.

The resulting data rates for common SF/BW combinations:

A higher SF number means better range (higher sensitivity) at the cost of lower data rate and longer time-on-air. At SF12, a 20-byte payload takes approximately 2 seconds to transmit — 6× longer than at SF7.

LoRaWAN Network Architecture

LoRaWAN adds a network protocol on top of LoRa modulation, defining a star-of-stars topology:

1. End devices transmit LoRa frames using OTAA (Over-The-Air Activation) or ABP (Activation by Personalisation). End devices do not associate with individual gateways — they transmit, and any gateway within range receives.
2. Gateways receive LoRa frames on all configured channels simultaneously (a LoRaWAN gateway typically monitors 8 channels in parallel) and forward them as IP packets to the network server over Ethernet, Wi-Fi, or cellular backhaul.
3. Network server de-duplicates frames received by multiple gateways, runs the ADR algorithm, manages MAC commands (join-accept, link check, SF/power adjustments), and routes application payloads to the application server.
4. Application server receives decoded payloads and delivers them to the application (database, dashboard, automation system).

This architecture means end devices are low-complexity — they transmit without needing to know which gateways are in range, and gateway infrastructure scales independently of end-device firmware.

Device Classes:

• Class A (all devices must implement this): opens two receive windows after each uplink (RX1 at ~1 s, RX2 at ~2 s after Tx), then sleeps until the next transmission. Lowest power consumption. Downlink from network server is only possible in these two windows.
• Class B: adds scheduled beacon-synchronised receive windows, enabling periodic downlink at defined intervals. Requires GPS-synchronised gateways for the beacon.
• Class C: receiver is open continuously except during transmission. Enables immediate downlink at any time, but at the cost of constant radio activity — suitable for mains-powered devices only.

LoRaWAN AU915 in Australia

In Australia, LoRaWAN operates under the AU915 regional parameters (defined in the LoRa Alliance Regional Parameters document RP002). Key specifications:

• Uplink frequencies: 64 channels at 125 kHz bandwidth from 915.2 MHz to 927.8 MHz (200 kHz channel spacing), plus 8 channels at 500 kHz bandwidth.
• Downlink frequencies: 8 channels at 500 kHz bandwidth from 923.3 to 927.5 MHz.
• Maximum EIRP: +30 dBm (1 W), under the ACMA Radiocommunications (Low Interference Potential Devices) Class Licence.
• Sub-band rotation: LoRaWAN AU915 divides the 64 uplink channels into 8 sub-bands of 8 channels each. TTN and Helium deployments in Australia use sub-band 2 (channels 8–15 + 65); private deployments can use any sub-band but must configure both end devices and gateways to match.

No duty-cycle restriction applies in AU915 (unlike EU868, which limits individual channel occupancy to 1%). However, LoRaWAN's fair-access policy and the practical gateway capacity (each gateway channel can receive approximately 1 packet per second) effectively limit throughput.

For a practical step-by-step guide to registering a device on TTN and configuring the AU915 sub-band 2 channel mask in LMIC firmware, see Connecting a LoRaWAN Device to The Things Network in Australia.

Typical Hardware

Radio ICs (paired with an MCU):

• Semtech SX1262 — current-generation LoRa IC; supports 150–960 MHz, +22 dBm Tx, −148 dBm sensitivity at SF12; replaces the SX1276. Standard choice for new AU915 designs. For a schematic-level guide to the SX1262 circuit — crystal, decoupling, matching network, and 50 Ω RF trace — see how do you design the hardware around an SX1262 or SX1276?.
• Semtech LLCC68 — lower cost variant of the SX1262 with reduced SF range (SF5–SF11); suitable for regional networks with dense gateway coverage.

LoRaWAN modules (pre-certified, AT-command interface):

• RAK3172 — STM32WL (integrated ARM Cortex-M4 + LoRa SoC), AT commands over UART, AU915 certified, < 2 µA sleep.
• Murata CMWX1ZZABZ — STM32L082 + SX1276 in module form; older but widely deployed in TTN nodes.
• Dragino LA66 — AU915-certified module with UART AT interface; popular for prototyping.

Development platforms:

• LilyGO T-Beam — ESP32 + SX1262 + GPS + 18650 battery holder; popular for LoRaWAN tracker prototyping.
• RAK WisBlock — modular prototyping platform; nRF52840 base with interchangeable sensor and radio modules.

For MCU selection guidance covering how ESP32, nRF52, and STM32 + SX1262 map to different wireless use cases, see how to choose a microcontroller.

Link Budget Basics

A link budget estimates whether a LoRa link will work between a specific end device and gateway:

Link margin (dB) = Tx EIRP (dBm) − Path loss (dB) − Required sensitivity (dBm)

For a LoRa end device at +14 dBm Tx with a 0 dBi wire antenna (EIRP = 14 dBm) communicating with a gateway at SF10/125 kHz (sensitivity = −132 dBm):

• In free space at 5 km, path loss at 915 MHz ≈ 111 dB (Friis formula).
• Link margin = 14 − 111 − (−132) = +35 dB — substantial margin; a reliable link even with significant building penetration loss.

At SF7 (sensitivity = −123 dBm), the same 5 km path: margin = 14 − 111 − (−123) = +26 dB — still healthy, but higher SF provides a larger buffer for difficult environments.

Battery life for a LoRa end device is determined primarily by transmit duty cycle — see how to calculate battery life for an embedded device for the duty-cycle-weighted approach with a worked IoT example at different sleep and wake current levels.

For LoRaWAN product designs requiring hardware engineering, AU915 firmware, gateway deployment planning, or ACMA compliance strategy, Zeus Design's product development team covers the complete stack — contact Zeus Design to discuss your LoRaWAN project.

Design Considerations

• ADR vs fixed SF: in a deployed LoRaWAN network, the network server's ADR algorithm dynamically adjusts each device's SF and transmit power based on its measured SNR history. ADR is recommended for static or slow-moving devices — it reduces time-on-air and battery drain for devices close to gateways. Disable ADR for mobile devices where the link quality changes rapidly.
• Gateway density vs SF strategy: dense gateway deployments allow all devices to use low SF (SF7–SF9), keeping time-on-air and battery consumption low. Sparse gateway deployments require higher SF (SF10–SF12) for devices at range, which increases time-on-air and reduces effective network capacity. Plan gateway placement based on the expected SF distribution.
• LoRaWAN payload size and frequency: LoRaWAN maximum payload size varies with data rate: SF7/125 kHz allows up to 242 bytes; SF12/125 kHz allows only 51 bytes. Design payloads to fit within the SF12 limit if the device will operate at the cell edge. For sensor data, binary-packed payloads (not JSON) are essential — a 20-byte packed sensor payload transmits in ~600 ms at SF9; a 100-byte JSON representation of the same data would take 3× as long.
• Crystal frequency and tolerance: LoRa transceiver ICs require a crystal with ±10–20 ppm initial tolerance. The LoRa receiver has channel bandwidth of 125 kHz — a crystal frequency error shifts the received signal off the intended channel. Use the crystal specifications from the IC's reference design.

Common Mistakes

• Confusing AU915 and EU868 channel plans: AU915 operates at 915–928 MHz; EU868 operates at 863–870 MHz. Flashing EU868 firmware on hardware deployed in Australia transmits on the wrong frequencies and violates the ACMA class licence. Always verify the region setting in the firmware and gateway configuration matches AU915 for Australian deployments.
• Using high SF for all devices regardless of link quality: SF12 provides excellent range but its 2-second time-on-air for a 20-byte payload uses 6× more energy per transmission than SF7. For devices within 1 km of a gateway with good SNR, using SF12 wastes battery capacity without a range benefit. Let ADR select the optimum SF, or explicitly choose a lower SF for well-covered devices.
• Not accounting for LoRaWAN join procedure at startup: OTAA join (the recommended activation method) requires two messages — JoinRequest and JoinAccept — before the device can transmit data. In areas with marginal coverage, the join may fail and retry, delaying initial operation and consuming battery. Test the join procedure at the installation site, not just in the lab.
• Ignoring time-on-air limits when designing high-frequency reporting: even without a duty-cycle rule in AU915, the LoRaWAN fair-access policy recommends limiting each device to approximately 30 seconds of total uplink time-on-air per day on TTN. A device sending 20 bytes at SF12 every 5 minutes transmits ~580 s of air time per day — roughly 20× the recommended limit. Use a lower SF or reduce reporting frequency.
• Routing the SX1262 RF trace without impedance control: the RF trace from the SX1262's RF_OUT pin to the antenna feed must be 50Ω microstrip. On a 2-layer 1.6 mm FR4 board, this is approximately 2.8–3.0 mm wide — much wider than the default track width in most EDA tools. Routing a narrow trace here produces a significant mismatch and reduces transmitted power. See how should you lay out the RF section of a PCB? for the full layout requirements.