Comments (8)
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.
from firmware.
@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.
from firmware.
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.
from firmware.
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
from firmware.
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.
from firmware.
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
from firmware.
@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
from firmware.
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?
from firmware.
Related Issues (20)
- [Feature Request]: Special case in `Screen::handleSetOff()` for E-Ink displays HOT 1
- [Bug]: When GPS lock is lost, position is still reported over MQTT with lat and long of 0,0. HOT 1
- [Bug]:
- hostnames (device names) with underscores break RFC HOT 5
- [Feature Request]: Short Name aka short_name shoud be 7 or 8 chars long for Amateur Radio mode HOT 1
- Make Store and Forward module storage abstraction for flash / SD card HOT 1
- [Feature Request]: Crypto/Channel drop when new device connected HOT 3
- [Bug]: Cannot rotate screen on SH1107 HOT 1
- [Bug]: Messages not sending when MQTT is enabled HOT 1
- [Bug]: Updates to button click accuracy adversely affect rotary encoders
- [Feature Request]: Range check and mesh complexity: Proposed Backwards compatible Meshtastic protocol improvement HOT 16
- [Feature Request]: Security: Factory reset via hardware, such as detection sensor module or button HOT 3
- [Bug]: RAK18001 buzzer very quiet - solution included HOT 2
- [Bug]: T-Echo reboot loop HOT 6
- [Board]: Flipper Zero with LoRa GPIO connection. HOT 1
- [Feature Request]: making meshtastic.local changeable HOT 2
- [Feature Request]: Expire node after x time of no contact. HOT 1
- [Feature Request]: Allow bluetooth connection when network is not connected HOT 16
- [Bug]: Critical Error 3 on heltec lora 32 V1 SX1276 HOT 4
- [Feature Request]: Enforced hop limits on packet relay for repeaters and routers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from firmware.