SD card current consumption

[Simon]

I need to log data to an SD card. But I can't stop the user pulling power before stopping the logging so the card could become corrupt. I will have to hold onto power for long enough to write the last batch of data and close the file off. Let's say 1s of power. Turns out I need up to 150mA, just for the card!

OK so I ran my trial with an arduino MKR zero, I was astounded at the 150+mA consumption so too the card out and now 23mA was used. I see it peak at 170mA so the safe assumption is 150mA for the SD card only. It's a kingston apparently. Isn't this a bit much power? looking around I see power draws quoted of about 30mA.

[David Hess]

Writing to Flash memory is power intensive.

[Simon]

Yea, especially when it is broke!  . I put other cards in and got 40-50mA total. I think I will not use a memory card. It is to be buried in the machine and cannot be retrieved. If it breaks or is corrupted the whole thing goes haywire. Considering I have 4 bytes of data to save each second I think an EEPROM may be better ani uses just a few mA and no file system to corrupt. The data is going to be read out rather than the file transmitted so no need for a file system or to store a lot of data as blanks that is there just for compatibility with something else. I can make all of that up on the fly as it is transmitted and only save what actually has a number to it.

[Manul]

SD cards are not all equal, as their performance too. Could be broken, could be not. Anyway, you can use SD card without file system too, not as easy, but very doable. Also, what you really should care is energy consumption, not the current consumption. So it depends on write speed too. EEPROM might very well be the best option here, but writting SD card could also be efficient if you have high speed SPI, because it will be fast and total energy used small (assuming low level write without file system overhead). Just ideas, I don't remember exact numbers off my head.

[Simon]

Given same voltage current is proportional to energy! the card is broken, windows will not open it! and the activity LED behaves differently with this card versus the other 2 that have the same LED pattern as each other and I can open the card on a computer. That card is definitely broken!

[Manul]

Given same voltage current is proportional to energy!

I was not talking about power, but energy, joules. It is power x time. For example, if same write takes 1ms at 330mW (3.3V * 100mA) it will be less energy used then 10ms write time at 100mW (3.3V * 30mA). So current consumption is not the whole story, speed is an important factor in the equation.

[Simon]

Are you trolling?

[Manul]

I'm not trolling. I really don't understand what is wrong with what I posted.

[Kleinstein]

With the relatively small data rate and thus likely a limited needed capacitoy a  EEPROM  or data-flash chip (e.g. at45... series) is likely the better solution. One has more control over the format and better defined performance.

With SD cards the normal performance may be OK, but there are rare cases the card has to do extra tasks. e.g. if the bock turns out to be bad.

[Simon]

I'm not trolling. I really don't understand what is wrong with what I posted.

I'm only asking about broad power consumption to expect. I have compared cards working at the same speeds and found differences. Current consumed is proportional to energy all other things being equal. I don't see your point. Yes if the card will draw about the same amount of power regardless of speed then the shorter the data transaction time the better but that is out the scope here and out of my control as it is an Arduino. It does what it does. If anything how much power/energy/current does it use if it works non stop, I can extrapolate from there!

[mikerj]

I'm not trolling. I really don't understand what is wrong with what I posted.

Don't worry, Simon quite often misunderstands stuff and gets irritable.  What you said is 100% correct, energy is the right parameter to consider when a time period is involved, such as completing a flash write when the supply is removed.

[Simon]

My point was how much current does it take to run the card, we measure current in mA, usually down to the s as that is the basis of the ISO system invented before a ms or µs were a concept or measurable. If a device to work consistently uses 5mA over an hour it will have used 5mAh, we usually state a current measurement with the assumption that using that amount of power over the period of one hour means that we use that same number in Ah, same for W and Wh. So given that I am not interested in looking at the time it takes to write to the card at the moment the question is how many mA does an SD card use, this is regardless of how long it is active for, how much I am writing and for how long. When I know the instantaneous current draw (over 1s) I can then start giving a hoot about the energy consumption per write. Asking how much energy is necessary does not really help anyone I have an entire circuit to run while the last write is made. I can at some point work out the time taken to write as much as is possible for an arduino based device. but to calculate the energy I still need to know the starting point which is how much power does the card use while active. When I know that and how long the card is active for I can worry about my energy storage needs.

[Simon]

As things stand I am looking at EEPROM unless there is another better choice out there? the task is to save some readings on a machine. A file system is not necessary and an SD card would be physically inaccessible so it is too risky to use given that I just need to save 4 bytes a second. All of the other information that was being saved is unnecessary as it is there for compatibility purposes only and can be made up on the fly during data transmission.

[mikeselectricstuff]

I'd look at SPI flash. You then have good control over exactly what happens when, and a choice of things like write page and erase block sizes.
Without measuring myself i'd anticipate that erasing takes more power than writing 4 bytes, and you could tolerate a power loss during erase.
Once erased you can write pages ( 256 bytes) at a time - providing enough power reserve to cover this is probably very practical.

You may also want to look at FRAM or battery-backed SRAM.
 

[Peabody]

It seems to me that FRAM would be ideal for something like this.  Each byte you send is written immediately instead of accumulating 256 bytes at a time, and the current requirements are very low.  But I don't see a lot of people using it.  Don't know if that impression is correct, or why it would be, except maybe it is just too expensive.  Anyway, Adafruit has a FRAM module that uses the MB85RC256V, which is 32KB.  That would be enough for a couple hours at 4 bytes per second.  You didn't say how much time you need to provide for, and I don't know how large FRAM chips get.  Of course the big advantage of an SD card is the virtually unlimited size, but you're stuck with the current spikes and writing at least 256-byte blocks.  Maybe serial battery-backed SRAM would be best so long as the battery isn't a deal breaker.  Something like the 23LCV1024 would give you 128KB at half the price of the smaller FRAM.

[Jeroen3]

That 32 kb sram sits around 3.5 USD per 1k while an eeprom of that size is 0.35 USD per 1k. I think that's a fair reason why not many people are using it.
But, if you need the "infinite" write cycles and wide temperature range, FRAM is for you.

[mariush]

You could just add a CR2032 battery as power backup. They should be able to handle 1-2s bursts of 40-50mA....
Think calendar/clock chips which keep time and have around 64 bytes of writable memory which use a battery to keep time and sram alive.

An alternative would be a small super capacitor, most cheap ones are rated for 2.5...2.7v max , but there's also 5.5v rated capacitors .. ex: https://www.digikey.com/en/products/detail/kemet/FYD0H104ZF/4290863

I think if you plan to write to a SD card, you would want to optimize your program to write in bursts, giving the controller an amount of bytes that would fill a write buffer or not cause pointless erases. Think 128 bytes / 256 bytes / 512 bytes ... just like some eeproms have 64 byte buffers and others have 128 byte buffers ... for example 128 kbit CAT24S128C4UTR (i2c eeprom) has 64 byte buffer ( see https://media.digikey.com/pdf/Data%20Sheets/ON%20Semiconductor%20PDFs/CAT24S128_Rev3_Nov2016.pdf )  and the 512 kbit version has a 128 byte buffer ( https://media.digikey.com/pdf/Data%20Sheets/ON%20Semiconductor%20PDFs/CAT24S128_Rev3_Nov2016.pdf )

Also note that the write current is only around 2.5 mA so you could basically just have a big capacitor (ex a 3300uF 6.3v electrolytic) and start dumping to eeprom as soon as power loss is detected.
 

[Simon]

My plan with an EEPROM would be to use capacitors as you say to hold up the power, on detection of power loss no more data is written but there is time to write one full set. The problem with an SD card is that I would be tied to an arduino design that right now I can't get the micro controller for so may as well just go my own way with a micro controller of my choice (the one I have stock of on the way) and use an EEPROM. I could look at SD cards later but I would need to deal with the file system first then the SD card protocol. Yes I could just use the SD card as raw memory as well but given the much greater power consumption on something with way more memory than i need I don't even see the point.

[Peabody]

I misspoke about the block size of an SD card.  It's 512 bytes, not 256.

Anyway, another consideration is how to keep track of where you are - where you last saved data - in the event of a power failure on the Arduino side.  If the data is preserved on the SD  or EEPROM or whatever, you can pick up where you left off when power comes back on, but only if you can find where you left off.

For an SD card with no file system, I guess you would do a binary search beginning at the middle sector of the card, looking for the last sector that doesn't begin with 0xFF (or 0, depending on the card).  But for each test sector you have to read in 512 bytes just to read the first byte (unless there's an abort command - I just don't remember).

With battery-backed RAM, you could just assign an address in RAM that contains the address, or at least the block, you last wrote to, and that would be updated after each data write.

But if you really need the large size of an SD card, you should consider writing directly to the sectors with no file system.  You can pre-erase the entire card, so writing would be fairly straightforward and pretty fast.  And I don't think it would necessarily be any less reliable than any other form of storage.  I wrote an SD card bootloader for MSP430 a while back, and the commands for reading from and writing to the card are not all that bad.  Most of the effort was dealing with FAT32.  But there's no getting away from the 512-byte block size.  So if someone pulls the plug before a block can be written, that data is gone unless you've provided for backup power for long enough to save it.

[Peabody]

Yes I could just use the SD card as raw memory as well but given the much greater power consumption on something with way more memory than i need I don't even see the point.

I don't think you've said how much memory you need.

[Simon]

The problem with an arduino is that it does not really do interrupts or at least I am not too willing to find out what I will break whilst trying. With my own code I can trigger an interrupt as soon as power goes. I have at least 12V supply 24V at the moment so with a switch mode regulator I can store the power at 24V which is more efficient and know I have enough to complete a last write to memory.

The problem with an SD card is that they are all the same as far as purchasing will be concerned. I have a failed Kingston card so it's not like you need to look far. I'd rather not have pissed off customers because I used totally the wrong tool for the job.

[Simon]

Yes I could just use the SD card as raw memory as well but given the much greater power consumption on something with way more memory than i need I don't even see the point.

I don't think you've said how much memory you need.

1MB would be nice, nothing stopping me using 2x 0.5MB chips as 0.5MB or 4Mb as they like to advertise memory arranged in 8 bits anyway are all I can see available right now.

[DrG]

FRAM has already been mentioned. Would also mention Microchip's EERAM http://ww1.microchip.com/downloads/en/DeviceDoc/20005371C.pdf

Not saying that it is suitable for your specific application, but worth a quick look. I have used these before and, to me, they were much easier and simpler to implement than the usual  circuitry to keep an EEPROM alive long enough. These use a single (and small) cap (ok, two if you include the normal bypass cap). They are I2C.

Basically your program writes to them as serial ram. When power is removed, they write their contents to their EEPROM on their own, which you can read as you like.

I had to 'invent' a method to detect whether a dataset had been written in its entirety or interrupted, but I think that you would need that with an EEPROM implementation as well.

Minimal endurance issues since their EEPROM as it only gets written to at power off.

Maybe worth a look ...

EDIT: after seeing your last post, these may not have the capacity that you want.

[mariush]

You may also want to consider how compressible is your data?
You could write up to some amount of bytes (ex 256 bytes) to memory then while you're idling you could read those 256 bytes and compress them to a smaller size.
Could have quite compressible data .... instead of having 100 records with values a,b,c,d you could rearrange as 100a, 100b and so on, and compress (do some rle encoding or some basic dictionary compression)

[mikeselectricstuff]

Yes I could just use the SD card as raw memory as well but given the much greater power consumption on something with way more memory than i need I don't even see the point.

I don't think you've said how much memory you need.

1MB would be nice, nothing stopping me using 2x 0.5MB chips as 0.5MB or 4Mb as they like to advertise memory arranged in 8 bits anyway are all I can see available right now.

2MBytes SPI flash costs about 25p
https://www.digikey.co.uk/en/products/detail/adesto-technologies/AT25SF081B-SSHB-B/13918480

Does it matter if you lose one sample when the power is lost ?

One simple approach may be to use two chips, write to them alternately ( or one immediately after the other). Any power-down glitch will only affect one copy, so a simple power-up check for consistency will tell you which data is valid.