APPLYING LoRa AND LoRaWAN TECHNOLOGY IN INDUSTRIAL COMMUNICATION SYSTEMS Remote Sensor Networks, Energy Efficiency and Real-Time Monitoring within the Industry 4.0 Framework Review Article Keywords: LoRa • LoRaWAN • Industrial IoT • LPWAN • SX1276 • STM32 • Industry 4.0 • Wireless Sensor Network • MQTT • ChirpStack ABSTRACT Industrial Internet of Things (IIoT) applications — energy monitoring, environmental tracking, smart agriculture, infrastructure inspection and manufacturing processes — demand reliable, low-power, long-range wireless communication infrastructure for these critical fields. Developed to overcome the limited range and high energy consumption of conventional wireless technologies (Wi-Fi, Bluetooth, ZigBee), the LoRa (Long Range) modulation technique and the LoRaWAN protocol stack built upon it have become the leading choice in industrial communication in recent years.
This study addresses in detail the theoretical foundations of the LoRa physical layer (Chirp Spread Spectrum modulation and the Spreading Factor, Bandwidth and Coding Rate parameters), the LoRaWAN network architecture (Class A/B/C device types, network server, application server), SX1276-based hardware design, STM32 microcontroller integration, energy optimisation strategies and real industrial deployment scenarios. The link budget provided by the 137 dBm receiver sensitivity of the Semtech SX1276 transceiver chip offers a range of 15 km in open areas and 3–5 km in urban environments, while power consumption falling to 2 µA in deep sleep mode allows years of uninterrupted operation on a 2000 mAh battery.
The study also addresses LoRaWAN network server software (The Things Network — TTN and the open-source ChirpStack), MQTT data integration, real-time cloud visualisation and integration with industrial SCADA systems. In conclusion, LoRa/LoRaWAN technology is shown to be applicable, with a balance of high reliability and acceptable cost, in industrial environments where bandwidth is limited but distance is critical.
Keywords: LoRa, LoRaWAN, Industrial IoT, LPWAN, SX1276, STM32, Industry 4.0, Wireless Sensor Network, MQTT, ChirpStack.
ABSTRACT Industrial Internet of Things (IIoT) applications — including energy monitoring, environmental surveillance, smart agriculture, infrastructure inspection and manufacturing process control — demand reliable, low-power, long-range wireless communication infrastructure. Developed to overcome the limited-range and high-energy limitations of conventional wireless technologies (Wi-Fi, Bluetooth, ZigBee), the LoRa (Long Range) modulation technique and the LoRaWAN protocol stack built upon it have emerged as the preferred choice in industrial communication applications in recent years. This study covers in detail the theoretical foundations of the LoRa physical layer (Chirp Spread Spectrum modulation, Spreading Factor, Bandwidth and Coding Rate parameters), LoRaWAN network architecture (Class A/B/C device types, network server, application server), SX1276- based hardware design, STM32 microcontroller integration, energy optimization strategies, and real-world industrial deployment scenarios. The 137 dBm receiver sensitivity of the Semtech SX1276 transceiver chip offers 15 km range in open areas and 3–5 km in urban environments, while power consumption dropping to 2 µA in deep sleep mode enables years of continuous operation on a 2000 mAh battery.
Keywords: LoRa, LoRaWAN, Industrial IoT, LPWAN, SX1276, STM32, Industry 4.0, Wireless Sensor Network, MQTT, ChirpStack.
1. INTRODUCTION Accelerating urbanisation on a global scale, the management of rising energy demand and the obligation on industrial facilities to increase efficiency under competitive pressure deepen year on year the need for connectivity infrastructure providing uninterrupted data flow between machines, sensors and information systems. According to Gartner research, the number of connected IoT devices is expected to exceed 75 billion by 2025, with industrial sensors making up a significant proportion of those devices.
Industrial communication technologies have historically been built on wired systems — particularly RS-485, Modbus, PROFIBUS and later the Ethernet-based PROFINET and EtherNet/IP. While these systems offer high reliability and deterministic latency characteristics, they carry significant constraints in installation cost, cabling infrastructure and lack of flexibility. Wireless alternatives entered the industrial environment in the early 2000s with ZigBee and WirelessHART operating in the ISM band; but those protocols proved inadequate for wide-area applications because of range constraints. The LoRa (Long Range) modulation technique is a proprietary technology developed by Semtech Corporation in 2012 and patented in 2013. Based on the Chirp Spread Spectrum (CSS) modulation principle, LoRa provides reliable data transmission at distances conventional narrowband modulations cannot reach. With the founding of the LoRa Alliance in 2015 through the cooperation of IBM, Semtech and Actility and the publication of the LoRaWAN protocol standard, LoRa became a global standard operating in unlicensed ISM bands.
Figure 1. The LoRaWAN Network Architecture: end-to-end data flow — every component from sensor node to application server.
This study addresses comprehensively, beginning with the mathematical foundations of the LoRa physical layer, the LoRaWAN protocol stack, the SX1276 transceiver hardware and STM32-based end node design, different industrial deployment scenarios and energy optimisation strategies. The aim is to offer engineers and technical readers both a theoretical grounding and a directly applicable design guide.
The remainder of the article is organised as follows. Section 2 examines LPWAN technologies comparatively. Section 3 explains the theoretical foundations of LoRa modulation. Section 4 addresses the LoRaWAN protocol architecture. Section 5 gives SX1276 transceiver integration details. Section 6 describes the STM32-based end node design. Section 7 discusses energy optimisation strategies. Section 8 addresses network server software and cloud integration. Section 9 presents industrial deployment scenarios. Section 10 examines security matters. Section 11 contains discussion and conclusions. 2. A COMPARATIVE EXAMINATION OF LPWAN TECHNOLOGIES 2.1 An Overview of Low-Power Wide-Area Networks (LPWAN) A Low-Power Wide-Area Network (LPWAN) is a communication paradigm positioned, in terms of range and energy consumption, between traditional mobile networks and short-range wireless technologies. LPWAN has three basic design goals: (i) wide coverage (10–50 km in open areas, 2–10 km in urban settings); (ii) low energy consumption (a battery life target of 5–10 years); (iii) low data rate (typically 0.3–50 kbps). These three goals balance one another: energy efficiency and wide coverage inevitably require low data volume. Because the great majority of industrial sensor applications (temperature, humidity, vibration, fill level and so on) transmit small data packets (10–50 bytes) once a minute or once an hour, this constraint is not a serious obstacle in practice.
The principal technologies competing in today's LPWAN market are: LoRa/LoRaWAN (Semtech/LoRa Alliance), Sigfox (Sigfox SA), NB-IoT and LTE-M (3GPP standard, licensed band) and Weightless-P. Each technology's strengths and weaknesses become clear in relation to its target application areas.
Figure 2. A comparison table of industrial wireless protocols — in terms of range, data rate, power consumption and topology.
2.2 A Comparison of LoRa and NB-IoT The basic distinction between LoRa and NB-IoT concerns infrastructure dependency. NB-IoT uses existing 4G/5G base station infrastructure, which makes it possible to reach wide coverage with low hardware investment. But the operator-dependent subscription model can increase long-term total cost of ownership (TCO). LoRa, by contrast, has the advantage in private network scenarios allowing the user to build their own network. A private LoRaWAN network set up for a factory or a large agricultural area is becoming preferable to NB-IoT because it requires no subscription fee and offers data privacy and the ability to operate offline. Assessed in terms of bandwidth, NB-IoT can theoretically offer 250 kbps downlink in a 200 kHz channel while LoRa is limited to 21.9 kbps in an SF7/BW500 configuration. But in industrial sensor applications that speed difference becomes operationally meaningless; even 5 kbps is sufficient for temperature data. In terms of signal penetration (buildings, underground), LoRa's CSS modulation gives an advantage over NB-IoT for deeply embedded sensors (water meters, underground tanks).
2.3 A Comparison with Sigfox Sigfox achieves extremely high spectral efficiency in a 100 Hz channel using Ultra Narrow Band (UNB) modulation. That approach, allowing thousands of simultaneous channels in the 192,000 kHz ISM band, falls behind LoRa in noise resilience. A more important disadvantage is that Sigfox's closed operator model does not permit private network deployment. In geographies where there is no Sigfox network (which includes the great majority of Türkiye's rural regions) it is entirely inadequate. LoRa-based private networks can fill that gap with a few cost-effective gateways. Criterion LoRa/LoRaWAN NB-IoT Sigfox Frequency Band 433/868/915 MHz (ISM) 700-900 MHz (Licensed) 868/915 MHz (ISM) Range (open area) 2–15 km 1–10 km 3–50 km Data Rate 0.3–50 kbps 20–250 kbps 100 bps Messages/Day Limit Unlimited (private network) Unlimited 140 uplink / 4 downlink Private Network Deployment Yes No No Battery Life 5–10 years 5–10 years 5–10 years Roaming LoRa Alliance member networks Global (4G coverage) Limited Table 1. A comparison of LoRa/LoRaWAN, NB-IoT and Sigfox technologies. 3. THE LoRa PHYSICAL LAYER: MODULATION THEORY 3.1 The Chirp Spread Spectrum (CSS) Modulation Principle LoRa's most important distinguishing feature is its use of the Chirp Spread Spectrum (CSS) modulation technique. Unlike conventional FSK or GFSK modulations, CSS spreads data across a wide bandwidth using sinusoidal signals (chirps) of varying rate and phase. A basic chirp is a signal whose frequency rises or falls linearly over time. In an up-chirp the frequency is swept linearly from low to high, in a down-chirp from high to low.
Symbols are encoded by controlling the up-chirp starting phase and frequency deviation points. This approach has three critical advantages: (i) Noise resilience: a CSS signal can be received far below the noise floor (at negative SNR values, theoretically even at -20 dB SNR). A conventional FSK receiver loses its function under those conditions. (ii) Resistance to multipath: because CSS continually changes frequency, it provides inherent immunity to multipath fading. (iii) Resistance to Doppler shift: the Doppler effect, critical for fixed-frequency signals, becomes for CSS merely a small time shift that can easily be corrected. 3.2 The Spreading Factor (SF) and the Effect of Its Parameters The Spreading Factor (SF) is the most critical parameter of LoRa modulation. It takes six values from SF7 to SF12; as the value rises, each symbol contains 2^SF chirps. To make this concrete: at SF7 a symbol contains 128 chirps, at SF12 4,096 chirps. This produces two opposing effects: a higher SF provides a higher link budget (longer range, deeper building penetration) while the time-on-air increases dramatically. A packet at SF12 occupies the channel roughly 50 times longer than one at SF7. The Bandwidth (BW) parameter also plays a decisive role in range and data rate. The standard BW values in LoRa are 125 kHz, 250 kHz and 500 kHz. Wider bandwidth provides a higher data rate; a narrow band allows a lower noise floor and therefore better receiver sensitivity. The Coding Rate (CR) determines the forward error correction (FEC) ratio: a choice can be made between CR4/5, CR4/6, CR4/7 and CR4/8. At CR4/8, 4 error-correction bits are added for every 4 bits of data; this improves link quality but halves the data rate. Figure 3. The balance of range and data rate by LoRa Spreading Factor value. SF7 provides the fastest data transmission, SF12 the longest range.
3.3 Link Budget Calculation The range capacity of a LoRa link is estimated with a link budget calculation. The basic formula is: Link Margin = EIRP + Receiver Sensitivity + Gains - Losses. Here EIRP (Effective Isotropic Radiated Power) is transmitter power plus antenna gain, while receiver sensitivity is the minimum detectable signal level. In the SX1276's SF12/BW125 configuration, receiver sensitivity is -137 dBm; that value is 10–15 dB ahead of conventional FSK receivers.
In the 868 MHz band used in Europe, maximum antenna power output is legally limited to +14 dBm (25 mW). Assuming a simple antenna with 2 dBi gain, EIRP = 14 + 2 = 16 dBm. Free space path loss (FSPL) for 1 km is roughly 92 dB (by the formula FSPL = 20 log(d) + 20 log(f) + 20 log(4π/c)). Using these values, to express it more precisely: Received Power = EIRP - FSPL = 16 - 92 = -76 dBm. Since the sensitivity limit is -137 dBm, the link margin = -76 - (-137) = 61 dB. This extraordinary margin makes it possible to maintain communication even with serious additional losses inside a building, in basements or in underground facilities. Figure 4. The components of the LoRa link budget — margin values calculated for a 915 MHz, SF12, BW125 configuration. 3.4 Channel Planning and the Duty Cycle Constraint The ISM bands in Europe (863–870 MHz) are subject to duty cycle limits set by the radio regulator ETSI. Duty cycle denotes the maximum proportion of a given time window during which a transmitter may occupy the channel. Across most of the 868 MHz band that proportion is 1%; that is, a device may spend at most 1 second of every 100 seconds transmitting. This limit constitutes an important design constraint for high-SF (long time-on-air) transmissions. At SF12/BW125 the time-on-air of a 50-byte packet is roughly 2.8 seconds, which means a mandatory 280-second wait for each transmission. In applications requiring a high update frequency, therefore, the use of SF7 or SF8 or the alternating use of multiple channels should be preferred.
SF BW (kHz) Data Rate (bps) Sensitivity (dBm) Time-on-Air 50B (ms) Range (open area) SF7 125 5,469 -123 102 ~2 km SF8 125 3,125 -126 184 ~4 km SF9 125 1,758 -129 329 ~6 km SF10 125 977 -132 659 ~9 km SF11 125 537 -134 1,319 ~12 km SF12 125 293 -137 2,793 ~15 km Table 2. Basic performance parameters by LoRa SF and BW combination. 4. THE LoRaWAN PROTOCOL ARCHITECTURE 4.1 The Layered Network Structure LoRaWAN is a MAC (Medium Access Control) protocol built on the LoRa physical layer. The standard defined by the LoRa Alliance consists of the following layers: (i) The Physical Layer (PHY): CSS modulation, frequency, power and SF parameters. (ii) The MAC Layer: device connection, message framing, ADR (Adaptive Data Rate), security and class management. (iii) The Application Layer: end application protocols, payload format and business logic. The network topology is based on a star-of-stars architecture. End nodes communicate directly with gateways; gateways in turn connect with the backend network server over an IP network. In this architecture gateways assume only layer-2 functions: they encapsulate the LoRa frames received into IP packets and forward them to the network server. Complex protocol processing and device management take place entirely on the network server. This design makes the use of low-cost, simple gateway hardware possible.
4.2 Device Classes: A, B and C The LoRaWAN standard defines three device classes according to different application requirements. Each class adopts a different strategy for receiving downlink (network → device) data and carries clear differences in power consumption.
Class A (All) is the basic class every LoRaWAN device must implement. Immediately after an uplink transmission, two short downlink receive windows open: RX1, 1 second after transmission; RX2, 2 seconds after. The network server may use either of those windows for downlink. If both windows pass empty, downlink transmission must wait for the next uplink. This constraint provides the lowest power consumption, because the device can enter sleep mode entirely outside the transmit and receive windows.
Class B (Beacon) adds periodic ping slots to Class A. Gateways broadcast a GPS-synchronised beacon every 128 seconds; Class B devices open downlink windows timed against that beacon. This method allows the network to send downlink at predictable intervals but expends additional energy on beacon reception. Class B is suitable for applications requiring moderate latency, such as actuator control.
Class C (Continuous) is the highest power-consuming class. The device remains in receive mode continuously outside moments of transmission, so downlink messages from the network server are delivered almost in real time. Class C is typically used in mains-powered devices (socket-connected actuators, smart grid equipment).
Figure 5. A communication timing diagram of LoRaWAN device classes A, B and C. Class A offers the lowest power consumption, Class C the fastest downlink response.
4.3 The OTAA and ABP Activation Methods Two activation methods are defined in LoRaWAN for an end node to join the network. Over-The-Air Activation (OTAA) is the dynamic method in which the device carries out an encrypted join procedure each time. The device sends a JoinRequest message containing the AppEUI and DevEUI identity information and the AppKey encryption key; the network server authenticates and derives new NwkSKey and AppSKey session keys for each session. Because this approach uses different encryption keys for each session, it provides the highest security. Activation by Personalisation (ABP) is the static method in which the session keys (NwkSKey, AppSKey) and DevAddr are written directly to the device. There is no join procedure; the device can send data directly. This method offers a low-latency advantage but fixed keys carry security risk and renewing them becomes complex if they are compromised. It may be preferred in closed private network applications where security requirements are low. 4.4 The Adaptive Data Rate (ADR) Mechanism Adaptive Data Rate (ADR) is LoRaWAN's mechanism for automatically optimising SF and power parameters according to channel conditions. When ADR is enabled, the network server monitors the signal quality data (RSSI and SNR) of the last 20 uplink messages. If the SNR margin is sufficiently high (for example if -2 dB is received when -5 dB is required), the server tells the device to use a lower SF or less TX power. This mechanism increases network capacity: devices at lower SF occupy the channel for a shorter time and leave more airtime for other devices. In industrial applications ADR is ideal for fixed-position sensors; on mobile devices ADR should be disabled because of dynamic channel conditions.
5. THE SX1276 TRANSCEIVER: HARDWARE ARCHITECTURE AND INTEGRATION 5.1 SX1276 Chip Architecture The Semtech SX1276 is the dedicated integrated circuit implementing LoRa modulation and is the most widely used LoRa transceiver chip in industry. The chip offers 137 mW RX power consumption, 120 mW TX power consumption (13 dBm) and 137 dBm receiver sensitivity. Its frequency range covers 137–1020 MHz and it supports both LoRa and FSK modulation modes. The SX1276's internal structure consists of the following blocks: the RF front end (LNA, PA and T/R switch); the frequency synthesiser (frequency step 61 Hz); ADC/DAC (12-bit, 9.6 MS/s); the DSP block (CSS modulator/demodulator, FEC encoder/decoder, whitening and CRC); the SPI interface (for connection to the MCU); and the DIO pins (6 configurable digital inputs/outputs for interrupt signals). The FIFO buffer is 256 bytes and is shared between TX and RX. Maximum TX output power reaches +20 dBm when the integrated PA Boost pin is used. 5.2 SX1276 Configuration Registers All SX1276 parameters are managed with 8-bit registers writable/readable over SPI. The basic configuration flow involves the following steps: (i) entering sleep mode and selecting LoRa mode (RegOpMode = 0x81); (ii) setting the frequency (the RegFrfMsb/Mid/Lsb triple); (iii) modem configuration (SF, BW, CR, implicit/explicit header); (iv) TX power setting (RegPaConfig); (v) preamble length (typically 8); (vi) enabling CRC. Basic register write examples are given below.
// SX1276 basic initialisation — with STM32 HAL SPI void SX1276_Init(void) { // 1. Enter sleep mode + select LoRa SX1276_WriteReg(REG_OP_MODE, 0x00); // Sleep HAL_Delay(10); SX1276_WriteReg(REG_OP_MODE, 0x80); // LoRa + Sleep // 2. Frequency: 868.1 MHz // Frf = 868.1e6 / (32e6/2^19) = 14222516 SX1276_WriteReg(REG_FRF_MSB, 0xD9); // 0xD9088A SX1276_WriteReg(REG_FRF_MID, 0x06); SX1276_WriteReg(REG_FRF_LSB, 0x66); // 3. Modem Config: SF9, BW 125kHz, CR 4/5, implicit hdr off SX1276_WriteReg(REG_MODEM_CONFIG1, 0x72); // BW=125k, CR=4/5 SX1276_WriteReg(REG_MODEM_CONFIG2, 0x94); // SF=9, CRC on SX1276_WriteReg(REG_MODEM_CONFIG3, 0x04); // LNA Gain auto // 4. PA Boost, +14 dBm SX1276_WriteReg(REG_PA_CONFIG, 0x8F); // 5. Preamble 8 symbols SX1276_WriteReg(REG_PREAMBLE_MSB, 0x00); SX1276_WriteReg(REG_PREAMBLE_LSB, 0x08); // 6. Enter standby mode SX1276_WriteReg(REG_OP_MODE, 0x81); // Standby 5.3 The TX and RX Process Flow The data transmission flow follows a standard SPI master-slave relationship. The MCU writes the data into the FIFO buffer, starts TX mode and waits for the 'TX Done' interrupt on the DIO0 pin, or polls the RegIrqFlags register at regular intervals. A simple C function for TX transmission is given below:
// Send data (polling based) HAL_StatusTypeDef SX1276_Send(uint8_t *data, uint8_t len) { if (len > 255) return HAL_ERROR; // Position at the FIFO TX base SX1276_WriteReg(REG_FIFO_ADDR_PTR, SX1276_ReadReg(REG_FIFO_TX_BASE_ADDR)); // Write the length SX1276_WriteReg(REG_PAYLOAD_LENGTH, len); // Write the data into the FIFO for (uint8_t i = 0; i < len; i++) SX1276_WriteReg(REG_FIFO, data[i]); // Start TX mode SX1276_WriteReg(REG_OP_MODE, MODE_LORA_TX); // Wait for TX Done (timeout: 5 s) uint32_t t0 = HAL_GetTick(); while (!(SX1276_ReadReg(REG_IRQ_FLAGS) & IRQ_TX_DONE)) { if (HAL_GetTick() - t0 > 5000) return HAL_TIMEOUT; // Clear the flag SX1276_WriteReg(REG_IRQ_FLAGS, IRQ_TX_DONE); SX1276_WriteReg(REG_OP_MODE, MODE_LORA_STDBY); return HAL_OK; 5.4 Antenna Design and Matching For the SX1276's RF performance to be fully realised, the antenna and impedance matching circuit must be correctly designed. The SX1276 RF output presents a nominal impedance of 50 Ω. On the printed circuit board it must be carried to the SMA connector with a coplanar waveguide (CPW) or microstrip line. On an FR4 PCB the typical line width for a 50 Ω line at 1.6 mm thickness is roughly 2.8 mm.
The most common antenna option for 868 MHz is the quarter-wave vertical antenna (λ/4 monopole). At 868 MHz, λ/4 ≈ 86.4 mm. On a board with a ground plane this antenna offers roughly 0 dBi gain and VSWR < 1.5 is easily achieved. In more compact designs a PIFA (Planar Inverted-F Antenna) or an off-the-shelf chip antenna (e.g. Molex 2137120100) may be preferred; but these options fall 2–3 dB behind the monopole in gain. In applications requiring long range, a 5 dBi yagi or an 8 dBi omni antenna is used on the gateway side.
6. STM32-BASED END NODE DESIGN 6.1 Hardware Selection and Power Optimisation The STM32 microcontroller family offers an optimal balance of power efficiency and processing power for LoRa end node design. The STM32L071 (Ultra-Low-Power series) was chosen for this study. The reasons for choosing the STM32L071 are: 0.4 µA standby current in deep sleep mode; a 32 MHz ARM Cortex-M0+ core hosting all the necessary peripherals such as SPI, I²C, UART and ADC; 192 KB Flash and 20 KB SRAM; and the ability to run directly from a LiPo battery thanks to its wide input voltage range (1.65–3.6 V).
Because power efficiency directly determines battery life, it must be prioritised at every stage of circuit design. The critical measures are: leaving unused GPIOs in analog mode (floating digital inputs create leakage current); creating a power-managed supply rail for external components (sensors, LEDs) controlled from an MCU GPIO through a MOSFET switch; keeping the SX1276 in sleep mode and activating it only at the moment of transmission; and switching off the ADC reference voltage between measurements.
Figure 6. A block diagram of the STM32L071 + SX1276 end node. Sensors connect to the MCU over I²C/UART/ADC, the SX1276 over SPI.
6.2 Sensor Integration The most common measurement parameters in industrial applications are temperature, humidity, pressure, vibration, current, voltage and ambient light. Selecting the appropriate sensor and designing the interface for each parameter is critically important. The I²C bus (400 kHz fast mode) offers the advantage that a large number of sensors can be connected with just two GPIO pins (SDA and SCL). The BMP280 (pressure/temperature), SHT31 (humidity/temperature), MPU6050 (accelerometer/gyroscope) and INA219 (current/power meter) are industrial-grade sensors widely used in this category.
// DHT22 humidity/temperature reading (1-Wire-like protocol) typedef struct { float temperature; // °C float humidity; // %RH uint8_t valid; } DHT22_Data_t; DHT22_Data_t DHT22_Read(GPIO_TypeDef *port, uint16_t pin) { DHT22_Data_t result = {0, 0, 0}; uint8_t data[5] = {0}; // Start: 18 ms low, then release high HAL_GPIO_WritePin(port, pin, GPIO_PIN_RESET); HAL_Delay(18); HAL_GPIO_WritePin(port, pin, GPIO_PIN_SET); DHT22_DelayUs(30); // Read 40 bits of data (each bit: low + high duration) SetPinInput(port, pin); for (int i = 0; i < 40; i++) { while (!HAL_GPIO_ReadPin(port, pin)); uint32_t t = GetMicros(); while (HAL_GPIO_ReadPin(port, pin)); uint32_t pw = GetMicros() - t; data[i/8] = (data[i/8] << 1) | (pw > 40 ? 1 : 0); // CRC check if (((data[0]+data[1]+data[2]+data[3]) & 0xFF) == data[4]) { result.humidity = ((data[0]<<8)|data[1]) / 10.0f; result.temperature = (((data[2]&0x7F)<<8)|data[3]) / 10.0f; if (data[2] & 0x80) result.temperature = -result.temperature; result.valid = 1; return result; 6.3 LoRaWAN Payload Format and Codec Payload efficiency is critically important in industrial applications. Given the duty cycle constraint and the range/energy balance, compact payload formats of 10–50 bytes should be preferred. Converting float values to integers by scaling, rather than sending them directly, reduces payload size significantly.
// Compact payload packing (4 measurements in 10 bytes) typedef struct __attribute__((packed)) { int16_t temp; // °C × 10 (e.g. 23.5°C → 235) uint16_t humidity; // %RH × 10 (e.g. 65.2% → 652) uint16_t pressure; // hPa - 900 × 10 (e.g. 1013.25 → 1132) int16_t current_mA; // mA × 10 uint16_t battery_mv; // battery mV } Payload_t; // 10 bytes in total // Filling the payload void Pack_Payload(Payload_t *pld, SensorData_t *s) { pld->temp = (int16_t)(s->temperature * 10); pld->humidity = (uint16_t)(s->humidity * 10); pld->pressure = (uint16_t)((s->pressure - 900.0f) * 10); pld->current_mA = (int16_t)(s->current * 10); pld->battery_mv = (uint16_t)(ADC_ReadBattery()); On the network server side (The Things Network or ChirpStack) the incoming raw payload is decoded back from the packing above. A JavaScript-based TTN codec function is given below: // TTN v3 Uplink Codec (JavaScript) function decodeUplink(input) { var bytes = input.bytes; if (bytes.length < 10) return { errors: ["Short payload"] }; var buf = new DataView(new Uint8Array(bytes).buffer); return { data: { temperature: buf.getInt16(0, false) / 10.0, humidity: buf.getUint16(2, false) / 10.0, pressure: buf.getUint16(4, false) / 10.0 + 900.0, current_mA: buf.getInt16(6, false) / 10.0, battery_mv: buf.getUint16(8, false), }; 7. ENERGY EFFICIENCY AND BATTERY LIFE OPTIMISATION 7.1 The Energy Consumption Profile The energy consumption of a LoRa end node consists of two main components: the active duty period (measurement, transmission, reception) and the sleep period. The duty cycle of a typical industrial node is between 0.1% and 1%, which means most of the day is spent in deep sleep mode. The leakage current in sleep mode therefore directly determines average consumption relative to the active period.
Figure 7. The energy profile of an SX1276-based LoRa device by operating mode. In deep sleep mode consumption falls below 2 µA.
Typical current values measured with the STM32L071 + SX1276 combination are: deep sleep (STOP+WFI, all peripherals off): 1.8–2.1 µA; MCU sleep only (SX1276 off): 45–55 µA; LoRa reception (RX single, BW125): 10.3 mA; LoRa transmission (TX +14 dBm): 28 mA; LoRa transmission (TX +17 dBm PA Boost): 44 mA; sensor reading + MCU active: 6–8 mA. 7.2 Battery Life Calculation Let us make the battery life calculation concrete for a typical industrial monitoring node. Scenario: temperature, humidity and pressure measurement every 15 minutes; SF10, BW125, +14 dBm TX, OTAA (Class A); a 2000 mAh LiPo battery.
Operation Duration (ms) Current (mA) Energy (µAh) Wake from sleep + MCU start 5 3.5 4.86 Sensor reading (I²C) 30 6.0 50.0 SX1276 start + TX 659 28.0 5131 RX1 window 10 10.3 28.6 RX2 window 10 10.3 28.6 Operation Duration (ms) Current (mA) Energy (µAh) MCU deep sleep (15 min minus operations) 899.286 s 0.0021 525 TOTAL (1 cycle) ~900 s — ~5768 µAh Table 3. An energy budget analysis of a 15-minute measurement cycle in an SF10 configuration. Hourly consumption ≈ 5768 µAh × 4 cycles = 23,072 µAh = 23.1 mAh. Daily consumption = 23.1 × 24 = 554 mAh. Theoretical battery life = 2000 mAh / 0.554 mAh per day ≈ 3,610 days ≈ 9.9 years. Taking practical factors into account — shelf life (LiPo with 20% self-discharge over 10 years), cable and connector resistance, capacity loss at low temperature — a realistic target is 5–7 years of battery life.
Figure 8. Estimated battery life by different Spreading Factors and transmission periods (2000 mAh LiPo, SF7/SF10/SF12).
7.3 Practical Energy Optimisation Strategies The measures that can be taken at software and hardware level to extend battery life may be summarised as follows. Above all, the lowest possible SF value should be chosen; the ADR mechanism performs that optimisation automatically. Transmission power should not be raised unnecessarily: if the link margin is large enough, using +7 dBm instead of +14 dBm almost halves the TX current. With a data aggregation strategy, several sensor measurements can be sent in a single packet, reducing both duty cycle usage and energy. Among the most effective hardware-level measures are placing a power switch (P-MOSFET) on the sensors so they are activated only at the moment of measurement, keeping the SX1276 in sleep mode until its reset pin is pulled, and running the MCU in STOP mode (waking with an RTC alarm). In a careful PCB design, increasing pull-up resistor values (100 kΩ instead of 1 kΩ), removing unnecessary bypass capacitors and preferring an LDO (Low Drop-Out) to a voltage regulator also provide significant savings.
8. THE LoRaWAN NETWORK SERVER AND CLOUD INTEGRATION 8.1 The Things Network (TTN) The Things Network (TTN) is an open-source, community-supported global LoRaWAN network infrastructure. TTN v3 (The Things Stack) unites thousands of community gateways worldwide under a single network umbrella. TTN coverage exists in Türkiye particularly in large cities such as Istanbul, Ankara and Izmir. A critical advantage for developers is the availability of free prototyping and testing; although there is a limit on the daily number of messages per device, it offers a satisfactory quota for development stages. The process of creating an application on TTN follows these steps: (i) registering a new application in the TTN console; (ii) defining the end node as a device with its DevEUI, AppEUI and AppKey information; (iii) writing the payload codec (JavaScript decode/encode functions); (iv) enabling MQTT or HTTP integration. Messages arriving over TTN's MQTT server (eu1.cloud.thethings.network:1883, or 8883 for TLS) can be received in real time by subscribing systems.
# TTN v3 MQTT subscription (Python paho-mqtt) import paho.mqtt.client as mqtt import json, base64 TTN_HOST = "eu1.cloud.thethings.network" TTN_PORT = 8883 APP_ID = "your-app-id@ttn" API_KEY = "NNSXS.xxxxx" # TTN API Key def on_connect(client, userdata, flags, rc):
topic = f"v3/{APP_ID}/devices/+/up" client.subscribe(topic) print(f"Connected, subscribed: {topic}") def on_message(client, userdata, msg):
payload = json.loads(msg.payload) dev_id = payload["end_device_ids"]["device_id"] uplink = payload["uplink_message"] decoded = uplink.get("decoded_payload", {}) rssi = uplink["rx_metadata"][0]["rssi"] snr = uplink["rx_metadata"][0]["snr"] print(f"{dev_id}: temp={decoded.get('temperature')} C, " ', f"rssi={rssi} dBm, snr={snr} dB") client = mqtt.Client() client.username_pw_set(APP_ID, API_KEY) client.tls_set() # enable TLS client.on_connect = on_connect client.on_message = on_message client.connect(TTN_HOST, TTN_PORT) client.loop_forever() 8.2 ChirpStack: An Open-Source Private Network Server ChirpStack is an open-source network server solution developed for setting up private LoRaWAN networks for industrial applications. Written in the Go programming language, ChirpStack consists of three components: the ChirpStack Network Server (LoRaWAN MAC layer management), the ChirpStack Application Server (API, web interface, integrations) and the ChirpStack Gateway Bridge (converting the Semtech UDP protocol arriving from gateways into MQTT). Installing ChirpStack with Docker Compose is quite simple. The installation stages on a Debian/Ubuntu-based server are:
# ChirpStack Docker Compose installation git clone https://github.com/chirpstack/chirpstack-docker cd chirpstack-docker # Edit the configuration files # configuration/chirpstack/chirpstack.toml # - network_server.band.name = "EU868" # - postgresql connection details docker compose up -d # Access the interface: http://localhost:8080 # Default login: admin / admin # The Gateway EUI is required to register a gateway:
# For the RAK7268: the lorawanSettings.gateway_ID value 8.3 MQTT and the Data Pipeline ChirpStack publishes incoming uplink messages to MQTT topics in JSON format. The typical topic structure is: application/{id}/device/{devEUI}/event/up. These messages can easily be consumed with Python, Node.js or any language. The common data pipeline in industrial applications is structured as follows: ChirpStack → MQTT Broker (Mosquitto/HiveMQ) → Node-RED (data transformation and filtering) → InfluxDB (time series database) → Grafana (visualisation).
Node-RED facilitates flow-based integration with its visual programming interface. By connecting an MQTT input node → JSON parser → InfluxDB output node, a working pipeline can be set up within a few minutes. On a Grafana dashboard, real-time temperature, humidity, current and battery graphs can be displayed, and email or Telegram alarms configured for threshold breaches.
Figure 9. RSSI and SNR distributions measured in an industrial environment. In most measurements RSSI concentrates between -80 dBm and -95 dBm.
9. INDUSTRIAL DEPLOYMENT SCENARIOS 9.1 Vibration and Temperature Monitoring in a Factory Environment Rotating machine equipment (motors, compressors, pumps, fans) is among the most critical assets of manufacturing facilities. Bearing failures in this equipment generally announce themselves in advance through changes in the vibration spectrum: an increase in vibration amplitude at particular frequencies is an early indicator of approaching bearing damage. Traditional condition monitoring systems are either wired (high installation cost) or 2.4 GHz wireless (sensitive to industrial noise). A LoRa-based vibration monitoring node fills that gap. An MPU6050 or industrial-grade ADXL355 accelerometer computes vibration RMS and peak values in a 1-second window at a 1 kHz sampling frequency. The computed statistics (RMS acceleration in the X/Y/Z axes, peak acceleration, temperature) are transmitted over LoRa every 5 minutes. In industrial buildings LoRa penetration reliably covers 200–500 m even among thick concrete walls and metal-framed machinery.
9.2 Agricultural Irrigation and Soil Moisture Monitoring Precision agriculture applications require real-time mapping of soil moisture and temperature distribution across large areas. To automate irrigation decisions, nodes monitoring capacitive soil moisture (5TE or EC-5), soil temperature and ambient conditions are placed in every 50–100 decares. Achieving a range of 5–8 km even with SF7 or SF8 in wide open-area conditions makes it possible to cover tens of decares of land with a single gateway.
The nodes are placed inside waterproof IP67 enclosures; a combination of a 10 W solar panel and a 5000 mAh LiPo battery is used as the energy source. This configuration ensures uninterrupted node operation even during the low-sunlight periods of winter. If soil moisture falls below the threshold, a LoRaWAN Class C downlink command is sent to the irrigation valve actuator through the gateway and irrigation starts automatically.
9.3 The Smart Grid and Energy Monitoring In electricity distribution networks and transformer substations in large industrial facilities, panel cabinet temperatures, cable terminal temperatures and supply voltages must be monitored continuously. Traditional SCADA systems run over RS-485 Modbus and require cabling infrastructure. LoRa-based retrofit nodes can be added to existing meter and transformer panels without cabling. Energy consumption is measured with a split-core current transformer (non-invasive CT) through an INA219 or CS1237; a simple LoRaWAN payload format is used instead of the IEC 62056 DLMS/COSEM protocol.
Scenario SF TX Power Period Estimated Battery Life Gateway Distance Factory vibration monitoring SF9 +14 dBm 5 min ~4 years (2000 mAh) 200–500 m Agricultural soil moisture SF7 +14 dBm 15 min Solar powered (∞) 3–8 km Smart grid monitoring SF10 +14 dBm 1 min ~1 year (mains) 500 m–2 km Scenario SF TX Power Period Estimated Battery Life Gateway Distance Water leak detection SF12 +17 dBm 30 min ~8 years (2000 mAh) 5–15 km Cold chain logistics SF8 +14 dBm 10 min ~3 years (2000 mAh) 2–5 km Table 4. Recommended LoRa configuration and estimated performance values for different industrial scenarios. 9.4 LoRaWAN Gateway Selection and Installation Gateway selection is a critical step in LoRaWAN network design. For indoor applications the RAK7268 (8 channels, Ethernet/LTE, built-in ChirpStack gateway OS) is a popular choice, offering a commercial-quality solution in the roughly 200–300 EUR price range. For open areas and remote regions, solar-powered options (RAK7244 with solar supply) may be used. Single-channel gateways (ESP32 + SX1276 based) are suitable for prototyping but should not be used in a production environment; they do not fully support the LoRaWAN standard and, since they can listen to only one SF/channel combination, cause serious message loss. 10. THE LoRaWAN SECURITY ARCHITECTURE 10.1 Two-Layer AES-128 Encryption The LoRaWAN standard defines two independent AES-128 encryption layers in versions 1.0.4 and 1.1. The first layer encrypts the MAC header and the message integrity code (MIC) with the network session key (NwkSKey). The second layer encrypts the application payload end to end with the application session key (AppSKey). This two-layer approach allows the network server to read the MAC content while being unable to see the application payload, separating the trust boundaries of the network operator and the application owner.
The Frame Counter (FCnt) mechanism provides protection against replay attacks. An incrementing counter is sent in each uplink message; the network server tracks the counter value and rejects messages with a counter lower than expected. In LoRaWAN 1.1 the FCnt is held at 32 bits wide, preventing overflow attacks. In addition, the Join Nonce mechanism in the join procedure makes each join attempt unique and prevents JoinRequest replay attacks. 10.2 Industrial Security Requirements For critical infrastructure and industrial applications, standard LoRaWAN security may at times be insufficient. In such cases an additional encryption layer beyond the AppSKey should be added with application layer encryption. Moving device authentication to an X.509 certificate-based structure, physical device security (tamper-evident enclosure, disabling JTAG) and the use of a Hardware Security Module (HSM) for key management should also be considered.
The Join Server component defined in LoRaWAN 1.1 provides a stronger chain of trust by separating key management from the network server. In industrial environments, deploying a private network not only ensures that only authorised devices join the network but also offers extra protection against traffic analysis; on shared public networks such as TTN, traffic metadata (message count, timing) can be observed by third parties.
Security Threat LoRaWAN Measure Additional Recommendation Eavesdropping AES-128 AppSKey encryption Additional application layer encryption Replay attack FCnt + Join Nonce Timestamp verification Rogue device AppKey + MIC check X.509 certificate + HSM Denial of service (jamming) Frequency hopping, ADR Multiple channels + backup network Physical tampering Application layer encryption Tamper-evident enclosure Key leakage OTAA new key each session HSM + secure storage Table 5. LoRaWAN security threats and the measures to be taken. 11. DISCUSSION AND CONCLUSIONS 11.1 A Technological Assessment LoRa and LoRaWAN technology is triggering a fundamental transformation in the industrial communication ecosystem. In the light of the technical parameters examined in this study the following assessments may be made: the -137 dBm receiver sensitivity provided by CSS modulation represents the strongest performance among LPWAN technologies in building penetration and urban distances. That sensitivity value amounts to an advantage of roughly 15–20 dB over conventional ISM band FSK systems.
The results obtained on energy efficiency are also striking: with a 2000 mAh LiPo battery, a 15-minute measurement cycle and an SF10 configuration, the calculated theoretical battery life reaches 9.9 years. Expecting 5–7 years under practical conditions is realistic; even that value minimises battery replacement costs in demanding physical environments and is compatible with industrial maintenance cycles. This cable-free structure can reduce installation costs in retrofit applications by 60–80% compared with traditional wired systems. 11.2 Limitations and Constraints The clear constraints of LoRa/LoRaWAN technology should not be overlooked. First, duty cycle limits and the low data rate make it unsuitable for applications requiring real-time high-resolution data streams. Closed-loop control systems requiring more than one update per second, or high-resolution vibration spectrum analysis, fall into this category.
The second important constraint is network capacity. In environments where a large number of nodes send packets densely (with a risk of collision), network performance can fall significantly. The ALOHA-based MAC protocol gives no deterministic latency guarantee; transmitting safety-critical commands (such as emergency stop) over LoRaWAN is therefore not recommended. Finally, LoRa frequency bands vary from country to country, and the legal status of the 915 MHz band in Asia-Pacific in particular must be assessed carefully. 11.3 Future Directions The development trajectory of LoRa technology is advancing in several critical areas. The LoRaWAN 1.1 specification published by the LoRa Alliance in 2022 defines a Relay mechanism allowing nodes to extend one another's coverage; this feature is a critical development particularly for basement and underground sensors. LR-FHSS (Long Range — Frequency Hopping Spread Spectrum) makes satellite connectivity possible with a low space segment cost and offers a revolutionary solution for remote regions without coverage. Semtech's new SX1262 and SX1280 series transceiver chips, with improved phase noise and 50% lower power consumption, are candidates to replace the SX1276. 11.4 Conclusion This study has addressed LoRa/LoRaWAN technology comprehensively from an industrial communication perspective. The theoretical foundations of CSS modulation, SX1276 hardware integration, STM32-based end node design, energy optimisation strategies, network server software and industrial deployment scenarios have been presented alongside both theoretical grounding and application-oriented code.
In conclusion, LoRa/LoRaWAN technology has become one of the infrastructure cornerstones of the Industry 4.0 transformation with its high reliability, low installation and operating cost, long battery life and flexible network topology. Its structure allowing private network deployment in particular constitutes a decisive advantage for industrial customers sensitive to data sovereignty and privacy. Future research is expected to focus on network capacity optimisation, AI-assisted anomaly detection and LR-FHSS satellite integration. REFERENCES LoRa Alliance. (2020). LoRaWAN Specification v1.0.4. LoRa Alliance Technical Committee. https://lora-alliance.org/resource_hub/lorawan-104-specification-package/ LoRa Alliance. (2017). LoRaWAN 1.1 Specification. LoRa Alliance Technical Committee. https://lora-alliance.org/resource_hub/lorawantm-specification-v1-1/ Semtech Corporation. (2020). SX1276/77/78/79 Datasheet: 137 MHz to 1020 MHz Low Power Long Range Transceiver. Semtech. https://www.semtech.com/products/wireless-rf/loraconnect/sx1276 Bor, M., Roedig, U., Voigt, T., & Alonso, J. M. (2016). Do LoRa low-power wide-area networks scale? Proceedings of the 19th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM), 59–67.
https://doi.org/10.1145/2988287.2989163 Augustin, A., Yi, J., Clausen, T., & Townsley, W. M. (2016). A study of LoRa: Long range and low power networks for the internet of things. Sensors, 16(9), 1466. https://doi.org/10.3390/s16091466 Adelantado, F., Vilajosana, X., Tuset-Peiro, P., Martinez, B., Melia-Segui, J., & Watteyne, T. (2017). Understanding the limits of LoRaWAN. IEEE Communications Magazine, 55(9), 34–40. https://doi.org/10.1109/MCOM.2017.1600613 Cattani, M., Boano, C. A., & Römer, K. (2017). An experimental evaluation of the reliability of LoRa long-range low-power wireless communication. Journal of Sensor and Actuator Networks, 6(2), 7. https://doi.org/10.3390/jsan6020007 Reynders, B., Meert, W., & Pollin, S. (2016). Range and coexistence analysis of long range unlicensed communication. 23rd International Conference on Telecommunications (ICT), 1– 6. https://doi.org/10.1109/ICT.2016.7500415 ST Microelectronics. (2022). STM32L071xx Ultra-low-power 32-bit MCU Arm-based Cortex-M0+ Datasheet. STMicroelectronics. https://www.st.com/resource/en/datasheet/stm32l071kb.pdf Mekki, K., Bajic, E., Chaxel, F., & Meyer, F. (2019). A comparative study of LPWAN technologies for large-scale IoT deployment. ICT Express, 5(1), 1–7.
https://doi.org/10.1016/j.icte.2017.12.005 Sanchez-Iborra, R., & Cano, M. D. (2016). State of the art in LP-WAN solutions for industrial IoT services. Sensors, 16(5), 708. https://doi.org/10.3390/s16050708 Lim, K., Abdullah, A. S., Venkat, I., & Pragatheeswaran, J. G. (2022). A systematic literature review of LoRaWAN in agriculture and smart farming. Computers and Electronics in Agriculture, 200, 107212. https://doi.org/10.1016/j.compag.2022.107212 Shanmuga Sundaram, J. P., Du, W., & Zhao, Z. (2019). A survey on LoRa networking: Research problems, current solutions, and open issues. IEEE Communications Surveys & Tutorials, 22(1), 371–388. https://doi.org/10.1109/COMST.2019.2949598 ChirpStack Foundation. (2023). ChirpStack open-source LoRaWAN Network Server documentation. https://www.chirpstack.io/docs/ The Things Network. (2023). The Things Stack for LoRaWAN documentation. https://www.thethingsindustries.com/docs/ Yang, Z., Zhou, Q., Lei, L., Zheng, K., & Xiang, W. (2016). An IoT-cloud based wearable ECG monitoring system for smart healthcare. Journal of Medical Systems, 40(12), 286. https://doi.org/10.1007/s10916-016-0644-9 Codeluppi, G., Cilfone, A., Davoli, L., & Ferrari, G. (2020). LoRaFarm: A LoRaWAN-based smart farming modular IoT architecture. Sensors, 20(7), 2028. https://doi.org/10.3390/s20072028 Petäjäjärvi, J., Mikhaylov, K., Hämäläinen, M., & Iinatti, J. (2017). Evaluation of LoRa LPWAN technology for remote health and wellbeing monitoring. 10th International Symposium on Medical Information and Communication Technology (ISMICT), 1–5. https://doi.org/10.1109/ISMICT.2016.7492086 Vangelista, L., Zanella, A., & Zorzi, M. (2015). Long-range IoT technologies: The dawn of LoRa. Future Access Enablers for Ubiquitous and Intelligent Infrastructures, 51–58. https://doi.org/10.1007/978-3-319-27072-2_7 Butun, I., Pereira, N., & Gidlund, M. (2019). Analysis of LoRaWAN v1.1 security. Proceedings of the 4th ACM MobiHoc Workshop on Experiences with the Design and Implementation of Smart Objects (SMARTOBJECTS), 1–6. https://doi.org/10.1145/3325480.3326570
