I'm a simple man, and did something similar but with bash+mosquitto+imagemagick running on a Kindle. That's boring/been done, but what I want to talk about is screen burn-in.
I've been displaying slight variations of the same image on an old Kidle paperwhite for a bit over 5 years! I've noticed NO burn-in at all. I'm doing partial updates every refresh (30 second refreshes), so the display will go 1+ years without a full refresh (~1 million partial refreshes a year). There's some retention when I first work with it, but clearing the screen and showing a full-screen pattern is enough to remove that retention entirely.
Pretty impressive, and I am also impressed the old firmware stays attached to wifi for the whole time as well! Sometimes it can have trouble reconnecting (power outage, dog unplugged wifi, whatever), that's when I'll see if there's burn-in, probably once a year(ish).
Idea for a product I would buy, maybe it exists already:
E-Ink screen and an ESP32 in a white case, i.e. similar to what this guy has built. Programmable via USB-C. So I could buy this, program it to display something and put it on my wall.
This is going to sound weird, but the first color changing LED lights I ever thought were worth a damn I found at Ikea. There are probably half a dozen decent ones now, but at the time it was Ikea or something that cost three times as much, which was ridiculous.
Yours looks way better than mine - I intentionally didn't show the inside because it's a mess of wires and the screen is held on with masking tape and blue sticky tack and the waveshare esp board wasn't really designed to be soldered to.
Initially I was also going to use an external RTC but didn't want to have the additional circuitry to actually turn on and off the esp32 via the RTC's interrupt signal. Did you find that the internal RTC on the esp wasn't accurate enough?
> Did you find that the internal RTC on the esp wasn't accurate enough?
It's more the power savings I was after :-) I wanted to put the esp32 into the deepest possible sleep state, which involves turning the RTC/RTC memory off entirely and is a pretty big drop. The external RTC I picked has a much lower current draw.
The esp's RTC is quite inaccurate, but certainly good enough to ballpark "morning update" and update system time to re-calibrate then.
Is there a way to fully turn off the RTC on the esp and still go into sleep, or are you using the external RTC to enable/disable the chip itself?
I noted this in the "future work" section but I don't have a way to actually test or validate whether the various deep sleep levels are working. If I try to use the ammeter on a standard multimeter it can't cope with the changing ranges as the esp draws a bunch of power to boot and I think probably causes brownouts.
Do you have a current ranger / ucurrent gold type device?
- On top of this, turn off the power domains for the RTC peripheral, RTC memory and the XTAL oscillator manually
- Use exlusively the ext1 external wakeup (ext0 requires the RTC peripherals to be powered on)
From my reading of the spec sheet, this is the best you can do on the chip.
Note that my choice of RTC also factors into the equation, the RV-3028-C7 has a significantly lower current draw than the common DS* RTC chips you see on maker-type boards.
And yeah, I bought a CurrentRanger :)
I'm very lazy about charging devices (I'm one of those people that keep their bicycle mechanical instead of going with the trend of electric shifters, because I absolutely don't want that hassle), so my goal was to maximize the number of months I wouldn't have to touch it.
Why E-Ink isn't cheap yet? I see supermarkets using hundreds (maybe thousands) of panels with different sizes for displaying prices. I doubt they are paying 50$ for 7" display panel.
They were highly patent encumbered for a while. I think much of that is expired but the manufacturing base hasn’t caught up yet.
The pricing is pretty expensive even in bulk. $50 for the larger displays isn’t off by an order of magnitude (e.g. 7 inch with red) especially as a retailer is buying that as a larger solution which includes all the syncing hardware, maintenance programs, and integrations.
For retailers, the savings story is in increased pricing accuracy and reduced labor for price changes. There is the promise of dynamic pricing but that’s a minefield for various reasons.
That’s why you tend to see it in high-value retailers (pricing accuracy, precision, smaller tag count) and grocers (lots of price changes, high labor costs).
I'm also a simple man, maybe the simplest here on HN. I see numbers on a graph that don't fit the red line on the graph and the lack of any scale for the data under the shaded area and I think WTF? I know this is an example but the data doesn't fit the numbers annotated across the top at all.
I also see Rust and I reach for WoolWax. That's just me though.
This is a cool project. I have been thinking of something like this using an old e-Reader.
I could have explained that better. The numbers on the Y axis indicate the min/max for the week, and the ones next to the days of the week are min/max for the day. The temperature graph is also scaled to not go all the way to the top of the graph. It's entirely possible that there's a bug in my code though - I didn't really write any unit tests for it.
The shaded area is a percentage and does extend to the top of the graph region, which means 100% chance of rain.
Thanks for the reply. I have marked up the display example [0] that you show in your post to highlight some of the issues that popped out at me.
From the mark-up it looks like the data used for drawing the red curve and for annotating the - Day High Low - for temperature may have come from a different set of days since they don't fit well in the graph area. The low temperatures for each day are especially wonky.
I also noted that sunrise appears to be around 5 am at your location based on a quick attempt to define a horizontal scale for hour of the day. I don't know if that is correct.
I hope all this helps. I really like that red line capability. That is one of the things that to me makes using an e-ink display less than ideal. I like to be able to use colors to help define the data being graphed or displayed.
Thanks for the detailed markup! I'm going to take a look at the code tomorrow and see if there's some obvious mistake I've made with the highs/lows. I do remember doing some filtering to only show the lows after noon because I'm typically not outside at 5am - maybe I messed that up.
The reason the current temperature is higher than the "weekly high" is simply that the current temperature is from actual observed data and the weekly high is from forecasted dated, so there are two possibilities: either the temperature is simply higher than forecasted, or the current temperature is higher than it will get the rest of the week.
For what it's worth, there are multicolor e-ink displays available at similar sizes but of course they're also more expensive and have longer refresh rates.
What's the advantage of Rust here? Like, I thought there was a bunch of more "native" tooling around ESP32 (Arduino?). Do the "neat" parts of Rust carry over into work on these small/embedded systems? Or is there a lot of fighting the toolkit because the vendor supports only C-libs?
The vendor toolkit is in C, so often you'll see for newer boards that Arduino/CircuitPython/etc don't support it yet because they have to build their own wrappers. Rust lets you use bindgen to basically immediately have access to the entire vendor library.
Now, in this case I'm using an older esp32 board so something like CircuitPython probably would have been equally fine, but it was nice to be able to share the same buffer type across the server and client. I also just enjoy writing Rust and find it less error-prone than C.
Bringing the high down is one thing. Having a flat line, with less than 1 degree deviation, for the whole day is another! Or perhaps "low" isn't calculated this way.
I think you're technically correct, but "low" and "high" are often just used as shorthand for "what temperature it will be in the morning" and "what temperature it will be in the afternoon," respectively. A weather app may just be reporting the expected temperature at 8 AM and 3 PM, even if there are lower lows or higher highs at some other part of the day.
Many libraries around me in the Bay Area seem to have 3D printing services for free — this might be an alternative for a one-off, while costing you nothing!
Are you willing to share the stl/general geographic area? I might be willing to print & ship. There's also https://old.reddit.com/r/3Dprintmything/ if all else fails.
I want to do something like this. Should I get the esp32 or go with an Arduino/Raspberry Pico?
Also, for the e-ink screen, is there anything I should watch out for? Do I need it without PCB or with?
I want to order the pieces now and do something with Rust, but I wanna make sure I don't order something wrong. Any pointers would greatly be appreciated!
Are there any projects that make use of those e-ink price tags that seem to be ubiquitous and maybe cheap(er)? Or are they locked to prevent their use for other applications? Not sure if there's a good source for those e-ink price tags on a one-off basis that's down in the low double-digit pricing.
What is the Rust used for here? Do you manually write x,y pixels to these devices?
Can you use another program to rasterize a two tone bitmap image with the appropriate dimensions and then pass it to the display controller without needing to write any software?
Rust runs on the esp32 to send the data to the display, and is used on the server side to generate the image that is then served up to the esp32 to send to the display.
There is minimal software on the e-ink display side… it connects to wifi, fetches the image, and sends it to the display.
It seems accurate enough at least to pick out clothes for the day. The precipitation forecast sometimes is a bit overzealous later out in the week but seems pretty accurate for the next 24 hours or so.
I've been displaying slight variations of the same image on an old Kidle paperwhite for a bit over 5 years! I've noticed NO burn-in at all. I'm doing partial updates every refresh (30 second refreshes), so the display will go 1+ years without a full refresh (~1 million partial refreshes a year). There's some retention when I first work with it, but clearing the screen and showing a full-screen pattern is enough to remove that retention entirely.
Pretty impressive, and I am also impressed the old firmware stays attached to wifi for the whole time as well! Sometimes it can have trouble reconnecting (power outage, dog unplugged wifi, whatever), that's when I'll see if there's burn-in, probably once a year(ish).