# The Design and Deployment of an End-To-End IoT Infrastructure for the Natural Environment
## 5 Deployment Experiences of an Environmental IoT
### Battery Usage (Interval for Changing Batteries)  
The runtime of all of the nodes was shorter than anticipated, requiring attendance at the field site at 5-day intervals by the environmental science team to attend to nodes which had ceased reporting. We consider four reasons for this: (1) Additional consumption of power by the attached sensors may have been greater than estimated. (2) The 3.6-V battery packs connected in series, each include an internal circuit protecting against over-charge and discharge. Any discrepancy in charge between the packs comprising a unit would result in one component pack reaching upper/lower protection thresholds ahead of others, interrupting the circuit for all component packs. With this experience, we consider that 12-V, deep-cycle, sealed lead acid batteries would offer a more cost-effective and suitable power source despite a somewhat larger and heavier format. These could be connected externally and maintained by a solar panel depending on node situation. (3) Later in the project, we detected a problem with the sleep/wake cycle of the XBee, which resulted in nodes ceasing to report and which may have been mistaken for a discharged battery. The frequency of this occurrence during field deployment is not clear, but in hindsight, the observation that nodes could often be restarted by cycling the power rather than replacing the battery, and observation that a healthy voltage was often measured in batteries recovered for charging suggests that this error may account for a significant number of early drop-outs. (4) Exceptionally poor weather limited solar recharge effectiveness across the deployment. In addition, we note that we were never able to operate the accelerometers on the animal tracker nodes as the volume of radio traffic generated was too high a drain on their batteries. Independent trials suggested that on-node classification algorithms could have been used to process data locally before sending a simple summary status of the animal such as \"standing\", \"sleeping\", etc. As a general comment on our platform, we found that the Arduino hardware that we chosen had a surprisingly high power draw even in sleep mode; a modified solution that uses a low-power micro-controller to wake up the main Arduino chip when needed could have significantly helped with this but was beyond our capability to implement in the time constraints that we had. An early guide from the environmental science team indicated a desire to try using a large number of cheap sensors rather than fewer more expensive sensors. The motivation behind this was to reduce deployment cost, sacrificing data quality for quantity in some cases, while still maintaining selected high-quality sensors in the field as calibration points. For our particular deployment conditions(particularly the extreme weather), this does not appear to have paid off, with a high frequency of anomalies in sensor data being apparent. For the prototype overland flow detector and the air temperature/humidity sensors, problems with the constructed housings are likely to have contributed to anomalous data. Overland flow detectors are not commercially available due to difficulties in designing a reliable instrument, and our prototype suffered problems with false positives due to internal condensation and blocked drainage. Subsequently the Grove water sensor, incorporated to detect the presence of water in the channel, became corroded due to the relatively cheap copper alloy used in its construction. Research-grade air temperature and humidity sensors are usually enclosed in radiation shields to minimise heating by solar radiation and direct exposure to precipitation. These may be passively or actively aspirated. These shields cost much more than our chosen sensors. We used white plastic cups as shields which excluded precipitation but were not vented and may have trapped heat and condensation.