[Bug]: E-paper partial updates on T-Echo and Wireless Paper

[ixt]

Category

Hardware Compatibility

Hardware

T-Echo

Firmware Version

2.2.16

Description

Both of these epaper displays look to support partial updates, I would have opened this issue at our GxEPD2 repo but cant.
Looking at this implementation of T-Echo's display driver https://github.com/cfr34k/t-echo-lora-aprs/blob/main/src/epaper.c#L377 it's not impossible to drive the display in this way.
This may also help mitigate #2356 .
The controller for T-Echo's display is SSD1681, its commands can be found here: https://v4.cecdn.yun300.cn/100001_1909185148/SSD1681.pdf

Wireless paper v1.1's display has a UC8151D-like controller, either there is some misunderstanding on my part of how partial updates are prepared for these controllers or we just don't have the right commands yet. Regardless, it's likely that this display also supports partial updates.
https://v4.cecdn.yun300.cn/100001_1909185148/UC8151D.pdf

Relevant log output

No response

[markbirss]

@ixt

These are the specific changes that were made initially to support a e-ink on 2nd spi bus on the t-echo as GxEPD2 don't/wont support any back light or touch displays, you would need different e-paper driver boards like the DESPI-C03 anyway

T-Echo
ZinggJM/GxEPD2@master...geeksville:GxEPD2:master

DESPI-C03
https://www.good-display.com/companyfile/32.html

The other fast display support i added including the RAK14000 eink i moved to using the recent/current GxEPD2 library as i was able to modify/specify SPI settings

I suggested recently on the discord group that it might help to take discussion with LilyGo regarding possible hardware changes/enhancements to possibly fix the highlighted issues already known

Im aware the actual e-ink display in the t-echo can support partial updates as i used the same display with my first diy nrf52 board

Here the other PR's for reference
#1240
f474953
8a1bf8c

I agree with the possibility for partial updates with the Wireless paper v1.1 also.

The other issue to include in discussion is the need for a full update to be includes after so many partial updates - e-ink displays are not meant to be partially updates for ever

[ixt]

A couple more notes about the wireless paper v1.1 board. I have found another (potential) device that uses it (or a variant) as well as the BWR version of the same display (note the model number), no datasheet yet, but i've asked a few places now. Since that display is showing Waveshare, its entirely possible we might see it pop up in a waveshare product at a later date. I couldnt find any mention or inclusion of it otherwise. Both A162 and A161 are undocumented online and I feel like I can comfortably say I am certain of that as of this comment

That's annoying re:GxEPD2 touch/bl support.

[ixt]

LCMEN2R13EFC1.pdf
I managed to get a copy of the datasheet for the v1.1 display. No partial support mentioned... And a different driver than expected.

[tuxphone]

Hello, i'm not sure if it is the source of problems or unespected behavior, but meshtastic uses the GxEPD2154D67 while Lilygo themselves are using GxDEPG0150BN.

https://github.com/meshtastic/firmware/blob/master/src/graphics/EInkDisplay2.cpp
#if defined(TTGO_T_ECHO)
#define TECHO_DISPLAY_MODEL GxEPD2_154_D67

https://github.com/Xinyuan-LilyGO/T-Echo/blob/main/examples/Display_lilygo/Display_lilygo.ino
#include <GxDEPG0150BN/GxDEPG0150BN.h> // 1.54" b/w

GxEPD2:
https://github.com/ZinggJM/GxEPD2/blob/master/src/epd/GxEPD2_150_BN.h

[ixt]

@tuxphone having a quick look over the two drivers, it's not actually that far off. The only difference I can spot are the inclusion of a LUT for better partials and a different value for a 0x22 in full update (Display update control 2), which I would decode but I assume its for loading or unloading that LUT. I'll test it and see if it makes much difference, thanks for bringing it to my attention, I dont think it'll fix much but it's probably better to use the right model, if just for consistency!

EDIT: Tried with the LUT and such, its not perceptibly better than what we are using now. Whenever we do the next rewrite to the graphics stuff / update to our GxEPD2 fork, we should make the change but it's not in the fork right now so probably not worth it

[todd-herbert]

I managed to get a copy of the datasheet for the v1.1 display. No partial support mentioned... And a different driver than expected.

Spotted the discussion here (and at #3069) and just thought I'd drop in to pass along a few resources.

I did manage to get my hands on both V1 (DEPG0213BNS800) and V1.1 (LCMEN2R13EFC1) Wireless Paper boards recently, and have got the displays on both working, with partial refresh.

I don't think people are having difficulty spotting the difference at this point: it sounds like you guys have been getting boards with a nice "V1.1" sticker on the back? It's about time Heltec got round to properly identifying their revisions like this. My V1.1 board turned up with no sticker, so it must be a recent development. If there's still any doubt, I wrote up the differences here.

I see the discussion at the Arduino forum has already been referenced in #3069. Following on from the thread that was referenced there, I did my best to give a neutral write-up about the operation flow for LCMEN2R13EFC1, which might be of some use. I didn't do anything similar for DEPG0213BNS800 (on the V1 Paper), because I got the impression that it was already supported by GxEPD2(?). Skimming the conversation on #3069 though, it sounded like maybe V1 was also not implemented yet(?)

Let me know if I can offer any insight into working with the two panels.

[ixt]

@todd-herbert yeah I dont have access to a v1 board, I tried tracking one down for myself but must have dried up. We havent got the DEPG* implemented yet, and yeah the V1.1 boards seem to have had a period at the beginning where they didnt have stickers.

I'll try out GxEPD2's partial updates working with the commands outlined in your fast mode. It doesnt look too dissimilar to what I already tried so I might assume that it was working and I missed a step somewhere else,

I think the DEPG* might be supported in GxEPD2 (since it is pretty similar in commands to a few different displays), but we weren't pulling Vext to get it to start up, but I cant confirm without having the board.

[todd-herbert]

I think the DEPG* might be supported in GxEPD2 (since it is pretty similar in commands to a few different displays), but we weren't pulling Vext to get it to start up

I just had a look into this now. Wireless Paper V1 (DEPG0213BNS800) is working correctly with GxEPD2, including partial refresh. The class is GxEPD2_213_BN, but it was first implemented in v1.5.4 , and meshtastic/GxEPD2 forked from ZinggJM/GxEPD2 at v1.3.4.

The GxEPD2_213_BN class won't drop directly in to meshtastic/GxEPD2; the base classes have undergone changes since v1.3.4 (June 2021). Of note: SPI is passed differently now.

I don't think it would be a huge amount of work to backport the GxEPD2_213_BN class to meshtastic/GxEPD2, but as you mentioned, it's not so easy to work on the area if no-one can get hold of V1 boards anymore. On the other hand, if the V1 boards are being promptly phased out, maybe it becomes less relevant of an issue every day. Is it still an area you would be interested in seeing development for?