Well, now that we have working ‘betas’ in the field, it is time for me to get back to the workbench. It’s clear from the November test runs that power management is going to be my next priority.  But I approach this problem differently from someone with more technical ability, who could simply dig into datasheets, rooting around for micro-controllers that are especially optimized for low power consumption.

One of my primary design goals is to make this thing easy for anyone (including me!) to build (plumbing parts, standard Arduino, AA batteries, etc) but the practical limitations of fieldwork are also affecting the design.  I currently envision a service cycle where we dive to retrieve the units, bring them to the surface, swap the batteries and retrieve the data, and then immediately return them to the sample locations in the caves.  I would love to come up with a system that does not break the watertight seal around the electronics, like the optical system of the HOBO Waterproof Shuttle, or the external screw contacts of the ReefNet Sensus; but it is going to be a quite a while before my Kung Fu is that strong.  And it might be non trivial to put this kind of kind of transmission window in the current pvc housing.

This is me taking a laptop apart to dry it out after the rain hit us – while tethered to an Aanderaa RCM.

More typically, one would download data from the units by simply connecting the motherboards to a USB port cable once they were on dry land. But it’s pretty common to get caught in downpour, so just taking your laptop into the field for this procedure can be risky. (In fact it’s not to much of a stretch to say that is how we kill many of our machines.) Now multiply this fiddle factor by the 5-10 units we might have deployed in a given cave and you see where potential bottlenecks could arise on the real world side of things.

So I am still planning to use SD cards as the data storage device, even though I know that card writing is overwhelmingly the biggest power user in the entire system.  Somehow I need to buffer the data with a low power system, and only write to the cards once per day.

The sensor read cycles are only generating about 60 characters of data at the moment, so one strategy is to try buffering to the arduinos internal 1k of eeprom memory, which would give me about 15 sample cycles before I had to do a save.  This approach has the benefit that it would need no extra hardware, which means no change whatever in the current physical build of the units if the internal eeprom is robust enough for all that traffic without becoming corrupted.  Unfortunately, the routines for reading and writing data to EEPROM are kind of primitive, limited to a single byte at a time. And I will have to work on my chops before I am comfortable using pointer variables to directly access memory. But perhaps there are easier ways to write data to an eeprom?

If I add a larger external eeprom chip to the SPI lines, I would have 16-32k to play with; more than enough to do a whole days worth of reading before I have to fire up the SD card. I have also found several DS3231 real time clock shields that already include I2C eeprom memory, so if the libraries are out there, they might be pretty easy to implement and many of these chips support page writes to simplify the code…or perhaps not. And many of the “combo” shields I’ve come across seem to have rechargeable (LIR2032) cells on them, so I am concerned that there is the power hog of a charging circuit in there somewhere.

Alternatively, some RTC’s have 1-2K of internal eeprom themselves, so perhaps I could find an RTC based on those chips.  I would not want to give up the accuracy of the DS3231 though.

And while I am sorting all that out the Sparkfun power management tutorial shows that there is still room for other power reductions that can be achieved through software alone. The problem of burden voltage on multimeters, means I will need to buy better equipment to even measure differences down in µA territory. I am still kicking myself for not getting my hands on one of the EEVblog uCurrents before he ran his spectacularly successful kickstarter, which of course means that I wont be able to get my hands on one for months while he deals with the resulting backlog.

And finally, it would not hurt to get a ‘real’ voltage divider in the units, so I know what Vcc actually is, rather than relying on the twitchy internal VCC reading trick to monitor the power supply.

I definitely have my work cut out for me…

After sending the first gen housings out for some real world testing, I returned my attention to the guts of my data loggers.  While the Uno & Adafruit data logging shield was dead easy to get up and running, the whole unit would wring out 6AA’s in about a day, and I needed a heck of allot more run-time than that.

So I started combing through the forums at the Arduino playground for any power management threads I could find. A myopia inducing week of screen reading later, I had developed a rough list of strategies to pursue, even though I had no idea how much difference each one would make. These fell into two basic categories:

Lower the voltage & clock frequency,  then get rid of any circuits you don’t need:
– like indicator leds, voltage regulators, usb interfaces, etc

and once you have that sorted:

Turn off parts of the processor you are not using with software:
– and if possible put the whole chip to “sleep”

And although I did not find this mentioned anywhere, I also penciled in a note to research different battery chemistries, as I knew that on year long time scales, self discharge was going to be a real issue.

So I started with the hardware, and dug into the stunning array of “bare bones” clones that had spun off since Banzi et.al gave their little project to the world. I whittled the list down to a handful of low power units including: the Pro Mini,  the Solarbotics Ardweeny, the Rocket Scream Mini Ultra, Modern Device Jeenodes, RFduinos, and a few others that seemed to be pushing the limits of low power design. Some of these designs were so minimal, they were barely more than a row of breadboard pins soldered onto the raw Atmel chip itself. So, for a while, I flirted with the idea of just sticking a chip on a mini breadboard and going from there.

I was comfortable with the idea of using a separate FTDI breakout board to program the unit, but some of the low power designs had non standard processor chips, and I knew that was not going to work, because I was still cutting my teeth on “Coding for Dummies” tutorials. And on a purely practical level, the mini breadboard I used with an Ardweeny started getting ugly once I wired in the SD card shield, the accelerometer, the FTDI chip, the battery connectors, etc.  I was not sure the resulting octopus would survive the bashing around these sensors were likely to see dangling from the side of a cave diver, no matter how tough my housings were.

Then, I got wind of a spectacularly successful Kickstarter campaign  for a new, ultra small Arduino board that was being made in Ohio, and everything just fell into place.  While the new TinyDuino system was a bit expensive, it delivered almost everything on my power management wish list and they also had an accelerometer, an SD card shield, with several protoboards.  But rather than describe the effect of all this with words, perhaps a picture would convey all this a little better:

My digital innards went from an alpha kludge to a running beta in one fell swoop!

So although I had some misgivings about their fragile looking stack connectors, adopting the Tinyduino meant that I could now start chewing on the gnarlier bits of software based power management.

The hardware selection had essentially just been one long process of elimination, but I knew right from the start that coding would put me on a much steeper learning curve. AVR assembly language still seemed like quasi magical incantation, so I just started gathering every example of “sleep code” I could find, like a squirrel collecting nuts for winter.  I figured I would just try to  cut & paste from simple examples like the Nightingale code until I was successfully shutting down the cpu, and waking it with the internal watchdog timer on eight second cycles, to check if it was time to read data.

But I kept finding comments in the forums about how sloppy the Atmel internal clocks could get, affected by everything from temperature variations and input voltage, to “animal spirits”.  With so many iterations needed to extend those “overflow interrupt” blips out to a real world sampling cycle of perhaps 15 minutes, or even an hour, I worried that even tiny timing errors would eventually accumulate into sizable ones. (And recently I have heard rumors of people locking up their Arduinos because of watchdog timer conflicts with the default bootloader)

So I started investigating the use of an external real time clock (RTC) to let the little logger sleep for extended, and hopefully more precise, times between wake cycles.  There were tantalizing clues out there that this could make a system run for years, but I could not  follow the discussions far enough into the technical brambles to really understand them. And if I had thought that the machine code for sleeping was hairy, trying to pick a suitable RTC by looking at libraries and data sheets, seemed like it might convert an already steep learning curve into a straight vertical line.

Fortunately, it was then that I found an excellent post on power saving techniques which had clear examples of how to both sleep, and wake up the cpu with alarm interrupts. I was back in the game, and for the first time I had a sense of what all these things were actually contributing to my overall power budget. Combining his I2C primer  with the DSS circuits post on the Effects of varying I2C pull-Up resistors, and a few more tweaks, I finally managed to get a chronodot RTC (on the left in the picture above) to wake my sleeping data logger at any time interval I wanted.

Whew! My little project was finally looking like it might go the distance, and I was thanking the Gods for mysterious Über-tecks on the other side of the world, like Nick Gammon, who had put their mild obsessive compulsive disorders to such great effect bailing out newbies like myself.

<—Click here to continue reading—>