Is there a safe "latchable" way to cut power to SD cards on a data logger?

That's very good news! My data is not at as much risk as I thought it might be.

BTW I found areference to the 250 uA sleep current on the Sandisk cards: pg 16 http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Components/General/SDSpec.pdf

If you were seeing sleep currents as low as 70uA, then perhaps I am making a mistake using the older smaller cards, which I had assumed used less energy. . Even if I don't need the space for data, going from 250 down to 70 would be a substantial savings for a logger application.

And in another thread, you mention grounding unused lines (rather than pulling them up as the spec sheet suggests), and hinted that perhaps that is what lowered the sleep currents.

Can I ask you exactly which ones those grounded lines were?
(using the 1-9 number convention used in this diagram from the Sandisk spec sheet - attached)

I would like to try this on my logger to see if the extra grounding brings the sleep currents down below the 250 uA I usually see.

BTW I found areference to the 250 uA sleep current on the Sandisk cards: pg 16 http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Components/General/SDSpec.pdf

This document is from 2004, ten years ago, and totally out of date. Billions of SD cards have been produced since then and they have improved a great deal.

I too was using old cards thinking they might be better for power since old cards have less performance.

I bought about 15 new cards, mostly mircoSDHC, and did a lot of tests. The new microSDHC cards are excellent for performance and power usage. Most cards are now microSDHC and are used in phones, tablets and other small battery powered devices that produce or consume video.

And in another thread, you mention grounding unused lines (rather than pulling them up as the spec sheet suggests), and hinted that perhaps that is what lowered the sleep currents.

I think pullups on the two data pins that are not used for SPI is best since that is what the standard says. I get low power use either way. I was speculating that cards go into very low power mode either way but floating pins could cause a problem since noise might wake the card. I have not done tests to verify this.

One more note about using the new microSDHC cards on microcontrollers. I have been able to get both read and write speeds over 20 MB/sec on the STM32 micro's 4-bit SDIO bus with better quality cards using a new library I am developing. These cards can do 80-90 MB/sec on a PC with a USB 3.0 adapter.

At this point I have a fair number of 64, 128 & 256mb sd cards around for my logger project (plus a few 1 & 2gb cards). All are Sandisk labeled, and I tested them with pullups & with pulldown (I used a 20K ohm resistor) just to see what they would do. I have gone through about 50-60 of them with this test.

I have found that some cards draw a low sleep current in my ProMini based logger (usually around 0.33 mA combined vreg & sd card current) even if I leave connections 8&9 floating. However as you suggested, several microSD cards want a pullup OR a pulldown resistor on the two data pins I was not using, without which the sleep currents were much higher than they need to be (some as high as 5 mA) .

But the general result of my trials is: If my logger+Sd card sleeps around 0.3mA with the pins floating, about 50% of the time it increased its sleep current with a pull down resistor, possibly as high as 0.9 mA (the other half of the time the puldown does not increase the sleep current). Most of those cards that started with the lowest sleep current, stay low with a pullUP resistor on lines 8&9, but it does not reduce their sleep current.

If my system draws between 0.5 mA to 2mA with the two pins floating…then a pull down resistor on those two lines will usually brings the whole system down to 0.33 mA sleeping current, while a pullup does not change the sleeping current quite as much (although pullup still reduces it by about 1/3-1/2 as much as a pull down) So preventing the pins from floating is always good to reduce sleep current, but the worse a card is when pins 8&9 are floating, the more likely it is that pulldown will help more than a pullup on those lines.

If I don’t get to near 0.33 mA sleeping with either a pullup or a pull down on the unused lines, then I am calling it a bad microSD card, and wont use it. If my “sleeping system” current for the whole logger is above 2 mA to start with, then I am assuming I have a REALLY bad counterfeit microSD card, and I just throw it in the rubbish bin.

And the WORST cards of all bounce down to a reasonably low sleep current when the system first goes to sleep, and then “creep” upwards over the course of 2-5 minutes, as I am watching the meter, even though the logger is completely asleep. Those cards seem to “creep up”, whether I put a pullup, or a pulldown, on the unused lines. What’s interesting is that they don’t “jump up” like I would expect if they were waking …they just slowly increase the current draw bit by bit. Of course I am watching this with a plain old multimeter, so I am only seeing “the average” go up. Perhaps its a whole bunch of wake/sleep cycles in some kind of self triggering loop?

And when I look at more recent data sheets for larger capacity cards:

They list even higher sleep currents: 350 uA in this 2012 Sandisk example.

Your datasheet values are for SDIO mode with a 25 MHz clock.

However, in order to achieve the lowest sleep current, the host needs to shut down its clock to the card.

The above is from your datasheet.

In SPI mode with no clock you can achieve very low sleep current.

I did these tests with a Teensy 3.1. It has a 3.3 V regulator and I measured 3.2766 V with a Fluke 287 meter.

These are standard size SanDisk cards with unused pins high through 10K resistors.

I started with an old SanDisk 1 GB card. I ran the the SdFat SdInfo sketch and measured current to the SD with the Fluke.

Manufacturer ID: 0X3 OEM ID: SD Product: SD01G Version: 8.0 Serial number: 0XFB5C4F70 Manufacturing date: 12/2006

cardSize: 1015.81 MB (MB = 1,000,000 bytes) flashEraseSize: 32 blocks eraseSingleBlock: true

The current after inserting the card was 66.1 micro-amps. After running SdInfo 65.8 micro-amps.

A newer SanDisk 4 GB class 4 SDHC card.

Manufacturer ID: 0X3 OEM ID: SD Product: SU04G Version: 8.0 Serial number: 0X3F6E5C18 Manufacturing date: 6/2012

cardSize: 3965.19 MB (MB = 1,000,000 bytes) flashEraseSize: 128 blocks eraseSingleBlock: true

Before init 77.9 micro-amps and after SdInfo 69.9 micro-amps.

Here is a SandDisk 4 GB class 4 card with higher current.

Manufacturer ID: 0X3 OEM ID: SD Product: SU04G Version: 8.0 Serial number: 0X4E728B0 Manufacturing date: 10/2013

cardSize: 3965.19 MB (MB = 1,000,000 bytes) flashEraseSize: 128 blocks eraseSingleBlock: true

Before 104.6 micro-amps after 108.4 micro-amps.

Here is a high end Samsung Pro 16 GB microSDHC www.amazon.com/Samsung-Electronics-Adapter-MB-MG32DA-AM/dp/B00IVPU894

Manufacturer ID: 0X1B OEM ID: SM Product: 00000 Version: 1.0 Serial number: 0X9B541463 Manufacturing date: 3/2014

cardSize: 16003.89 MB (MB = 1,000,000 bytes) flashEraseSize: 128 blocks eraseSingleBlock: true

before 92.3 after 89.8

Well I clearly still have more things to figure out before I get to results like that.

Since I have the sd card connected right to the pins (& using SdFat.h) http://edwardmallon.wordpress.com/2014/07/01/a-10-diy-data-logger-is-born/ I presume I that this applies: "The only time SPI clock is active with these libraries is during an actual data transfer. In your case it will be rare for SPI clock to be active."

OR

Are there more steps I need to take to completely shut down the clock line signal? If that is the case I would very much appreciate any hints you could pass on there, since your comment about the floating pins really helped alot. Should I put a 50K pulldown on the clock line to make sure it goes quiet when the sd card is supposed to be sleeping?

For all I know I might already be in the target zone. I am only monitoring the combined current draw from the sleeping Arduino & SD cards at the battery to come up with my 0.33 mA sleep current target. My units are all hard soldered together, so I will have to breadboard one together so I can tap the SD card power line alone. I had been assuming that 200 µA of that was the sd card, plus about 100 µA ground pin current on the MIC5205 (http://www.micrel.com/_PDF/mic5205.pdf) and 40 µA for the ADXL345 I have running as a sensor on my test system (powersave mode, 25hz) . But that is all just assumptions based on datasheets rather than actual measurements.

I am still curious about why my "high current" cards were brought to lower sleep currents with the unused pins pulled down, rather than up. Because I am using such small cards, I probably have alot of fake ones (though they all bear the Sandisk label) so perhaps this is an artifact of non standard manufacturing.

Because I am using such small cards

The sleep current depend only on the card controller, not the flash chips.

The only time SPI clock is active with these libraries is during an actual data transfer. In your case it will be rare for SPI clock to be active."

This is correct.

I did an experiment on a breadboard with the old 1 GB SanDisk card with nothing connected to the SD. I found that if any data pin is floating except CS (see below) you may get higher current. I used a 3.3V breadboard power supply.

With six 10K pullups on CLK, CS, and the four data pins I get 67 micro-amps. This is total current to the SD including pullups.

The SD standard suggests 10K-100K pullups.

D3/CS has an internal pullup and I don't disable it. I found that I don't need a pullup on this pin to get low current.

I put together a low power test system with an SparkFun 8 Mhz pro mini and a SanDisk SD card. It sleeps with 92 micro-amps from the batteries.

I cut the solder bridge on the pro mini to disable the power led and regulator. I used a Microchip MCP1700 low quiescent current LDO 3.3V regulator. I connected 3 AA batteries to the MCP1700.

The current into the regulator was 92 micro-amps after the SD was initialized and the pro mini was sleeping.

Edit:
I added 10K pullups to CS, MOSI, and MISO in addition to the pullups on the unused data pins. CS should not need a pullup but the internal pullup is very weak and appears susceptible to noise. This reduces the sleep current for many cards.

Some SanDisk cards now allow a total system sleep current as low as 64 micro-amps.

That’s brilliant!

And it means that there are still huge advances to be made with my little logger builds (attached). I have been using the Rocket Scream ultra boards, and powering everything through its on-board MCP1700, but with the Pololu latching power switch (which adds 0.22-0.24mA), DS3231rtc, AT24c32, ADXL345 & SDcard all hanging on, I only get down to 0.54 mA even if I pull up those lines on the SD card. I’ve been using muve music uSD cards, as they seem like the only way to be sure I get authentic Sandisk on eBay.

When I have some more spare time, I will dig into the component level drains and post them. I suspect there are still much better uSD cards out there for me to find as well.

(P.S. - Yes, the high side of the voltage divider is in the wrong place in the photo. It is usually connected to Vin, but I was moving things around when I took this photo.)

TheDIYdatalogger_Breadboard.jpg

Well fat16lib, you were right…again…

I tested two breadboard models of my loggers to get a handle on the current drawn by each individual component:

The whole logger with a ProMini clone board drew a sleep current of 0.26 mA

with:
Adxl345 accelerometer (50 hz, power save mode) : 0.058 mA
Sandisk 256mb uSD card : 0.061 mA
DS3231 & AT24c32 eeprom combo with (4.7k pullups) : 0.089 mA

(*I tested a AT24c256 separately, and that eeprom draws about 0.03 mA when not being accessed)

This indicates that the ProMini clone mcu plus MIC5205 regulator needs 0.052mA when the unit is sleeping. I am guessing that about half of that due to losses on the regulator, since it’s still providing power to the above components.

I then swapped the MCU for a RocketScream Ultra board, and the logger drew 0.22 mA with the same SD card used above, indicating that its sleep current for the MCP1700 regulator & MCU is around 0.012 mA (sleeping powerdown mode for all tests using RocketScreams Low power library, ADC & BOD off: GitHub - rocketscream/Low-Power: Low Power Library for Arduino )

I then tested that Rocket ultra unit with the Pololu power switch, and sleep current went up to 0.53 mA with the Pololu power switch back in the circuit, indicating that the Pololu power switch is adding 0.32 mA to the sleep current for this design (even after I removed it’s power LED). Just to be sure about this I measured the current on the other side of the Pololu switch, and the logger unit was still drawing 0.22mA in total, so it was not noise, or some other weird side effect keeping the SD card from sleeping.

I have started looking at the DS3231. I am powering it with a digital pin and a battery. I found that the interrupt to wake the powered down Arduino works on battery power. I set the digital pin low and input mode before powering down.

Looks like the DS3231 only draws a about a mirco-amp from the battery. This is a real puzzle. Why such a huge difference?

I will do more tests after I update an old DS3231 library I wrote a few years ago. It needs some new features for alarms. I wrote the library to be able to synchronize the DS3231 with a GPS one second pulse. I wanted time accurate to a ms, the GSP pulse is good to the microsecond level.

GPS PPS signals have an accuracy ranging from 100 ns to a few microseconds per second..

I was quite surprised by the numbers for the RTC as well. But I am using a somewhat crude method to measure the currents so for all I know my little sparkfun meter is messing with the numbers a bit. Also, those cheap RTC boards are not exactly the highest quality, and I have always been a bit dubious whether or not they have genuine chips on them. So multiple factors could be at play. When I get the chance I will look at the chronodot in more detail, as I trust that to be authentic

But on first bounce, I wonder if it is a similar issue to the SD cards? where I have left some pins floating and that is causing excessive current? If your battery power results look simmilar to the coin cell draws, then I will go digging. If all it takes is a couple of pullups to save power I would be happy about that.

I knew about the register setting to force the alarms to continue on battery, but I did not know how long the little coin cell could sustain something like a 5 minute alarm schedule (a typical field logger setting), and I am running from AA’s most of the time, so I am not operating down in micro power territory.

I knew about the register setting to force the alarms to continue on battery, but I did not know how long the little coin cell could sustain something like a 5 minute alarm schedule (a typical field logger setting), and I am running from AA's most of the time, so I am not operating down in micro power territory.

I don't enable the 32kHz output with battery power. The same settings work for alarms with power from battery or VCC. I powered the DS3231 with only power on the battery pin and measured the current with a very high end DMM. The current is less than a micro-amp while waiting for an alarm.. There is a larger current draw when temperature adjustments are done about once a minute. The datasheet specifies that the average battery current is less than 3.0 mico-amps. A CR2032 is good for about 200 mAh. You can draw 3 micro-amps for about seven years.

Accessing the DS3231 with I2C does result in a large current on battery but I2C is not active while waiting for an interrupt.

I just don't understand the difference in current between waiting for an interrupt on battery power, less than 3.0 micro-amps, and with vcc, about 80 micro-amps. Using vcc takes about 30 times as much current. Maybe I2C is always active with VCC. The datasheet says I2C is not active on battery if SDA and SCL are both at zero volts or both are at Vbat volts.

I have put together a low power logger with a Pro Mini, DS3231, and SD that only draws 68 micro-amps while sleeping.

I connected the DS3231 battery pin to 3.3V and left the DS3231 Vcc pin floating. The alarm interrupt works fine.

I wrote this file using the DS3231 to wake every 10 seconds. The total current into the 3.3 V regulator for the Pro Mini, SD card and DS3231 was about 68 micro-amps during the 10 second sleep periods.

2014-10-11 02:28:24
2014-10-11 02:28:34
2014-10-11 02:28:44
2014-10-11 02:28:54
2014-10-11 02:29:04
2014-10-11 02:29:14
2014-10-11 02:29:24
2014-10-11 02:29:34
2014-10-11 02:29:44
2014-10-11 02:29:54
2014-10-11 02:30:04
2014-10-11 02:30:14
2014-10-11 02:30:24
2014-10-11 02:30:34
2014-10-11 02:30:44
2014-10-11 02:30:54
2014-10-11 02:31:04
2014-10-11 02:31:14
2014-10-11 02:31:24
2014-10-11 02:31:34
2014-10-11 02:31:44

Here is the test program:

#include <Wire.h>
#include <DsRtc.h>
#include <SdFat.h>
#include <LowPower.h>
SdFat sd;
SdFile file;
DsRtc rtc;
time_t t;
//------------------------------------------------------------------------------
void rtcInterrupt() {
 detachInterrupt(0);
}
//------------------------------------------------------------------------------
void sleepUntil(time_t t) {
  if (!rtc.setAlarm1(t) ||
      !rtc.modify(DS3231_CONTROL_ADDRESS, 0XFF, 
                  DS3231_CONTROL_INTCN | DS3231_CONTROL_A1IE) ||
      !rtc.modify(DS3231_CONTROL_STATUS_ADDRESS,
                  DS3231_CONTROL_STATUS_A1F, 0)) {
    while(1);
  }
  attachInterrupt(0, rtcInterrupt, FALLING);
  LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF); 
}
//------------------------------------------------------------------------------
void setup() {
  if (!sd.begin(SS) || !file.open("LOWPWR.TXT", O_RDWR | O_CREAT)){
    while(1) {}
  }
  Wire.begin();
  t = rtc.getTime();
  pinMode(2, INPUT);
  digitalWrite(2, 0);
}
//------------------------------------------------------------------------------
void loop() {
  t += 10;
  sleepUntil(t);
  rtc.printDateTime(&file);
  file.println();
  file.sync();  
}

I tried shutting down 32khz via the register, and it did not change the sleep current, nor did putting a pullup on 32khz line. Just thought that might have been a possible source of current drain.

From the datasheet:

"There are several modes of operation that affect the amount of VBAT current that is drawn. While the device is powered by VBAT and the serial interface is active, active battery current, IBATA (70μA at 3.3v - pg3 of datasheet), is drawn.

When the serial interface is inactive, timekeeping current IBATT (3.0μA at 3.3v), which includes the averaged temperature conversion current, IBATTC, is used.

Temperature conversion current, IBATTC (575μA at 3.3v), is specified since the system must be able to support the periodic higher current pulse and still maintain a valid voltage level. (refer to Application Note 3644: Power Considerations for Accurate Real-Time Clocks for details - for details on extending the time between temperature conversions to save power)."

If I assume that the eeprom is drawing 20μA, then 70μA for the rtc in active mode would explain my high current draw. But the mcu is sleeping in power down mode, so I have to find out why the clock thinks that I2C is still active while the units are sleeping. I did not find anything about I2C being forced active on Vcc in the data sheet…but I think your suggestion is a real possibility.

Or perhaps my ADXL or Eeprom is sending things along the I2C line, even when the mcu is asleep? and this keeps telling the rtc that the serial interface has to stay active?

Because of the way these boards are soldered, I would have to clip a pin on the IC to force the RTC to run on Vbat because I am using the vcc line as a pass through to power the other I2c devices. Will try that experiment and report back later.

Yep, if I simply cut the Vcc line to the RTC forcing it to run on Vbat , the logger draws 70uA less during sleep, but alarm functions and I2C comms still seem to be working.

So the question is, can I do this same thing less dramatically in software…

I connected Vcc to an Arduino pin and set that pin low during sleep. That way I can use a battery on Vbat. The DS3231 only draws high current, 78 μA, while the Arduino is awake.

I tried shutting down 32khz via the register, and it did not change the sleep current, nor did putting a pullup on 32khz line. Just thought that might have been a possible source of current drain.

I checked and the 32kHz doesn’t change the DS3231 battery current.

When the serial interface is inactive, timekeeping current IBATT (3.0μA at 3.3v), which includes the averaged temperature conversion current, IBATTC, is used.

My DS3231 is on a ChronDot board. It draws 0.85 μA except for the Temperature Conversion Current. I see the Temperature Conversion Current but can’t measure it since it is for a very short time period once every 64 seconds.

The datasheet claims the Temperature Conversion Time is typically 125 ms and draws 575 μA

The average Temperature Conversion Current is (0.125*575)/64 = 1.12 μA so my average DS3231 current is about 2 μA while sleeping.

If I power the DS3231 on Vcc while sleeping, it draws 78.8 μA.

This is my low power test program. I logs the date, time and one analog pin. It still draws 68 μA while sleeping.

#include <Wire.h>
#include <DsRtc.h>
#include <SdFat.h>
#include <LowPower.h>
//
// SD card chip select pin.
const uint8_t SD_CS_PIN = 10;
//
// RTC INT/SQW pin.
const uint8_t RTC_INT_PIN = 2;
//
// RTC primary power pin.
const uint8_t RTC_VCC_PIN = 3;

SdFat sd;

SdFile file;

DsRtc rtc;

// Time to wake from sleep.
time_t t;
//------------------------------------------------------------------------------
#define SERIAL_DEBUG 0
#if SERIAL_DEBUG
#define dbgMsg(msg) {Serial.println(msg); Serial.flush();}
#define error(msg) {Serial.print(msg); while(1);}
#else
#define dbgMsg(msg)
#define error(msg) while(1)
#endif
//------------------------------------------------------------------------------
void rtcInterrupt() {
 detachInterrupt(0);
}
//------------------------------------------------------------------------------
void sleepUntil(time_t t) {
  uint8_t r[2];
  
  // Enable interrupt for alarm one.
  r[0] = DS3231_CONTROL_INTCN | DS3231_CONTROL_A1IE;
  
  // Clear status bits and disable 32 kHz output.
  r[1] = 0;
  if (!rtc.setAlarm1(t) || !rtc.write(DS3231_CONTROL_ADDRESS, r, 2)) {
    error("sleepUntil");
  }
  // RTC to low power battery mode.
  digitalWrite(RTC_VCC_PIN, LOW);
  
  attachInterrupt(0, rtcInterrupt, FALLING);
  LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
  digitalWrite(RTC_VCC_PIN, HIGH);
}
//------------------------------------------------------------------------------
void setup() {
#if SERIAL_DEBUG
  Serial.begin(9600);
#endif

  // Power RTC with digital pin while not sleeping.
  pinMode(RTC_VCC_PIN, OUTPUT);
  digitalWrite(RTC_VCC_PIN, HIGH);
  
  if (!sd.begin(SS) || !file.open("LOWPWR.TXT", O_RDWR | O_CREAT | O_TRUNC)){
    error("SD setup");
  }
  Wire.begin();
  t = rtc.getTime();
  // should check for error
}
//------------------------------------------------------------------------------
void loop() {
  dbgMsg("loop");
  t += 10;
  sleepUntil(t);
  rtc.printDateTime(&file);
  file.write(',');
  file.println(analogRead(1));
  file.sync();  
}

Nick Gammon gives an example of powering a 1307 from a pin at:
Gammon Forum : Electronics : Microprocessors : Power saving techniques for microprocessors (about 1/2 way down)

But he uses a decoupling capacitor and a limit resistor. Did you get stable operation without those?

I will have to check on my battery current when the power pin is low. I still have an I2C accelerometer running even when the logger is asleep (providing interrupts), and am wondering if that would be generating enough noise to make the RTC think it still has to keep the I2C interface active this might mean that the battery is providing 70uA, instead of the <3uA when Vcc is low

And

Since my loggers are in caves, and the temperature does not change very quickly in that environment, I am setting the temp conversion time to 512sec as per application note 3644

i2c_writeRegBits(DS3231_ADDRESS,DS3231_STATUS_REG,1,Bit4_MASK);
i2c_writeRegBits(DS3231_ADDRESS,DS3231_STATUS_REG,1,Bit5_MASK);

But he uses a decoupling capacitor and a limit resistor. Did you get stable operation without those?

I get stable operation. I have not had a problem with noise. But the datasheet says you should use a 0.1μF to 1.0μF decoupling cap.

I am setting the temp conversion time to 512sec as per application note 3644

I thought only the DS3232/DS3234 allowed setting the "Temperature Update Time".

The app note is not very clear. It states:

The DS3232/DS3234 provide a bit field in a user-programmable register that allows the time between temperature updates to be increased, thus reducing the average current requirement. Both devices provide the C_Rate bit field in the Control/Status Register, which provides four different periods between temperature updates. This register is detailed in Table 1.

My Rev 9; 1/13 version of the DS3231 datasheet just shows zeros for the C_Rate field.