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

I am working on a simple data logger that connects the SD card shield directly to the pins of a ProMini/RocketUltra/Clone board: http://edwardmallon.wordpress.com/2014/07/01/a-10-diy-data-logger-is-born/

So far they are working really well, but the big weakness of the system is what happens when the battery voltage falls below the 3.4 v needed by the voltage regulators. Usually the system goes into a kind of loop, constantly restarting due to "draw down - brown out - battery rebound - restart". These units are already monitoring the power supply voltage via a divider, but I need to add some way of having the logger completely disconnect itself from the power supply when it falls low, but I would like that to be controlled by the Arduino rather than by passive components.

The reason I want the Arduino to control the shutdown is that the new file creation event on the SD cards is the single biggest sustained load and I am afraid that a passive component system would see the voltage drop from that, and pull the power just when the SD card is in the middle of a write process, effectively nuking the card, and all the data on it. If the Arduino handles the decision to power down, then it can wait till all the SD card operations are safely complete. Once the shut down occurs, I don't want the arduino waking up again until there has been a full disconnect (ie new batteries are put in) because I am sure there will be voltage rebound on the power supply after the disconnect happens.

I have found this: http://www.pololu.com/product/751

But I wondered if there were any suggestions for something simpler? I am hoping for an approach that is as minimal as the rest of the logger design.

I use a button connected to a pin. In setup() put the button pin in input pullup mode and halt if the pin is high. If the button is low log data. When you are ready to start the logger, press the button and then hit reset.

I disable pullup mode in setup. I don't know if this save battery, probably is not necessary.

I like the simplicity of this technique to ensure that the system only starts when you want it to start. Since I have a voltage divider monitoring the battery voltage, I have been using a voltage check in setup to do the same thing as your pin check. But I am still left wondering what happens to the sd card with a series of quick power up & down cycles, no matter how they get intercepted. I would rather just pull the plug once.

But I am still left wondering what happens to the sd card with a series of quick power up & down cycles, no matter how they get intercepted. I would rather just pull the plug once.

It only takes one low power write to the directory or FAT to trash the SD. A single block junk write to the directory will take out up to 16 files. There are redundant FATs but this doesn't always work. Each FAT block represents 256 clusters for FAT16 and 128 clusters for FAT32. After a series bad writes you may lose the entire SD.

There is never a series of quick power cycles with the button since the button pin reads high and you never init the SD.

I tried voltage methods and batteries do go through a phase where SD init or write current causes crashes and restarts.

If you want to insure data integrity, Enable CRC. SdFat has an option to calculate the 16-bit CRC used by SD cards. SD fat verifies the CRC on read and the SD returns a write error if it sees a bad CRC. This should minimize damage. SD commands are protected by an 8-bit CRC so you may never get to data transfers or even init the SD.

To enable CRC, edit SdFatConfig.h at about line 59.

/**
 * To enable SD card CRC checking set USE_SD_CRC nonzero.
 *
 * Set USE_SD_CRC to 1 to use a smaller slower CRC-CCITT function.
 *
 * Set USE_SD_CRC to 2 to used a larger faster table driven CRC-CCITT function.
 */
#define USE_SD_CRC 0

I did not know about enhanced CRC support for Sd card writing… will check that out.

I had heard that simply letting the power to an SD card brown out “slowly”, as a fading battery pack would do, was enough to kill a card, even if you did not init the card, or write to it in any way. This is what would happen in a long term logger deployment - even if I intercept the inits with a pin check.

And eventually the BOD on the atmel is going to kick in if the batteries keep draining… and I have no idea what is getting sent along the SD com line pins when that happens or how robust SD cards are to accidental signals.

I had heard that simply letting the power to an SD card brown out "slowly", as a fading battery pack would do, was enough to kill a card, even if you did not init the card, or write to it in any way.

Where did you hear that cards can be corrupted when low voltage is applied to a card that is not initialized?

SD cards have a very safe power up and initialization sequence.

Card operate correctly at very low voltages. The big problem is data errors on the SPI bus at low voltage.

The only way a card can be corrupted by internal operations is if power fails during a write while flash is being programed.

Cards are designed to not become corrupt if power fails while they are idle. There are a lot of battery powered devices using SD cards.

Be sure to use a good genuine SanDisk card. SanDisk cards will work correctly for power up and card identification at under 2.0 V and data write at under 2.5 V.

You should not have a problem if you stop writing to the SD while there is still adequate voltage. Just don't trust the batteries when they rebound since they won't supply enough current to program flash.

Edit: Some cards like Panasonic Gold even have Power Failure Guard so data written during a power failure is either the original data or the new correct data with no corruption.

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.