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.

There was a lot more water in vernal pool MLS619 on July 30 than I expected. The level was only 11 cm lower than it was on April 10 when I last serviced the logger. I was even more surprised to learn that the water temperature was only 2.5 °C warmer than it was in April. Photo by Ned.

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 water level in MLS619 is high enough to flood the marsh fern and stinging nettle around the edges.

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.

Figure 1. Air and water temperature and water depth for vernal pool MLS619. Data are from a data logger on a stake at the deepest part of the pool. Rainfall data (April, May, June) are from a station in Middlebury (4.2 miles east of the pool) or (July) from Rutland (36 miles southeast of the pool).

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 think these two plants at the south end of the pool are marsh fern (Thelypteris palustris) and stinging nettle (Urtica dioica). The fern fronds are mostly under water. That is probably not the preferred situation for marsh ferns, so maybe the water level is not always this high in July.

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.

Ned deploying the AudioMoth to listen for bat calls at the edge of MLS619.
Figure 2. Water depth data from the ultrasonic rangefinder for the entire winter/spring/summer period. Question marks highlight the unreliable data when snow covered the ice on the pool and when the sensor returned suspect data in June and July.

Leave a Reply

Your email address will not be published.