meta data for this page
This is an old revision of the document!
lamaPLC Communication: LoRa, LoRaWAN and LoRa Mesh
LoRa (from “long range”) is a proprietary physical radio communication technique. It uses spread-spectrum modulation techniques derived from chirp spread spectrum (CSS) technology. It was developed by Cycleo, a company based in Grenoble, France, and patented in 2014. Semtech later acquired Cycleo.
LoRaWAN (wide area network) defines the communication protocol and system architecture. LoRaWAN is an official standard of the International Telecommunication Union (ITU), ITU-T Y.4480. The ongoing development of the LoRaWAN protocol is managed by the open, non-profit LoRa Alliance, of which Semtech is a founding member.
Together, LoRa and LoRaWAN define a low-power, wide-area (LPWA) networking protocol designed to wirelessly connect battery-operated devices to the Internet in regional, national, or global networks, and to meet key Internet of Things (IoT) requirements, such as bi-directional communication, end-to-end security, mobility, and localization services. The low power, low bit rate, and IoT use distinguish this type of network from a wireless WAN designed to connect users or businesses and carry more data at higher power. The LoRaWAN data rate ranges from 0.3 kbit/s to 50 kbit/s per channel.
LoRa is one of the most popular low-power wireless sensor network technologies for the Internet of Things, offering long-range communication compared to technologies such as Zigbee or Bluetooth, but with lower data rates.
LoRa operates exclusively within unlicensed (ISM) (Industrial, Scientific, and Medical) sub-gigahertz bands. Because these bands are license-free, anyone can deploy a network without paying regulatory fees, provided they adhere to regional rules such as duty-cycle limits.
Global License-Free LoRa Frequency Bands
| Region | Primary ISM Band | LoRa Frequency Range | Short name | Regulatory Body |
|---|---|---|---|---|
| China | 230 MHz | 230 MHz | CN230 | In China, the 230 MHz band is allocated as a specialized band. |
| Low Frequency (LO) | ||||
| Europe | 433 MHz | 433 MHz | EU433 | ETSI |
| Asia (Various) | 433 MHz | 433 MHz | AS433, CN433 | Varies by country |
| China | 470 MHz | 470 – 510 MHz | CN470, CN470-510 | SRRC |
| Low Frequency (HI) | ||||
| China | 779 MHz | 779 – 787 MHz | CN779, CN779-787 | SRRC |
| India | 865 MHz | 865 – 867 MHz | IN865, IN865-867 | WPC |
| Europe | 868 MHz | 863 – 870 MHz | EU868, EU870, EU863-870 | ETSI |
| North America | 915 MHz | 902 – 928 MHz | US915, US902-928 | FCC Part 15 |
| Australia / NZ | 915 MHz | 915 – 928 MHz | AU915, AU915-928 | ACMA |
| China | 920 MHz | 920 – 922 MHz | CN920 | SRRC |
| South Korea | 920 MHz | 920 – 923 MHz | KR920, KR920-923 | MSIT |
| Asia (Various) | 920 MHz | 920 – 923 MHz | AS920, AS920-923 (“AS1”) | Varies by country |
| Asia (Various) | 923 MHz | 923 – 925 MHz | AS923, AS923-925 (“AS2”) | Varies by country |
Regional Highlights
- Europe (EU868): Restricted by strict duty cycle limits (often 1%) to ensure fair access to the shared spectrum.
- North America (US915): Uses Frequency Hopping (FHSS) instead of duty cycle limits, allowing for higher transmission power up to +30 dBm.
- India (IN865): A unique, narrower band that overlaps with some European channels but requires specific hardware tuning.
- China (CN470): Specifically allocated for IoT and smart metering, often utilizing the most channels for massive urban deployments.
More information from regional parameters: https://lora-alliance.org/wp-content/uploads/2020/11/lorawan_regional_parameters_v1_0-20161012_1397_1.pdf
LoRa Alliance
The LoRa Alliance is an open, non-profit association whose stated mission is to support and promote the global adoption of the LoRaWAN standard for massive-scale IoT deployments and remote or hard-to-reach locations.
Members collaborate in a vibrant ecosystem of device makers, solution providers, system integrators, and network operators, delivering the interoperability needed to scale IoT across the globe through public, private, hybrid, and community networks. Key areas of focus within the Alliance are Smart Agriculture, Smart Buildings, Smart Cities, Smart Industry, Smart Logistics, and Smart Utilities.
Key contributors to the LoRa Alliance include Actility, Amazon Web Services, and Cisco. Everynet, Helium, Kerlink, MachineQ (a Comcast Company), Microsoft, MikroTik, Minol Zenner, Netze BW, Semtech, Senet, STMicroelectronics, TEKTELIC, and The Things Industries. In 2018, the LoRa Alliance had over 100 LoRaWAN network operators in over 100 countries; in 2023, there are nearly 200, providing coverage in nearly every country in the world.
LoRaWAN vs LoRa Mesh
| Feature | LoRa Mesh | LoRaWAN |
|---|---|---|
| Network Topology | Mesh (Multi-hop): Nodes relay data to each other | Star (Single-hop): Nodes talk directly to a gateway |
| Infrastructure | Gateway-free: Can operate entirely between nodes | Gateway-required: Needs a central gateway and network server |
| Power Efficiency | Lower: Relay nodes must stay awake to forward data | Ultra-low: Devices sleep most of the time; battery life can last years |
| Scalability | Moderate: Performance may drop as node density and “hops” increase | High: Designed for thousands of devices per gateway |
| Standardization | Low: Often uses proprietary or custom protocols (e.g., Meshtastic) | High: Globally standardized by the LoRa Alliance |
| Security | Variable: Depends on the specific implementation | Built-in: Mandatory AES-128 end-to-end encryption |
| Range | Extended: Hops allow the signal to “wrap around” obstacles | Direct: Limited by the line-of-sight to the nearest gateway |
Summary of Use Cases
- LoRa Mesh: Best for niche, infrastructure-free environments like deep forests, tunnels, or off-grid emergency messaging where nodes are out of range of a central gateway.
- LoRaWAN: The industry standard for commercial IoT, smart cities, and large-scale agricultural deployments that require high reliability and long battery life.
If you'd like to support the development of the site with the price of a coffee — or a few — please do so here.
Here's a handy tip: you can quickly save this page as a PDF by clicking “export to PDF” in the menu on the right side of the screen.
LoRaWAN
Since LoRa defines the lower, physical layer, the upper networking layers were lacking. LoRaWAN is a protocol that defines the network's upper layers. LoRaWAN is a cloud-based medium access control (MAC) protocol that primarily operates as a network layer protocol for managing communication between LPWAN gateways and end-node devices, and as a routing protocol maintained by the LoRa Alliance.
LoRaWAN defines the network communication protocol and system architecture, while LoRa's physical layer enables long-range communication. LoRaWAN also manages the communication frequencies, data rates, and power for all devices. Devices in the network are asynchronous and transmit only when they have data to send.
Data transmitted by an end-node device is received by multiple gateways, which forward the data packets to a centralized network server. The data is then forwarded to the application servers. This technology shows high reliability under moderate load; however, it has performance issues with acknowledgment transmission.
LoRaWAN networks simplify system building. LoRaWAN is an open, global standard for low-power wide-area (LPWA) wireless networks for the Internet of Things (IoT).
Things Network (TTN)
The Things Network (TTN) is a collaborative, global IoT ecosystem that provides a decentralized LoRaWAN network for community use. As of 2026, it is a primary platform for developers to connect long-range, low-power sensors to the internet without traditional cellular or Wi-Fi subscriptions.
- The Things Stack Sandbox: Formerly known as the “Community Edition,” this is the free tier for non-commercial, small-scale testing and experimentation.
- Decentralized Infrastructure: The network is powered by gateways owned and operated by the community. If a public gateway is nearby, you can connect your device for free; otherwise, you can contribute by setting up your own gateway.
- Global Connectivity: TTN supports all major LoRaWAN regional frequency plans, including EU868, US915, AU915, AS923, and IN865.
Key Features (2026)
- Protocol Support: Full compatibility with LoRaWAN 1.0. x and 1.1. x specifications, supporting Class A, B, and C devices.
- Packet Broker: A peering service that allows different LoRaWAN networks (such as private enterprise stacks and the public community network) to exchange traffic, extending overall coverage.
- Security: Mandatory AES-128 encryption for all data transmissions, with hardware-based security integration available on modern devices such as the “Generic Node”.
- Integrations: Ready-to-use templates for major cloud platforms, including AWS IoT Core, Microsoft Azure, and Home Assistant.
Sandbox vs Cloud
| Feature | The Things Stack Sandbox (TTN) | The Things Stack Cloud |
|---|---|---|
| Cost | Free (Fair Use Policy applies) | Paid (Subscription-based) |
| Reliability | Best-effort (No SLA) | Guaranteed Uptime (SLA backed) |
| Best For | Testing, students, and hobbyists | Commercial and production projects |
| Support | Community Forum | Professional expert support |
Use tools like TTN Mapper to check whether there are active gateways in your area.
LoRa Mesh
LoRa mesh is a decentralized network architecture in which individual nodes communicate directly with one another and relay data across multiple “hops” to extend range. Unlike standard LoRaWAN, which uses a centralized star topology, LoRa mesh enables infrastructure-free, self-healing communication in environments where direct line-of-sight is obstructed.
Key Characteristics
- Multi-Hop Relaying: Every node in the network can act as a relay, forwarding data from other nodes until it reaches its final destination.
- Self-Healing & Ad Hoc: The network is self-organizing; it automatically adjusts its topology when nodes join, leave, or fail, ensuring continuous data transmission.
- Decentralized Structure: There is no single point of failure; the nodes themselves handle all routing.
- Infrastructure-Free: It operates without the need for centralized gateways, cell towers, or internet connectivity, making it ideal for off-grid use.
- Long Range & Low Power: Leveraging LoRa's Chirp Spread Spectrum (CSS) modulation, it maintains a range of several kilometers while consuming minimal battery power.
- LoRa mesh networking allows devices to spontaneously form decentralized, self-organizing networks without the need for pre-existing infrastructure like cellular towers or internet gateways.
Spontaneous Networking Capabilities
LoRa mesh networks excel in scenarios where communication must be established “on the fly” because they do not rely on a central coordinator.
- Self-Organization: Nodes automatically discover neighbors and establish routing paths when powered on, forming a functional network in minutes.
- Infrastructure Independence: Unlike LoRaWAN, which requires static gateways and a central server, a LoRa mesh operates entirely through node-to-node multi-hop communication.
- Dynamic Reconfiguration: If a node moves or fails, the network “self-heals” by automatically finding new transmission paths through other available nodes.
- Emergency Deployment: In disaster zones or wildfires, handheld LoRa nodes can extend signal reach (up to 5 km in dense urban areas) to provide critical GPS and text communication.
LoRa Mesh Applications
LoRa Mesh by EByte
Ebyte offers several specialized LoRa MESH units designed for decentralized, self-healing networks where each node can relay data to extend range beyond a single point-to-point link. Unlike standard LoRaWAN, these modules use Ebyte's proprietary “New LoRa MESH” technology for autonomous networking.
Ebyte's LoRa MESH lineup ranges from the compact E52 module for PCB integration to the industrial-grade EWD95M DTU. While the E52 and EWD95M specifically feature Ebyte's “New LoRa MESH” ad-hoc networking, the E610 series is primarily a high-speed continuous transmission module that can be used in mesh-like topologies via manual relay or specialized firmware.
Some MESH Module Comparison Table
| Feature | Ebyte E52-400/900NW22S | Ebyte E610-433/900T30S | Ebyte EWD95M-400/900NW22 |
|---|---|---|---|
| Type | Embedded SMD Module | High-Power Serial Module | Industrial Rail-Mount DTU |
| Frequency | 410-509 / 850-930 MHz | 410-441 / 850-930 MHz | 410-493 / 850-930 MHz |
| Transmit Power | 22 dBm (160mW) | 30 dBm (1W) | 22 dBm (160mW) |
| Mesh Support | Native (New LoRa MESH) | Auto-Relay / High-Speed | Native (New LoRa MESH) |
| Max Distance | ~2.5 km (Single Hop) | ~10 km (Single Hop) | ~2.5 km (Single Hop) |
| Interface | UART (Serial) | UART (Serial) | RS485 / RS232 |
| Key Advantage | Self-healing, 255-level routing | High-speed continuous data | Industrial “three-proof” shell |
If you'd like to support the development of the site with the price of a coffee — or a few — please do so here.
Here's a handy tip: you can quickly save this page as a PDF by clicking “export to PDF” in the menu on the right side of the screen.
LoRa technical solutions
LoRa systems differ from similar network systems in many ways; more about these differences.
Classes
The LoRaWAN specification has three different communication profiles between devices and applications: Class A, Class B, and Class C. Each class serves different application needs and has optimized requirements for specific purposes. The main difference between the three classes is latency and power consumption: end-devices can always send uplinks when needed, but their class determines when to receive downlinks.
Class A: "Aloha"
This is the default operational mode for LoRaWAN networks, and all devices must support it. These devices implement a bidirectional communication profile in which two short downlinks follow the end-device's uplink transmission receive windows, usually referred to as RX1 and RX2. If the server does not respond in either RX1 or RX2, the next opportunity will be after the next uplink transmission. Class A devices are often battery-powered and spend most of their time in sleep mode; therefore, they have the lowest energy consumption, maintain long intervals between uplinks, and experience high downlink latency.
Class B: The "Beaconing" Class
Class B devices extend Class A devices by adding scheduled receive windows for downlinks, thereby emulating a continuously receiving device by opening receive windows at fixed intervals. This class should be implemented when low-latency downlink communication is required while keeping power consumption as low as possible.
Class C: Continuous Reception
A Class C communication profile is used in applications with sufficient power, so there is no need to minimize the duration of reception windows; this is the case for most actuators (e.g., smart plugs, street lights, electrical meters, etc.). Class C devices always listen for downlink messages unless they transmit an uplink message. This behavior results in the lowest latency between the server and the end device.
CSMA for LoRa
In wireless communication, particularly within the IoT domain, effective channel utilization and collision avoidance are essential for network reliability and spectral efficiency. Previously, LoRaWAN has relied on ALOHA as the medium access control (MAC) layer protocol.
To improve this, the LoRa Alliance's Technical Recommendation TR013 introduces CSMA-CA, tailored to account for LoRa's distinctive modulation characteristics, including Spreading Factor orthogonality and the capability for communication below the noise floor.
Adaptive Data Rate (ADR)
To maximize the battery life of each end device and the overall network capacity, LoRa uses an Adaptive Data Rate (ADR) mechanism to optimize data rates, airtime, and power consumption. ADR controls the following transmission parameters on end devices:
- Spreading factor: the speed of data transmission. Lower spreading factors indicate a higher data transmission rate.
- Bandwidth: the amount of data that can be transmitted from one point to another within the network.
- Transmission power: the energy the end-device transmitter produces at its output.
Spreading factor (SF)
The table below compares spreading factor, data rate, and time on-air at a bandwidth default of 125 kHz (125/250/500 kHz):
| Spreading Factor | Data Rate | Range | Time on-Air | Approx. SNR Limit |
|---|---|---|---|---|
| SF7 | 5470 bps | 2 km | 56 ms | -7.5 dB |
| SF8 | 3125 bps | 4 km | 100 ms | -10 dB |
| SF9 | 1760 bps | 6 km | 200 ms | -12.5 dB |
| SF10 | 980 bps | 8 km | 370 ms | -15 dB |
| SF11 | 440 bps | 11 km | 40 ms | -17.5 dB |
| SF12 | 290 bps | 14 km | 1400 ms | -20 dB |
The minimum SNR required to successfully decode a packet depends on the Spreading Factor (SF). Higher SFs allow for lower (more negative) SNR thresholds, increasing range at the cost of data rate.
Data Rate & Spreading Factor for 125 kHz BW
For a fixed 125 kHz bandwidth, the data rate (speed) and sensitivity (range) are determined by the Spreading Factor (SF). According to The Things Network, lower SF values provide higher data rates but shorter range.
| Data Rate (DR) | Modulation | Spreading Factor | Bandwidth | Indicative Bit Rate |
|---|---|---|---|---|
| DR0 | LoRa | SF12 | 125 kHz | 250 bps |
| DR1 | LoRa | SF11 | 125 kHz | 440 bps |
| DR2 | LoRa | SF10 | 125 kHz | 980 bps |
| DR3 | LoRa | SF9 | 125 kHz | 1760 bps |
| DR4 | LoRa | SF8 | 125 kHz | 3125 bps |
| DR5 | LoRa | SF7 | 125 kHz | 5470 bps |
| DR6 | LoRa | SF7 | 250 kHz | 11 Kbps |
| DR7 | FSK | SF7 | - | 50 Kbps |
| DR8 | LR-FHSS | - | 137 kHz | 162 bps |
| DR9 | LR-FHSS | - | 137 kHz | 325 bps |
| DR10 | LR-FHSS | - | 336 kHz | 162 bps |
| DR11 | LR-FHSS | - | 336 kHz | 325 bps |
LoRa EU863-870 DR characteristics.
LR-FHSS
LR-FHSS extends LoRa’s physical-layer modulation to improve data transmission in congested networks where capacity is limited by duty-cycle restrictions, channel availability, and collision risks. It employs frequency-hopping spread spectrum (FHSS), which increases link range and enables many devices to communicate on the same channel simultaneously, with signals still being properly received and demodulated by the gateway. LR-FHSS is the LoRa Alliance’s implementation of FHSS, a method also used in technologies like Bluetooth and early Wi-Fi versions. FHSS rapidly switches the carrier frequency across a set of channels, offering greater resistance to interference and unauthorized access. This is especially useful in satellite networks where end devices and gateways are distant and node density is high. LR-FHSS handles only uplink transmission; the downlink remains on the LoRa PHY.
There are four LR-FHSS DRs: DR8 to DR11, and all of them are included.
Transmission power / RF power (PWR)
LoRa transmission power (often denoted as PWR or TX Power) is the radio-frequency (RF) power delivered to the antenna, typically measured in dBm (decibels-milliwatts). This setting is strictly governed by regional regulations (FCC, ETSI) to prevent interference and is a primary driver of both communication range and battery life.
Regional Power Limits
Maximum allowable power varies significantly by region and frequency plan. Exceeding these limits is illegal and can lead to device non-compliance.
| Region | Frequency Plan | Max Transmit Power (ERP/EIRP) | Regulatory Body |
|---|---|---|---|
| Europe (HI) | EU863-870 | +14 to +16 dBm (~25–40 mW) | ETSI |
| Europe (LO) | EU433 | +12.15 dBm | ETSI |
| North America | US902-928 | +30 dBm (1 Watt) | FCC |
| Australia | AU915-928 | +30 dBm | ACMA |
| Asia | AS923 | +13 to +16 dBm | Varies (e.g., ARIB) |
| India | IN865-867 | +30 dBm | WPC |
| China | CN433 | 12.15 dBm | MIIT/SRRC |
| China | CN470 | 17 dBm to 19 dBm (50 mW) | MIIT/SRRC |
| China | CN779 | 12.15 dBm | MIIT/SRRC |
| China | CN920 | 12.15 dBm (~16 mW) | MIIT/SRRC |
Impact on Performance
Adjusting the PWR setting creates a direct trade-off between the reliability of your mesh or point-to-point network and the device's operational lifespan.
- Range: Increasing transmit power extends the signal reach. In real-world urban settings, you may need to increase power by 4–10 times (6–10 dB) to double the effective communication distance.
- Battery Life: Higher TX power consumes significantly more current. For example, a 3 dB increase in power can nearly double the energy required per transmission, which is critical for devices intended to last 5–10 years.
- Adaptive Data Rate (ADR): In LoRaWAN, the network server often manages PWR automatically. If a device is close to a gateway, the server will command it to lower its power to save battery and reduce network noise.
Signal-to-Noise Ratio (SNR)
In LoRa technology, Signal-to-Noise Ratio (SNR) is a critical metric that evaluates the quality of a radio link by comparing the power of the received signal to the power of the background noise
Key Characteristics of LoRa SNR
Sub-Noise Demodulation: Unlike most wireless technologies (such as Wi-Fi), LoRa can demodulate signals below the noise floor. This means you will often see negative SNR values.
- Typical Ranges: LoRa SNR values generally range from -20 dB to +10 dB.
- Performance Tiers:
- Excellent: > +5 dB to +10 dB.
- Good: 0 dB to +5 dB.
- Acceptable (Negative): -5 dB to -20 dB. In this range, the signal is “buried” in noise, but the LoRa modulation can still recover it using high spreading factors.
Frequency / Bandwidth / Channels
LoRa channels
LoRa channels in the 433 MHz range are primarily defined by the EU433 frequency plan, which is used in Europe (ITU Region 1) and parts of Asia. Compared to the 863–928 MHz bands, the 433 MHz band offers superior signal penetration through obstacles like buildings and terrain, but has a much narrower total bandwidth and fewer available channels.
Channel Comparison: 433 MHz vs. 863–928 MHz
| Feature | EU433 (433 MHz Band) | EU868 / US915 / AU915 / AS923 |
|---|---|---|
| Frequency Range | 433.05 – 434.79 MHz | 863 – 928 MHz (varies by region) |
| Default Channels | 433.175, 433.375, 433.575 MHz e.g., | 868.1, 868.3, 868.5 MHz (EU868) |
| Total Channels | Supports at least 16 channels | 8 to 72+ channels (varies by region) |
| Bandwidth | 125 kHz (standard) | 125 kHz, 250 kHz, or 500 kHz |
| Max Tx Power | +10 to +12.15 dBm (ERP/EIRP) | +14 dBm (EU) up to +30 dBm (US/AU) |
| Duty Cycle | 1% (recommended for LoRaWAN) | 1% (EU) or Frequency Hopping (US/AU) |
| Key Advantage | High penetration through walls/terrain | Higher data rates and network capacity |
Regional Usage and Constraints
- European Union (EU433): Governed by ETSI EN300.220, the 433 MHz band is a “secondary” allocation. While it allows a duty cycle of up to 10% legally, LoRaWAN typically limits this to 1% to minimize congestion.
- North America: The 433 MHz band is not used for LoRaWAN in the US or Canada, as it is largely reserved for government and amateur radio operations. These regions exclusively use the 902–928 MHz band (US915).
- China (CN470): While 433 MHz is used in Asia, China uses a wider band from 470–510 MHz for smart metering and urban LoRa networks.
- Hardware Compatibility: Devices like the Semtech SX1278 are specifically designed for the 433 MHz band, offering a reported communication distance of up to 15km under ideal conditions.
Performance Trade-offs
- Range vs. Power: A 433 MHz signal can travel roughly twice as far as an 868 MHz signal at the same power level due to physics. However, because the legal power limit is often lower for 433 MHz (+10 dBm) than for 868 MHz (+14 dBm), the real-world range is often similar in many deployments.
- Antenna Size: Because 433 MHz has a longer wavelength, antennas must be roughly twice as large (approx. 17cm for a 1/4-wave whip) as 868/915 MHz antennas (approx. 8cm), which can be a constraint for compact mobile devices.
EU433
The following table lists the mandatory join channels and the common data rate configurations for the 433 MHz band with 125 kHz Bandwidth.
| Channel Type | Center Frequency | Bandwidth | Spreading Factor (SF) | Data Rate (DR) |
|---|---|---|---|---|
| Default 0 | 433.175 MHz | 125 kHz | SF12 | DR0 (250 bps) |
| Default 1 | 433.375 MHz | 125 kHz | SF11 | DR1 (440 bps) |
| Default 2 | 433.575 MHz | 125 kHz | SF10 | DR2 (980 bps) |
| Optional | 433.775 MHz* | 125 kHz | SF9 | DR3 (1760 bps) |
| Optional | 433.975 MHz* | 125 kHz | SF8 | DR4 (3125 bps) |
| Optional | 434.175 MHz* | 125 kHz | SF7 | DR5 (5470 bps) |
*Note: The network operator can add additional channels within the 433.05–434.79 MHz range.
Technical Constraints
- Mandatory Channels: All EU433 end-devices must implement the first three channels (433.175, 433.375, and 433.575 MHz) to ensure they can join any network.
- Duty Cycle: While local regulations (ETSI) may allow up to a 10% duty cycle, LoRaWAN typically enforces a 1% limit to avoid congestion in this narrow band.
- Max Power: The maximum transmit power for EU433 is generally limited to +12.15 dBm EIRP (or +10 dBm ERP).
EU868 / US915 / AU915 / AS923
Regional Parameters Comparison
| Feature | EU863-870 (Europe) | US902-928 (North America) | AU915-928 (Australia/NZ) | AS923 (Asia-Pacific) |
|---|---|---|---|---|
| Regulation | ETSI EN300.220 | FCC Part 15 | ACMA Standards | Varies (e.g., ARIB JP) |
| Uplink Channels | 8 to 16 | 64 (125kHz) + 8 (500kHz) | 64 (125kHz) + 8 (500kHz) | 2 to 16 |
| Join Channels | 3 (868.1, 868.3, 868.5) | 64 (902.3–914.9 MHz) | 64 (915.2–927.8 MHz) | 2 (923.2, 923.4 MHz) |
| Tx Power (Max) | +14 to +16 dBm | +30 dBm | +30 dBm | +14 to +16 dBm |
| Duty Cycle | 1% strict | None (uses FHSS) | None (uses FHSS) | 1% or LBT |
| Dwell Time | No limit | 400 ms | 400 ms | 400 ms (Optional) |
Key Differences & Use Cases
- Capacity vs. Range: US915 and AU915 have significantly more channels (72 total), making them better suited for high-density IoT deployments where many devices transmit simultaneously.
- Spectrum Management: Europe (EU868) uses strict duty cycle limits to prevent band congestion, while the US and Australia use Frequency Hopping (FHSS) to switch between channels.
- AS923 Variants: To accommodate regional differences across Asia, this plan is divided into sub-plans, such as AS923-1 (Japan, Singapore) and AS923-2 (Vietnam, Indonesia), each with specific frequency offsets.
- Hardware Selection: While some modern modules, such as the iM980B, are pre-certified for multiple regions, you must still ensure your antenna is tuned to the target frequency (868 vs 915 MHz) for optimal performance.
EU863-870
In the EU863-870 frequency plan, channels are managed under strict ETSI duty-cycle limits to prevent interference. Devices must implement the three mandatory join channels to be LoRaWAN-compliant.
Mandatory Join Channels (125 kHz BW)
These channels are used for the “Join Request” and initial communication. Every gateway and end-device in Europe must support them.
| Channel | Frequency | Bandwidth | Duty Cycle |
|---|---|---|---|
| 0 | 868.10 MHz | 125 kHz | < 1% |
| 1 | 868.30 MHz | 125 kHz | < 1% |
| 2 | 868.50 MHz | 125 kHz | < 1% |
Common Extended Channels (Multi-Channel Gateways)
Most commercial gateways use an 8-channel configuration. The Things Network (TTN) typically uses these additional five channels:
| Channel | Frequency | Bandwidth | Max Data Rate |
|---|---|---|---|
| 3 | 867.10 MHz | 125 kHz | DR5 (SF7) |
| 4 | 867.30 MHz | 125 kHz | DR5 (SF7) |
| 5 | 867.50 MHz | 125 kHz | DR5 (SF7) |
| 6 | 867.70 MHz | 125 kHz | DR5 (SF7) |
| 7 | 867.90 MHz | 125 kHz | DR5 (SF7) |
Special Purpose Channels
- High-Speed Channel: 868.30 MHz can also be used at 250 kHz bandwidth (DR6 / SF7BW250) for faster data transmission.
- FSK Channel: 868.80 MHz is often reserved for FSK (Frequency Shift Keying) modulation at 50 kbps.
- RX2 (Downlink) Window: The default frequency for the second receive window is 869.525 MHz at SF9 (DR3).
Key Constraints
- Duty Cycle: You can only transmit for 3.6 seconds per hour on a 0.1% channel or 36 seconds per hour on a 1% channel.
- Listen Before Talk (LBT): While not mandatory in EU868, LBT can be used as an alternative to duty-cycle limits in some sub-bands.
Default Settings
The following parameters are recommended values for the EU863-870MHz band.
RECEIVE_DELAY1 1 s RECEIVE_DELAY2 2 s (must be RECEIVE_DELAY1 + 1s) JOIN_ACCEPT_DELAY1 5 s JOIN_ACCEPT_DELAY2 6 s MAX_FCNT_GAP 16384 ADR_ACK_LIMIT 64 ADR_ACK_DELAY 32 ACK_TIMEOUT 2 +/- 1 s (random delay between 1 and 3 seconds)
If you'd like to support the development of the site with the price of a coffee — or a few — please do so here.
Here's a handy tip: you can quickly save this page as a PDF by clicking “export to PDF” in the menu on the right side of the screen.
LF vs HF Version
In LoRa hardware, LF (Low Frequency) and HF (High Frequency) refer to physical optimizations of the RF circuitry for specific frequency ranges. Using the wrong version for your region will cause severe signal loss and potential hardware damage due to mismatched internal filters.
| Feature | LF Version (Low Frequency) | HF Version (High Frequency) |
|---|---|---|
| Optimized Range | 410 – 510 MHz | 850 – 930 MHz |
| Primary Regions | China (CN470), Europe (EU433) | Europe (EU868), North America (US915), Australia (AU915) |
| Typical Chipsets | SX1278, SX1262 (LF variant) | SX1276, SX1272, SX1262 (HF variant) |
| λ/4 Antenna Length | ~16–17 cm | ~8 cm |
| Penetration | Superior; better for basements and deep indoors | Good; better suited for urban/outdoor line-of-sight |
| Range (at same pwr) | ~1.33x farther than HF | ~75% of the distance of LF |
| Data Rate | Generally lower due to narrow bands | Potentially higher; supports wider 500kHz channels in US/AU |
Key Technical Differences
- Hardware Filtering: The distinction is physical; LF modules use larger inductors and capacitors in their impedance-matching networks to handle lower frequencies, while HF modules use smaller components for the 800/900 MHz bands.
- Regulatory Trade-offs: LF (433/470 MHz) typically experiences less interference but has very strict power and duty cycle limits in Europe. HF (868/915 MHz) is more crowded but supports Frequency Hopping (FHSS) in North America, allowing higher transmit power.
- Antenna Size: Because wavelength (λ) is inversely proportional to frequency, LF antennas must be roughly twice as long as HF antennas to maintain resonance.
Authentication and Security
Dual-Layer Encryption (LoRaWAN Standard)
Most LoRa mesh implementations (like LoRa Mesh Networking by Semtech) utilize the standard LoRaWAN 1.1 security architecture, which separates network and application security:
- NwkSKey (Network Session Key): Ensures message integrity as it hops through the mesh. Intermediate nodes can see the routing metadata but cannot read the payload.
- AppSKey (Application Session Key): Provides end-to-end encryption. Only the final application server can decrypt the actual sensor data.
Node Authentication Methods
To prevent “Sybil attacks” (where a fake node joins to disrupt routing), nodes must authenticate using one of two methods:
- OTAA (Over-the-Air Activation): The most secure method. Nodes perform a “handshake” using a unique AppEUI and AppKey to generate dynamic session keys. This is the preferred method for Mesh because keys are never hardcoded.
- ABP (Activation by Personalization): Keys are hardcoded into the device. While simpler, mesh is less secure because if one node is physically compromised, its static keys are exposed forever.
Open-Source Mesh Security (e.g., Meshtastic)
For off-grid mesh systems like Meshtastic, security is often handled via Channels:
- AES-256 Encryption: Every packet is encrypted with a pre-shared key (PSK) assigned to a specific channel (e.g., “LongFast”).
- Public vs. Private: You can set up a Private Channel with a unique key, so even if nearby nodes are present, they cannot see or repeat your traffic unless they have the key.
Hardware-Level Security
For high-security industrial mesh, designers often use Secure Elements (such as the Microchip ATECC608). These chips store the LoRa keys in a tamper-proof hardware vault, so the keys cannot be extracted even if the node is stolen.
Mesh-Specific Security Challenges
| Threat | Mitigation Strategy |
|---|---|
| Replay Attacks | Using Frame Counters. If a node receives a packet with a counter lower than the last one processed, it drops the packet. |
| Wormhole Attacks | Using Time-to-Live (TTL) or hop limits to prevent packets from being endlessly recirculated or tunneled. |
| Selective Forwarding | Implementing Acknowledge (ACK) requirements. If a neighbor node consistently fails to forward, the mesh re-routes via a different path. |
Encoding Rate (ER)
In LoRa technology, the Encoding Rate (ER) - more commonly referred to as the Coding Rate (CR) - is the forward error correction (FEC) setting used to protect the data against interference and noise.
LoRa adds redundant bits to the data packet. If some bits are lost or corrupted during transmission due to interference (common in the crowded CN470 or EU868 bands), the receiver can use these extra bits to reconstruct the original message without requesting a retransmission.
Standard Coding Rate Values
The Coding Rate is expressed as a fraction 4/(4+n), where n ranges from 1 to 4.
| Coding Rate | Ratio | Overhead | Robustness |
|---|---|---|---|
| CR 4/5 | 1.25x | 25% (Low) | Least protection; fastest transmission |
| CR 4/6 | 1.50x | 50% | Medium protection |
| CR 4/7 | 1.75x | 75% | High protection |
| CR 4/8 | 2.00x | 100% (High) | Best protection; slowest transmission |
Impact on Transmission
- Time on Air (ToA): A higher CR (such as 4/8) increases the packet size, making “Time on Air” longer. In regions with strict duty-cycle or dwell-time limits (such as China's <1s rule), using a high CR might require sending smaller payloads to stay legal.
- Battery Life: Because the radio stays in “transmit mode” longer to send the extra bits, a higher CR consumes more battery power.
- Reliability: In high-interference environments (e.g., industrial plants or dense urban areas using CN470), a higher CR (such as 4/7 or 4/8) is often necessary to ensure the packet arrives intact.
LoRaWAN Standard
For almost all standard LoRaWAN networks (including The Things Network), the fixed coding rate is 4/5. This provides a baseline level of protection while keeping overhead low to maximize battery life and network capacity.
Network Identifier (NetID)
In LoRaWAN, the Network Identifier (NetID) is a 24-bit value assigned by the LoRa Alliance to uniquely identify a network operator. It ensures that device addresses (DevAddr) do not overlap across networks, which is critical for roaming and avoiding cross-network interference.
Structure and Types
The NetID is divided into “Types” (0–7) based on network size. Large operators receive small NetID ranges that support millions of devices, while smaller private networks use different types.
| NetID Type | Bit Length | Max Device Addresses | Target Use Case |
|---|---|---|---|
| Type 0/1 | 6 bits | 32,768 to 2M+ | Large Public Operators (e.g., Orange, Helium) |
| Type 3 | 21 bits | 512 | Small Private or Enterprise Networks |
| Type 7 | 24 bits | Variable | Localized Private Networks |
The DevAddr Relationship
The NetID is embedded within the DevAddr (32-bit Device Address). When a gateway receives a packet, the Network Server checks the NetID prefix in the DevAddr to determine whether the packet belongs to its network or should be “roamed” to another provider via the LoRa Alliance IPX.
Public vs. Private IDs
- The Things Network (TTN): Uses a specific set of NetIDs (e.g., 0x000013) to identify traffic across its global community clusters.
- Experimental/Private: The IDs 0x000000 and 0x000001 are often reserved for testing or private networks (such as a local ChirpStack instance) that do not require global roaming.
LoRa P2P / Mesh “Network ID”
If you are using LoRa Peer-to-Peer (P2P) or systems like Meshtastic, “Network ID” usually refers to a Sync Word:
- Public (0x34): The default sync word for LoRaWAN networks. Devices using this can “see” (but not decrypt) LoRaWAN traffic.
- Private (0x12): Used to isolate private P2P networks so they ignore LoRaWAN packets at the hardware level, conserving battery life.
Listen Before Talk (LBT)
Listen Before Talk (LBT) is a “politeness” mechanism where a LoRa device scans the channel for existing RF activity before transmitting. If the RSSI (Received Signal Strength Indicator) is above a defined threshold, the device waits for a clear slot.
In many regions, LBT serves as a legal alternative to strict Duty Cycle limits.
- Capacity: In the EU868 band, a device limited to a 1% duty cycle can only transmit for 36 seconds per hour. With LBT enabled, some regulations allow the device to bypass this limit and transmit more frequently, provided the channel is clear.
- Interference Avoidance: It prevents “collisions” in dense environments like China (CN470) or Japan (AS923), where many devices share a narrow spectrum.
Technical Implementation (CCA)
The process is often called Clear Channel Assessment (CCA):
- Scan Time: The radio listens for a fixed duration (e.g., 5 ms or 128 us).
- Threshold: If the signal exceeds -80 dBm (typical for Japan), the channel is “Busy.”
- Back-off: If the channel is busy, the device waits for a random period before retrying.
Hardware Support
Not all LoRa chips handle LBT efficiently. Modern chips such as the Semtech SX1261/SX1262 include built-in CAD (Channel Activity Detection) and dedicated LBT commands, whereas older chips like the SX1276 require the host MCU to manually implement the listen-and-wait logic.
Data Transfer Unit (DTU)
In the context of LoRa hardware, a Data Transfer Unit (DTU) is an industrial-grade gateway or terminal that converts serial data (RS232/RS485/USB) into LoRa wireless signals. These devices typically operate in one of four primary working modes.
Understanding these modes is critical for setting up Modbus networks or for long-range industrial monitoring.
In industrial LoRa DTUs and high-performance radio modules (such as those from Ebyte or Waveshare), these modes determine how data is buffered and transmitted over the wireless link.
- Stream Mode (Continuous): Stream mode treats the wireless link as a live pipe. It is designed for low latency and real-time data flow. As soon as data enters the serial port (RX), the radio begins transmitting it over the air without waiting for a complete packet or a “stop” character.
- Packet Mode (Buffered): This is the standard operating mode for most IoT devices. Data is collected into a “bucket” before being fired off as a single burst. The DTU buffers incoming serial data until a specific condition is met:
- A predefined packet length (e.g., 256 bytes) is reached.
- A timeout occurs (no new serial data for ~20ms).
- Relay Mode (Repeater): Relay mode turns the DTU into a “middleman” to extend the communication range beyond a single hop. The device listens for a packet. If the packet's destination address does not match its own, but the “Relay” flag is set, the device re-broadcasts the packet at full power.
| Mode | Data Handling | Latency | Reliability |
|---|---|---|---|
| Stream | Instant / Byte-by-Byte | Lowest | Lower (no CRC) |
| Packet | Buffered / Block-by-Block | Medium | Highest (CRC check) |
| Relay | Store and Forward | High | Best for Range Extension |
Transmit (TX) and Receive (RX) channels
In LoRaWAN, the relationship between Transmit (TX) and Receive (RX) channels depends on whether the region uses Symmetric (same frequencies) or Asymmetric (different frequencies) plans.
Channel Structure by Region
| Region | TX / RX Relationship | TX Channels (Uplink) | RX Channels (Downlink) |
|---|---|---|---|
| EU433 | Symmetric | 433.05 – 434.79 MHz | Same as TX (RX1 window) |
| EU868 | Symmetric | 868.1, 868.3, 868.5 MHz | Same as TX (RX1 window) |
| US915 | Asymmetric | 902.3 – 914.9 MHz | 923.3 – 927.5 MHz |
| AU915 | Asymmetric | 915.2 – 927.8 MHz | 923.3 – 927.5 MHz |
| AS923 | Symmetric | 923.2, 923.4 MHz | Same as TX (RX1 window) |
| CN470 | Asymmetric | 470.3 – 489.3 MHz | 500.3 – 509.7 MHz |
The Two Receive Windows (RX1 & RX2)
To save battery, a LoRa device only listens for a “downlink” (reply) from the gateway during two precisely timed windows after it finishes its transmission:
- RX1 Window: Typically opens 1 second after transmission. In symmetric regions (EU868), it uses the same channel as TX. In asymmetric regions (US915), it uses a fixed frequency offset.
- RX2 Window: Opens 2 seconds after transmission. It uses a fixed, dedicated frequency regardless of which channel was used for TX (e.g., 869.525 MHz in Europe or 923.3 MHz in the US).
Asymmetric Networking (US915/CN470)
In high-capacity plans like US915, the band is split to prevent “self-interference”:
- Uplink (TX): Devices communicate with the gateway on the lower 902–915 MHz band.
- Downlink (RX): The gateway communicates back on the higher 923–928 MHz band.
- Sub-bands: Networks typically group these into 8-channel blocks. For example, if your gateway is on Sub-band 2, your device must TX on channels 8–15 to be heard.
Hardware “TX/RX” Switching
LoRa chips such as the Semtech SX1262 use a Half-Duplex architecture. This means the device cannot transmit and receive simultaneously. The internal RF switch toggles the antenna between the Power Amplifier (TX) and the Low Noise Amplifier (RX) in accordance with the LoRaWAN protocol timing.
Received Signal Strength Indicator (RSSI)
In LoRa systems, RSSI (Received Signal Strength Indicator) is a hardware-measured value of the incoming signal power (in dBm). You don't typically “enable” or “disable” the measurement itself—the radio chip calculates it for every packet received—but you can enable or disable the reporting of that data to your application.
LoRaWAN (Gateways & Network Servers)
In a LoRaWAN environment (like The Things Network or ChirpStack), RSSI is always enabled and sent as metadata with every uplink.
Address on a LoRa DTU
To set the address on a LoRa DTU, you must first put the device into Configuration Mode (usually by switching physical pins M0/M1). The address is a 16-bit value from 0 to 65535 (0x0000 to 0xFFFF).
Understanding the Address Logic
- Transparent Mode: If all DTUs are set to the same address (e.g., 0001) and the same channel, they act as a multi-point cable.
- Fixed-Point Mode: In this mode, unique addresses matter. To send data from Node A to Node B (Address 1234), Node A sends a 3-byte prefix: [High Addr] [Low Addr] [Channel] + Data.
- Broadcast Address (65535 / 0xFFFF): If a DTU sends data to address 65535, every node on the same channel will receive it, regardless of its own address.
Semtech LoRa transceiver series
The table below compares the primary Semtech LoRa transceiver series. The SX126x represents the newer generation with improved power efficiency and higher transmit power, while the SX127x series remains a widely used legacy standard.
| Feature | SX1261 | SX1262 | SX1276 | SX1272 | SX1278 |
|---|---|---|---|---|---|
| Frequency Range | 150–960 MHz | 150–960 MHz | 137–1020 MHz | 860–1000 MHz | 137–525 MHz |
| Max TX Power | +15 dBm | +22 dBm | +20 dBm | +20 dBm | +20 dBm |
| RX Current | 4.6 mA | 4.6 mA | 9.9–11 mA | 10 mA | 11 mA |
| Max Sensitivity | -148 dBm | -148 dBm | -148 dBm | -138 dBm | -148 dBm |
| Link Budget | 163 dB | 170 dB | 168 dB | 158 dB | 168 dB |
| Spreading Factor | SF5–SF12 | SF5–SF12 | SF6–SF12 | SF6–SF12 | SF6–SF12 |
| Primary Region | Global (Low Pwr) | Global (High Pwr) | EU/NA (HF) | EU/NA (HF only) | China/Asia (LF) |
Key Series Differences
- SX1261 vs. SX1262: These chips are nearly identical in functionality, but the SX1261 is optimized for low-power transmissions up to +15 dBm (ideal for European ETSI limits), whereas the SX1262 can reach +22 dBm for maximum range.
- Generational Improvement: The newer SX126x series uses approximately 50% less current in receive mode (~4.6 mA) than the older SX127x series (~10 mA), significantly extending battery life for IoT sensors.
- SX1276 vs. SX1278: These chips are nearly identical in performance, but the SX1278 is strictly a “Low Frequency” (LF) chip for the 433/470 MHz bands used in China and Southeast Asia. The SX1276 is a universal chip that supports both LF and HF (868/915 MHz) bands.
- Modulation Support: Both series support LoRa and (G)FSK modulations. However, the SX126x series adds a new SF5 spreading factor, enabling higher data rates in dense network environments.
Energy Harvesting for LoRa
This technology enables LoRa sensors to operate battery-free or to achieve significantly extended battery life by harvesting energy from the surrounding environment. Because LoRaWAN is ultra-low power, it can run on the tiny amounts of energy generated by these sources.
- Solar (Photovoltaic): The most common method, using outdoor or indoor solar cells to power devices such as air quality sensors or smart agricultural trackers.
- Thermal (TEG): Uses temperature differences (e.g., between a hot pipe and the air) to generate electricity.
- Kinetic/Vibration: Captures energy from movement or button presses to send occasional data packets.
- Radio Frequency (RF): Scavenges energy from existing wireless signals such as Wi-Fi or TV broadcasts.
- Current Transformer (CT) Harvesting: A coil is clamped around an AC power line. The alternating current generates a magnetic field that induces a current in the harvester's coil, acting as a transformer.
- Kinetic Electromagnetic Induction: Uses a magnet moving through a coil (often triggered by vibrations or rotational motion) to generate electricity. This is commonly used in “self-powered” wireless switches.
- Stray Magnetic Field Harvesting: Captures “leaked” magnetic energy near large electrical equipment such as substations or motors.
- Harvester (Coil): Captures the magnetic flux.
- Rectification: Converts the induced AC voltage to DC.
- Power Management IC (PMIC): High-efficiency chips such as the STMicroelectronics SPV1050 or the e-peas AEM series use Maximum Power Point Tracking (MPPT) to extract the maximum energy even at low input voltages (as low as 380 mV).
- Storage: Harvested energy is stored in supercapacitors or small rechargeable batteries to provide the high-current “bursts” needed during data transmission by the Ra-01/Ra-02.
Lora Manufacturers
| Manufacturer | Core Interface | Typical Series | Link on lamaPLC | Target Market | Key Strengths |
|---|---|---|---|---|---|
| Ebyte | UART (Serial) | E32, E22, E220 | Ebyte E22, E220, E30, E32 | Industrial, DIY, Arduino | High cost-performance; proprietary firmware for easy “transparent” transmission. |
| Ai-Thinker | SPI | Ra-01, Ra-02 | Ra-01, Ra-02 | Maker, Hobbyist, Arduino | Very low cost; raw access to Semtech chips; standard in the Arduino community. |
| Waveshare | SPI / UART | LoRa HATs | Waveshare | Raspberry Pi, Pi Pico, Arduino | Excellent documentation; plug-and-play “HAT” designs for single-board computers |
| Murata | SPI / UART | Type ABZ, 1SJ | - | Enterprise, Wearables | Extreme miniaturization and low power; often used in high-end consumer products |
| Microchip | UART (AT Commands) | RN2483, RN2903 | - | Industrial, Medical | Fully certified LoRaWAN stacks; high reliability and long-term supply |
| RAKwireless | SPI / UART | WisDuo, WisBlock | - | Industrial IoT, Meshtastic | modular “WisBlock” ecosystem; strong support for Meshtastic and LoRaWAN gateways |
| HopeRF | SPI | RFM95W, RFM98W | - | DIY, Low-cost OEM | The industry standard for basic SPI modules; widely used in libraries like RadioHead |
Compatibility Among Manufacturers
Although LoRa modules from different manufacturers are based on the same LoRa modulation technology developed by Semtech, they are not always compatible out of the box. Compatibility largely depends on whether you are using a simple SPI-based module or a UART-based one with proprietary firmware.
Key Compatibility Factors
- Hardware Interface (SPI vs. UART): If the modules are standard SPI-based (connecting directly to a microcontroller's SPI bus), they can be made compatible through software. For example, most Ebyte modules (like the E32 series) use a UART serial interface with a built-in MCU running proprietary firmware.
- Proprietary Protocols: Ebyte’s UART modules often use a specific “transparent transmission” or “fixed-point” protocol that includes custom packet headers and encryption. These are generally incompatible with other manufacturers' UART modules unless you can exactly replicate those settings on the other device.
- LoRa Chip Generations: Modules using the SX1262 (often found in newer Waveshare hats) and SX1278 (common in older Ebyte E32 modules) can communicate, but they have specific incompatibilities, such as Spreading Factor 6 (SF6), which is handled differently by each chip.
- Firmware Lock-in: Some Waveshare products, such as their USB-to-LoRa modules, run a custom firmware that may only allow communication between identical modules unless they are reprogrammed.
The incompatibility among the Ebyte, Waveshare, and Ai-Thinker (Ra-01/02) products stems primarily from their differences in data handling (UART vs. SPI) and the use of proprietary firmware.
Incompatibility Comparison Table
| Feature | Ai-Thinker (Ra-01 / Ra-02) | Ebyte (E32 / E220 Series) | Waveshare (LoRa HATs / Modules) |
|---|---|---|---|
| Communication Interface | SPI (Raw access to chip) | UART (Serial TTL) | SPI or UART (Varies by model) |
| Protocol | Layer Raw LoRa (PHY Layer) | Proprietary Firmware (Transparent/Fixed) | Varies (Some use proprietary, some raw SPI) |
| User Control | Full control over all LoRa registers | Limited to manufacturer parameters | Depends on the specific module version |
| Packet Structure | Standard Semtech packets | Custom headers/checksums added by Ebyte | Standard (SPI) or Proprietary (UART) |
| Antenna Connection | Ra-01: Spring; Ra-02: IPEX | Typically SMA-K | ypically SMA or IPEX |
Manufacturers specify links on lamaPLC
LoRa topics on lamaPLC
Communication topics on lamaPLC
This page has been accessed for: Today: 4, Until now: 141


