# Design and Evaluation of IoT-Enabled Instrumentation for a Soil-Bentonite Slurry Trench Cutoff Wall
## 4 Data Transport  
The data collection job on the Raspberry Pi produces JSON files that need to be transmitted to the gateway and inserted into the time series database for permanent storage. Wireless sensor networks have developed mature data collection and transport protocols [9; 10; 11; 12; 13]. Implementations of these network protocols are available for typical WSN platforms such as TinyOS [14] and Contiki [15]. 6 LoWPAN [16] could also be leveraged for its data transport capability. However, we discount these solutions because they are typically deployed with IEEE 802.15.4 [17] radios, which would require multiple hops to reach the gateway from the deployment site. Since the site and gateway is separated by a river and private property, it would be very difficult to deploy multiple nodes along the path to create a connected network. On the other hand we also explored commercial point-to-point WiFi solutions (e.g., Ubiquiti LiteBeam ([[https://www.ubnt.com/](https://www.ubnt.com/)]([https://www.ubnt.com/](https://www.ubnt.com/))), MikroTik ([[https://mikrotik.com/](https://mikrotik.com/)]([https://mikrotik.com/](https://mikrotik.com/))), etc.). These solutions deliver hundreds of megabits per second data rates over ranges up to 15 km. This is orders of magnitude more than is required for our application, which comes at a price. In this case, the cost is energy consumption up to 10-Watts. Additionally, these solutions required 120 Volt AC power or 24/48 Volts for PoE. This would necessitate another DC-DC converter or power inverter at the site in addition to extra batteries and solar panels. To avoid the significant energy cost, we elected to re-purpose the existing equipment we had. Namely, the Digi XBee 900 HP radio modules and 900-MHz Yagi antennas. To transport the data we built a lightweight point-to-point reliable data transport protocol that we call the XBee Transfer Protocol. The XBee Transfer Protocol (XTP) was inspired by ZMODEM [18] and similar classic network protocols. It is a simple protocol for reliably transferring files between two XBee radios that is written in Python using the Python-XBee package ([[https://github.com/niolabs/python-xbee](https://github.com/niolabs/python-xbee)]([https://github.com/niolabs/python-xbee](https://github.com/niolabs/python-xbee))) and is made available as open source software ([[https://github.com/amm042/XbeeTransferProtocol](https://github.com/amm042/XbeeTransferProtocol)]([https://github.com/amm042/XbeeTransferProtocol](https://github.com/amm042/XbeeTransferProtocol))). The entire protocol implementation is approximately 400 lines of Python split evenly between the sending and receiving code. The receiver periodically broadcasts a beacon for discovery. Once the receiver has been discovered by the sender, the protocol breaks up a file into chunks and data fragments for transmission as shown in Figure 8. The file is first broken into fixed-sized chunks up to 64 KB. Each chunk is then split into fragments smaller than the MTU of the radio for transmission. The fragment size can vary depending on the XBee variant, but is typically 127 bytes. This two-level structure enables transferring large files while still allowing efficient 3-byte data fragment headers. Correctness is ensured at all levels. Fragments are checked by the radio's underlying per-packet CRC. Each reconstructed chunk must also pass a 32-bit CRC. Finally, the resulting file must have the same MD5 hash for a transfer to be successful. Transmitting a chunk is initiated by the sender transmitting a send request containing an 8-bit packet identifier followed by four 32-bit unsigned values defining (1) byte offset of the chunk in the file, (2) the total file size in bytes, (3) the number of fragments in the chunk, and (4) the 32-bit CRC of the chunk. Following this header is the filename encoded as a UTF-8 string. Since the offset and file size are 32-bits, the maximum supported file size is 4 GiB. The send request packet length is 17 bytes plus the length of the encoded filename.