Early Open Wave Height Logger battery tests

The Open Wave Height Logger prototype stack.
The Open Wave Height Logger prototype stack.

Following on the previous post about the Open Wave Height Logger project, I’ve been conducting a simple battery life test. One of the prototype OWHLs was powered by a 3 D-cell alkaline battery pack and shoved in the freezer for 32 days. The image below shows the collated daily data files for that time period, during which the data logger was sampling 4 times per second continuously. The black line is pressure in millibar, and the blue line is temperature converted into Fahrenheit (why? Because America, that’s why). The spikes in the blue temperature trace are due to the defrost cycle in the frostless freezer.

Pressure record from the OWHL sitting in a lab freezer recording at 4Hz for 32 days on battery power (10.7 million records). The blue line is temperature in Fahrenheit.
Pressure record from the OWHL sitting in a lab freezer recording at 4Hz for 32 days on battery power (10.7 million records). The blue line is temperature in Fahrenheit.

Over the 32 days, the battery voltage dropped to around 3.5V, which is close to the dropout voltage of the 3.3V voltage regulator in the prototype. For the time being I’m going to continue running the batteries below that voltage to see how the OWHL responds when the voltage regulator is dropping out. The AVR running the whole operation is set to go into permanent brown-out mode at 2.7V. The next round of prototypes is going to use a 3.0V regulator since all of the peripherals (SD card and MS5803) and the AVR should happily run at 3.0 volts.

Battery usage of the OWHL sitting in a lab freezer for 32 days. Powered by 3 fresh D-cell batteries.
Battery usage of the OWHL sitting in a lab freezer for 32 days. Powered by 3 fresh D-cell batteries.

Update 2014-11-11: After this initial battery test, I subsequently discovered that the old micro SD cards I was using (circa 2008) were particularly bad on power usage. After a write cycle that lasted approximately 40ms, they would proceed to suck down 30mA for around 300ms before going to “sleep” and letting the overall current usage drop to around 1mA. This destroyed my power usage, since the whole device was pulling 30mA for far longer than I had originally observed or accounted for. I believe I was using a modern card in my original current draw tests and when observing things on the oscilloscope, but then switched to an old card for the battery test above. I have since purchased several 8GB SanDisk class 4 cards produced in 2014 that are much better about going into a low power state immediately after a read/write operation.

In addition, I finally took the advice to not use the sync() and close() functions of the SDfat library after every write operation to the micro SD card. Those operations were extending the ~40ms write cycle to ~60ms, once per second. Removing them, and letting the card’s internal controller decide when it needs to do a full read-erase-write cycle on a block of memory allows for quicker write operations. The downside is that if you eject the card without shutting down, or lose power unexpectedly, there is the possibility of losing a few seconds worth of data since the last time the card flushed itself. I’ve decided that the possibility of losing those few seconds of data is meaningless in the context of this project, particularly at the expense of thousands upon thousands of write cycles that are 1/3 longer than they need to be, which increases power draw.

New battery tests have now begun with the new SD cards and revised software. See this post for the new version.