4 ms·
> the rp2040 dooms it; the rp2040 lacks a reasonable deep-sleep mode; its lowest-power mode is nearly a milliwatt, so it will drain the battery flat when it's n
by csdvrx 3y ago
> the rp2040 dooms it; the rp2040 lacks a reasonable deep-sleep mode; its lowest-power mode is nearly a milliwatt, so it will drain the battery flat when it's not being used
Low tech immediate solution: add a power switch cutting off the battery.
Bad for the RTC, but it's nothing that NTP or even rdate can't fix (or just don't use the switch if you need the RTC)
Better solution: replace the rp2040 in the next revision.
- kragen 3y agothat's not a solution, for three reasons the screen will fade after 30 seconds (unlike epaper) once or twice an hour you'll forget to turn off the switch when you stop to think and the battery will drain anyway and you'll corrupt the flash
- csdvrx 3y ago> the screen will fade after 30 seconds (unlike epaper) So what? I see that as a positive! > you'll forget to turn off the switch Uh, if I don't see the screen fading in 30 seconds, I'll conclude I forgot. > once or twice an hour I intend to only turn on the device when I need it. > and you'll corrupt the flash I don't think so, I use industrial SDs + journaling filesystems, and I do `sync` before turning off my devices.
- kragen 3y agolet's contrast the sensibly designed device with the design i think you are describing on the sensibly designed device, say i'm answering an email. i look at the screen, ponder for 30 seconds, scroll down, ponder for 30 seconds, and hit reply. redrawing the screen took, perhaps, a million clock cycles each time, so it required powering up a 240 megahertz esp32 for 2 milliseconds. so i've consumed 6 milliseconds of cpu, 0.6 millijoules at 100 milliwatts, plus the 50 microwatts of the screen for 60 seconds, which is 3 millijoules then i spend 10 minutes typing out a 300-word reply at 60 words per minute with a duty cycle of about 50%. each time i press a key, the cpu powers up, processes for an average of 65536 clock cycles (0.3 ms), updates the screen, and powers back down. in total my 1500 keystrokes result in 450 ms of cpu time and 45 millijoules. keeping the screen active has cost another 30 millijoules. finally i power up the 1.5 watt wifi radio hardware for 100 milliseconds and send the mail, consuming another 150 millijoules total power consumption to read and answer the email: a bit under 250 millijoules. i'll get over 9000 emails out of a cr2032 coin cell, about six months of use [i'm being very generous with these numbers to be sure to estimate conservatively. my best estimate is that this screen will hold 12 lines of 40 characters of text readably, and proportional-font layout with word wrap takes about 40 clock cycles per character, including blitting from a font bitmap, so redrawing the screen should take about 19200 cycles, not a million; and handling a text editing keystroke should average 7500 cycles, not 65536; and sending an email over wifi should require it to be powered up for 1 ms, not 100.] with what i think is your proposed design, i have to leave the pi zero running at 1 watt for the whole 11 minutes, so i use 660 joules, 2640 times as much. the cr2032 coin cell will last me for 3.3 emails 2640 times more energy consumption means 1/2640 the battery life. with the battery they propose to use i think it's 33 emails vs. 90000 instead of 3.3 vs. 9000 [corrected obvious dumb math error above, sorry] evidently the second device is not an adequate replacement for the first even if it does support sixel --- as for corrupting the flash, a flash block that was partially written before the chip lost power looks exactly like a correctly written block some percentage of the time, maybe a high percentage like 99%. but sometimes you will read back corrupted data, maybe depending on temperature, emi, or state of charge. so cutting power to your industrial sds when you're not sure if the flash is writing or not is going to bite you sooner or later better hope it's not on orbit when it happens it was for me
- csdvrx 3y ago> evidently the second device is not an adequate replacement for the first Agreed, but the 2nd one is available on preorder. I'd like to see the 1st one you describe, and I think it may happen. Buying the 2nd one to show my interest in the project seems like the best way to make that happen! > even if it does support sixel Well TBH if only the 2nd one supported sixels, that'd be my choice (though I'd work hard to have that working in the 1st one too lol) > so cutting power to your industrial sds when you're not sure if the flash is writing or not is going to bite you sooner or later When I type sync and wait a while, I do assume the flash is not writing.
- Someone 3y ago>> you'll forget to turn off the switch > Uh, if I don't see the screen fading in 30 seconds, I'll conclude I forgot. I think that many cases of forgetting to switch it off would involve laying down the device and not looking at it. Say you get up to switch on a lamp or to get a snack, but get a phone call or get interrupted by your child. Even if you look at it a bit later and see the screen being off, I doubt you’ll always remember whether you flipped that switch? There’s a reason smartphones automatically switch off the screen when idle.
- kragen 3y agothe reason smartphones switch off the screen when idle is that the screen uses literally twenty thousand times more power than this screen, over a watt instead of fifty microwatts, so leaving it on drains the battery rapidly it's pretty shitty for things like reading a book, watching a compilation, or text chat, but for a smartphone the alternative is worse by contrast, running the pi zero for one second uses more energy than keeping this screen on all day