## 3 Nodes' Configuration and Transmission Protocol
This time will depend on several factors, such as the number of packets to be transmitted (considering both the locally generated and the forwarded traffic), the transition time from _sleep_ to _active_ mode and viceversa, and the time needed to acquire synchronization among nodes. On the other hand, following the Semtech SX1272 LoRa module datasheet [32], the transition times account for a maximum of few ms, and hence it can be neglected in the following. As for transmission time, the Time on Air for a LoRa module with the settings defined in Table 1, i.e., CR = 4/5, SF = 12 and BW = 125 kHz, can be calculated according to [35], and it has been evaluated in different conditions in [36]. For a 51 byte payload it has the following value:  
\[T_{onAir}\simeq 2.1\,\mathrm{s} \tag{1}\]  
Concerning power consumption, the SX1272 datasheet provides the following values:  
* Supply current in Receive Mode (Boost modality off) \[I_{RX}=10.5\,\mathrm{mA}\] (2)
* Supply current in Transmit Mode (Boost modality off, RFOP\(=+13\,\mathrm{dBm}\)) \[I_{TX}=28\,\mathrm{mA}\] (3)  
Nevertheless, these values do not take into account the power consumption of additional components like the microcontroller, the sensors and the connection circuitry. Accordingly, in order the get a more realistic value, the actual current absorption has been experimentally acquired by powering the test Sensor Node with a laboratory DC power supplier and then measuring the current with a digital multimeter. The following values have been measured:  
* Supply current in Receive Mode (Boost modality off) \[I_{RX}=66\,\mathrm{mA}\] (4)
* Supply current in Transmit Mode (Boost modality off, RFOP\(=+13\,\mathrm{dBm}\)) \[I_{TX}=98\,\mathrm{mA}\] (5)  
These values show that the overall consumption of the logic and acquisition part of the Node would be unsustainable if the nodes were always active. As an example, for a commercial battery capacity of 3-4 Ah, the battery should be recharged every 1-2 days. On the other hand, in order to implement an efficient duty cycling mechanism, the clocking mechanism is of particular importance. To this respect, two possible clocking systems can be considered for the scenario at hand: (_i_) an internal clock (natively embedded inside a microcontroller) or (_ii_) an external clock (generally an ad-hoc RTCor any other kind of device as for example a counter [37]). While external clocks are in general more accurate [38], internal clocks prevent from the necessity of using an additional device. Moreover, with internal solutions, the length of the sleep period can also be dynamically changed through the use of an ad-hoc firmware. For this reason, the use of the internal clock has been adopted in this work. Needless to say, one of the most important factors that affect the efficiency of duty-cycling mechanisms in the considered scenario is given by the clock accuracy. This aspect will be extensively discussed in the next Section. In order to estimate the accuracy of the internal clock of a microcontroller, a test duty-cycling routine was set up on an Arduino UNO board. In this routine a 3600 s sleep period was set: after this lapse of time, the microcontroller wakes up and transmits a packet. The Timestamp of the packets arrival are recorded and the differences between two successive Timestamps are taken as a measure of the actual sleeping period. A total of 1000 values was measured and their distribution is shown in Figure 5, where \(f_{g}(x)\) is the pdf of the sleeping time error. It is worth noting that, despite the clock error is unbiased, a considerable deviation with respect to the expected waking up time is observed (in certain cases the error can be higher than 100 s). In order to put in evidence the critical role of the synchronization inaccuracies in the considered scenario, a prototype monitoring system has been set up and tested in the laboratory.