# Design and Evaluation of IoT-Enabled Instrumentation for a Soil-Bentonite Slurry Trench Cutoff Wall
## 7 System Evaluation  
After more than 2 years of operation, we have collected over 1 GB of raw sensor data using this system. The system was designed to ensure that at least one sample per hour is recorded from each sensor. To ensure this minimum level of data, the datalogger is programmed to sample the primary sensors 4 times per hour. The secondary, non-essential sensors such as weather and battery voltage, are sampled once per hour. Accordingly, the database should receive 11,453 raw samples per day. Using this number as a benchmark, the actual data yield over the deployment is shown in Figure 11. Data from July 2016 is available, however, has been omitted in our analysis because the datalogger program was modified several times in this period and as a result the number of samples received varied. Figure 10: The web-based dashboard plotting data from one sensor in a group of sensors. Over the 722-day evaluation period, the database received 99.42% of the expected data. There was one day early in the test where extra samples were received. Early in the deployment data was also collected manually, which required disconnecting the Raspberry Pi from the datalogger. If the Raspberry Pi was downloading at the same time the download progress is not saved. After this event, we made sure to stop the Raspberry Pi before disconnecting it. There were two periods in late 2016 that the battery on the datalogger died causing loss of data for various periods over 6-days. As a result, the original 24 Ah battery was replaced with a 113 Ah battery eliminating this problem. Excluding the dates with power failures, the database recorded 99.95% of the expected raw data. The exact cause of the remaining data loss was investigated and the lost data was consistently from the weather station not providing a set of hourly readings. One possible explanation is that the weather station's temperature/humidity sensor was the only sensor to use the SDI-12 serial protocol and this sensor was also duty-cycled sensors to save power. Since SDI-12 is an active protocol, it is possible this sensor failed to respond in time and recordings were skipped. We were unable to verify this explanation. However, because all other sensors reported correctly at these times we believe this data was never received by the datalogger. To avoid this we could replace the sensor or disable duty-cycling in the future. To investigate the performance of XTP under the deployed conditions, we added performance monitoring in September 2018 to all XTP file transfers. Figure 12a shows the hourly radio performance in terms of packet (fragment) delivery rate and aggregate throughput. The average packet delivery was 99.97% and the median throughput was 7.13 Kbps. Figure 12c shows the hourly radio utilization is under 1% with median 0.38%. These results show that transporting data from the site is a relatively easy task. We did not evaluate the overall data latency as the XTP latency is significantly less than the latency caused by the data collection job. The distribution of file transfer duration is shown in Figure 12b. The data collection job runs every 5-min, which is much grater than the typical transfer time. Overall, we conclude there was no data loss due to a failure of the data collection, transport, or storage systems developed for this project. We believe this is a result of our intentional focus on redundancy and separation of tasks within the system. If a data collection fails, it can be retired as the data is buffered on the datalogger. The data transmissions are checked at multiple levels and if a transmission fails, it starts over until it succeeds buffering incoming data in the meantime. Data is stored in the time series database and archive data is also stored both on the SD card at the site and on the gateway computer's hard drive for recovery. Fortunately, we have not had to use these archives but having them provides extra safeguards.