Measuring battery discharge on an Arduino Data Logger

I’ve written before about how the main battery discharge record is one of my primary tools to determine what happened when a logger fails, but I thought I would try another kick at that can; delving into some of the things that show up on units that are apparently running OK, but still leave me scratching my head.

I did not really know how to solder at the beginning of the project, so I was using Tinyduino based platforms that drew sleep currents between 0.5-0.6 mA. I was running them right from the battery with no voltage regulation, and using the 328’s internal 1.1v band gap trick  to track the power supply:

Battery Voltage (mV) with

Battery Voltage (mV), 2 x 3AA battery pack, Tiny Duino based logger

These units buffered less than half a day of readings to the small 4K eeprom on the RTC breakout,  so I attributed most of that 100 millivolt  jitter to the frequent SD card writing. Some have pointed out that the internal voltage reading trick itself can suffer from as much as 10% variability from one processor to the next, with additional thermal variations. But at least those curves were predictable, with a 6 cell (2x3AA) pack lasting longer than the four months between fieldwork trips.

The need to provide regulated power to an increasing number of sensors encouraged me to switch over to 3.3v pro-mini style Arduinos,  and adding a 32K external eeprom extended my buffering out to several days. This smoothed the power curves dramatically, and on good builds I now see voltage records like this:

Cave Pearl data loggers

Battery (mV), Rocket Ultra logger, 3xAA Battery, 0.19mA sleep

The steps on that curve correspond to the limits of the ADC (with a 2 x 4.7MΩ divider cutting the battery voltage in half), so that’s as good as I’m ever likely to see. The thing that has me curious is that I also see curves that look irregularly bumpy, and have other intermittent features. For instance, some of the loggers built from the same parts, with the same code as the one above, give me a clear pattern of 100mV dips whenever the data gets transferred to the SD card:

Battery (mV), Rocket Ultra, 2x 3xAA supply

Battery (mV), Rocket Ultra logger, 2x 3xAA Battery, ~3 day buffer

As you see the depth and duration of the dips vary somewhat, although the amount of data being written is always exactly the same, which makes me wonder about random latency delays. And that curve also has a mysterious low voltage anomaly showing up around 9/20 that lasted for the better part of a week.  I see stuff like that in about 15% of the loggers that give no other sign of problems, have low sleep currents, and decent operating lifespans. And this is definitely not temperature related, since most of the cave loggers see less than 1°C variation over a deployment.

Other times I see hump shaped features in the curve that seem to indicate that the problem occurred long enough to pull the batteries down significantly, but then went away, and returned again some time later:

Battery (mV), Moteino based logger, 3xAA supply, 0.22 mA sleep

Battery (mV), Moteino based logger, 3xAA supply, ~5day buffer, 0.22 mA sleep

I took this unit out of service, and am running tests on it now to try to identify what happened. Again there was no hint of a sensor failure in the data, and the sleep current still looks the same as it did at the start of the deployment. I’ve seen this hump/step pattern a few times now, and for all I know it’s an issue with the batteries hitting some kid of threshold, rather than the logger. 90% of my deployments use alkaline AA’s, as I usually catch them on some kind of promotional sale at the local hardware store. I rarely use lithium AA’a as they are more expensive and I’m not convinced they give you longer operating life in low current applications.  They also fall so precipitously at the end of life that I am concerned they will brown out in the middle of an SD card operation, destroying my data before the code has a chance to intercept the low voltage problem. (…and they are not allowed in air travel luggage …)

Probably the longest running power curve mystery are the events that only show up once every month or so. These hits are so widely spaced that they don’t seem to be directly related to the buffering & regular SD card writing events, and I have yet to find anything else in the code that explains them:

Battery (mV), Rocket Ultra, ~3day buffer, New file @~15 days

Battery (mV), Rocket Ultra, ~3day buffer, New file @~15 days

The timing of these long gap events can be regular, as shown above, or more variable. My current hypothesis is that some threshold is being passed inside the SD card controller triggering some kind of huge load balancing event that hits the battery with a sustained power draw much larger than any of the normal logger operations. This makes me wonder if the battery packs would benefit from a parallel supercap to buffer those pulsed loads.  I suspect that the SD cards are responsible for most of the power curve anomalies that I’m seeing. All the loggers are now using Sandisk’s MUVE music SD cards that quickly go into low current sleep, so I am still left wondering what the real cause is.

Anyway, I’d love to hear comments from others who have seen curves like this in ‘otherwise normal’ equipment.

Addendum 2016-03-02:

Just thought I would add another interesting one to the batch. When I build a new logger I like to put them on a shakedown test for a week or two, with rapid sampling and small eeprom buffers to make sure the SD card sees lots of activity to test it out.  So this is in no way a “normal” operation power consumption curve like the ones posted above but it does show another interesting phenomenon:

This unit was taking a sample every 5 minutes, and only buffering 20 readings to the eeprom.

This unit was taking a sample every 5 minutes, and with only 20 readings buffered to the eeprom those numerous 100mV spikes are from the frequent SD write events.

This was a continuous run, so the code did not change even though there was a fairly dramatic shift of the pattern in the voltage readings. Usually I see this kind of thing in reverse when a sensor fails (ie: a smoother curve becoming more and more variable as the sensor goes down).  I have no idea what caused this unit to become more regular as the run progressed?

Addendum 2016-04-07:

Found anther one to add to the collection.  This flow meter is still in service, though the overall curve is crunchy enough to make me suspicious that something is going on, the logger has not replicated the central up/down anomaly in any subsequent deployments:

Caption

Battery (mV), Rocket Ultra 8mhz, ~5day buffer, New file @~15 days

Addendum 2016-04-07:

I monitor the main AA supply with a simple  2 x 4.7MΩ divider  on an analog pin, but Dangerous Prototypes spotted a low voltage indicator circuit that can be built from a couple of comparators. This could come in handy for builds that don’t have enough pins left to keep track of Vbat. This would be handy for minimal builds with AT Tiny’s. There is also some interesting background info on battery discharge curves with boost converter in this TI appnote.

Addendum 2016-07-30:

Reviewing the data from the latest round of fieldwork, and have another interesting power curve to add to the collection:

Rocket based logger,

Rocket Ultra 8mhz based logger, 3xAA, 15min sample, 512 records buffered to eeprom

That’s the first time I’ve seen higher voltages appear in a record where the logger was in a stable thermal environment, and it makes me wonder how that might of occurred. Since there was no change in the cave temperature, I suspect that the voltage regulator on the Arduino had a few low voltage events, and this messed with Aref enough to create artificially high readings on A0.  All the other data in the log appeared to be fine, but I will be keeping my eye on this logger…

Addendum 2016-09-12:

shottky1n5817This is a bit of a tangent, but I’ve been using bog standard 40v 1A Shottky 1N5819 diodes to isolate the 3xAA battery banks on some of my loggers, and I just noticed in the datasheet that 20v 1N5817’s have about 1/2 the Vf. And I just found out that with beefier 3A diodes, I can probably bring the voltage drop even lower during SD card write events, which could push the logger below the 0.1 A line at the bottom of this graph. This makes me wonder how much of the voltage dips I’ve been seeing are a real effect of the load on the battery, and how much is simply an artifact of the isolation diodes?

Addendum 2016-10-17:

1n400x15Continuing on the diode tangent, I’ve recently come across a few mentions of powering Arduino projects with 4xAA batteries in series, using a 1N4001 diode to drop the voltage into the 5.5v range you see on some 3.3v Arduino regulators. I have yet to find any tests of exactly how much power you would be wasting over the diode, vs the extra power you could extract by taking 4 cells down to about 0.85v  than you could with 3 cells in series (~1.16v) . The circuit would cause a voltage fluctuation of about 0.2 volts but I don’t know if that is worse than the Shottkys, as their datasheet does not go down to very low current levels. It’s worth noting that the MIC5205 on the ProMini is rated to 12v input but that comes at the cost of another 0.05mA sleep current which would burn away the benefit of that extra cell fairly quickly.

Addendum 2016-10-27:

EEVblog #140 – Battery Capacity Tutorial
EEVblog #772 – How To Calculate Wasted Battery Capacity

That last one makes me  less concerned about the LDO regulators relatively high 3.5v cutoff when using 3xAA’s, but even more concerned about the curves that show a 100mv pulse discharge drop during SD writing. If those events trigger the low voltage shutdown too early that would loose a significant percentage of the overall battery capacity.  Perhaps the best solution would be to switch to the MCP1703 regulator which accepts up to 16 V, then I could use 4xAA batteries and avoid that diode loss problem. It is available with 3.3V output (MCP1703-3302E  & the SOT23-3 boards to mount them)  although some people have had problems with the 1703 in low power applications. Having the extra input voltage space would let me try putting 3.6v lithium cells in series, which you can buy in “D” size with a whopping 19Ah. Of course with  lithium discharge curves being so flat, I might get away without the regulator at all: I just don’t know how sensitive the SD card would be to that drop at the end, and it’s not worth risking data to find out…

Addendum 2017-02-23:

I finally started tracking down those SD card wear-leveling events with my Uno-scope. It’s hard to catch ’em because they don’t get triggered very often, but after setting a unit to constantly loop through a repeated sequence of short data saving events I managed to snag one:

This is just a brief one, but perhaps others last long enough to cause one of those dips in the voltage log?  I read the battery voltage before and after the data saving, so if the SD card does that kind of housekeeping after the file close event is complete, then SDfat has released the code block and I could be doing that second battery read while the SDcard has the current drain at up near 60 mA or more…