Another field trip is rapidly approaching, and I am scrambling to finish the bench tests before we have to stuff everything into a suitcase. The last three months have seen the project migrate away from the unregulated TinyDuinos as the heart of the data logging platform, to RocketScream based builds. Most of my sensors require a regulated 3.3 volt supply, and with only one MCP1700 voltage regulator in the mix, the Ultras have been delivering better sleep currents overall. The MCP also gives me the ability to use lithium batteries in a pinch (who’s over-voltage would fry the unprotected processor on a TinyD board) , and it delivers up to 250mA if I end up with really power hungry sensors later on. Now that I have the same core logging platform in all the different Cave Pearl models, it is easier to shave down my code, as the compiles keep bumping up against the 32k limit for multi-sensor configurations like the pressure/temp/RH unit.
But I have not forgotten how the TinyDuinos catapulted this project into viability back in 2013, and I am waiting to see if they release a generic I2C driver shield. Despite my rough handling of those early Tiny-based builds, most of them are still chugging along after months under water, a tribute to the quality of their build. I enjoy soldering my little bots together, but anything you have to do a hundred times begins to loose it’s luster.
Bench testing over the last few months has seen more sensor failures than I can throw a stick at, and I am sure that there are more to come if I keep using cheap eBay vendors. The best overall diagnostic to identify good breakout boards continues to be shutdown mode current. If it’s on spec, and the board delivers a stable reading after wake-up, your golden. Along the way, there have been so many little code tweaks I could not even begin to list them all. Some, like having the sensor reading LED pip change color to also indicate battery status, were effortless. But others, like determining the optimum number of times to use precious power up cycles to check that battery status, still have me scratching my head. We have more than 12 new loggers to deploy this time round, and I will be embedding plenty of little mini-experiments in the code to give me some empirical data for those questions.
At this point I am focusing on micro amps, not milli amps, and the best drip sensor builds are coming in with sleep currents in below 15 μA (if I get all the sensors in to their low power modes and pin-power the RTC) That’s a heck of allot better than I was expecting for a few jumpers connecting off-the-shelf breakout boards. Even with the physical build coming together well, I still have a huge sensor calibration to-do list hanging over my head. But the tickets already bought, so that will have to wait till after the next set of field deployments. I also need to develop a new bench testing method that gives me the ability to discriminate how relatively subtle code changes affect a micro-power budget. Oscilloscopes seem to capture a time window that is too brief for the complex duty cycle of a data logger, and the power use ranges from a few μA of sleep current to many tens of mA for SD card writing during each cycle.