## 5 Evaluation and Results
### Experimental Setup and Evaluation  
To realize the experimental testbed, we set up 15 WISPES nodes to communicate within a cluster to the sink node. Note that, it is possible to extend the cluster network into a hierarchical topology as  
Figure 7: Experimental testbed topology. investigated in [53], in which, every cluster-head performs aggregation by summing up the compressed vectors. In our study, we assume the sink is rich in energy-resource due to unlimited power supply, and it is capable of processing the data received from the network (see [63], for detailed discussion on the hardware unit and the software protocol stack). Considering that we are dealing with a fire scenario, we are constrained to mimic a real wildfire by generating an artificial fire prescribed as test-burn with the use of a heat gun. The heat gun is capable of generating a regulated hot air up to 200 \({}^{\circ}\)C in a short burst. This enables testing of SWIFTNET across different temperature ranges and on several nodes. Particularly, we conducted two separate scenarios; an equivalent of a 24 h and a 48 h test-burns. For both cases, the air temperature is sampled at 5 min intervals, which amounts to 288 samples in 24 h and 576 samples in 48 h, the sparsity K is set to 25% of the total samples collected in each case. The first test-burn offers a glimpse on the behavior of SWIFTNET with respect to acquiring data aggressively when there are meaningful events and otherwise performs data compression. Figure 8a depicts how SWIFTNET begins operation in the normal mode roughly between \(0\) and \(142\) data points when aggressive data gathering is not necessary, and then it adaptively switches to fire zone (recall from Figure 4) at about \(143\) to \(185\) data points, when the user-defined _threshold_ is consistently violated over the \(n\)-window period. We observed the operation worked seamlessly in the network and all the nodes that captured the changes in air temperature reported their data accurately. SWIFTNET in Figure 8a transmitted less data to the sink compared with the adaptive prediction (NLMS) in Figure 8b, which transmitted more data to the sink. However, not much accuracy is lost by SWIFTNET, the details are presented under the discussion of result section. The second test-burn, that is the 2-day period offers a more interesting scenario, as we are able to generate fire scenarios at different time intervals of the days using a threshold cut-off air temperature of 45 \({}^{\circ}\)C (this is shown in Figure 9a). This figure reveals different fire intensities between 0 and 300 data points during the test-burn and then the evolution of the air temperature as the fire cools off. It can be observed from this figure that our algorithmic solution switches back and forth between data compression and adaptive prediction seamlessly without disrupting the operation of the nodes in the network. For example, roughly between data points 80 and 120, the air temperature drops below the 45 \({}^{\circ}\)C threshold and the node automatically switches to CS. Beyond 120 data point we increase the burst of the hot air temperature, and the node switches back to adaptive prediction. This trend can be observed on other data points on the series. Comparing this behavior between SWIFTNET in Figure 9a and adaptive prediction algorithm (NLMS) in Figure 9b, it can be observed that the adaptive prediction algorithm achieves smoother trend following the original data trace. However, this is at the expense of a higher transmission cost. Instead, SWIFTNET is able to transmit less data with a comparable level of accuracy. More details of this result is discussed in the next sections. An important characteristic is that the nodes are able to work autonomously, while sending their individual data packets to the sink node for the signal reconstruction. Figure 8: Signal reconstruction from Node 1, for a 1-day wildfire monitoring test-burn using a 40 \({}^{\circ}\)C _threshold_ cut-off point.