Bench-top Power Test Results : May – June 2014

The part swaps in March left me with a complete “spare” pendulum unit to bring back home. This has proved quite handy to explain the design to people, but I was keen to do a complete power test with the build, as I had set one of the pendulums in the cave to a short 5 minute sample interval, not knowing if it would go the distance.

Until I get my hands on an EEVblog uCurrent (or perhaps a Fried Circuits USB tester..?), there is only one way for me to determine power usage of the whole system, and that’s simply to plug one in and let it run. So on April 23rd,  I set the spare unit up on a bookshelf with 3 AA alkaline batteries, and a sample interval of 1 minute (to give the batteries a recovery period). Since then this test has been interrupted a few times due to random bumps during show and tell sessions. The gap around 20 000 samples was interesting in that the RTC alarm signal kept working, but the unit stopped recording the date/time data when an I2C wire was broken during handling. The Tinycircuits compass board level shifters kept the unit running, despite the loss of the other I2C lines, until I noticed the break and repaired it.

20140609_DryPowerConsumptionTest_graph

Vertical grey lines ~ 2000 records:  approximating one month of samples at 15 minute interval.

These results are as good as I could have hoped for: >61 000 records recorded on the SD card, with the power supply falling from 4380mV down to 3750mV (read with the internal Vcc reading trick, after the shottky diodes on the power module). That’s around 22 months of operation if we were capturing data every 15 minutes, and the units currently installed in the caves have twice as many batteries in them. Even better, this test is still comfortably on the alkaline battery power plateau –  nowhere near the 2800 mV cutoff I set in the code to protect against unsafe SD card writing. I intend to let this test run to completion to see how gracefully the unregulated unit handles the eventual loss of power.  Since I have a 3v button cell backing up the DS3231 RTC, my guess is that once the main power supply falls below that point, the RTC will sleep, and stop sending the wakeup alarm to the logging platform. This would be a fairly graceful fail if it happens that way, but the data could get choppy for a while as Vcc wobbles by 50-80 mV from one reading to the next in the current record. I will just have to see how it goes as I still have quite a few component changes to work through before I start counting chickens. My plan is for the next round of deployments to compare data from several different sensors measuring the same parameter in the same unit.  So there will be a one-of build with three temperature sensors, or three accelerometers, etc., making good use of the excess power available at this stage.

Addendum 2014-06-12

I just reviewed the DS3231 data sheet again, and the DS3231 is designed to keep running from Vcc well after the main supply falls below the voltage of the rtc backup battery.  The actual “Power-Fail” voltage”, where a low VCC stops the SQW alarm,  doesn’t kick in until somewhere between 2.45v min – 2.7v max. All below the 2.8 volts minimum for safe SD card writing. So it looks like the system clock wont give me a graceful power out behavior unless I somehow lower the RTC’s input voltage below the rest of the system ( by .2 to .3v …perhaps with a Shottky diode?). Interestingly, you can go the other way if you need to: Bit 6 (BBSQW) of the DS3231’s control register 0Eh, can be set to 1 to force the wakeup alarms to continue when running the RTC from the back up battery alone. Not useful here but perhaps on another project. 

Addendum 2014-06-12

 The power drain test with this unit was finally completed on Aug 06, 2014, recording 390000 records with 3 alkaline AA batteries.

Addendum 2014-09-21

The real world results were dramatically different from this bench testing, due to excessive sleep current being drawn by counterfeit SD cards in the deployed units.