… we interrupt this hydro-metric-flow-thingy blog to bring you an important announcement …
Back in 2004, my wife did a post-doc at McMaster university with Dr. Derek Ford & Dr. Henry Schwartz, that focused on drip hydrology in caves. She set up a monitoring network of sensors to determine drip rates & water chemistry and we were very fortunate at that time to have the help of Kenrick Chin, who built custom data loggers for the project. While I was not capable of addressing the electronics back then, I did manage to create some DIY tipping-bucket sensors, which Trish combined with thermistors & conductivity sensors into a portable assembly. The resulting contraptions yielded an impressive data set, but we had minor problems with moisture/corrosion, and major problems with cave critters who absolutely love chewing on plastic cable insulation.
So with that as back story, I am very pleased to introduce a working beta of the new model “D” line of Cave Pearls, for research in “dry” cave environments. This unit is a drip sensor, prototyped with the ProMini based data logging platform discussed in my previous post, bringing the total parts cost in around $25 (+ 4 hours building time):
.
The unit sleeps until the vibration of a drip impact triggers a hardware interrupt that wakes the Arduino, which then updates a counter variable, pips the LED, and goes right back to sleep. When the RTC interrupt fires (which is adjustable) the counter data then gets written to the EEprom or SD card. I actually had multiple sensors on the Alpha unit (temp, pressure, etc) but the back-splash from the protruding sensor wells on top caused spurious drip count readings. So, like the under-water models, the dry cave sensors will have different builds to record the various aspects of the cave environment.
While re-examination of the 2004 cave sensors has been on the back burner for a while, this drip counter was a direct result of my search for better tilt sensors for the flow meters. Those investigations lead me to several projects building DIY seismometers, and it occurred to me that if accelerometers were that sensitive, it might be possible to detect drips falling onto the housings. In the course of evaluating the ADXL345 (and rejecting it from the flow sensors due to relatively low bit depth at 2g) the well commented code posted by wyojustin & Kevin Stevenard introduced me to tap sensing registers. The “Eureka” moment that followed spurred on a week of furious prototyping, and this new drip counter is the result. I still have a bit of refining to do as I optimize timing & sensitivity settings, but as you can see from the video, the basic idea works down to around 10 cm fall distance. If I set the sensitivity high enough to catch drips closer than that the acclerometers internal noise starts to generate false positives.
While not directly related to the flow meters, I have a feeling that this kind of positive feedback/serendipity is going to happen with increasing frequency from here on, so I would like to officially retract my statements in the last post, where I implied that the Pro Mini based data loggers were not going to affect the project that much. A week of soldering later, and I can say with confidence that having a $10 datalogger to prototype with is a huge step forward, even if the specific build never goes into the field.
… we now return to the regularly scheduled pend-aqueous-hydropod programming …
<— Click here to continue the story—>

Mods to use an ADXL345 on a 3.3volt bus. On newer builds I now only use boards that already have a 3.3v input (Geetech, CJMCU-105, etc.)
Addendum 2014-07-15
I almost forgot… for those of you wanting to build one of these drip sensors, the ADXL345 was one of the cheep boards from eBay . When all you want is tap sensing, things that the clone boards are notorious for like offsets, drift, etc. don’t matter that much. Most of these breakouts come with a voltage regulator already installed, but since I was driving the I2C lines from the pro mini, which already has a 3.3v regulator, I had to de-solder the vReg (& its isolation cap.) from the breakout board and then bridge the vcc line straight across. (see top) And since I2C lines are running through the RTC breakout , they already have 4.7kΩ pullups on them, so I also had to lift the little smd resistors from the accelerometer breakout board. You can see the empty solder pads, just below the chip in the photo.
Addendum 2015-01-10
Just stumbled across someone trying to use capacitance and IR to detect drips without interacting with the drip itself. I think the capacitance idea has legs, but I would worry about all the condensation you get on objects in a cave giving you grief with IR approaches.
The design seems flexible too. I was thinking about a particular application where for example I only wanted to know about counts of droplets above a certain size. (There would be refresh rate problem with this, but) I could imagine adding one simple see-saw to the design that required a droplet of a minimum mass to depress and consequently contact and vibrate the accelerometer.
I have been thinking about this: information on the relative “force” of the impact is already be available in the x,y& z registers of the accelerometer(with a bit of math), but I can’t think of a way to correct for the different fall heights. A large droplet falling a short distance, could conceivably have the same momentum as a smaller droplet falling from a greater height (up to terminal velocity). I also don’t quite have the build consistency to the point where I am confident that I could distinguish the distance of the hit from the sensor’s sweet spot (center) from differences in the impact momentum.
I think you could still measure the total water volume pretty accurately with a simple drip counter, if you first ran the water through a funnel that standardized the diameter of the drip tube [as per http://en.wikipedia.org/wiki/Drop_(liquid) ] I suspect we will be using this technique on our field trials, as we also hope to measure other information, such as conductivity, and a funnel makes that much easier to do. We also have to deal with the fact that although drips from traditional stalactites stay in one location, drips from cracks, etc. tend to wander around quite a bit.