LoRa & LoRaWAN

LoRa and LoRaWAN are the standard choice for long-range, low-power IoT connectivity where Wi-Fi's power draw and BLE's range are both unsuitable: kilometres of range on a coin cell or small battery, at the cost of a few hundred bits per second of throughput. This subtopic covers LoRaWAN at the implementation level: connecting a device to a real network, choosing a device class, and designing the RF hardware around the SX1262/SX1276 radio IC.

What Is LoRa Implementation?

This subtopic covers what it takes to actually ship a LoRaWAN-connected product: registering and joining a device on a real network (The Things Network, in the Australian AU915 band), choosing the right device class for the application's power and latency requirements, and designing the RF hardware (crystal selection, matching network, PCB trace routing) around the SX1262 or SX1276 radio. For the protocol fundamentals — LoRa modulation, spreading factors, LoRaWAN architecture — see What Is LoRa and LoRaWAN?.

This subtopic is part of the Wireless topic.

Why LoRa Implementation Matters

• A correctly working LoRa radio can still fail to join the network — the most common real-world LoRaWAN bring-up failure is a firmware byte-order or sub-band configuration mistake, not a hardware fault, and it produces symptoms (JoinRequest visible on the gateway, nothing on the device) that point away from the actual cause.
• Device class is a power-vs-latency commitment, not a minor setting — Class A's power efficiency and Class C's near-instant downlink latency represent genuinely different architectures, and choosing wrong means redesigning the application's communication pattern later, not just changing a config value.
• RF hardware mistakes are invisible until range testing fails — a crystal load capacitor calculated incorrectly, or a matching network built from generic rather than IC-specific reference values, can pass basic bench testing and still under-perform significantly on real-world range.
• AU915 is not a single set of settings — Australia's LoRaWAN deployments use a specific sub-band and channel plan that differs from other regions' LoRaWAN configurations; using a generic (often US915 or EU868-oriented) tutorial's settings is a common source of join failures for Australian deployments.

Key Concepts

• OTAA (Over-The-Air Activation) — the standard LoRaWAN join procedure: a device sends a JoinRequest, and the network server responds with a JoinAccept containing session keys, derived from the device's AppKey, DevEUI, and JoinEUI (AppEUI). See AU915 TTN device setup.
• Sub-band — AU915 divides its channel plan into eight sub-bands of 8+1 channels each; a device and gateway must agree on the same sub-band (TTN Australia uses sub-band 2) or the device's uplinks will never be heard.
• Device Class (A/B/C) — Class A opens two brief receive windows only after an uplink (lowest power, highest latency); Class B adds scheduled ping-slot receive windows synchronised to a beacon (moderate power, bounded latency); Class C keeps the receiver on continuously (highest power, near-instant downlink). See LoRaWAN device classes explained.
• SX1262 / SX1276 — Semtech's current- and previous-generation LoRa transceiver ICs; SX1262 integrates the T/R switch and adds a DC-DC option and TCXO support, while SX1276 requires an external T/R switch. See SX1262/SX1276 hardware design.
• Link budget — the calculation determining whether a link will close at a given range: TX power + antenna gains − path loss ≥ receiver sensitivity; spreading factor directly trades data rate for receiver sensitivity and therefore range.

Common Mistakes

• DevEUI/AppEUI byte-order errors — a very common OTAA join failure: some libraries (MCCI LMIC) expect these identifiers in LSB-first order while the network console displays and copies them MSB-first, causing the network server to receive an unregistered DevEUI and silently discard the JoinRequest.
• Wrong AU915 sub-band configured in firmware — a device transmitting on the wrong 8-channel sub-band will never be heard by a gateway configured for a different sub-band, even though the device appears to transmit successfully from its own logs.
• Choosing Class C when Class A would suffice — Class C's continuous receive draws far more current than Class A's brief windows; use it only when the application genuinely needs near-instant downlink delivery, not as a default "just in case" choice.
• Using generic RF reference values instead of the specific IC's application note — the SX1262 and SX1276 have different pin architectures and matching network requirements; copying a generic LoRa PCB layout without following the specific IC's reference design (crystal load capacitors, matching network component values) risks measurable range loss.

Common Questions

Why does my gateway show my device's JoinRequest, but the device never joins?

This almost always means the network server received the JoinRequest but rejected it: most commonly because the DevEUI, AppEUI (JoinEUI), or AppKey registered on the network console doesn't match what the firmware is actually sending, frequently due to a byte-order mismatch between the console's display format and the firmware library's expected format. Verify each identifier byte-for-byte between the console and the firmware source rather than assuming a copy-paste was correct. See AU915 TTN device setup for the full join diagnostic approach.

Do I need Class B or Class C, or is Class A sufficient?

Class A is sufficient (and the right default) for the large majority of battery-powered sensor applications where the device initiates all communication and can tolerate downlink commands arriving only after its next scheduled uplink. Class B and C exist for genuinely different requirements: Class B for applications needing bounded (not instant) downlink latency without Class C's power cost, and Class C for mains-powered or otherwise power-unconstrained devices needing near-instant downlink (actuators, real-time control). See LoRaWAN device classes explained for the full power/latency trade-off.

Should I choose the SX1262 or the SX1276 for a new design?

The SX1262 for any new design without a specific reason to use the older part: it integrates the T/R switch (simplifying the PCB and BOM), adds a DC-DC option for improved efficiency, and supports a TCXO for better frequency stability, all in the current-generation part Semtech is actively developing for. The SX1276 remains relevant mainly for compatibility with existing designs or modules already built around it. See SX1262/SX1276 hardware design for the full hardware comparison. Zeus Design designs LoRaWAN hardware and firmware for Australian AU915 deployments.

Knowledge Base

Network Setup

• Connecting a LoRaWAN Device to The Things Network in Australia — AU915 sub-band 2 channel configuration, OTAA device registration on TTN, LMIC and RadioLib firmware setup, and first-join verification

Device Classes

• What Are LoRaWAN Device Classes A, B, and C? — Class A/B/C trade-offs: AU915 receive window timing, Class B ping slot calculations, power consumption comparison, and when to use each class

Hardware Design

• How Do You Design the Hardware Around an SX1262 or SX1276? — IC-specific hardware design guide: power supply decoupling, 32 MHz crystal and load capacitor selection, impedance-matching π-network, and 50 Ω RF trace routing for AU915

Alternative Architectures

• How Do You Use LoRa Point-to-Point Without LoRaWAN? — driving the SX1262/SX1276 physical layer directly, without a gateway or network server, for a private point-to-point or star link

Forum Discussions

• LoRaWAN OTAA join failing on TTN AU915 — JoinRequest visible in gateway traffic but device live data is empty — the MCCI LMIC DevEUI byte-order failure mode, the gateway-vs-device diagnostic split, and the AU915 JOIN_ACCEPT_DELAY timing