Resources and Suggestions

[vroland]

Feel free to post useful resources, suggestions or show off your projects here. Older comments of this nature can be found in #21 .

[vroland]

epaper-breakout.pdf This is the schematic, that's probably easier. My layout is a little bit different from yours, the circuit would be identical if VBUS on D7 would instead be a connection after D8. But shouldn't this work as well? Still leaving the power supply input with the higher voltage?

[mcer12]

@vroland Indeed seems like it should work in parallel just as well. I wonder why did I do it like that back then...

[vroland]

@mcer12 Ok, I'll have a look at it after a night's sleep and if it still makes sense, i'm using it like this ;)

[mcer12]

@vroland I almost forgot, you asked what I add to my board :) You can see it in the schematic, just few buttons and WS2812 led as an indicator. The biggest difference will be that I am designing it to perfectly fit behind the eink panel (one version for 9.7" and one for 6"), only the buttons will stick out. So the differences are more about pcb layout than anything else. I added the other LT1945 but you later added it to your design as well :) I will also probably add optional temperature sensor but that's it. Oh and I also added simple battery sensing which I highly suggest, I don't think I saw it in your design.

[vroland]

@mcer12 Ah, yes. I tried to align the connectors to fit under the display as well, but it's hard to do that for all of them at once. So with my board, some will align well, some not. But on the other hand they have a smaller footprint :) Which values did you use for the battery sensing? Using the same values / ratio will make it easier to offfer a library function for that. I think I'll add this behind a scratchable jumper, so if you need the pin you can remove it.

[mcer12]

I use 2x 680k, additional 0.1uF capacitor from ADC to GND for decoupling. If my calculations are correct, this draws additional 4uA. To mitigate this, another mosfet can be used and would allow for lower value resistors so there would be less noise.

[vroland]

Hm, I'd suggest using a ~5:1 ratio, like 560k/120k, such that even when powered with USB you'll stay in the range of the ESPs internal reference voltage of ~1.1V. With 2x680k you'd need the additional attenuation which might hurt precision unnecessarily. I mean, not that the ESP is that precise anyway, but once we're at it ;)

[mcer12]

3.3V range is used by default (at least in arduino IDE), that's why I use it ;) Honestly the noise i smuch bigger problem then attenuation, at least in my case. It was all over the place without the decoupling capacitor. Also, in my opinion, this has nothing to do with e-ink and should be done separately somewhere in the example sketch and not built-in in the library itself.

[vroland]

With the IDF you have to be explicit, so I'd like to be sure not to break my ESP by choosing the wrong setting. But yes, precision-wise this doesn't make much difference. Regarding the library: The temperature sensor is already part of the library. This is because the EPD timing is dependent on temperature (although I don't correct for that, yet). Reading the voltage does not directly relate to it, but is also dependent on board revision, etc. So to write a robust program that can deal with different board revisions / future derivates, you'll sooner or later have to add a couple of #defines. As someone just writing a program, I may not want to keep up with those. So adding this to the library will make it easier for people to write portable sketches.

[vroland]

Btw. epdiy now runs on those LILYGO displays as well:

[vroland]

@mcer12 Looks like they swapped the use of GPIO19 and GPIO0: They use GPIO0 for driving the shift register and I use GPIO0 for a data line. Do you see a reason why this would be beneficial?

[mcer12]

@vroland I don't see any advantages for that. Maybe they did it for lower power consumption but from my testing, GPIO0 doesn't draw any extra current. I'm not sure if I have it isolated to archieve that, will have to take a look.

[vroland]

@mcer12 I wrote them an email and they told me "there will be a problem of waiting for download after power-on" when using GPIO0... I'm not sure why, maybe some displays pull their data lines up? But if that's the case, it might be a good idea to swap them just to be sure.

[mcer12]

That could be some issue specific to their board, this never happend to me but since the shift register is always powered, it makes sense to conenct GPIO0 to it instead just to be on the safe side

[vroland]

I mean, It's certainly not worse, so we might as well do it.

[mmib]

Found this device on ali https://www.aliexpress.com/item/1005001835564831.html it seems this progject is fell into the hands of Chinese engineers already :) Maybe new boards will be also available on Ali

[vroland]

@mmib Jup, but they published their code as the license requires and sent me a sample, so that's fine I guess. This will also make it more accessible to people. I also looked into selling some of my boards, but turns out that's a real legal challenge here. Even disregarding certifications and safety stuff, I don't want do be sued because it gets to hot and burns someone /something. So I'd either have to take a legal risk or invest more than I'd ever earn with a niche dev board :/ Maybe I'll set up a donation button someday :D Edit: Here's the link: https://github.com/Xinyuan-LilyGO/LilyGo-EPD47

[mmib]

Yep, this is absolutely fine as it is opensource project! I'm happy to see it on market

[mcer12]

@mmib from a quick glance, it is the old design with linear regulators for +-15V. This is very inefficient and may be unstable so be aware of that ;)

[vroland]

@mcer12 It's probably fine for the small display, but not suitable for the larger ones. Maybe they chose it because it's cheaper ;) There's no suitable connector for the larger ones anyway.

[mcer12]

@mmib i don't see anything open about the TTGO board, they only released the software which is just slightly modified epdiy. I don't see schematic or pcb on github. But license-wise, I don't see any issues. Maybe they could credit @vroland in schematic + pcb design, but epdiy schematic is arguably also a remix.

[mcer12]

@vroland Maybe you could change the license to allow commercial use but only if the remixed schematic remains open source. Can't remember the license by name, would have to look it up.

[vroland]

They sent me a schematic via email, but they did not publish it yet, afaik.

@mcer12 Yes, wether the schematic is even complex / original enough to be covered by copyright is probably debatable as well :D But if it is, adding a Share-Alike clause could indeed be useful to ensure that the community can make use of derived board properly. I guess CC-By-SA would be the license you mean?

[mcer12]

@vroland seems like GNU GPLv3 would be a good match?

[mcer12]

@vroland that doesn't seem to include attribution, so https://creativecommons.org/licenses/by-sa/4.0/ seems the best

[vroland]

@mcer12 GPLv3 doesn't really apply to hardware / schematic and is probably more suited for source code. And the library source code is in fact GPLv3. So I'd agree that CC-By-SA is the best match.

[vroland]

@mcer12 @2dom I've now swapped GPIO19 and GPIO0 in the schematic and completed the board routing. Could you check for any obvious mistakes / issues again (esp. with the routing)? I think it's time to go for a prototype board. epdiy_v5.pdf epaper-breakout.pdf

[mcer12]

From a quick glance, it seems to me you have GND pour under the antenna? I forgot to remove it one time and it caused me a lot of headache before I found out. If you don't it's still too close to the antenna and I would definitely push if further. It causes really weird issues. Take a look here (page 12): https://www.espressif.com/sites/default/files/documentation/esp32_hardware_design_guidelines_en.pdf and this is really great, different board but that doesn't matter at all. You can compare different layouts, awesome stuff: https://www.espressif.com/sites/default/files/documentation/esp-wroom-02_pcb_design_and_module_placement_guide_0.pdf

[vroland]

Oh, you're right, I forgot to add back the keepout area after I removed it. But thanks you the link, looks like I have to move the temperature sensor as well.

[vroland]

And connect it to the switched input voltage since it can draw up to 12uA.

[mcer12]

I would suggest to cut the pcb out in that area, similar how I did it on my board: https://www.reddit.com/r/esp32/comments/k4uxvh/6_kindle_paperwhite_display_with_esp32/ It will give you the best performance.

I get the push for the smallest board possible but since this is really a development board for several types of displays, I wouldn't bother with size and give it some more breathing space. The board won't hide behind the displays anyway so I don't see any reason for it :) I will design boards specific for each display which will copy the display size and hide behind it.

The coils being right next to each other can introduce some interference, also data lines running around the high voltage booster is not great, it can introduce noise to the data lines, shouldn't be all that significant though.

Btw I see you included ED060SC7 connector, I am very curious about that one :)

[vroland]

Thanks for the feedback! I've added the cutout and tried to separate the coils a bit more.

Regarding the board size: It actually hides well for all displays except the ones with the XC5 connector. And with this form factor, I can just upgrade my existing projects with a drop-in replacement ;) So I'd really like to keep the form factor (more or less). I get that it is a bit crowded, but with the old boards I had a similar layout and did not experience interference issues. But if I get weird issues, we'll have your boards as a comparison. The data lines crossing under the booster may not be great, but they are for the broken out pins anyway, which should be fairly low-speed and digital (in most cases). epdiy_v5.pdf

Btw I see you included ED060SC7 connector, I am very curious about that one :)

The connectors for it just arrived today, and they are tiny... This will be a challenge to solder :D But the SC7 could be a really nice display.

[mcer12]

@vroland With proper amount of flux, anything is possible!

Maybe you have the display conector flipped as opposed to my board? Or do you have the usb connector facing inwards? It's hard for me to imagine how it looks. Maybe it's because my board looks very different :) This is how my board looks when connected (it's 9.7" variant), I will only be adjusting the pinouts according to V5 but this is how it looks, I am very happy with how it turned out :) https://www.dropbox.com/s/8nlqyum403vsegx/Photo%2008.01.2021%2014%2012%2041.jpg?dl=0

[vroland]

@mcer12 Yes, the USB connector is facing inwards for the 9.7" display. That way, I can better hide the usb cable behind the case and hide the board completely inside the case with other components instead of exposing the usb connector. Your board seems to aim for a more specific application with the buttons at the bottom, but if you need them, it looks like a very nice solution!

[2dom]

Looking good - excited to try it out :) 👍

[mcer12]

@vroland I made a slack channel, I think it will be better than spamming the issues for general questions and discussions :) Everyone feel free to join https://join.slack.com/t/newworkspace-63h1804/shared_invite/zt-kx2yqjxg-BSlEOBC_QN7IKI5RYlrXkA

[tim-seoss]

@mcer12 Hello, I've been lurking here until now... Thanks for creating a channel, but personally I think it might be better to keep discussions here whilst they are at a relatively slow pace.

If it's felt that a real-time chat would be better... Since I'm a member of a few different online communities at the moment, I thought I should feedback that I find the slack-hosted ones really suffer from the fact that a lot of people don't have slack subscriptions, and so can't search/access old messages.

The chat platform I currently recommend is Matrix - which is a fully free and open source standard (designed to be a decentralised platform - like IRC), and which has been adopted already by Mozilla (e.g. Mozilla shutdown their IRC service and moved to Matrix), KDE, and Gnome, amongst others. I would suggest creating a room on the free matrix.org server (it can always be federated to another server afterwards).

Some benefits:

• No limitations on ownership of your data (won't hide/ransom access to older messages).
• Open ecosystem in the style of IRC with many clients (even IRC style command line/terminal clients if you prefer those to the default web and/or app clients) and also servers (for public and/or self-hosting).
• Moderation tools which are much better suited to public communities than those offered by Slack.
• Messages can be indexed by search engines, if you set the appropriate room permissions to allow that (to increase discovery by other users).
• End-to-end encryption if desired for private chats (uses same encryption protocol as Signal).

Since "a picture is worth a thousand words" - you could view a limited preview (without signing up) of one of the rooms that I use in the "Element" matrix client, in it's in-browser form by clicking: https://matrix.to/#/#stm32-rs:matrix.org and then clicking "Continue in your browser".

[mcer12]

@tim-seoss I am personally used to Slack from both work and community projects (diyHue has thriving community on slack), that's why it's my go to. The reason for chat app is to quickly discuss stuff and exchange ideas and leave issues to be... issues. And finally, it goes down to what people know and are familiar with which is mostly Slack and plenty people have it already installed.

[vroland]

@mcer12 I actually think matrix fits the use case for quick discussions or answering a quick question a bit better here, because it's a more open platform with a lower barrier of entry. With slack, you have to register and don't have access to history. Additionally it has a limit on the number of members and constantly tells me to install their desktop app, which I don't want to for various reasons. So conceptually, I like matrix a lot better ;) But if you prefer slack, we could use both an connect them via a bridge?

[mcer12]

Bridge would make best sense I guess if it's possible.. not familiar with matrix at all :)

[tim-seoss]

There is a Slack to Matrix bridge available and I believe it's reasonable, but I've not used it (I think when I looked into it at one point, you needed to have a Slack subscription to do some things I wanted with it, which I don't - but that may not be the case (any more))? https://github.com/matrix-org/matrix-appservice-slack

n.b. if you use matrix.org to host your Matrix room, then the bridge is already available, and can be setup via the Element UI I believe (use the 'i' icon at top-right to select "room info", then click "Add widgets, bridges & bots", scroll down to bridges, and select 'slack').

[vroland]

I'll have a look into it, hopefully soon-ish ;)

[vroland]

@mcer12 @tim-seoss I've set up a matrix home server bridged with the slack channels in both directions. Links are in the Readme :)

[mcer12]

Now everyone's happy!

[cxw0102]

@vroland I am a novice，First use Epdiy PCBv5. When I accidentally short-circuited 3v3 and Gnd, I could only watch lt1945(U2) smoke and burn , Because I can't close the battery immediately. It is recommended to add a switch. and，add reset button are convenient for our novices。now i test my displays ，only unplug usb.╯︿╰

[martinberlin]

Once I get some EPDiy PCB I will start experimenting with bigger touch overlays. So far I got chinese L58 working: https://github.com/martinberlin/FT6X36-IDF

Is the one that EPD47 from Lilygo uses. Is a refurbished mobile touch but works pretty good. I really like the I2C simplicity, SPI is already a mental limitation, and understood enough of Valentin work just to collaborate with software rotation. Waiting patiently for my first EPDiy pcb so nice first one I got is being tested by my father. He likes it so much he is not giving it back to me ;) Jokes aside, if someone wants to implement any touch my IDF implementation can be a good start to make a fork and develop in the top of this. I have a keyboard and a draw example working and with DU refresh mode they work awesome. My next task is to make LittleVGL drivers for this

[vroland]

@cxw0102 Sorry to hear that :/ Where would you add the switch? I'm not sure how that would prevent you from shorting 3.3V and GND... Regarding the reset button: Yes, I assume it would be useful sometimes but I left it out because of space constraints. But I guess you could easily mod one by adding a push button that pulls the EN pin to ground through a resistor.

[vroland]

@martinberlin Nice work :+1: But doesn't it use i2c? I don't see the SPI anywhere...

[martinberlin]

Yeah sure! Touch controllers are so far I2C the ones I tested. I think 2 wires are enough since they just send x,y and some additional info. I’m trying LVGL now and it looks complicated, but one SPI epaper is already drawing pixels ( no touch tested yet). I would love to find a way to make this UX library work with EPDiy and the touch together in Lilygo EPad47

[martinberlin]

New repository can be already tested with Lilygo EPD47 and 6" using EPDiy as a bridge component: https://github.com/martinberlin/lv_port_esp32-epaper Will write a tutorial and integrate the touch driver (L58)