Category Archives: Developing a DRIP ⚶ sensor

An event logger counting drips from stalactite formations in dry caves.

For a case study showing the data we collect from these sensors, see: A Flexible Arduino-Based Logging Platform at

(Sensors is an open access journal, so the PDF is free to download)

Project Update: the Next Generation of Drip Sensors

It’s been a while since I made a post, as the basement workshop is in now in full swing assembling units for the next round of fieldwork. But I recently found out (thanks to Fernanda at Rio Secreto) that one of the drip sensors we installed in August croaked early, with a suspicious order of magnitude increase in the number of drips it recorded just before the battery took a nose dive:


Local climate stations don’t show that kind of increase in rainfall, and the batteries did not leak,  so my first thought is that the ADXL345 went through some kind of failure, self-triggering as it brought the whole unit down. But before that event, the battery voltage was good (I used lithium AA’s, which is why they started so high), so even with fake SD cards pulling alot of sleep current I think the other units will survive until we can retrieve them. To be honest, those first drip sensors were a dogs breakfast of different components, and most were cobbled together the week before the trip, so I am surprised that we only have one dead soldier so far. The fact that the data on the SD card survived a complete loss of power is also very good news.  I am actually looking forward to examining that unit, as it is the first hardware failure we have had in the field(I wish I could say the same thing for my code…)

Cave Pearl Drip Sensor Data Logger

With the usual quid pro quos of a highly variable duty cycle, this kind of sleep current might get me in to multi-year territory on 3 AA cells.

For the new set of builds, I have made a few changes to reduce the power consumption of the logging platform.   With a design goal of one year, continuous operation, I have decided to leave out the Pololu  switch, as it wastes too much power when you only have 3 AA’s. The Muve music SD cards from eBay have all been great low current sleepers, bringing my typical build with a Pro Mini clone board into the 0.25mA range. Powering the Vcc line on the RTC from a pin on the Arduino saves another 0.089 mA, and taking advantage of the MCP1700 on the Rocket Ultra brings my best builds down to 0.13mA  with a sleeping SD card (~ 60 µA) and an ADXL345 running (~ 50 µA) to provide interrupts.  Of course, there is always the chance that the RTC will not survive repeated switching on it’s power supply, so I will only test this technique on a couple of units in the next deployment.  If they survive without running the CR2032 coin cells dry, I will adopt this modification for the whole Cave Pearl line. It doesn’t sound like much, but that little RTC breakout will eat 600 mAh (1/4 of a AA) if you power it from Vcc for a year.

When you disconnect Vcc, the DS3231 goes into a 3uA timekeeping mode.

Here I have lifted the Vcc line from the RTC breakout board.  When this line is pulled low by the Arduino, the DS3231 goes into a 3uA timekeeping mode, saving 89uA

As a point of comparison, I tested an “unregulated” TinyDuino stack with the same code, SDcard, RTC, ADXL and battery pack, and it only went down to 0.55 mA while sleeping. Lifting the tiny light sensor board I2C lines, and having the SD card in place, means that the Tinyduino stack actually had two live voltage regulators, while my Rocket based loggers only have one. (Also, I don’t think they are pulling up the unused data lines on their SD shield, so floating pins might be increasing the SD sleep current a bit.)  And while having a regulator on every shield affects my particular application, I can see lots of good reasons for that aspect of their design. I still love the overall form factor of the TinyDuino’s, and the significant amounts time I spend soldering these loggers together has me patiently waiting for TinyCircuits to produce a generic voltage regulated, level shifted, I2C communications shield, so I could spend more of my time fixing code bugs instead of soldering (hint..hint!) It takes me about four hours to build one of these drip loggers from scratch.

I simply let the wires I am already using to tap the cascade port I2C lines poke up enough to give me solder points for the EEprom. Don't forget to remove the pullups on the EEprom board.

I simply let the wires I am already using to tap the I2C cascade port poke through as solder points for the EEprom.

The final upgrade in this iteration the addition of a 32K AT24C256 eeprom. With the testing I did back at the beginning of the project, I know there is a chance that this much I2C bus traffic (buffering up to 512 records if I fill the whole thing)  might not save much power, but it lets me standardize the data handling to one SD writing event per day no matter how many sensors are attached, or how short the sample interval is.  I will have a couple of the drip sensors buffering five days worth of data on the next deployment, to see if using this eeprom to condense five smaller SD card events into one big one  (which takes about 2 seconds to complete)  reduces the long term power consumption of the loggers. And finally, if the unit has a catastrophic power failure that completely toasts the SD card, there is a good chance that I will be able to retrieve the records buried in the eeprom for forensic analysis.

Having a second eeprom in the system also lets me “reserve” the little 4K AT24C32 on the RTC breakout for calibration data. While this is not that important for the drip sensors, it will come in quite handy as my flow sensors mature, and I start to tackle things like hard & soft iron correction on the magnetometer.  The drip loggers are so quick to make & deploy, they have become my low-risk test platform for new ideas.

Drip sensor test rig

Life was easier when I only had one calibration stand. Testing multiple units at the same time turns you into the proverbial man with two watches…

And speaking of test platforms, I now have two testing riggs set up for the drip loggers as they come off the bench, and they have taught me a very valuable lesson: Whenever you invent a new device, you also have to develop a new calibration protocol; which can turn out to be more challenging than building the actual device. Initially, I thought that all I would need for the job was a graduated cylinder and a funnel with some kind of flow limiter.  But my initial test results were all over the place, with the counts varying by 30% or more from one run to the next. At first I blamed the accelerometer thinking “It must be registering multiple counts, or it is just not firing the interrupt when it should”. I tried different sensitivity settings, varied timing delays, everything I could think of. But nothing seemed to improve the consistency between runs, and after many tests with crummy numbers, I was beginning to think I must be missing something fundamental.  I was so frustrated by this I decided to just sit there, staring at the little LED and counting the drops myself for as long as it took to figure this out… And I am really glad I did, because an hour into this caffeine powered exercise in utter boredom I had sore eyes, but I knew beyond shadow of a doubt that those sensors were working fine. Every drop was being counted. Every last one. So what was throwing the numbers?

Surface splatter from a drip impact. The green light is the LED indicating the count.

I made several attempts to capture photos the surface splash after a drip hits, as I thought this was throwing the counts off. Here you see the green LED light being triggered with five or six splash-drips flying away from the point of impact.

Google didn’t bail me out on this one, and all Wikipedia gave me was an article on how drip volume depended on the relationship between surface tension and tip radii.  But both funnels had the same 8mm pex tubing, hand polished smooth, as the drip source point, and they were still giving dramatically different results. It was time to call in the big guns, so I asked Trish to let me root around the Web of Science the next time I was at her office. That lead me to this paper:

Controls on water drop volume at speleothem drip sites:  An experimental study
by Christopher Collister and David Mattey, published in the Journal of Hydrology.

I used heat-shrink to get nice sharp 5mm diameter tube tip.

I  also used heat-shrink to make a much smaller  5mm  drip tube, further reducing the drip size.

In that paper there is a graph (pg 264) that illustrates: “At fast drip rates with drip intervals less than about 10s, drop volumes are seen to increase with a greater degree of scatter in the mass of individual drops.”  Their plot had almost 50% drip volume variability when the drip interval fell to 1 second. I had been testing my units at 3-6 drips per second or more, because I was worried about clipping the high end with all the delays I put in the code to prevent double counts from splash back. I also thought that with more runs, and larger the volumes of water (which increased pressure above the drip), I would be reducing the errors.  I went back with a magnifying glass, and sure enough, I could see the water surface tension shaking like a struck drum after each drip detached, and this wobbling increased dramatically with the rate of flow. Fortunately the paper also provided a solution to my problem:  “The results confirm that drop volumes are essentially constant at drip intervals greater 10 seconds.”  So I completely changed tactics, going for lower volumes and slower drip rates. On the very next try, I was getting data like this:

Unit 10: 500 mL
Drip Count: Time to complete: Drips/Min (max)
6289 135 min 62 dpm
6281 138 min 64 dpm
6314 141 min 63 dpm
Unit 10: 1000 mL
13097 246 min 70 dpm

At about one drip per second, I am still running these a bit fast. It will be a while before I get “ideal” interval tests done as they will take at least ten times longer to perform.  You can see how the larger 1000 mL volume pushed the flow rate up a bit, increasing the 500ml equivalent count up to 6548.  But even at 1 second intervals, I am pretty sure my handling of the graduated cylinder is on par with drip variation as a source of error. And the two different test rigs are within a couple of percent of each other now as well.


Addendum 2014-12-02

Since the GSA, I have had people asking when I would have the drip counters for sale, and this post will likely trigger a few more enquiries. Right now every unit I can put together is earmarked for my wife’s research, or projects with other researchers who are helping me improve the overall design. So before that trickle becomes a flood, I should point out that plain old tipping bucket sensors are dirt cheap, and they are pretty easy to hook up to any arduino logger you can find (some people even hook them directly to bicycle speed loggers or calculators. And if you want it wireless, you can use a doorbell). There are some very interesting alternatives in the weather station station market (like the Hydreon RG-11, though at 15-50mA it’s a non starter for battery powered loggers) There are also plenty of lab-based drip counters out there that use approaches such as IR beam deflection or even photo interrupters / optoisolators.  A fair number of people are working on acoustic rain sensors. And finally there is already a drip counter on the market specifically for cave research: The Driptych Stalagmate. The Driptych uses a piezo sensor to detect the impact of the drips. While I have never seen one in person, I can guess that if they are able to use the voltage spike from the piezo to trigger the interrupt line directly, their loggers might be able to operate with an extremely low sustained power draw. In comparison, my accelerometer based approach will probably always pull at least 0.06 mA to keep the sensor ticking over, so I have a ways to go before I reach the four years of operating life they offer, not to mention all the other little bugs I still have to sort out. I am just having a heck of allot of fun doing it.

Addendum 2015-05-29

I recently tried replacing the accelerometers with some very sensitive 18020P shake switches. This removed the constant power drain of the accelerometer, but they also made it fiendishly difficult to adjust the sensitivity. Those simple vibration detectors are not standardized very well, so you have to rotate the switch in 3d space to find the best response angle for each individual one. (unlike the accelerometers, where its just a simple register setting) Tilt it a little too far and the switch will just self trigger, not far enough and you have to hit the thing very hard (relative to drip energy) to trigger the interrupt.  And when you have it in the right physical orientation for “light” drip impacts to register, the spring continues vibrating for quite a long time after receiving a “hard” drip impact.  Those “echo” triggers stretch well past 150-200ms, causing the problem that when the water is really flowing, and the drop volumes increase causing harder hits, the settling time gets longer and longer, so the sensor itself imposes a fairly low maximum detectable drip rate after which the spring mechanism is just triggering all the time.

<— Click here to continue reading the story—>

Field Report 2014-08-26: The First Drip Sensor Deployments

Selecting test locations. (Photo courtesy of Monica Wnuk)

We were spoiled for choice of locations in a beautifully decorated system like this.  (Photo courtesy: Monika Wnuk)

Yesterdays success with the flow meters meant we could now turn our attention to deploying the new drip sensors. Trish had ongoing work in the Rio Secreto Nature Reserve section of Pol Tunich cave, included an interesting student project monitoring calcite raft deposition. A maintenance visit to those experiments was already on the schedule, so it was an obvious choice to use that site for our first drip sensor deployment as well. Even better, Rio Secreto had several capable science liaison staff, some of whom were conducting experiments of their own nearby.

Units are tethered so flood conditions don't wash them away.

When you do something for the first time in the field, you tend to improvise allot, especially when you are trying to apply the Goldilocks principle to something as random as cave drips. But Trish seemed to know exactly what she was after, and with the help of our guide from Rio Secreto, we quickly started locating ‘gotas’ that were ‘just right’.  We knew from Kayleen’s video that the water level in the cave could be highly variable so we tethered the units located close to the water level to assure that flood conditions would not wash them away.



They are intentionally placed at an angle, so that water does not pool on the sensor surface and cause spurious readings.

We also wanted to set the sensors in areas with multiple drips in relatively close proximity.  Trish has always been fascinated by the question of why some drips readily form deposits while others quite nearby,  possibly with similar chemistry, are much less capable of creating decorations. With this in mind our guide led us to a wonderful “stalagmite garden”  which had many excellent drip sites for comparison.  We found that the soft, slightly concave rubber bottom on the drip sensor housing made it very easy to perch the sensors without harm to the stalagmites. Several units were set up in short order, and as we exited the cave we could see their little green indicator lights blinking away in the darkness behind us.  Even with the help of lithium AA batteries, there is a fair bit of uncertainty about how long these units will actually run, so I was quite happy to hear our guide Fernanda say that she would stop in to check on them when she had the chance. The sensors are designed to light a red led when the battery voltage falls too low, but I told her to remove and disconnect them before that if they showed any other unusual behavior. These units were assembled with an assortment of cheap clone boards, most of which use the MIC5205 voltage regulator, and I will be especially keen to see the performance of the one build with the Rocketsream Ultra, as it’s MCP1700 delivered some very low sleep currents during my bench top testing.  My hope is that we get at least four months of good data from all of them before the batteries expire.

<— Click here to continue reading the story—>

 Addendum 2014-12-12:

This first deployment was a great success, which you can read about here.

Drip Sensor Update: The Gamma Build

I suggested in the last post that a new build usually comes together on the third iteration, so I though I would post a few photos of the current drip sensor, to show how much they changed in that short series:

Alpha, Beta & Gamma builds

Alpha, Beta & Gamma builds of the Cave Pearl Drip Sensor

That Alpha would only detect drops in the very center of the housing, and often registered double hits because of the splash back from the complex surface topography, which also caused a buildup of water on the surface, further interfering with the signal. So I removed the pressure and temperature sensor wells from the Beta, and used a heat gun to bow the surface and shed water.  I hand sanded the pvc to make the strike surface thinner and more responsive, which increased the “reliable” sweet spot to the diameter of the circle you see on drawn there. This worked well, but as you might imagine removing that hour long fabrication step rose to the top of the priority list (if necessity is the mother of invention, laziness is surely the father…) I also did not want to penetrate the housing for those standoffs if I could avoid it because this device has to maintain integrity with constant water impact at exactly that spot.

JB Plasicweld bonds the accelerometer to the cap

Plastic-weld bonds the sensor, preserving the integrity of the housing

My solution to both problems was to solvent weld a four inch knock out cap to the top of the hard pvc shell.  The green color you see there is ABS to PVC transition cement, that I learned about back at the beginning of the project when I was mangling Leggo bricks for internal scaffolding. The ABS is translucent, so the LED no longer needs a portal of clear epoxy because the light passes right through.  The knockout is thin and stiff, which eliminates all that sanding and improves the response of the accelerometers so much that now the device even responds to loud noises, and almost the entire surface sensitive to the smallest drip.  As a result I now have to tweak the settings to reduce the sensitivity so we don’t get too many false positives.  But on the third build of a new sensor, that’s the kind of problem you want to have.  I though the flat surface might resurrect the water pooling problem we had on the Alpha, but in the end it just ended up being a lesson in how I still miss things that are really darned obvious, because simply setting the drip sensor up with a slight tilt will shed the water without affecting the operation at all.  (I am just glad I realized this before some three year old came along and pointed it out to me…)

These guys are only $1.5 each, and are much easier to work with than the plastic micro SD adapters

Much easier to solder those jumpers now.


The trickiest part of the build is routing the wires to reduce strain. Thin silicone 26awg wire helps quite a bit there.

There have been a few improvements to the logging platform as well.  I found these really inexpensive  raspberry pi SD card adapters that are mounted on their own pcb, which neatly solves the melting problem that the cheap plastic  adapters give you if you linger too long with your soldering iron.

Drip Sensor Gamma BuildSo this is the new baby, and I am now running burn tests on loggers using a few different clone boards, including a Rocket Scream Mini Ultra, as they have some very interesting power saving features that might significantly increase the operating time, while keeping the overall simplicity of the three component design.  I expect a few more issues will arise in testing, so I will hold off posting the code to Github, till I am sure that they are behaving properly.  I am still a bit stunned that these drip sensors came together so quickly, but perhaps the last six months of work on the flow meters had something to do with that. 🙂

<— Click here to continue reading the story—>  .


Adafruit just posted a video from the National Science Foundation showing how water droplets move on various hydrophobic surfaces.  Way cool…

Addendum 2014-12-11:

We deployed our first batch of these drip sensors in August, and when we went back to get them in December, we were delighted to find that the first real world run was a resounding success.

A New Drip Sensor for Cave Research

 … we interrupt this hydro-metric-flow-thingy blog to bring you an important announcement …

Trish wiring up our home made drip sensors in 2004

Trish installing her drip sensors in a B.C. cave

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.

DripSensorBetaWhile 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 the ADXL345 on a regulated bus.

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.


A DIY Arduino data logger for $10 from 3 components (2014)

Addendum 2019-01-15:

I posted the $10 DIY Arduino data logger in July 2014, and there have been many updates to the way I assemble the basic three component logger since the early version described in 2014. In 2019 we updated the design to reduce the total build time to about 1 hour:   We’ve also added support to the code for using the indicator LED as a light sensor, so you can start monitoring the environment right away :

In 2018 we published in Sensors: Cave Pearl Data Logger: A Flexible Arduino-Based Logging Platform for Long-Term Monitoring in Harsh Environments This paper describes how to optimize these loggers for long-term deployment and the PDF is free to download.

 Original Post from 2014-07-01:

To celebrate Arduino day this year, Sparkfun put their 3.3v Pro Minis on sale for $3. Well, how could I resist that?  I put in my order and, in due time, the little red boxes arrived with the morning mail. I was in the midst of assembling a small army of TinyDuino based logging platforms, so the Pro Minis just sat on the shelf for a while, as hacked into the tiny light sensor boards to drive my 3v sensors.  But then, a couple of weeks ago, I stumbled across a project where someone had soldered a micro SD card adapter directly to the pins of a Pro Mini…What? I had at least half a dozen of those things lying around! Within minutes I was in the basement, waiting for the soldering iron to heat up and realizing that an onboard regulator meant that the RTC could also be connected directly to the board.  Using 90° header pins to provide solder points at the base of the board (keeping the vertical pins free for sensors) I had the thing roughly connected   in less than 30 minutes.  A little scramble to re-jumper an old serial adapter I had in the drawer to run 3 volts (…because I forgot to order the 3v FTDI you need to use the Pro Minis), and the new unit worked like a charm right from the start.  I had cobbled together a working data logger from only three components. I did a little cost estimation:

 ProMiniDatalogger6 3.3v Pro Mini
Ds3232 RTC w At24c32 
256mb Sandisk micro SD (with adapter)
Wires, solder, ties, etc
Deans style connectors
indicator LED, Resistors etc
3v lithium Coin cell
Total: $10.43
2x 10K ohm taps the vraw pin.

I used two 10Ks to divide the battery voltage in half & put it on A0.  But you could use up to 2 x 10MΩ and bring leakage down to 0.3 µA with a small cap to stabilize the reading.

The Grove hub adds another $3, but it’s not really needed unless you are doing sensor swaps like I am. Otherwise the I2C sensors can just be soldered directly on to the other end of that RTC module.  But I was still missing one piece of the puzzle:  How do I track the battery voltage when I can’t use the internal 1.1v reference trick like I did with the TinyDuino?  I googgled and found an excellent JeeLabs post about how to use a voltage divider to read supply voltages above Vcc on an analog pin. A little tweak to add the analog read to the Vcc read function in the codebase, and I had the cheapest “fully functional” data logger I have ever seen… sitting right in front of me.

It didn’t take long for that moment of “Wait…did that just happen?” to have my brain hoping around like a bullfrog on a hotplate.  You see, while this project originated with the challenge of determining water flow in cave systems, I hoped that there was at least the potential to do more than just keep my favorite hydro-geologist happy.  Over the years we have worked with so many great people at various NGO’s, Eco-Centers, etc. plugging away with boundless spirit & enthusiasm, but hobbled by shoestring budgets.  For these guys, something as expensive as a Hydrolab is just never going to be part of the game.  But if you combine something as cheap as this Pro Mini based logger platform,  with the super simple rubber bottom housings I came up with back in 2013:

IMGP0029this unit survived ~ 4 months
@ 5m depth, 50% salt water.
Fernco Qwik Cap
Nibco 3” pvc endcap
2x 3” knockout cap
4 x 2” 8-32 riser bolts
2x 3AA battery holders
3in of 3” dia pvc pipe
& ¾” pipe for sensor well
& pvc adhesive, etc.,
Total: $10.95

…then you have some real world environmental monitoring capability for about twenty five bucks.  If you use this with I2C, or one wire sensors, you can sidestep the Arduino’s limited 10bit ADC, and get better data, with more frequent sampling than most, if not all , of the other low priced loggers on the market. (you could also use the ADS1015 12bit OpAmp/ADC combo board…) And because you have the ability to edit the code yourself, it is easy to track the rate of change and increase the sampling frequency during  “events” of interest.  Features like that don’t usually appear in commercial data-loggers until you start spending some serious money.

The only unknown at this point is how long this thing will run on a fresh set of batteries. On the bench this Pro Mini logger (with three sensors & 2x 10k voltage divider attached) draws about 1.8 mA while sleeping.* I figure ~2mA is going to chew through a standard alkaline battery (~2000mAh) in about a month, so a build with 6x AAs should be good for at least 3-4 months depending on the sample frequency.  Most people are not working 30 minutes into a cave & 10 m under water, so that kind of retrieval schedule might be all right.  Or one can make the pvc pipe a bit longer on that housing and have room for another battery pack, which should easily get you past 6 months.  If you really want to splash out you could also go to lithium AA’s which provide an additional 1000 mAh per cell, and probably taking this thing up to a year on 9 cells…

As you might imagine, I have a couple of these loggers running on the bookshelf already, and I will post the burn test results here as soon as I have them. For now, I will simply post the wiring diagram, so anyone who wants to can build one.  Just don’t take too long soldering the contacts on the micro SD card adapter, as you can melt through the plastic around them very quickly.  I also suggest you test each stage of the wiring as you go along, before you finally attach everything to the platform…


Note: that several sources recommend pullups on CS, MOSI, MISO and SCK, though I have been running my loggers without them, but I have found that some SD cards take a very long time to go to sleep unless CS, MOSI & MISO are pulled up.

Read the Addendums below!: The Rocket Scream Mini Ultra is the lowest current board I have found so far & good SD cards are crucial to the success of your data logger. My latest builds based on this design usually get down to ~0.35 mA while sleeping. Recent field tests have shown that 3 good quality AA batteries will power a logger that draws 0.33mA for 9 months.

You can download my latest code to drive these loggers from the Cave Pearl Project GitHub.  Just make sure you set the initial configuration defines properly before you compile (ie: uncomment ‘#define vRegulatedMCU 1’,  and comment out ‘#define unregulatedMCU’ if you use a resistor divider to read Vbat…which you really have to do if you want the unit to gracefully power down when the batteries expire) Also note that depending on which sensor you connect, other changes to the code will be necessary to co-ordinate buffering, and formatting the data that gets written to the SD card.

So how does this affect the project?

Power tests in progress

Pro Mini power tests are now under way….( Update: read the Addendums -> Sparkfun Pro Mini’s gave me a host of problems with the SD card communications, while many cheap clone boards worked fine? )

The currently deployed Pearls are set to be retrieved in about a month, and if they deliver the same (> 1 year) power performance that the Betas did, I suspect I will be staying with the TinyDuinos for a while, at least for long term in-cave deployments.  Just getting out to a remote cave site is often the most expensive part of field work, so if another fifty bucks worth of components means that I can safely wait a month or two (or six…) to find a flight deal, then I will ante up.  But we already have people interested in using the Pearls for monitoring flows at springs and other open water locations.  Most of them are on site, and they can service batteries by simply swimming out into the bay.  So I think I will get those folks rolling with Pro Mini based loggers right from the start.  It makes the build cheap enough that if some of these more exposed units “walk away on their own”, we wont be loosing our shirts. And it sends a tenner over to Sparkfun, without doubt one of the coolest nerd companies out there.  As the Pro Minis are licensed boards, Sparkfun also passes on a bit of each sale to Mr. Banzi et. al., and that’s pretty good too.

<— Click here to continue reading—>

Addendum 2014-07-02

I have discovered that it is possible to run the Pro Mini’s without the on-board voltage regulators…in fact, so many people have been manually cutting the trace to the voltage regulator to get low power operation out of the ProMinis, that Sparkfun has now put a power isolation jumper right into the design.  So if you get sensors that already have voltage regulators (as many IMUs do), or you use sensors that can handle large voltage swings (like the DS18B20)  you could turn this pro mini based logger into something like the unregulated TinyDuinos that will operate for a very long time on couple of AA’s. You would still need to regulate & level shift the SD card lines for data logger operation so another alternative is to bypass the on-board regulators by simply connecting an alternate supply directly to Vcc.  This is how the FTDI serial board powers your Arduino while you have it connected to the usb cable!  

fatlib16 posted a picture (near the bottom of the thread) of his ProMini powered by an MCP1700 :  you can bypass the on-board regulators by simply connecting the battery supply directly to Vcc  -> this is how the FTDI serial board powers your Arduino while you have it connected to the usb cable!

These guys are only $1.5 each, and are much easier to work with than the plastic micro SD adapters

I just discovered I should not be leaving those unused pins floating like I have in this photo – they should have pull-up resistors.

Addendum 2014-08-07

 There are some very inexpensive Raspberry pi micro SD card adapters on the market now that are much easier to work with than the thin plastic SD card adapters I used on the first build. I suspect that the spring connectors are more physically robust as well. Of course you could try Adafruit’s adapter for $2.50, and if you had money to burn, you could go to the Sparkfun SD board.

Addendum 2014-08-11

 Well serves me right for counting my chickens…After doing many different run tests on six different drip loggers built to this basic design I have some good news, and some bad news. The good news is that the cheap pro mini clone boards run well, logging data till they bring the power supply voltage low, at which point the voltage regulators go into a cycling reset loop, which so far has not hurt the data files on the SD cards. The bad news is that the units that have given me the most problems are…the ones that use the “real” Sparkfun Pro Mini. I still have not figured out why, but they have had no end of SD card problems.  I don’t think its because too much current being drawn, as they are only 128mb cards, and the units seem to be able to write SD data when they connected to the 3.3v FTDI board, which can only deliver about 50mA in total.  I will post an update when I get a handle on this problem…. (Note: later trials worked OK with other ProMini boards…these were just a bad batch. )

Addendum 2014-08-17

 I have about a weeks worth of burn test data in hand from six different loggers built with this basic design.  As I expected, the pro mini clone boards draw down a 3xAA power supply at almost the same rate no matter what the sample frequency is set to, indicating that the sleep current on the MC5205 voltage regulator they all use might the biggest load* on the system. (*This is an error – I found out later that the SD cards I was using were the real energy vampires. See below  From these rough tests it looks like I should get at least 3-4 months of operation out of them (on regular alkalines – 1/3 more with lithium) before the power supply gets down to the 3.35v minimum needed by the regulator. The best results so far have been from loggers built with the Rocket Scream Mini Ultra:

As I want to see how gracefully these voltage regulated systems behave when the batteries croak, I started the ultra based unit on a 3.4 volt power supply which already had a dead cell in it just to bring the voltage into the range of the voltage regulators minimum. More than 40000 SD card records later and the voltage is now at 3.3volts.  I did nothing special to the board myself, just loaded the same code running on the clone board tests above, which makes liberal use of generic sleep code (ie: not using Rocket screams special libraries!) This thing is performing like one of my unregulated tiny-duino based systems. I will leave this unit running until the voltage divider reading vRaw gets to 2800 mv,  (this might be a destructive test as this is way below the MCP1700T regulators minimum rating) because I still want to see how gracefully it handles a full brown out.   

Addendum 2014-09-23

Just a quick update on the three component loggers. At this point I have put together about 20 of them with many different boards and they all seem to work OK (including the Sparkfun ProMini’s – Although they still give me more grief initializing the SD than the clones, even with the pin13 led removed. I just don’t know if their regulator is up to the task?). However I have found that the sleeping SD cards themselves are by far the most important part of the system, and that most builds come close to 0.3mA sleep current if you have REAL Sandisk memory cards….  However if you get burned with counterfeit cards your sleep currents can go above 5mA!  Assuming your sensors don’t draw too much, with a 0.3 mA sleep current, a single AA battery could power one of these unit for a couple of months, and 3 AA’s should get you close to nine months. The big quid pro quo here is that nothing is protecting your SD card if you suffer a power failure. I’m working on that now. Making smaller individual data files is probably the first step.

Addendum 2014-09-27

 After more testing of the many 64, 128 & 256 mb cards I bought from eBay, and I have found that if you have the “good” Sandisk cards, the whole logger should gravitate towards about 0.33 mA,  even if you leave connections 8 & 9 unconnected as I did in my earlier builds. (& I have an ADXL345 on my drip counter test system so about 40 µA of that current is being drawn by the sensor) However lots of my microSD cards seem to need pullups (OR pulldown) resistors on the two card connections that are not used to keep them from floating, or the sleep currents will be much higher. In the forums (and in the datasheets) people seems to be recommending 50-100K pullups, and I have done a few experiments which I will write up as a longer post later.

But the general result is: If this logger system+Sd card sleeps around 0.3mA with the pins floating, you already have a good card, pullups won’t change much, and about 1/2 the time it actually increases sleep current if you use a pull down resistor, possibly as high as 0.9 mA (the other half of the time the pulldown does not increase the sleep current). If your system draws between 0.5 mA to 2mA with the card sleeping…”generally” I find a pull down resistor on 8 &9  (I used 20k ohm)  works better than a pullup, and should bring the whole system down to a stable 0.33 mA sleeping current.  This is very strange because no where in the data sheets does it specify to use a pulldown. I probably need to do more testing here so I put a pullup on the illustration above just to be safe.

If you don’t get to near 0.33 mA with either a pullup or a pulldown, then you have a bad microSD card, and you should go find another one. If your “sleeping system” current for this logger design is above 2 mA, then you have a REALLY bad counterfeit microSD card, and you should just throw it in the rubbish bin. And the worst cards of all bounce down to a reasonably low sleep current initially, and then slowly “creep” upwards over the course of 2-10 of minutes, as you are watching the meter.  Those cards often seem to be bad, whether you put a pullup, or a pulldown, on the unused lines so the card controller is probably NFG.

Generally, if you have a good card, it goes into sleep state almost instantly as soon as the MCU sleeps, and you can see that on the current meter because the numbers are completely stable at the lower reading right away. The crummy cards seem to wander around for a while, like they have to think about whether they actually want to go to sleep or not.

Addendum 2014-09-27

I have posted an updated version of this logger design. The new version adds a Pololu latching power switch, which allows the Arduino to cut its own power when the batteries fall low, protecting the data on the SD card. This is a real trade off because the switch itself draws as much current as the whole logger when sleeping, so you would have to go to six batteries to see 6-9 months of operation for that build. I have also provided links to sources of components have been using for my builds.

Addendum 2016-01-25

Reliable sources recommend pullups on the SPI lines, though I have been running my loggers for a long time without them.  I have noticed that some SD cards take a really long time to go to sleep unless CS, MOSI & MISO are pulled up, and some just refuse to sleep at all without the pullups. These weak pullup resistors are not described in this tutorial. If you already have loggers built without them, there is a workaround using the 328’s internal pull-up resistors that I current have in testing.  Despite the fact that only CS requires it, I found that all three lines had to be pulled up before misbehaving cards went to sleep properly. So add these lines to the beginning of your setup before you run sd.begin

// pulling up the SPI lines
pinMode(chipSelect, OUTPUT); digitalWrite(chipSelect, HIGH); //pullup the CS pin
pinMode(MOSIpin, OUTPUT); digitalWrite(MOSIpin, HIGH);//pullup the MOSI pin
pinMode(MISOpin, INPUT); digitalWrite(MISOpin, HIGH); //pullup the MISO pin

  It’s worth noting that there is some debate about the utility of this approach. Because SPI is a complex protocol, adding internal or external pullups could actually prevent you from being able to use other SPI sensors with your data logger. That is one reason why I tend to stick to I2C & analog sensors on my builds, so the SPI lines are dedicated to the SD card only.

The new fleet of flow sensors is ready to sail!

Hi everyone. I wrote most of this entry on a plane today, as it was almost the first free time I’ve had “away from the workbench” since the initial proof of concept loggers were deployed last year. I have redesigned the Cave Pearl data loggers into a more modular platform that should be flexible enough for quick field repairs, while enabling future development with more sensors.  (I want at least CTD, and my wife has an infinte supply of other suggestions  🙂

The loggers are now assembled in four interchangeable components, which from top to bottom are:

1) Upper housing

It was too cold in the basement for the epoxies to set properly...

It was too cold in the basement for the epoxies to set

Lots of lessons have been learned here about sealing the hull penetrations thanks to the diy ROV crew. Sort lengths of 3/4 pipe form “wells” to protect the sensors, with JB Plastic Weld putty wrapped around the wires as they initially pass through from the inside of the housing. The putty sets on the roughened surface, pluging the hole and holding the sensors in position, but I found that the silicones I tested flex quite a bit after curing, so they are too easily “sheared” away from the pvc surface. As a result,  the current builds use JB weld around the DS18B20 thermal sensors, and Loctite E-30CL to for a transparent seal over the “heartbeat” LEDs which pip when the samples are taken. Experience has shown me that you must have some way of knowing your units are working happily (or if they are in an error state…) before you dive them into the cave.

2) Main electronics platform

The LED is an Octopus Brick because they had a good buckled connector, and the RTC is a cheap DS3231 module from eBay because I wanted the AT24C32 it had on board.

The LED is an Octopus Brick because they had a good buckled connector, and the RTC is a cheap DS3231 module from eBay because I wanted to use the AT24C32 eeprom it also had on board.

I am still quite happy with Tinyduino, as the package integrates the mcu, accelerometer, and now digital compass, with the smallest footprint and the least amount of extraneous wiring. I put riser pins on their new overhanging protoboard, and this jumps out to a grove I2C hub as a central interconnect system allowing me to interchange the logger platform with housings that will sport different sensors in future.  All of the electronic components have had a good bath of conformal coating this time around, so hopefully they will be a bit more robust. (I might try Rustoleums Neverwet next time)

3) Power supply

The gap between the two shells provides room for the interconnect, and some filtering caps, etc. if needed.

The gap between the two shells provides room for the interconnect, and some filtering caps, etc. if needed.

Physically it’s just two pvc knockout caps held together with four bolts & a 1cm “hold down ring” to keep it in place in the lower housing. Electronically there are two versions. The first is an unregulated supply uses two banks of 3 AA batteries, through Shottky diodes to prevent the banks from draining unequally. This supply will drop from 4.5 volts down to a lower cutoff of 2.8 volts before the system stops logging, so it needs fairly robust sensors. The second power supply uses three banks of 2 AA batteries (with three Shottky’s) feeding into an NCP1402 3.3 volt boost regulator which then powers the logger. Several of the sensors I want to use have a strict 1.8-3.3v input range, so they can not be used with an unregulated system. It will be interesting to see if the greater “draw-down” enabled by a boost regulator compensates for the power it wastes (here about 25%). This deployment will hopefully be some months long, so I will find out how the regulated VS unregulated systems actually perform.

4) Lower housing & external weight system

This series needs about 100-150 grams of ballast mass to be neutral.

This series needs about 100-150 grams of ballast mass to be neutral.

The buoyancy troubles we had on the initial deployment showed me that I needed some form of external system to compensate for changes in battery mass, cable buoyancy, salinity, etc. So I have a simple solution using a bolt through a threaded end cap which holds a number of washers as ballast. All stainless steel, but I am curious to see how long they actually last in the near marine environment. The buoyancy mass will be spit evenly on the top & bottom of the units to prevent rotational torques which which would affect the angle readings.

The battery run down tests are still looking very good for one year + deployments!

The battery run down tests are still looking very good for one year + deployments!

So this is the new fleet: Four pendulum units and one high resolution temperature &  pressure sensor that will remain stationary.  Hopefully they will all be underwater logging in a few days. Looking back at the build journal, I should add that there has also been a fair bit of coding, but I will post details on all that later, after I have integrated support for the HMC5883L digital compass & MS5803 pressure sensors into the main logger script.

BUT before we deploy these new units,  we need to go and retrieve Beta’s 1&2 which we left in a cave last December.  My fingers are crossed that they have survived these last few months under water…

<—Click here to continue reading—>

Addendum 2015-01-07

For the DIYers out there, I should mention that this housing style proved quite robust through several deployments in 2014, and probably could go to substantial depth due to the thickness of the 3″ end caps.  But in early 2015 I came up with a new design built with Formufit table caps, which is much easier to assemble provided you can squeeze your electronics package into 2″ pipe.