E-Ink UI - long term planning

[todd-herbert]

From what I've heard, off in the distance (more than a year from now) there are big UI changes planned. I know there's active work going into designing a "mobile phone" style UI, for some of the more powerful devices. This is all very exciting.

Because of their slow refresh rate, E-Ink displays have unique UI requirements, which will require special consideration. I also understand that the new graphics framework may be too resource intensive to run on some older devices.

My aim here is to start a discussion early, so we have plenty of time to work on solutions.

What role do you feel an E-Ink display should play?
What features do you feel are important in an E-Ink UI?
Do you have any technical suggestions about implementation?

[feh123]

I can comment on question one and two. On my meshtastic nodes I have only used the rak14000 e-paper module (B and W). I have used an e-ink screen for other raspberry pi projects. These require quite a lot of text to be displayed with additional icons and images. It handles these really well. This use does not require a fast refresh rate so it's prefect.
I use a rak14000 on a stationary node in my house to obtain weather date from a node in my garden. It's great for clarity of text and ease of reading. I much prefer it to OLEDs. I would like to use it for hiking but I cannot because I also use gps so the pins are not available. However I have some experience of it on a mobile node. The major advantage I see is that it uses far less power than an OLED. I have no measurements of this other than a comparsion of two identical nodes one with OLED, one with E-ink. It seemed the e-ink was using less battery (clearly real power measurements would be better than my indirect method). The clarity was better as expected, the only downside was in bright sunlight you need some way to shade the screen to read it.

[todd-herbert]

Thanks for sharing your experience! It's definitely helpful to hear that you're using it for weather data; points out that it's important to keep support for modules to display things like sensor data, which is something I might have otherwise overlooked myself. Also hear you that power-saving is a big thing to consider.

[markbirss]

@todd-herbert

Over and above the new UI discussion that started, there was also a Meshtastic forum member that posted about e-ink gui long while ago - https://meshtastic.discourse.group/t/new-ui-for-e-ink-display/3666

I also like the idea that one can reverse the e-ink display and instead do this

[todd-herbert]

I do like the idea of the reversed UI, I was even thinking about playing with it on a custom build later on.
Is it particularly unhealthy for the display to draw light-on-dark like this? I've always had the suspicion, but never actually looked into it.
I'll check out that discourse thread too!

[markbirss]

I also tried it out, just reversed the drawing and init color, with partial updates the display did tend to get dirty more quickly

[todd-herbert]

Maybe just a nice custom screensaver (drawn with full refresh) to compliment a dark enclosure 😉

[GUVWAF]

This might be an interesting target as well: https://x.com/lilygo9/status/1798119560522178971
They mention "there is lora".

[todd-herbert]

That's absolutely an interesting target! It looks like it might be at home somewhere alongside that new T-Deck UI? I know they've got E-Ink on the roadmap. I'd absolutely be keen to join in on that project, helping to get this device supported once it's available; that is, if Mark Birss doesn't already have it totally covered!

I'd overheard at some point that some of current devices (e.g. T-Echo) might not have enough flash to support the big new UI, and have been slowly thinking about display code specifically to target these variants. It'd be nice to design around the need for static elements and slow refresh rate, and directly on-top of GxEPD2, rather than through the OLED library.

[mkgin]

I have 2 x Heltec v1.1 wireless paper. At the moment using one. I think it's a handy thing to have on the desk and be able to glance at without needing to press a button since the screen is always there. There's just the one user button and no easy access to more gpio.

I use the recent patch to disable the screen saver when display.screen_on_secs: 0 and have display carousel set for 10 seconds so I don't need to long much to go through the whole cycle. I'm not concerned about the screen wearing out.

Not strictly an e-INK thing but GUI related. It would be interesting to have a but of customization of the UI via the configuration.

For example more control over the node information in graphics/Screen.cpp perhaps something simple like on/off and ability to display metrics... or even being able to specify a custom format string or regex. (I understand that would be a stretch.) But would bring customization to those not comfortable with building custom firmware.

[todd-herbert]

I'd like to make it more configurable, but possibly via an on-screen interface, to avoid filling the apps with settings that only apply to a handful of devices.

perhaps something simple like on/off and ability to display metrics...

I don't quite understand, but I'd definitely like to. Can you explain a bit more?

[mkgin]

Being able to choose what information is displayed in the node screens... if available. Ef, maybe I don't want to see uptime or distance but interested in some node power or environmental telemetry.

Like some on the examples above, e-paper makes a nice dashboard, it can be updated only when necessary.

For smaller screens, like Heltec wireless paper. The carousel allows it to show alot of info if you are willing to wait.

Though the user button is already quite loaded with functions, some other ideas.

• Stop and restart the carousel, if one want's to stay one page and see the changes
• highlight changes on a screen with inverse or underline maybe

[todd-herbert]

Ah right, I see what you're talking about! Thanks, it's good to hear these ideas, in case this whole project does go ahead eventually.

[mkgin]

Nice that you are proactively looking for suggestions! I hope the project get's support.
I understand the challenges with firmware, hardware and other resources.

Are you focusing on E-ink or anything connected to new UI features welcome?

I'll try not to spam you to much with every idea and just edit below here for now.

• Virtual screen and buttons in the web browser when connected to the device via the web client .

[todd-herbert]

The web client is totally outside my realm of knowledge unfortunately.

Virtual screen and buttons in the web browser when connected to the device via the web client .

That one might be quite tricky, but if your goal behind the idea is really to get a mimimal slideshow of info, like what you'd see on a device screen, then that could be totally realistic and might be worth opening as a feature request over on the web client repo