Challenges in Developing Intelligent Geosystems - Semantic Scholar

Challenges in Developing Intelligent Geosystems (and the pros/cons of interdisciplinary research) Tracy Camp, Marc Rubin, and Santiago Gonzalez Dept. EECS, Colorado School of Mines Golden, CO 80401 {tcamp, mrubin, sgonzale} @mines.edu

Abstract—In this article, we examine the challenges of developing intelligent wireless geosystems and the pros and cons of interdisciplinary research. First, we summarize the range of current practices in wireless sensor network research projects by analyzing recent contributions in the literature. Specifically, for each wireless sensor network project, we compile details regarding the scope (e.g., simulation, testbed, real deployment), the type of mote used (e.g., TinyOS, Android, Arduino), and the type of sensors used (e.g., inertial, biological). Next, we discuss reasons why Arduino based wireless devices are perhaps the future of applied wireless sensor network research. Arduino-based systems are inexpensive, easy to use, readily available, well documented, 100% open-source (hardware and software), object oriented, extendable (using the “shield” concept), and flexible (e.g., in terms of radio choices). Lastly, we discuss the pros and cons of interdisciplinary research; that is, we highlight the struggle between working on difficult, relevant, inherently multi-disciplinary research problems while maintaining scholarship in individual fields.

I. I NTRODUCTION SmartGeo at the Colorado School of Mines is an interdisciplinary engineering and science graduate program designed to prepare leaders in the development of intelligent geosystems, i.e., engineered and natural earth systems/environments that sense their environment and adapt to improve performance. SmartGeo is different than traditional Ph.D. programs, e.g., SmartGeo students and faculty participate in Interdisciplinary Collaborative Research Teams to pursue transformative advances in intelligent geosystem concepts. SmartGeo began in 2008, thanks to a grant provided by NSF’s IGERT program. Figure 1 shows the wide range of disciplines that have been involved in SmartGeo over the years.

There are many applications that fall within SmartGeo, including intelligent earth dam geosystems and intelligent remediation geosystems. For example, consider that our nation’s subsurface is contaminated, due to legacy industrial, commercial, and military operations. Current practice in remediation involves a significant manual process for feedback, e.g., water from a contaminated site is manually collected from discrete sampling locations for analysis. Our goal in SmartGeo is to create an intelligent remediation geosystem that senses existing contamination in the subsurface and then autonomously adapts the geosystem to ensure the contamination does not flow into our drinking water. In regards to earth dams and levees, the average age of the 84,000 earth dams in the U.S. is just over 52 years [1], which is past their intended design life of 50 years. Current monitoring practice, even for high-risk dams, is a manual process that occurs infrequently, with limited automation and little adaptability. Our goal in SmartGeo is to create an intelligent earth dam geosystem that senses erosion (a dominant failure mode of earth dams) and then adapts the geosystem to improve performance (e.g., lower water in the reservoir). Although we are surrounded by geosystems in the United States, and although the failure of a geosystem can have a dramatic negative impact on society, the current state-ofpractice for monitoring a geosystem is labor-intensive, very costly, and does not provide a good understanding of the overall system behavior (e.g., lacks a temporal understanding). The goal of SmartGeo is to create the technology to allow for continuous non-invasive geophysical monitoring, performance assessment, and maintenance of geosystems. Challenges to meet this goal include: • • • • • •

Fig. 1: SmartGeo Disciplines.

the development of a wireless geophysical device to facilitate a dense and long-term field deployment, significant energy usage challenges that we reduce with compressive sensing techniques, accurate time synchronization and precise localization and orientation of each mote and sensor, automatically creating and maintaining a model of the geosystem behavior, making predictions of the geosystem’s state (with a given level of uncertainty), and validating that the feedback loop within the intelligent geosystem is functioning accurately.

In this paper, we focus on the first challenge, i.e., development of a wireless geophysical device to facilitate a dense and long-term field deployment. We first present data on the different types of wireless sensing devices that are most often used in research projects (see Section II). We gathered this data by investigating the wireless sensing devices used in research that has been published within two premiere conferences: the ACM/IEEE International Conference on Information Processing in Sensor Networks (IPSN 2013 and IPSN 2014) [2] and the ACM Conference on Embedded Networked Sensor Systems (SenSys 2012 and SenSys 2013) [3]. Of the 91 papers investigated in these four conferences, we note that none of the authors used (or even mentioned) an Arduino based device in their research projects. Then, in Section III, we discuss (1) why we were unable to use off-the-shelf motes for SmartGeo deployments, (2) the details on two wireless sensing devices that we developed for monitoring geosystems, the first of which was developed similar to the motes that are commonly used in wireless sensor network research projects (see Section II) and the second of which was a “shield” prototype that works with an Arduino Fio, and (3) a performance analysis comparing the two developed devices. The discussion in Section III explains why we strongly recommend that other researchers consider Arduino based wireless devices in their projects. Lastly, before concluding in Section V, we present the benefits and challenges that we have experienced in our involvement with interdisciplinary research (see Section IV).

Fig. 2: The types of projects discussed within the papers presented in four premiere sensor network conferences.

used motes in their research, 25 (27.5%) used smartphones, 4 (4.4%) used both motes and smartphones, and 6 (6.6%) used neither.

II. T RENDS IN W IRELESS S ENSOR N ETWORK R ESEARCH We present the various system types, mote platforms, smartphone platforms, and sensors that have been used recently within wireless sensor network research, i.e., within recently published papers in premiere conferences. Specifically, we present a summary of the wireless sensing devices discussed in every paper published in IPSN 2014, IPSN 2013, SenSys 2013, and SenSys 2012. We acquired the data summarized herein by manually reading each paper and extracting relevant information. We note that there were 91 papers published in these four conferences. First, we investigated whether the authors of these published papers only conducted a simulation, only implemented a testbed, conducted both a simulation and implemented a testbed, conducted an actual deployment (i.e., a real deployment within some target environment), or whether the paper was purely theoretical. Figure 2 illustrates the results from this analysis. As shown, most of the papers presented in these four premiere conferences had a testbed and/or a real deployment. In total, 76 (83.5%) of the 91 papers published in these four conferences had some type of testbed and 15 (16.5%) of the papers had some type of real deployment. (We note that seven of the papers published had both a testbed and a real deployment.) We then categorized each of the 91 papers according to the type of device that was used in the research (i.e., mote or smartphone). Figure 3 displays the types of devices used in the projects of the published papers. Of the 91 papers, 56 (61.5%)

Fig. 3: The types of devices used in the projects presented in four premiere sensor network conferences.

We further investigated the different mote and smartphone platforms discussed in the papers of these four conferences, and we present these results in Figures 4 and 5, respectively. Of the 64 different mote types (within the 60 mote-based papers, see Figure 4), 19 (29.7%) used a custom designed mote, 18 (28.1%) used the commercially available TelosB platform, 12 (18.8%) used one of several commercially available platforms (i.e., MicaZ, Opal, Pandaboard, or Imote2), and 9 (14.1%) used a platform that we combined into “Other”; devices classified in “Other” are either not general purpose devices or seem to be less popular in the literature (e.g., IRIS, Tinynode and, BeagleBone Black). We note that 6 (9.4%) of the papers did not specify the mote platform used, which we found incredible [4]; that is, when the mote platform is not specified within a published paper, the repeatability of the research is directly compromised. A few of

these six papers stated that they use a “generic” platform that runs either TinyOS or Contiki OS; however, both TinyOS [5] and Contiki OS [6] are capable of running on a wide variety of mote platforms, such as the TelosB and MicaZ. We also note that none of the research studies utilized the Arduino platform; we also found this result surprising, as there are many benefits to Arduino-based research (see Section III).

Fig. 4: The types of mote used in the projects presented in four premiere sensor network conferences.

Figure 5 shows the different smartphone/tablet platforms used in the smartphone-based research of these four conferences. Of the 33 smartphone-based applications (within the 29 smartphone-based papers, see Figure 5), 23 (69.7%) used Android-based devices, 7 (21.2%) used iOS-based devices, and 1 (3.0%) used a Windows Mobile based device. Similar to the incredible result for motes, 2 (6.0%) of the papers published did not specify the smartphone used in their research projects. We strongly encourage researchers to always specify the device(s) used in their research studies.

conferences. We found 28 different types of sensors, varying from popular sensors (e.g., accelerometers and GPS) to semi-obscure sensors (e.g., cadence and airflow). We further classified these 28 types of sensors into the following categories (listed in descending order by usage): Inertial: Accelerometer, Gyroscope, Magnetometer Mechanical Energy: Acoustic / Seismic, Microphone, Piezo, Airflow, Flow Meter Tracking/Localization: GPS, Wifi Localization, ADS-B Optical/Imaging: Camera, Optical Flow, Solar Irradiance, Ambient Light, Microsoft Kinect Power Monitoring: Power Monitoring / Harvesting Environmental: Temperature, Barometric Pressure, Wind, Smoke Radio Signal: Received Signal Strength / Attenuation Biological: Cardiological, Cadence, Alcohol Detection: Passive Infrared, Ultrasonic Rangefinder, Hall Effect We note that we grouped sensors according to their sensing metric instead of their sensing technology (e.g. MEMS or mechanical). Figure 6 shows the relative usage of our defined sensor categories. We note that many of the described systems in the papers make use of more than one sensor. We also note that we include RSS (Received Signal Strength) and signal attenuation, though they are not dedicated sensors in the conventional sense. As shown in Figure 6, inertial is the largest category of sensors used; within that category, accelerometers were the most frequently used sensor, followed by GPS (in the Tracking/Localization category) and power monitors / harvesters (in the Power Monitoring category). We note that only 1 (1.1%) of the 91 papers used a seismic sensor and none of the papers used any other sensor (e.g., resistivity, self potential, and induced polarization) that is commonly used in a SmartGeo application.

Fig. 6: The types of sensors used in the projects presented in four premiere sensor network conferences. Fig. 5: The types of smartphones used in the projects presented in four premiere sensor network conferences.

III. G EOPHYSICAL M OTE

We also collected data on the different sensors that were used in the research studies of these four premiere

The geophysical sensing techniques (e.g., resistivity, seismic, self potential, and induced polarization) used in SmartGeo

applications (1) require kilohertz scale signal sampling at submicrosecond precision and (2) produce kilobytes of data per mote over a few seconds. In other words, the electrical signal produced by the physical phenomena sensed by the geophysical sensors is very low voltage, covers a large dynamic range, and takes place in a noisy uncontrolled natural environment. Thus, high resolution (24-bit1 ) analog to digital converters (ADCs) with configurable variable gain are necessary to reliably discern the target signals. Additionally, because the signal is amplified prior to conversion, the conversion circuits must be low noise. Commercially available mote platforms have on-chip ADCs that are limited to 10 or 12-bit resolution, have no configurable variable gain, experience significant switching noise from the digital microprocessor clock signal, and do not include denoising filters. In short, our geophysical sensing requirements in SmartGeo could not be met by currently available offthe-shelf (OTS) motes (e.g., TelosB, Mica); thus, we also ventured down the path to create our own custom geophysical mote. In this section, we describe (1) our first generation mote, which we developed to be similar to a TelosB mote (a popular wireless sensing device, as shown in Figure 4), (2) our second generation mote, which we developed due to challenges we encountered with our first generation device, and (3) a performance analysis comparing our two developed motes.

Fig. 7: The initial gsMote prototype in a waterproof enclosure.

A. gsMote The development of the gsMote platform included two phases: 1) initial prototype (see Figure 7) and 2) final printed circuit board (see Figure 8) [7]. We prototyped our first generation mote with design assistance and components donated by Earth Science Systems, LLC [8]. The mote design requirements were to provide automated and unattended selfpotential sensing and both active and passive seismic sensing in a ruggedized field deployable wireless package. Figure 7 illustrates our initial gsMote prototype and handmade PVC enclosure. In the second phase, we incorporated lessons learned from the prototype phase and developed a printed circuit board (PCB). See [7] for details on the lessons learned, and Figure 8 for an illustration. In short, our gsMote custom hardware includes the following features: • Sensing: three-axis accelerometer for seismic measurements, waterproof connections for externally connected self potential electrodes, temperature sensors for calibration purposes, and external 4 – 20 mA sensor connectors for various sensors (e.g., piezometer, inclinometer, etc.). 1 24-bits of precision provides suitable signal sensitivity for a potentially large range of acoustic sensor values, from subtle changes on the microvolt level to large signals on the volt-level scale.

Processing: dynamically configurable direct and alternating current filters, low noise variable gain amplifiers (1 – 128 times), off-chip 24-bit ADC, and an Atmel AVR XMEGA256A microprocessor that provides 32 million instructions per second of processing power for data analysis. • Storing: 64 KB of SRAM and 32 GB of long-term (SD) storage to handle the large amount of data generated from kilohertz scale sampling over several seconds. • Communicating: 900 mHz variable power radios with 2 km range in high power mode to enable remote deployments and offer communication that can reach gateways for remote data access and system monitoring. Our first generation wireless geophysical device addressed the requirements of geophysical sensing techniques, including high accuracy and high speed ADCs, ample and high-speed ferroelectric RAM, configurable filters, and signal amplifiers. Our gsMote platform enables continuous and unattended geophysical monitoring, and supports several wireless geophysical monitoring applications. Contact Earth Science Systems, LLC [8] if interested in further details on this wireless geophysical device. •

Fig. 8: The printed circuit board (PCB) of the gsMote platform. The PCB gsMote is 1.5”x8”.

B. GeoMoteShield Our first generation mote took a long time to develop and had many delays. Building a custom wireless mote “from the ground up” takes many, many hours of labor for circuit design, firmware development, testing, debugging, and validation. Also, similar to OTS motes, such as TelosB, Tmote Sky, and MicaZ, our gsMote was not well documented nor easy to use “out of the box”. To address the difficulties we were encountering, we developed a second generation geophysical mote that is Arduino based; we chose the Arduino platform due to how simple it is to use and the amount of support and documentation available online. In this section, we describe the specifications for the custom hardware we developed that works with the Arduino and provide details of our implementation using OTS products (put together on a custom PCB). 1) Specifications: In addition to providing precise analog to digital conversion, we wanted our second generation geophysical custom hardware to be inexpensive and easy to use. In this section we list and explain the hardware specifications for our second generation custom electronics. • High Precision, Low-Noise ADC: As discussed previously, our custom hardware must provide 24-bit of signal

input precision. Additionally, the ADC must have a high precision reference voltage that does not fluctuate. • Additional RAM: for SmartGeo applications, we require more RAM than is provided OTS (e.g., to implement buffering for wireless packet collision avoidance or to perform on-mote data processing on larger chunks of signal); we, therefore, included 32 KB of RAM on this second generation geophysical mote. • Persistent Removable Storage: Current OTS platforms do not have an interface for persistent removable storage such as an SD card; however, as previously discussed, SmartGeo applications require additional storage to handle the large amount of data generated from kilohertz scale sampling over several seconds. Adding an optional SD card socket provides the user with, for example, 32 GB of additional persistent storage. • Long-Range Radios: As discussed previously, for a realworld, outdoor deployment, sensor nodes must be capable of communicating wirelessly over hundreds of meters (or more). • Global Positioning System (GPS): Having an optional GPS unit was not a consideration in the development of the gsMote; that is, numerous WSN localization and time synchronization publications over the years have stated that the use of GPS is excessive because GPS receivers are expensive and consume too much power (e.g., [9], [10], [11], [12]). As optional GPS unit will, however, allow users to obtain localization information as well as precise global time synchronization, which are two of our other challenges in SmartGeo applications (see Section I). Furthermore, as the cost of GPS microchips continues to decrease, using GPS to localize and synchronize wireless motes continues to increase in viability and makes solving such problems as localization and synchronization much simpler. The listed specifications can be addressed using an Arduino Fio mote, OTS components, and mostly open-source software libraries. In the next section we provide details of our implementation that follows Arduino’s “shield” concept. 2) Implementation: To meet these requirements, we developed two different “shield” prototypes that can be plugged into an OTS Arduino Fio wireless mote platform. The first version of this shield, i.e., GeoMoteShield “Slim” (e.g., Figure 9), has a 24-bit ADC and 32 KB of external SRAM. The second version, known as GeoMoteShield “Standard”, includes a GPS unit and microSD card socket (in addition to the ADC and SRAM). There are several advantages to creating a shield to interface with the existing Arduino Fio wireless platform. First, all Arduino-based platforms (including the Fio) are based on a high-level, C++ based API that abstracts much of the low-level procedural programming of embedded systems into classes and objects. This high level abstraction provides an easy to use and intuitive interface to control all the components. Second, the Arduino Fio is 100% open source, both in terms of software and hardware. Thus, in the unlikely event that

Fig. 9: The prototype GeoMoteShield “slim” includes a 24-bit ADC and 32 KB of external SRAM. The GeoMoteShield interfaces with an OTS Arduino Fio wireless mote.

the Arduino Fio is no longer commercially available, then we can build the wireless mote platform (with the exact same specifications) from scratch. Third, the Arduino Fio has an XBee radio socket, allowing users to “plug and play” different types of radios depending on the application, from 100m range low-power radios to 10 km high power radios. Lastly, the Arduino platform has a massive online support community that produces valuable software libraries. In our implementation we used existing software libraries for the XBee radio, GPS unit, SRAM, and SD card socket. Using existing libraries was unlike developing the “from the ground up” gsMote, which required developing custom firmware to control not only the ADC and SRAM, but also “standard” components such as the microcontroller and radio. C. Field Test Results In this section, we summarize a few field test results comparing a traditional wired acquisition system to our two custom wireless hardware platforms, i.e., the gsMote and GeoMoteShield. In particular, we recorded seismic data during a geophysical “walk-away” field test using three different systems and then compare the wired versus wireless systems in terms of signal quality. 1) Experimental Setup: Field testing was led by a geophysics expert and Ph.D. student at Colorado School of Mines. The experimental design, known as a “walk away” test in geophysics, consists of placing many geophone sensors adjacent to one another in a cluster with minimal spacing. As data is being acquired, the experimenter uses a sledgehammer to pound a metal plate on the ground at various distances from the cluster. The purpose of the “walk away” test is to evaluate and calibrate an acquisition system for data consistency and time synchronization accuracy; the sledgehammer impact waveform should be nearly identical in all sensors used. For our experiments, we used three different systems, a Geometrics Geode wired system, a wireless sensor network (WSN) of our custom gsMotes, and a WSN of Arduino Fios with our custom GeoMoteShields. For each system, we acquired data simultaneously from nine geophone sensors placed in a tight cluster as described previously for the “walkaway” test (e.g., Figure 10). Each geophone was sampled at 1000 Hz sampling rate with 24-bit precision. The sledge hammer impacts were tested at 10, 20, and 40 feet from the geophone cluster.

point, or at 50 ms. Next, we normalized each individual seismic signal to have zero mean and unit variance. We then time aligned the wireless signals to the wired data by calculating the cross-correlation time lags between the respective events and applying the appropriate delay to the wireless signal. Figure 11 depicts the time-aligned and normalized seismic events between nodes and systems. Wired

GeoMoteShield

gsMote

0 25 50 75 100 Time (ms)

0 25 50 75 100 Time (ms)

0 25 50 75 100 Time (ms)

Node9 Node8 Node7 Node6 Node5

Fig. 10: We performed seismic “walk-away” field tests to compare three sensor systems: a WSN of “from the ground up” wireless gsMotes, a WSN of Arduino-based GeoMoteShields, and a Geometrics Geode wired seismograph.

Node4 Node3 Node2 Node1

In the WSNs, each geophone sensor was interfaced with a single wireless mote; thus, each WSN consisted of nine sensing nodes and a base station to receive and store the data. We implemented a “snap-shot” data collection paradigm for both WSNs. In this paradigm, the wireless motes sat idle (with radios on) until the base station broadcasted a “start” command. Once the start command was issued, the wireless motes began sampling the geophones at 1000 Hz simultaneously until a “stop” command was received or SRAM became full. After data was acquired by the wireless nodes, the base station polled each mote for its seismic data in a round-robin fashion and the motes returned to the initial idle state. We note that the radios of gsMote and geoMoteShield WSNs operated at different frequency bands, i.e., 900 MHz and 2.4 GHz, respectively. 2) Results: In this section we present results from our wired versus wireless comparison tests. Specifically, we compare the accuracy of the seismic data acquired using the two WSNs to the data collected by the wired system. The results presented are from tests four and six of seven (i.e., sledgehammer impacts 20 feet from the target). We note that runs four and six were selected because they were the only tests with full and synchronized data from all three systems. That is, several of the gsMote WSN test runs had missing or unsynchronized data, and one of the wired test runs did not save data. During field test data acquisition, the three systems were not perfectly time aligned; in other words, “time zero” of the three systems was not exactly the same. We, therefore, focus on the three seismic “events” (or sledge hammer impacts) recorded during each test. We time aligned the seismic events using a cross-correlation lag approach that is common in signal processing. Specifically, we analyzed the signal envelope of each node’s data and picked the three most energetic points (which correspond to the hammer impacts). After finding the three events using the signal envelope, we extracted 100 ms of seismic data with the peak event occurring at the halfway

Fig. 11: One of the three normalized and time-aligned seismic events recorded by all three systems during the “walk-away” field test. The “Wired” system is a Geometrics Geode seismograph, the “GeoMoteShield” is a custom, Arduino-based shield, and the “gsMote” is a custom standalone, “from the ground up”, mote that we developed.

After extracting, normalizing, and time-aligning the events, we calculated the normalized root mean square error (NRMSE) between the wireless and wired seismic events. NRMSE is calculated as: p mean((xij − yij )2 ) N RM SE = , max(xij ) − min(xij ) where xij is the wired signal and yij is the wireless signal from node i and event j. In essence, NRMSE quantifies the differences between the wireless and wired target signals. Figure 12 summarizes the NRMSE results from the wired versus wireless signal comparisons; box plots are used to plot the median, quartiles, 2.7σ, and outliers from the wired versus wireless NRMSE results. The results presented in Figure 12 show that our lowcost, Arduino-based system performs comparably to an expensive, traditional wired system and slightly better than a fully custom (i.e., “from the ground up”) wireless platform. Roughly, the wired Geometrics Geode seismograph costs tens of thousands of dollars (excluding geophones), each gsMote costs about $750, and our Arduino Fio plus custom GeoMoteShield “Slim” costs about $150. The take home message is that Arduino should not be overlooked as a research grade WSN tool; Arduinos are flexible, inexpensive, adaptable, and extremely easy to use. We further discuss the pros and cons of using Arduinos in applied WSN research in Section V. IV. I NTERDISCIPLINARY R ESEARCH There are many benefits, and challenges, to interdisciplinary research. We briefly summarize the pros and cons that we have experienced within our SmartGeo program.

0.18 0.16 0.14

NRMSE

0.12 0.1 0.08 0.06 0.04 0.02 GeoMoteShield

gsMote

Fig. 12: A statistically summary of the normalized root mean square error (NRMSE) calculated between the wireless and wired seismic event signals. The box plot depicts the median, 25th and 75th quartiles, 2.7σ, and outliers of the error between wired and wireless signals.

The main benefit to interdisciplinary research is the opportunity to work on tough, relevant, real-world research problems. In addition, significant funding is available for interdisciplinary research. For example, the primary objective of the National Science and Technology Council (NSTC) is to set national goals for Federal science and technology investments [13]. Also, interdisciplinary research is required to solve all of the fundamental challenges in our society that are discussed in a recent publication by NSTC [14]. True interdisciplinary research is, however, extremely hard. Three of the key challenges that we have experienced within the SmartGeo program follow. First, understanding another field within your core discipline takes time, but learning the technical problems that exist in another discipline takes even longer. While we do not do research in geophysics, we need to understand their problems enough to find solutions together that will be impactful in both our disciplines. Second, communication between different disciplines is often problematic. Different disciplines have different languages (e.g., Kalman Filters in engineering are basically dynamic Bayesian networks in statistics [15]). In SmartGeo, we learned that localization for a geophysicist concerns the location of the subsurface phenomenon (not the location of the mote in a WSN). Lastly, publishing an interdisciplinary paper can be challenging. Discipline conferences and journals need to be narrowly defined in order to be well-known, which often leaves little room for interdisciplinary papers. V. C ONCLUSIONS In conclusion, we encourage others to look into joining (or leading) an interdisciplinary project; while there are several

challenges with interdisciplinary research, the pros far outweigh the cons. Also, even though few WSN projects are using Arduinos (see Section II), we strongly encourage researchers to consider Arduinos for their WSN research projects. As discussed, Arduinos are flexible, inexpensive, adaptable, and extremely easy to use. For example, the development of our Arduino-based device for geophysical monitoring was far easier (and cheaper) than the development of our “from the ground up” gsMote. In addition, we have successfully used Arduinos in our WSN research concerning compressive sampling [16]. We note, however, that Arduinos are more power hungry when compared to TelosB, and the device does not give researchers control for developing low-level (e.g., MAC) protocols. However, for interdisciplinary research, where you just want to “get it done” quickly and cheaply, Arduinos rule. ACKNOWLEDGMENTS This work is supported in part by NSF Grants DGE0801692 and OISE-1243539. We thank Vladimir Yaromenka for developing the gsMote firmware and helping collect field test data. We also thank Justin Rittgers for aiding with wired geophysical data collection. R EFERENCES [1] American Society of Civil Engineers, “Dams: Report Card for America’s Infrastructure.” http://www.infrastructurereportcard.org/dams/ Accessed June 14, 2014. [2] ACM, “SenSys.” URL: http://sensys.acm.org. Page accessed on June 10, 2014. [3] ACM and IEEE, “IPSN.” URL: http://ipsn.acm.org. Page accessed on June 10, 2014. [4] S. Kurkowski, T. Camp, and M. Colagrosso, “MANET simulation scenarios: The incredibles,” ACM MC2R, pp. 50–61, 2005. [5] TinyOS, “Section 2.2: What hardware does TinyOS support?.” URL: http://http://tinyos.stanford.edu/tinyos-wiki/index.php/FAQ. Page accessed on June 10, 2014. [6] Contiki, “Contiki Hardware.” URL: http://www.contikios.org/hardware.html. Page accessed on June 10, 2014. [7] K. Stone, C. Oden, B. Hoenes, and T. Camp, “Hardware for a wireless geophysical monitoring testbed,” in Proceedings of IEEE MASS, pp. 652–659, 2011. [8] Earth Science Systems, “ESS.” http://www.earthsciencesystems.com/. Accessed June 1, 2014. [9] M. Maroti, B. Kusy, G. Simon, and A. Ledeczi, “The flooding time synchronization protocol,” in Proceedings of SenSys, pp. 39–49, 2004. [10] S. Ganeriwal, R. Kumar, and M. Srivastava, “Timing-sync Protocol for Sensor Networks,” in Proceedings of SenSys, 2003. [11] P. Sommer and R. Wattenhofer, “Gradient Clock Synchronization in Wireless Sensor Networks,” in Proceedings of IPSN, 2009. [12] K.-Y. Shin, K. Y. Lee, and K. Lee, “Crit: A hierarchical chained-ripple time synchronization in wireless sensor networks,” in Proceedings of ICNSC, 2006. [13] Office of Science and Technology Policy, “NSTC.” URL: http://www.whitehouse.gov/administration/eop/ostp/nstc/. Page accessed on June 10, 2014. [14] National Science and Technology Council (NSTC), “Social, behavior, and economic research in the federal context.” URL: http://www.nsf.gov/sbe/prospectus v10 3 17 09.pdf. Page accessed on June 10, 2014. [15] R. Meinhold and N. Singpurwalla, “Understanding the Kalman filter,” The American Statistician, vol. 37, no. 2, pp. 123–127, 1983. [16] M. Rubin and T. Camp, “On-mote compressive sampling to reduce power consumption for wireless sensors,” in Proceedings of SECON, 2013.