Add a hardware power button?
The refresh rates are nice but it's really not the same, and in direct sunlight on a hot California day you can see a world of difference between the contrast and glare of a high school graphing calculator and a Kindle.
they do have glare but are quite readable in direct sunlight or outdoors in the shade or on a cloudy day
also they cost almost three orders of magnitude more
Sharp Memory LCDs are reflective, not transreflective. They're easier to read outdoors than indoors, much like eink. (Sharp markets these screens for devices like bike computers and gas pumps.) Some of the optical properties are in the same ballpark as eink as well.
Furthermore, there's no radio other than what's on the Zero? That whacks it right into useless territory for me. What's the point of a low-power device if all it has is high-power communication?
My first/only care for this would be a LoRa backpack. Or even some Nordic thing, or BLE, I don't really care, just anything's better than wifi.
maybe if you had a speaker you could do ultrasonic communication with ble-like range; there are several megahertz of spectrum there that can propagate through air for a few meters, and milliwatts might be adequate. similarly with infrared; historically it's suffered a lot from highly directional interfaces that assume stupid, fragile encoding schemes, but we have enough compute now to do better
Note to any hardware hackers out there: I would buy the crap out of a unit in this form factor with an ESP32, LiPo charging, and proper deep-sleep oriented circuit design (I have seen too many circuits with cheap voltage regulators leaking many tens of μA).
can you plug in an external keyboard
or are you supposed to program it via whisper.cpp speech recognition
but i just want to wake up for five milliseconds
wrt xtensa, in theory risc-v ought to help them with lowering the power suck (it sure helped the gd32v) but i'm not sure it makes a difference in sleep
and of course for milliamps per mips, going to subthreshold switching like ambiq will make a much bigger difference than anything architectural
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.
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
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.
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
with with the csdvrx designed device, i have to leave the computer running at 1 watt for the whole 11 minutes, so i use 66 joules, 264 times as much. the cr2032 coin cell will last me for 33 emails
evidently the second device is not an adequate replacement for the first
---
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
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.
> 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.
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
Plan for power management is pretty simple - trim as much fat from OS startup sequence as possible to get boot-times down to ~5s, eg https://github.com/IronOxidizer/instant-pi. Then turn the Pi off as much as possible. Write to screen, turn off Pi. Set timers on rp2040 to turn Pi on periodically.
With the 2000mAh battery, if the plan works, it should run for a while.
or does the pi zero have a submilliwatt suspend to ram and i'm just the last to know
i think that it could be a fun hacker toy if you put a low-power microcontroller on it with access to the screen and keyboard and control over the pi's power rails (and the rp2040's if you put that in too)
as a bonus if the low-power micro was an esp32 you would have wifi and bluetooth
then you only need to fire up the pi when its computational gronk is really needed, and the ui stays responsive the whole time
2 amp hours (why would you say 'two thousand milliamp hours', that's four extra syllables for no reason) is 27 kilojoules at 3.7 volts; that's ten months at one milliwatt, a weekend at an esp32-like 100 milliwatts, 7 hours at an optimistic one watt, or three hours at 2.5 watts, which i think is more realistic for the pi
you won't even be able to use this thing all night with the pi running; you'll need an external battery to recharge it before the sun comes back up, like that old laptop that you used to take out of the house back when its battery lasted more than two hours
also 2 amp hours is somewhere in the neighborhood of 20 grams of battery, while the rest of the device is i think around 15 grams. admittedly still pretty small and light compared to the fragile monsters that pass for android cellphones nowadays
Yes, that's exactly the plan. Pi zero does not have suspend to ram unfortunately, hence this elaborate work around. Remember, the use case is a weekend chat device. This power management scheme fits the use case perfectly.
but waiting 5 seconds for a keystroke to be echoed (sometimes) is appalling. you would not get permission to do a user study from an irb. it would be denied on the grounds of needless cruelty to experimental subjects
it would fit the use case perfectly if you had a low-power microcontroller that updated the screen in response to keystrokes, but what you're describing is a user interface design botched for no good reason
even the rp2040 would work for that at the weekend level
that's the plan i described yesterday in https://news.ycombinator.com/item?id=35983387
that's the plan i think will give you three hours of battery life: 2 amp hours times 3.7 volts divided by 2.5 watts gives 3 hours of use. 36 5-minute timeouts. do you have a different estimate? did i miscalculate?
that's not a weekend
in that comment i also explained an approach that would beat that by two orders of magnitude if you applied it with the same components (though there i supposed the hardware would use an esp32)
btw my grandparent comment https://news.ycombinator.com/item?id=35984332 is upvoted to 11 at the moment so evidently even if you think it's stupid your customers don't
You use “customers” as if this were trying to be a full product. This is a weekend hack. Of course there’s going to be low-hanging fruit that could be optimized away.
Stop shitting on the guy’s earnest enjoyment. What you’re doing is akin to going to your favorite package’s issues tracker and making a P0 request like “rewrite it in rust, python sucks”
it's not a weekend hack, it's a commercial product, designed and built by a team of several people. the weekend hackers are the intended customers, not the makers. they have 50 prototype units in stock, and they're taking preorders for two more larger batches which they expect to ship in august and september. august is 70 days away, an interval which is 35 times larger than a weekend
the 'weekend' aspect is how long the user should expect it to work for, not how long they've spent on developing it
unfortunately, their current design seems to have a fatal flaw that renders it useless for its intended purpose, but one that's easily fixed
my comments are not shitting on it; they explain how to fix it, providing information the original designers were evidently unaware of, so that they can ship a product that fulfills its intended purpose
but what's a razer 2
Put that caveat somewhere obvious on the site. “I’m not taking this seriously but I will seriously take your money! Caveat emptor!”
this is much more interesting than an e-paper device; it's a memory-in-pixel lcd device, which means 100 times better refresh rate and 1000 times better power consumption than e-paper. the lcd in question (ls027b7dh01, i assume, though that information is missing from the web pages) is supposed to run on 175μW at 20fps, so you can get a full usable computer system in submilliwatt territory, so the 2.2 kilojoules in a cr2032 can power it for weeks
however, i think that, as a low-power device, this is probably fatally flawed. 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
also it's unclear, in this design, how much the rp2040 can do without powering up the pi zero, which is a humongous power hog, using over 1000 milliwatts. so instead of weeks of active use from a cr2032 (and months of standby if you use a low-power micro instead of an rp2040) you get hours
what's the point of using a super expensive memory-in-pixel lcd to get the display power consumption down from e-paper's 10-100 milliwatts into submilliwatt territory if you're just going to burn a thousand milliwatts in a raspberry pi? just use a conventional lcd then, maybe one with nice 24-bit color. old nokia lcds will run on a milliwatt
maybe an esp32 would be a better middle ground if you aren't willing to go all the way to an ambiq apollo3 or something, which can (hypothetically) give you submilliwatt power consumption with workstation-class performance, as long as you don't need virtual memory; you probably want an esp32 or equivalent in there anyway for wi-fi
usb-c is a great way to be able to hook up a full-size external keyboard, but speaking usb-c to a keyboard is also probably beyond the capabilities of the rp2040, and so would also need to power up the giant power hog pi zero