Conceptio › Archive › arXiv CS
arXiv CSopen access

Energy-Aware LoRaWAN Design for Long-Lived Agricultural Sensing: Insights from a Multi-Year Deployment and Controlled Platform Comparison

· arxiv_cs
arXiv CS · Papers · License: Open Access
Open Source ↗Direct PDF ↓
distributed-systemsinternetnetworkingprotocols
networking, internet, protocols, distributed systems

Energy-Aware LoRaWAN Design for Long-Lived Agricultural Sensing: Insights from a Multi-Year Deployment and Controlled Platform Comparison Carl Dickinson, Shishir Nagaraja, Chuadhry Mujeeb Ahmed

arXiv:2609.14732v1 [cs.NI] 13 Sep 2026

School of Computing, Newcastle University National Edge AI Hub Newcastle upon Tyne, UK Email: {carl.dickinson, shishir.nagaraja, mujeeb.ahmed}@ncl.ac.uk

Abstract—Agricultural IoT nodes are often far from mains power and have limited access for maintenance. Therefore, IoT deployments benefit from low-power, long-range communication such as LoRaWAN. However, communication alone does not guarantee multi-year operation. Previous work has measured communication energy, modelled system lifetime, and documented long-lived deployments. This paper connects long-term deployment evidence with controlled platform measurements. The AgriTrust deployment has operated for 2 years and 8 months using MKR WAN1310-based Squirrel Box nodes. Building on this evidence, we compared the MKR WAN1310 and STM32WL LoRaWAN platforms using time-resolved current traces during confirmed-uplink cycles. For this outdoor comparison, we tested nine combinations of payload size and data rate with three repetitions each. Both platforms achieved 3/3 ACKed packets in every condition. The STM32WL had lower cycle energy than the WAN1310 in all tested conditions. Cycle energy ranged from 0.0350 J to 0.3550 J for STM32WL and from 0.0698 J to 0.5662 J for WAN1310. These communication events are brief, while sleep and leakage currents persist between cycles. The STM32WL sleep current was recorded at 59.6 nA, while the WAN1310 sleep current was 104 µA, approximately 1745× that of the STM32WL. This difference shows that sleep current is a first-order determinant of long-term viability. However, the whole-system energy budget also depends on sensing loads, duty cycle, communication energy, and harvested-energy support. The study should be treated as a controlled characterisation, not a universal comparison across all sites, firmware stacks, or LoRaWAN modes.

I. I NTRODUCTION Agricultural IoT nodes often operate far from mains power, with intermittent connectivity and limited maintenance access. LoRaWAN is attractive because it provides long range and low average power, but multi-year operation is not explained by communication technology alone. Endurance also depends on sleep architecture, sensing schedule, power-tree overheads, and energy harvesting [1], [2], [3], [4], [5]. This paper addresses a gap between two common forms of evidence. Existing work provides analytical and measurementbased models of LoRaWAN communication energy [1], [2], [3], [6], while agricultural deployments often demonstrate utility without exposing the board-level energy mechanisms that support long lifetime [7], [8], [9]. Less common is a

combined treatment of real deployment evidence, controlled platform comparison, and system-level lifetime interpretation. We make four contributions. First, we use the AgriTrust deployment as a real-world anchor for long-lived agricultural sensing [10]. Secondly, using one instrumented STM32WL node and one instrumented WAN1310 node, controlled confirmed-uplink experiments show that both platforms complete the outdoor comparison matrix: DR0/DR3/DR5, 15/30/45 B payloads, three repetitions per condition, and 27/27 ACKed messages per platform. STM32WL consistently achieves lower cycle energy, shorter radio-active time, and lower mean current than WAN1310 in this setup. Thirdly, we report a measured sleep-current disparity of approximately 1745×. Fourthly, we show that communication energy alone cannot explain multi-year lifetime: sleep current and system design dominate the long-term outcome. Figure 1 summarises how the deployment and measurements connect. II. BACKGROUND AND R ELATED W ORK LoRaWAN Class A energy is tightly coupled to MAC timing. Each uplink is followed by receive windows, so even when application downlinks are absent there remains a deterministic post-uplink listening cost [11], [12]. Confirmed traffic further couples energy to ACK reception and possible retransmission behaviour, while data-rate (DR) selection changes airtime through the regional spreading-factor and bandwidth mapping [11], [12], [13]. Measurement-based work shows that realised cost is not set by airtime alone: receive-window overheads, retries, firmware behaviour, and board-level implementation can all affect total message energy [1], [2], [3], [14]. At system level, long lifetime is usually estimated from cycle energy, daily demand, and available battery or harvested energy [2], [6], [15]. However, practical LoRa sensing studies show that sensing load, reporting interval, sleep-mode current, standby leakage, and application scheduling can dominate the budget once reporting becomes sparse [16], [15], [9]. This matters especially in agriculture and environmental monitoring, where remote placement, link variability, and maintenance cost are normal rather than exceptional [7], [8], [17], [18].

Long-term field deployment AgriTrust WAN1310 LiPo + solar, hourly duty ∼2 years 8 months

Controlled comparison one STM32WL node one WAN1310 node confirmed uplinks 3 DRs × 3 payloads 27 runs/platform

Measured behaviour ACK success cycle energy mean/peak current TX/RX timing current traces

Fig. 1: Deployment-informed LoRaWAN energy evaluation framework linking the long-running AgriTrust deployment with the controlled STM32WL–WAN1310 measurement workflow.

Solar assistance shifts the design objective from finite battery lifetime to maintaining a positive long-term energy balance under variable harvest [4], [5], [19], [20]. Recent LoRa-based environmental-sensing work further shows that fixed duty-cycle assumptions may fail under changing harvest conditions, motivating adaptive scheduling and system-level energy management [21]. Taken together, prior work provides strong models, measurements, and deployments, but fewer studies combine long-horizon agricultural evidence, controlled cross-platform LoRaWAN measurements, and system-level interpretation of sleep leakage, sensing load, duty cycle, and harvested-energy support. III. D EPLOYMENT C ONTEXT AND R ESEARCH Q UESTIONS AgriTrust provides the deployment context for this study [10]. The node is based on the Arduino MKR WAN 1310, powered by a 3.7 V LiPo battery with solar charging and an external timer-assisted wake/sleep strategy. Its duty cycle is approximately hourly, and project records indicate a field duration of roughly 2 years and 8 months. The deployment shows that long-lived agricultural sensing is a system-design problem rather than simply a radio-efficiency problem. Deep sleep between events, controlled wake duration, sparse reporting, and harvested-energy support make long operation possible. This motivates the controlled comparison used in this paper: if a platform is field-capable, what is its board-level energy behaviour under matched confirmed-uplink experiments? We therefore ask how reliably the two platforms execute confirmed uplink cycles, how energy, current, and timing vary with data rate and payload, whether cleaner board-level behaviour makes one platform more suitable for low-power experimentation, and how communication measurements should be interpreted alongside deployment lifetime, solar support, and sleep current. IV. E XPERIMENTAL M ETHOD AND DATASETS The experiments use a host-driven LoRaWAN test workflow: a PC-side script configures each run, starts current capture, coordinates the node-side action, and stores the run summary, validation output, current trace, host log, and device event log in a per-run directory. This preserves the electrical trace and event timing needed to separate wake, TX, RX, and acknowledgement behaviour.

We focus on confirmed uplinks because they expose transmission, LoRaWAN Class A receive windows, and acknowledgement (ACK) success. In a confirmed uplink, the device transmits a frame requesting confirmation, opens receive windows after TX, and the exchange is successful only if the network ACK is observed. Thus missing_ack_warning means the run was measured and parsed, but the expected ACK was not observed. The reported results therefore reflect reliable-delivery cost under this workflow; unconfirmed uplink was not evaluated. Here, data rate (DR) denotes the regionspecific PHY setting, with lower DRs implying longer airtime. One run corresponds to one transmission attempt and at most one packet. A condition is one platform/DR/payload combination with three outdoor repetitions; condition-level metrics are the aggregated values over those repetitions, such as mean cycle energy/current/timing and ACK totals such as 3/3. The two main experimental platforms are the ST BWL5M-SUBG1 STM32WL board and WAN1310, both operated from a 3.7 V supply during the reported runs. The workflow records time-resolved current traces together with host and device event logs, allowing each run to be analysed in terms of cycle energy, mean current, peak current, and phase timing. The main outdoor comparison uses an approximately 100 m outdoor distance path and a matched matrix of three data rates (DR0, DR3, DR5), three payloads (15 B, 30 B, 45 B), and three repetitions per condition, giving 27 runs per outdoor dataset. The analysed STM32WL outdoor dataset records tx_periodicity_ms=5000, while the analysed WAN1310 outdoor dataset records tx_periodicity_ms=150000. This preserves the same communication matrix while allowing platform-appropriate inter-run spacing. The longer WAN1310 interval follows Arduino’s documented MKRWAN modem limit of one message every two minutes [22]. Using 150 s keeps WAN1310 above that firmware-imposed limit while preserving the same payload and data-rate matrix as STM32WL. The comparison is therefore a controlled per-cycle cost comparison, not a throughput comparison under identical inter-run spacing. Retransmission behaviour is not fully observable, so the analysis is based on observed cycle completion and ACK reception. Table I summarises the configuration details that can be confirmed directly from the code, metadata, and run summaries

TABLE II: Datasets used in the paper.

used in this paper.

TABLE I: System configuration. Item

Value confirmed from artefacts

Region

EU868

LoRaWAN class

Class A for STM32WL firmware; WAN1310 class not explicitly logged, default stack behaviour Confirmed uplink

Traffic type ADR state Data rates used

Disabled (adr_enable=0) in the analysed runs DR0, DR3, DR5

Payload sizes

15 B, 30 B, 45 B

Repetitions

3 per condition where available

Cadence in analysed runs

STM32WL outdoor dataset: tx_periodicity_ms=5000; WAN1310 outdoor dataset: tx_periodicity_ms=150000 STM32WL run summaries log 13 dBm; WAN1310 TX power was not surfaced by the saved experiment artefacts or configuration snapshots 125 kHz in logged radio-configuration events/run summaries STM32WL run summaries log CR4/5; WAN1310 coding rate follows stack/modem behaviour and was not surfaced by the saved experiment artefacts STM32WL run summaries log EU868 uplink frequencies; WAN1310 frequency follows stack/modem channel selection and was not surfaced by the saved experiment artefacts WisGate Edge Pro, model RAK7289CV2, using built-in server configuration Built-in gateway server; Network ID 1; server-side ADR enabled with ADR margin 5 dB; minimum allowed uplink DR0 (SF12/BW125), maximum allowed uplink DR7 (FSK 50 kbps); downlink TX power 20 dBm RX1 delay 1 s and RX1 data-rate offset 0; RX2 frequency 869.525 MHz at DR0 (SF12/BW125) Confirmed uplink used; run summaries report retry_count=0 in analysed examples; frame-counter validation disabled in the gateway server configuration Current Ranger

TX power

Bandwidth Coding rate

Frequency

Gateway model/configuration Network server

RX1/RX2 parameters

Retrans. settings

Current measurement device

Table II summarises the experimental datasets used in the paper. The STM32WL DR sweep serves as a preliminary characterisation for the outdoor study. It comprises eight valid runs across DR0–DR5 at 15 B and demonstrates a clear airtime-driven reduction in energy consumption, decreasing from DR0 (0.2561 J) to DR4 (0.0399 J) and DR5 (0.0325 J), consistent with expected communication costs. The primary quantitative comparison between platforms in this work is based exclusively on the two outdoor datasets.

Dataset

Board

Setting

DR sweep

STM32WL

precursor

8

8

Prelim. trend

Outdoor

STM32WL outdoor

27

27

Main comparison

Outdoor

WAN1310

27

27

Main comparison

outdoor

Runs Msgs.

Use

V. R ESULTS A. Reliability In the analysed outdoor comparison, both platforms produce a complete matrix: all 27 STM32WL runs and all 27 WAN1310 runs validate successfully, all nine DR/payload conditions produce packets, and every condition achieves 3/3 ACKed packets. Given the uniform ACK performance across all conditions, the analysis emphasises energy and current measurements as the distinguishing metrics. B. Energy Behaviour For the STM32WL outdoor dataset, mean cycle energy is consistent and physically interpretable across the full matrix. At DR5, cycle energy rises gently with payload from 0.0350 J at 15 B to 0.0397 J at 45 B. At DR3, the corresponding values are 0.0563 J, 0.0624 J, and 0.0714 J. At DR0, cycle energy rises further to 0.2505 J, 0.3037 J, and 0.3550 J, reflecting the much longer airtime and receive-window occupancy at the lowest data rate. The WAN1310 outdoor dataset shows the same qualitative airtime-driven trend but at a consistently higher absolute cost. At DR5, mean cycle energy rises from 0.0698 J at 15 B to 0.0811 J at 45 B. At DR3, the values are 0.1053 J, 0.1135 J, and 0.1274 J. At DR0, they rise to 0.4106 J, 0.4894 J, and 0.5662 J. Because all outdoor runs are successful confirmed uplinks in the analysed datasets, energy per successful packet is identical to cycle energy for both platforms throughout the matrix. The key comparison is therefore straightforward. Both platforms exhibit coherent scaling with data rate and payload, but STM32WL remains lower in cycle energy in every outdoor condition. The gap is already about 2.0 × at DR5/15 B (0.0350 J versus 0.0698 J) and remains substantial at DR0/45 B (0.3550 J versus 0.5662 J). The longer 150 s WAN1310 inter-run spacing does not contribute to these values because the reported energy is integrated over the active measurement window of each confirmed-uplink cycle rather than over the idle time between runs. C. Timing and Current Behaviour Figure 3 explains the energy trends mechanistically. For STM32WL, wake time is nearly constant at about 7.1 ms, while TX and RX dominate the cycle. TX time expands from 83.6 ms at DR5/15 B to 2611.1 ms at DR0/45 B; RX time

Fig. 2: Core outdoor distance comparison. All outdoor conditions achieved 3/3 ACKed packets on both platforms. Bars show three-run condition means; maximum coefficient of variation (CV) is 2.4% for energy and 2.2% for mean current, so error bars are omitted for readability. STM32WL remains lower in energy and mean current across the matrix.

rises from about 1058 ms at DR5 to about 2337 ms at DR0. The total cycle duration therefore grows from roughly 1.21 s at DR5/15 B to about 5.02 s at DR0/45 B. For WAN1310, the timing picture is also internally consistent across the matrix, but the radio-active portion is longer. TX time grows from 1278.6 ms at DR5/15 B to 5033.7 ms at DR0/45 B, and total cycle duration grows from 1.35 s to 5.11 s. A notable platform-level difference is that WAN1310 shows a very short logged RX interval of about 20 ms across the matrix, whereas STM32WL exposes a much longer receive-window contribution in the saved run summaries. This should not be over-interpreted as a literal statement that the WAN1310 radio physically listens for only 20 ms. Rather, the two boards expose RX timing at different instrumentation layers. In the STM32WL firmware, EV_RX_WAIT_START is emitted when the stack enters its receive phase and EV_RX_DONE is emitted when that phase closes, so the logged rx_time_ms includes the receive-window wait. In the WAN1310 sketch, by contrast, EV_RX_WAIT_START is emitted only after modem.endPacket(...) returns, so the saved rx_time_ms reflects only the short sketchvisible completion interval between that return point and the subsequent ACK/RX-done events. The mean average-current bars in Fig. 2 reinforce the same point: STM32WL average current ranges from 8.59 mA to 21.16 mA, while WAN1310 ranges from 15.61 mA to 33.54 mA. Peak current is also generally higher for WAN1310, reaching about 55.2 mA at DR5/15 B compared with 33.3 mA for STM32WL. Figure 4 provides a trace-level view of the same behaviour. The STM32WL representative trace shows a clearly segmented cycle with a stable idle period followed by a compact radioactive interval. The representative WAN1310 trace, by contrast, contains a longer radio-active interval with multiple separated current bursts. This is useful scientifically because it links the aggregate timing and energy metrics back to

observable current behaviour. D. System vs Platform Energy The controlled experiments are intentionally platformcentric rather than full deployment replicas. They measure the electrical cost of the communication cycle under a matched workflow, allowing board behaviour to be compared without implying that the resulting joule values are the total daily energy of an agricultural node. This distinction matters because sensing, storage, wake circuitry, battery characteristics, and solar charging all sit outside the radio-only budget [2], [6], [9]. Our measurements nevertheless make one useful systemlevel point. Even the heaviest successful outdoor condition in the controlled comparison, WAN1310 DR0/45 B at 0.5662 J, remains a sub-joule event. Communication is therefore episodic, whereas long-term survival depends mainly on what happens between cycles: sleep leakage, sensing frequency, and whether harvested energy can cover the average daily demand. At system level, a first-order energy budget can be written as the sum of the dominant tasks within one reporting cycle: Etotal ≈ EMCU,on + Esensors,power + Esensing + Eprocessing + Estorage + Ecomm + Esleep .

(1)

Here, Ecomm corresponds to the cycle energy characterised in this paper, while the remaining terms depend on the sensing stack, processing workload, storage behaviour, and duty cycle. Local processing is captured by Eprocessing . It may be negligible for thresholding or packet formatting, but can become material for embedded AI. As an indicative STM32WLclass measurement, a quantised WISDM activity-recognition model deployed through X-CUBE-AI consumed approximately 2.59 J over 400 logged samples, assuming a 3.7 V supply, or about 6.48 mJ per logged sample. Although outside the LoRaWAN comparison dataset, this illustrates why

Fig. 3: Timing breakdown for the outdoor distance comparison. Bars show three-run condition means; maximum coefficient of variation is 1.2% across plotted timing components, so error bars are omitted for readability. Both platforms show airtimedriven growth as data rate decreases and payload increases. RX timing should be interpreted carefully because STM32WL and WAN1310 expose receive behaviour at different instrumentation layers.

AI workflows, especially camera vision, must be treated as additional active loads. For agricultural nodes, the sensing side can dominate: the energy required to power sensors, wait for them to settle, acquire measurements, optionally log data to storage, and then switch those peripherals off can exceed the radio cost. In that sense the full node budget is approximately additive at first order, although real implementations also inherit losses from regulators, switching elements, and battery behaviour [2], [6]. Table III is included to illustrate how sensing and storage load can shift the overall energy balance away from radio energy alone. It gives a representative AgriTrust peripheral current budget that is used later for a worked example. Summing these devices gives an active peripheral load of 97.9 mA. In the worked example below, this load is held constant across platforms so that the effect of the different sleep-current cases can be compared directly. This framing motivates practical power-saving strategies: switch sensor and storage rails only for the measured time needed to complete each task, return the MCU to its lowest viable sleep state after transmission, and use external timerbased power gating when board-level sleep current remains too high.

TABLE III: Illustrative AgriTrust peripheral current budget based on typical operating currents under an all-active load assumption, not a full measured time-profile. Device

Current

Soil temperature sensor Soil moisture sensors pH sensor NPK sensor Ambient light sensor Ambient temperature & humidity sensor SD card module

0.7 mA 6.6 mA 11 mA 22 mA 7 mA 0.6 mA 50 mA

Total active peripheral load

97.9 mA

E. Sleep Current Impact Sleep current is a first-order determinant of long-term behaviour in sparse-duty-cycle operation. The measured contrast is 59.6 nA versus 104 µA, or about 1745×. The STM32WL value is plausible against STM32WLE5 datasheet figures of 31 nA shutdown, 360 nA standby with RTC, and 1.07 µA Stop2 with RTC at 3 V [23]. The WAN1310 value matches Arduino’s board-level statement that MKR WAN 1310 can reach 104 µA when properly configured [24], but remains configuration-dependent [25]. These are measured platformlevel sleep figures, not a fully harmonised board-for-board benchmark. Table IV converts them into idealised battery-only terms for a 3.7 V, 3700 mA h battery.

Fig. 4: Representative single-run current traces from complete successful cycles; standard deviations are therefore not plotted. WAN1310 remains longer and more bursty during radio activity than STM32WL.

The daily sleep-energy term is computed as shown in Table IV. TABLE IV: Idealised impact of sleep current for a 3.7 V, 3700 mA h battery. Platform

Sleep current

Sleep energy/day (Wh)

Sleep-only lifetime (days)

STM32WL WAN1310

59.6 nA 104 µA

5.29 µWh 9.24 mWh

2.59 × 106 1482

These lifetimes are comparative, not deployment predictions: they ignore battery self-discharge, temperature, sensing load, and communication. At 24 transmissions/day, the representative STM32WL DR5/15 B communication cost is only 0.233 mWh/day, whereas a constant 104 µA sleep current consumes about 9.24 mWh/day. External power-gating can reduce the effective WAN1310 sleep term substantially; AgriTruststyle timer operation can reach about 5 µA to 6 µA, while nano-power timer devices such as the TPL5110 are around 39 nA [26], [27]. F. Lifetime and Solar Interpretation For a node executing Ncycles communication cycles per day with energy Ecycle , the communication-only daily energy demand is Edaily = Ecycle × Ncycles . (2)

Expressing battery capacity in watt-hours, an ideal batteryonly lifetime estimate is Lifetimedays =

BatteryWh . Edaily

(3)

We use a 3.7 V, 3700 mA h battery, 24 cycles/day, and an illustrative solar recharge of 0.6 Wh/day. For representative STM32WL DR5/15 B, Ecycle = 0.0350 J gives Edaily ≈ 0.000233 Wh/day. This communication-only result is not a deployment prediction; it shows that radio energy is small relative to the battery and solar budget, so long-term behaviour is governed by sleep leakage, sensing strategy, duty cycle, and harvested-energy support. Figure 5 summarises this interpretation. To extend the communication results to a fuller agriculturalnode budget, Table V applies the 97.9 mA shared active load from Table III, 10 s active time, 3590 s sleep time, a 3.7 V 3700 mA h battery (13.69 W h nominal, 80% usable), and 1.4 W h d−1 usable solar input from a 0.5 W panel. It is illustrative, not a re-decomposition of the measured traces. The average current is Iavg =

Iactive tactive + Isleep tsleep . tcycle

(4)

and the corresponding full-duty-cycle daily energy is Eday,avg = Vbat × Iavg × 24.

(5)

The same active load is applied to each case so the sleepcurrent effect can be read directly. Nominal days uses the full 13.69 W h battery energy, Usable days uses the derated 80% usable battery energy, and positive solar surplus means daily harvest exceeds daily consumption. TABLE V: Representative AgriTrust-style lifetime example with shared active load. Daily Solar Nominal Usable energy surplus days days (Wh/day) (Wh/day)

Case

Sleep Iavg current (mA)

WAN 1310

104 µA 0.376 0.0334

410

328

+1.3666

WAN 1310 + timer

6 µA

0.278 0.0247

555

444

+1.3753

STM32 59.6 nA 0.272 0.0242 WL

567

453

+1.3758

This example shows that once sensing and storage loads are included, the system moves from extremely large communication-only lifetimes to a more plausible battery-only range of roughly 1 to 1.5 years. Under the stated solar assumptions, all three cases are energy-positive daily, explaining why AgriTrust-style operation depends on solar balance, battery ageing, environmental conditions, and hardware reliability rather than nominal battery capacity alone.

Fig. 5: Communication-only battery-lifetime comparison for representative outdoor STM32WL and WAN1310 conditions. The figure is illustrative rather than predictive. VI. D ISCUSSION Two conclusions emerge clearly from the analysed datasets. First, the AgriTrust deployment demonstrates practical viability: a LoRaWAN agricultural node can remain useful over multiple years, but only when the entire system is engineered for low average power. Secondly, the controlled comparison demonstrates clear platform differences even when both

boards complete the same outdoor confirmed-uplink matrix successfully: STM32WL is consistently lower in energy, mean current, peak current, and TX duration than WAN1310 across the measured payload and data-rate combinations. The deployment shows that long life is achievable; the controlled comparison shows which platform properties make that outcome easier to engineer and analyse. This has a broader methodological implication. Comparing platforms by joules alone is most informative when both sides are executing comparable successful transactions; the present outdoor matrix provides exactly that condition. The remaining differences can therefore be attributed more directly to board- and stack-level behaviour rather than to missing acknowledgements or truncated cycles. This is also consistent with prior work suggesting that system energy can be strongly influenced by standby, sensing, and platform overheads rather than by radio transmission alone [2], [6], [15], [9]. The deployment and controlled experiments therefore complement each other: one demonstrates that a practical node can work in the field, while the other shows which platform characteristics make low-power behaviour easier to characterise and optimise. The observed WAN1310 behaviour should also be attributed carefully. In the analysed outdoor matrix it completes all confirmed-uplink transactions successfully, so the main difference is not reliability failure but higher electrical cost for the same communication task. That difference may arise from modem/stack implementation details, radio timing, and the way the saved run summaries expose TX and RX phases, rather than from any single hardware factor alone. The present results therefore support a claim about measured platformlevel behaviour in this setup rather than a blanket claim about intrinsic hardware superiority in all LoRaWAN scenarios. The study also has clear scope limits: one outdoor site of approximately 100 m, three repetitions per condition where available, confirmed uplink only, and platform-dependent behaviour under one host-driven workflow. Because the platforms expose some timing events at different instrumentation layers, the paper reports descriptive statistics, run-level validation, and repeated-run variability rather than inferential significance testing. The comparison should therefore be read as a controlled characterisation study, not as a complete generalisation across sites, firmware stacks, or all LoRaWAN modes. To support reuse, the collected measurement dataset used for the paper results is available on Zenodo at DOI: 10.5281/zenodo.20136328. VII. C ONCLUSION This paper combines a real agricultural LoRaWAN deployment with controlled platform-level experiments. The deployment evidence shows that multi-year operation is achievable in practice, but only through system-level energy design. The controlled comparison shows that both STM32WL and WAN1310 can execute a complete confirmed-uplink outdoor matrix in this setup, while STM32WL does so with lower energy, lower current, and shorter TX durations across the tested payload and data-rate combinations. Most importantly,

the system-level analysis shows that radio energy alone does not explain long lifetime: sleep leakage, sensing strategy, duty cycle, and solar support are the dominant determinants of longterm viability. R EFERENCES [1] L. Casals, B. Mir, R. Vidal, and C. Gomez, “Modeling the energy performance of LoRaWAN,” Sensors, vol. 17, no. 10, p. 2364, 2017. [2] T. Bouguera, J.-F. Diouris, J.-J. Chaillout, R. Jaouadi, and G. Andrieux, “Energy consumption model for sensor nodes based on lora and lorawan,” Sensors, vol. 18, no. 7, p. 2104, 2018. [3] S. Maudet, G. Andrieux, R. Chevillon, and J.-F. Diouris, “Refined node energy consumption modeling in a lorawan network,” Sensors, vol. 21, no. 19, p. 6398, 2021. [4] V. Raghunathan, A. Kansal, J. Hsu, J. Friedman, and M. Srivastava, “Design considerations for solar energy harvesting wireless embedded systems,” in IPSN 2005: Fourth International Symposium on Information Processing in Sensor Networks, 2005, pp. 457–462. [5] A. Kansal, J. Hsu, S. Zahedi, and M. B. Srivastava, “Power management in energy harvesting sensor networks,” ACM Transactions on Embedded Computing Systems, vol. 6, no. 4, p. 32, 2007. [6] B. Thoen, G. Callebaut, G. Leenders, and S. Wielandt, “A deployable lpwan platform for low-cost and energy-constrained iot applications,” Sensors, vol. 19, no. 3, p. 585, 2019. [7] G. Codeluppi, A. Cilfone, L. Davoli, and G. Ferrari, “Lorafarm: A lorawan-based smart farming modular iot architecture,” Sensors, vol. 20, no. 7, p. 2028, 2020. [8] R. K. Singh, M. Aernouts, M. De Meyer, M. Weyn, and R. Berkvens, “Leveraging lorawan technology for precision agriculture in greenhouses,” Sensors, vol. 20, no. 7, p. 1827, 2020. [9] V. Novák, P. Ambruz, E. Kánská, M. Stočes, J. Vaněk, J. Veselý, and K. Sylvar, “Predictive battery life modeling for lorawan sensors using real-world deployment data,” AGRIS on-line Papers in Economics and Informatics, vol. 17, no. 3, 2025. [10] C. Dickinson, S. Nagaraja, C. M. Ahmed, and R. Hyde, “Agritrust: A testbed to enable trustworthy smart AgriTech,” in Proceedings of the First International Symposium on Trustworthy Autonomous Systems (TAS), Edinburgh, UK, 2023, pp. 22:1–22:13. [11] LoRa Alliance Technical Committee, “LoRaWAN L2 1.0.4 Specification (TS001-1.0.4),” LoRa Alliance, Tech. Rep., 2020. [12] LoRa Alliance Technical Committee Regional Parameters Workgroup, “LoRaWAN Regional Parameters (RP002-1.0.5),” LoRa Alliance, Tech. Rep., 2025. [13] Semtech Corporation, “SX1272/3/6/7/8: LoRa Modem Design Guide (AN1200.13),” Semtech Corporation, Tech. Rep., 2013. [14] S. Ould and N. S. Bennett, “Energy performance analysis and modelling of lora prototyping boards,” Sensors, vol. 21, no. 23, p. 7992, 2021. [15] R. K. Singh, P. P. Puluckul, R. Berkvens, and M. Weyn, “Energy consumption analysis of lpwan technologies and lifetime estimation for iot application,” Sensors, vol. 20, no. 17, p. 4794, 2020. [16] O. Väänänen and T. Hämäläinen, “Efficiency of temporal sensor data compression methods to reduce lora-based sensor node energy consumption,” Sensor Review, vol. 42, no. 5, pp. 503–516, 2022. [17] A. Liopa-Tsakalidi, V. Thomopoulos, P. Barouchas, A. D. Boursianis, and S. K. Goudos, “A lorawan-based iot platform for smart irrigation in olive groves,” Smart Agricultural Technology, vol. 9, p. 100673, 2024. [18] F. Perret, I. Cherif, F. Cherqui, N. Walcker, A. Barra, B. Bourjaillat, L. Bacot, and O. Navratil, “elogup! a precise, affordable and opensource iot data logger to scale-up long-term environmental monitoring,” HardwareX, vol. 23, p. e00660, 2025. [19] S. Peng and C. P. Low, “Prediction free energy neutral power management for energy harvesting wireless sensor nodes,” Ad Hoc Networks, vol. 13, pp. 351–367, 2014. [20] R. La Rosa, L. Boulebnane, A. Pagano, F. Giuliano, and D. Croce, “Towards mass-scale iot with energy-autonomous lorawan sensor nodes,” Sensors, vol. 24, no. 13, p. 4279, 2024. [21] A. Ma, J. C. Tonday Rodriguez, and M. Sha, “Enabling reliable environmental sensing with lora, energy harvesting, and domain adaptation,” in 2024 33rd International Conference on Computer Communications and Networks (ICCCN), 2024, pp. 1–9. [22] Arduino. (2025) LoRa Send And Receive. [Online]. Available: https://docs.arduino.cc/tutorials/mkr-wan-1310/lora-send-and-receive

[23] STMicroelectronics, “STM32WLE5xx / STM32WLE4xx Datasheet: Multiprotocol LPWAN 32-bit Arm Cortex-M4 MCUs with LoRa, (G)FSK, (G)MSK, BPSK,” STMicroelectronics, Tech. Rep., 2022. [Online]. Available: https://www.st.com/en/ microcontrollers-microprocessors/stm32wle5cc.html [24] Arduino. (2026) Arduino MKR WAN 1310. [Online]. Available: https://store.arduino.cc/products/arduino-mkr-wan-1310 [25] zuyan9. (2020) MKR WAN 1310 Sleep Current. [Online]. Available: https://github.com/arduino-libraries/MKRWAN/issues/79 [26] Microchip Technology. (2018) ATtiny24/44/84 Automotive Microcontrollers Datasheet. [Online]. Available: https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7701_ Automotive-Microcontrollers-ATtiny24-44-84_Datasheet.pdf [27] Texas Instruments. (2025) TPL5110 Nano Power System Timer for Power Gating Datasheet. [Online]. Available: https://www.ti.com/lit/ds/ symlink/tpl5110.pdf

Record · ID 919306 · SHA-256 c3d315d3dade1892
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.