Unsound data

A water depth data logger has been running unattended at a vernal pool (MLS619) at Snake Mountain in Bridport since April 10. The water was a meter deep when I waded out then to change the batteries and swap the microSD card. I have not been in a hurry to do the swap again assuming that the longer I wait the less wet I will get doing it. But I didn’t know how long the batteries would power the logger. The previous record was 11+ weeks, although a similar logger has been running in my office for more than a year on the same batteries. That one only saves data when certain conditions are met but it has been waking up every 30 minutes and sensing its environment for almost 13 months. I decided 16 weeks would make a good record for field deployment at MLS619 and was pleased to find that data had been written to the microSD card once every 30 minutes during those 3.7 months.

I am disappointed in the quality of the water depth data. The device measures the distance down to the water surface by sending an ultrasonic noise down to the water and measuring the time it takes to reflect back. The ultrasonic rangefinder has recently been returning bogus data about as often as it was returning good data. It’s possible that much of the bad data is due to the rangefinder sensing the edges of the plastic jug the logger is under. There might be a good explanation for this (maybe spiders are building webs in there) so I might have to modify the design. There are also other bad data points for which I have no explanation. But most of these bad data are easy to distinguish from meaningful data so I have removed the suspect data points from the graphs below.

The record of water depth in April and May seems to be well documented by the logger (Figure 1). Water depth responded to two rainfall events in April. It appears that a third, smaller rainfall event in early May was not recorded at the Middlebury weather station 4.2 miles east of the pool. The rest of May was almost without rain and water level dropped steadily for more than two weeks. So the first half of the data set seems reasonable.

In June the water depth data became less reliable. Through July an increasing proportion of the distance measurements became “0.82” cm which suggests either that the sensor was failing or a bug was living right in front of it. I don’t have good local rainfall data for July because it was not available yet, so I substituted a distant weather station near Rutland which is not a great record of thunderstorms impacting the pool. However, I know there was regular rain in the area in June and July and there is no evidence of it in the water depth measurements, so I have little confidence in any of the water depth data after May.

I plan to bring that data logger in for service. I might just install it in my home pond where I can pay more attention to it and maybe figure out why it has been returning bad data. I could also send the data over the home Wifi and eliminate the wading.

I can retreive the logger this week when I return to MLS619 to retrieve the AudioMoth which we deployed to listen for bats. The AudioMoth was deployed this spring to document when frogs started calling at the pool. The standard microphone on the AudioMoth works in the ultrasonic range of bat calls and seems to record nearby bats in my backyard. It occurred to me that bat calls could be the source of the bad data returned by the ultrasonic rangefinder. It didn’t take long to dismiss that hypothesis and accept that the real reason will be far less interesting.