-
• #2
Sun 2019.07.21
Hey good morning @AkosLukacs. Quite an impressive all inclusive undertaking!
This topic is a bit out of my league. I'm basing my comment on what I have read. Wasn't able to quickly locate the links I Had, still searching.
I took a quick peek at the data and the results, then looked at a datasheet or two. Although I currently am unable to locate a thorough complete document, it appears the values above are less than those on the manufacturer datasheet.
Someone please correct this should the following be in error, but aren't these devices reading and writing in blocks, or when spanning more than one block, and could that skew the data write? What about an erase or clear? Doesn't a page of blocks have to be cleared before an actual write takes place? I also remember that a write only occurs if the data bit at the write location changed, so r/w the same data doesn't change a thing and the current therefore would be much less. I don't recall if writing clears the bit or vise-versa. One requires current the other doesn't. Didn't @allObjects post on this topic a while back?
'that's the point where a proper setup with an oscilloscope would be handy'
It's likely that most reading this have the same desire. Car vs oscilloscope. Add to your X-Mas wish list. Mines been there for thirty years!! ;-)
EDIT: Good Evening! (from post #2, refraining from over posting to this thread)'Morning? /me cooking dinner :)'
Keep forgetting that most forum users seem to be around GMT time zone, and it is just allObjects and myself that are a quarter of the world away and behind GMT . . .
Hey, that would make for a really great app!
-
• #3
Morning? /me cooking dinner :)
Oh, looks like there is a misunderstanding in the write part, added this to the original post:
Tests done:
- append a 46 character long line to an existing file (to simulate adding a new line to a log file. This is my original use case)
- read a 4 character file
- read a 334 character long file
So on the write tests the file is continuously growing.
Did the read tests out of curiosity / for completeness's sake. Right now I don't intend to read the data with Espruino.The power consumption is more than likely to be lower than manufacturer's values, because there is the overhead of JS execution (reading and writing small chunks of data each time), and also it's a Pixl.JS, and that has to maintain Bluetooth connection. So I'm pretty sure not even close to real 100% duty cycle.
Now thinking about that: probably I'm wrong about the maximum current draw, and the real max current is higher.(kind-of sort-of have a scope, but haven't really used it. They forked Sigrok / Pulseview, and the software support was pretty meh for a long time. I think the logic analyzer part is supported by Sigrok, but the scope part is still not supported in Sigrok. In hindsight, probably should have skipped it...)
- append a 46 character long line to an existing file (to simulate adding a new line to a log file. This is my original use case)
-
• #4
Thanks for posting that up - it's really handy to know about the consumption with the SD card, as I'd really expected that might be higher.
Where did the 30mA figure come from? In your use case (writing a small log message) I'd imagine capacitors would smooth at least the 10mA enough that it's not hurting the coin cell too much.
If you're interested, you'll find that writing to a file opened with
E.openFile
is way faster -fs.writeFile
is having to open the file first, which requires a few sector reads I believe... However for logging you'll probably want to have the file closed in case there's a power failure and it corrupts the file. -
• #5
Some background info: basically, I want to log a row of data (about 100-200 bytes) every minute. Saw the
E.openFile
method, but since I don't write continuously, just usingappend
felt safer & simpler.
Would be powered by a power bank, because I need 5 volts for the PMS7003, but wanted to test the coin cell backup.
First I modified the Pixl as described in "CR2032 battery backup" section and did some testing with the coin cell writing a row every 3 seconds. Was working fine for a couple of hours, but eventually the SD card didn't like the low voltage :)
Then wanted to do some power measurements, but that took a "bit" longer than expected... Without a scope, just run reads or writes continuously for 10 seconds, and wrote the current value. That 30mA is the "average" consumption of the Pixl.Js + SD card.But probably would need a scope or some more sophisticated method to really capture what's going on.
I did some timing & power consumption measurements with a couple of SD cards.
My setup is not perfect, don't have a scope set up, so just did reads and writes in a loop for 10 seconds, and measured the power consumption.
Hardware:
SD Cards:
Tests done:
A helper function (runs the
funk
function continuously forseconds
seconds, and returns how many times it had executed):Test values and files for perf measurements:
Baseline power consumption:
doFor(10, function(){})
: 8.4mASome surprises:
The 32Gb Sandisk Ultra is faster, and consumes more power.
But if we assume that a single read or write takes the propotionally less time, it's overall energy consumption is lower, if we go to 1MHz reads and 2MHz writes and above. Write energy consumption:
So looks like the fastest card at the highest speed is the winner?
But 30mA current is a bit high if you run on a coin cell. Or might not matter, because a capacitor could smooth out a single write-spike? Dunno, I guess that's the point where a proper setup with an oscilloscope would be handy.
Raw data in the attachment
1 Attachment