# Development of Radio-Frequency Sensor Wake-Up with Unmanned Aerial Vehicles as an Aerial Gateway
## 6 Experimentation and Results
### Energy Consumption Analysis and Verification
This statement has been similarly stated in [11; 13]; however, no physical implantation and comparative validation are found in their efforts. \begin{table}
\begin{tabular}{c c} \hline \hline
**Hardware** & **Current** \\ \hline _MCU_ & 15 mA \\ _Sensors_ & 30 mA \\ _XBee_ & 165 mA/45 mA \({}^{*}\) \\ _IR_ & 0.45 mA \\ _RF_ & 2.3 uA/6.1 uA ** \\ \hline \hline \end{tabular} \({}^{*}\) The two values represent working/idle listening, ** 2.3 uA when 1 channel is enabled, 6.1 uA when 3 channels are enabled.  
\end{table} 
Table 3: Nominal current values for subunits within a sensing module. To evaluate the qualitative statement above, we built a sensing network using Waspmote 1, 2, and 3. Each were set up with XBee modules, and the wake-up hardware corresponded to Solutions 1, 2, and 3. For each implemented solution, the more was attached with a rechargeable 6600 mAh lithium-ion battery. We programmed that when the Waspmote woke up, the MCU will measure the battery voltage level and calculate the current battery percentage. A separate XBee coordinator was placed within the line-of-sight to each network of the Waspmote modules, forming a star XBee network in an indoor environment. To compare the difference in energy consumption between these three solutions, we minimized the possible power consumption from the front-end hardware; therefore, no additional sensing units were used in this test. Each Waspmote was woken up by using its corresponding methods and joined the XBee network every 4 h. Then, they sent a 'hello' message to the coordinator, which was always turned on. After that, each Waspmote read the current battery level and then went back to its original state: XBee idle listening, IR receiver listening, or RF receiver listening, respectively, as designed and implemented in Solutions 1, 2, and 3. We monitored the test for about 130 h for the three physical prototypes, and the battery levels were measured and recorded. The resulting energy consumption results are collectively shown in Figure 11.  
From the above results we found that Solution 1, in which the XBee module and MCU were always turned on, drained the battery quickly, in less than 90 h. The data transmitted in Solution 1 discontinued after 88 h since the battery level dropped to 23%, and the Waspmote stopped working due to the low voltage. In Solution 2, we can still see a linear drop in the battery level, but with a slower rate compared to Solution 1. As we stated above, most energy in Solution 2 was consumed by the IR receiver and the MCU. We concluded that the XBee idle and listening states consumed a large percentage of energy. Although we did not measure until the more stopped working for Solution 2, we believe the battery level drop was linear, a rate of 0.48% per hour, and would last a total of about 208 h (through linear fitting with a fixed intercept of 100%). Lastly, the battery level of Solution 3 did not drop significantly due to the RF wake-up solution. Due to the low dropping rate, we only measured a 2% drop during the 130 h test. Assuming a linear rate of consumption (through the linear fitting in Figure 11), we expected that the Solution 3 network would continue working for about 5556 h (or about a 7.5-month period). This was a remarkable improvement compared with both Solutions 1 and 2. Figure 10: Energy consumption illustrations resulting from the three solutions. Second, all the consumption rates were compared (as shown in the linear fitting in terms of the slope values). One can see that the power consumption rate from Solution 3 was about 3.8% of Solution 2, and 1.9% of Solution 1. This approximately confirms the previous analytical studies. In fact, we noted a better result (3.8% instead of 6%) from the analytical evaluation based on Figure 10 when comparing Solutions 2 and 3. We believe this was attributed to the actual XBee communication time being less than 1 min since there was not so much data being transferred in this test.