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.

Ebyte Products (E22, E220, E30, E32 Series)
Waveshare Products
AI-Thinker Products (RA-01, RA02)

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

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

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.

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.

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).

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

Use tools like TTN Mapper to check whether there are active gateways in your area.

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.

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.

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 EByte 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

• E52-400/900NW22S (The Network Specialist)
  • Networking: According to CDEBYTE, this module uses a decentralized “New LoRa MESH” protocol that supports up to thousands of nodes and 255 routing levels.
  • Reliability: Features include CSMA collision avoidance, network self-healing (automatic rerouting), and encrypted transmission.
  • Ease of Use: Specifically designed for smart home and industrial sensors where nodes might be frequently added or removed.

• E610-433/900T30S (The Long-Range Powerhouse)
  • Speed: Identified by Ebyte as an “unlimited high-speed continuous transmission” module, offering air rates up to 470kbps.
  • Power: Operates at 1W (30dBm), making it the strongest option for long-range links up to 10km.
  • Integration: Primarily uses GFSK modulation but is often grouped with LoRa products due to its long-range performance and UART simplicity.

• EWD95M-400/900NW22 (The Industrial Solution)
  • Hardware: A “Micro Wireless Data Radio” featuring a DIN-rail mount and a shell with anti-fungal, anti-humidity, and anti-salt spray coating.
  • Compatibility: Supports the same “New LoRa MESH” as the E52 series, making it the ideal edge device for connecting RS485 sensors (like Modbus RTU) to a mesh network.
  • Power Supply: Supports a wide voltage input range of 8V to 28V DC, suitable for standard industrial power cabinets.

• Note on Selection: If your priority is a self-organizing network for low-power sensors, the E52 series is the standard choice. If you require industrial durability and RS485 connectivity out of the box, use the EWD95M

Waveshare's LoRa product line primarily utilizes the SX1262 chip. While Waveshare does not use the same “New LoRa MESH” proprietary protocol as Ebyte, several of their units support multi-level relaying and auto-repeating, which allow for decentralized, long-range mesh-like network topologies.

Some WaveShare MESH Module Comparison Table

Feature	SX1262 LoRa HAT	SX1262 LoRa DTU	Core 1262 Module
Primary Use	Raspberry Pi / Arduino / STM32 / UART Nodes	Industrial Data Transfer	Embedded PCB Core
Mesh/Relay Type	Auto Multi-level Repeating	Multi-level Relay	Hardware-only (Custom)
Max Range	5 km (Single Hop)	5 km (Single Hop)	5 km (Single Hop)
Interface	UART / USB / GPIO	RS232 / RS485 / RS422	SPI
Power	22 dBm (Max)	22 dBm (Max)	22 dBm (Max)
Enclosure	Open Board	Industrial DIN-Rail	Raw SMD / Pins

• SX1262 LoRa HAT (For Raspberry Pi / Arduino / STM32)
  • Networking: Supports a private protocol for auto-repeating, allowing it to transmit further than its 5km base range by hopping through intermediate nodes.
  • Features: Includes Listen Before Talk (LBT) and Wake on Radio (WOR) to improve success rates in dense environments and save battery.
  • Compatibility: Note that this HAT does not support LoRaWAN; it is designed for private node-to-node or mesh networks.

• SX1262 LoRa DTU (Industrial Unit)
  • Industrial Design: Encased in an aluminum alloy shell with protection against over-voltage, surges, and ESD.
  • Relay Support: Specifically marketed for multi-level relay networking, making it suitable for extremely long-distance communication in complex industrial or agricultural environments.
  • Configuration: Supports AT commands for setting parameters like AES encryption and relay levels.

• Core1262 HF/LF (Core Module)
• Versatility: This is the raw hardware used in the other products. While it doesn't have a built-in mesh firmware, it is the standard choice for developers building custom mesh solutions like Meshtastic or proprietary protocols.
• Stability: Features a high-quality TCXO (Temperature Compensated Crystal Oscillator) to ensure stable communication in extreme temperatures (-40 to 85°C).

LoRa systems differ from similar network systems in many ways; more about these differences.

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.

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 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.

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.

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.

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.

The table below compares spreading factor, data rate, and time on-air at a bandwidth default of 125 kHz (125/250/500 kHz):

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.

LoRa EU863-870 DR characteristics.

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.

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.

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.

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.

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

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.

The following table lists the mandatory join channels and the common data rate configurations for the 433 MHz band with 125 kHz Bandwidth.

*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).

Regional Parameters Comparison

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.

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.

Common Extended Channels (Multi-Channel Gateways)

Most commercial gateways use an 8-channel configuration. The Things Network (TTN) typically uses these additional five channels:

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)

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.

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.

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

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.

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.

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.

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) 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):

1. Scan Time: The radio listens for a fixed duration (e.g., 5 ms or 128 us).
2. Threshold: If the signal exceeds -80 dBm (typical for Japan), the channel is “Busy.”
3. 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.

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.

1. 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.
2. 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:
   1. A predefined packet length (e.g., 256 bytes) is reached.
   2. A timeout occurs (no new serial data for ~20ms).
3. 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.

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

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.

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.

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.

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.

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.

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.

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

This page has been accessed for: Today: 6, Until now: 7