# New Protocol and Architecture for a Wastewater Treatment System Intended for Irrigation
## 3 Results
### Status of the SDs  
Considering the protocol described in Figure 7, one of the main aspects of this protocol is storing data, instead of sending it, waiting until the moment in which the water quality changes to send all stored data. We have to consider that the nodes which are not a Cluster Head (CH) store the data before sending them to the CH once the node detects a change. This procedure implies that the CH node stores large amounts of data just before sending them. Figures 10 and 11 show the stored information in the SD of each one of the included nodes in our topology. While Figure 10 focuses on the first 60 min of the simulation, allowing for seeing some of the processes in detail, Figure 11 summarizes the whole simulated period. Figure 8: Maximum theoretical distance at 868 MHz for free space. Figure 9: Maximum theoretical distance at 868 MHz for few obstacles. In Figure 10, we can identify the stored information in the SDs of the clusters of six included locations: (a) UA1, (b) UA2, (c) IC1, (d) PO1, (e) PO2, and (f) PO 3. Focusing on Figure 10a, we can identify that the three nodes store information until minute 35. In minute 35, Node 3 and Node 2 detect a change in water quality. Node 1 has a false negative. Node 3 sends data to Node 2 and erases the data. Then, Node 2 checks that both nodes registered a change and sends all the data stored in the SD to the gateway. We can identify that Node 3 continues storing information during the rest of the period. In UA2, in Figure 10b, we can see the same case in minute 5, in this case, Node 3. Then, we identify a case in which the three sensors detect a water pollution change, see minute 52. In that case, the two nodes (Node 1 and Node 3) send the CH node data. Thus, the stored information is incremented three times. At that moment, the SD of the CH node stored  
Figure 10: Stored information in the SDs cards of nodes. Details of the first 60 min of operation. Different letters (**a**) to (**f**) denote the different locations of the cluster: (**a**) UA1, (**b**) UA2, (**c**) IC1, (**d**) PO1, (e) PO2, and (f) PO 3. 5550 bits of information. Similar cases can be seen in Figure 10c in minutes 41, 47, 51, and 59, and in Figure 10d in minutes 51 and 57. This delay of 10 min between IC1 and PO1 is the simulated time that the water remains in each pool. Finally, Figure 10e,f show the normal data storage process in the SDs. Since water is treated twice and three times, there are fewer water quality changes. On the other hand, Figure 11 shows the SD usage for each node along the simulated period of one week. We can identify that locations UA1, UA2, and IC1 have a similar trend. All these areas, in Figure 11a-c, have low volumes of data stored in the SDs due to the constant exchange of information with the gateway caused by changes in water quality. Meanwhile, PO1, PO2, and PO3 are clusters characterized by larger amounts of data stored in the SDs, particularly during the second day of our simulation. In general terms, we can see that areas characterized by a lot of change follow the patterns seen in Figure 10. We can  
Figure 11: Stored information in the SDs cards of nodes. Summary of the whole simulated period. Different letters (**a**) to (**f**) denote different locations of the cluster: (**a**) UA1, (**b**) UA2, (**c**) IC1, (**d**) PO1, (**e**) PO2, and (**f**) PO 3.  
have false positives, false negatives, or true positives related to the water quality, which induce the sending event of stored data. In addition, we can see a secondary pattern here, mainly in the areas characterized by a lower degree of change. In these cases, when no changes are detected, Node 1 and Node 3 send all the information to the CH at midday to free their SDs, and as a method of control, as explained in Figure 5. This behavior can be particularly identified in the node of PO3, in which the unique movements of data in the SDs are related to the process.