Public Lab Research note


*FIXED* Riffle SD card Power Consumption

by kinasmith | June 14, 2016 00:17 14 Jun 00:17 | #13195 | #13195

After some sleuthing, I figured out the culprit for why the Riffle was consuming so much power, as detailed in this Research Note.

Bugs!!

Turns out there is a bug in the SD Card Library included with the Arduino IDE that doesn't let the SD Card sleep.

I found this thread in the Arduino Forums, which says this about the SD Library included with the Arduino IDE.

SD.h has not added bug fixes from SdFat for about three years and the Adruino developers have added their own bugs. I tried SD.h with my tests and found cards pulled from 15 to 28 ma when idle.

That was posted 3 years ago, and is about what I was experiencing with the Riffle.

As suggested in the thread, I switched over to using the sdFat Library and the sleeping current consumption dropped to about to 0.5mA, which is what the literature suggests. The Riffle sleeping consumes about 300µA, and the SD card consumes about 200µA.

I also discovered the Open Source Building Science Sensors project. They are using the sdFat Library to successfully and stably power cycle the SD card itself.

I was successfully able to power cycle the SD Card using the MOSFET switch included on the board. Not sure if it really makes much of a difference power wise....but it seems pretty stable over the last hour at a logging interval of 15 seconds.

Updated code is in the Github Repo.

Currently, the sleeping current is 0.487mA, which is a theoretical battery life of about 3-4 months depending on logging interval.

Better than 9 days!


4 Comments

Great discovery. @donblair will be pleased.

Reply to this comment...


great work!

Reply to this comment...


Bravo!! This is amazing.

This makes me wonder what accounts for the rest of that quiescent current draw ... maybe the majority of it is due to the RTC itself?

I've also heard some strange tales of current leaks on the SPI bus ... I wonder if setting the internal pullups on the MISO, MOSI, SCK lines during sleep mode would drop the power draw a bit?

Anyway -- fantastic, game-changing work accomplished, here. Reducing the power consumption by a factor of 10, using only code, is kind of a big deal! :)

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


I have posted most of the low power techniques I am using at: https://edwardmallon.wordpress.com/2015/11/05/a-diy-arduino-data-logger-build-instructions-part-4-power-optimization/

Forcing the DS3231 to run off of the backup coin cell saves almost 0.1mA and my best guess at this point is that a CR2032 should be able to handle the drain for about four years of operation before it needs to be replaced. Putting the internal pullups on the SPI bus lines seems to help some cards, and not others, but when it does help it makes a huge difference in how fast the SD card goes to sleep.

Depending on the number of sensors I usually buffer up to five days worth of data to those little I2C eeproms, and that makes a big difference because its not just the individual write events that use power. Once you pass a certain threshold some sort of internal routine seems to be triggered and the SD card goes into house keeping modes that can hold the whole logger hostage for up to half a second of latency while it does its thing. I track my battery voltages, and these really show up in the record as hits to the power supply but I don't have an oscilloscope to look at those events in detail, and even if I did it would take some luck to catch them.

Btw, I've had a mutual discussing threads at the Arduino playground with the fellow who wrote SdFat, and he does not recommend de-powering the SDcards. However the folks over at OSBSS seem to have been doing it with no problems so perhaps there is something different about the newer sd cards that makes them more robust? Would love to hear how the depowering works out for you guys if you try it.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


Login to comment.