ZBD EPOP Blade-C E-Ink Displays - Page 1
Forum section: electronics / projects

author: Richard RT
author_rank: Newbie
timestamp: November 26, 2018, 04:37:56 pm
content: Hi!I have ended up with a shedload of the above displays, as detailed athttp://www.realitytech.co.uk/rich/?p=231I'd really like to get some use out of these as not only are they nice high res displays they are true bistable displays, eg update the display and then leave it, no refresh needed or constant power.I can think of dozens of uses for this and reaching out to the manufacturer (predictably) got no response so I plan on reverse engineering these. Having popped the lid there isnt a whole lot under there. An RF Tranceiver with the pinout labelled (Thank you ZBD). An Atemga16L8AU with no CP bits set (Thank you again!), an EEPROM and then some power circuitry topped off with a Lithium primary cell.I've managed to capture data from the modem as I got the programmer too! What I can see looks very much like some form of RLE image data so it *looks* like we are just sending a raw bitmap. My breif attempt at decoding RLE data didnt work out too well. I've also tried recording the serial stream and replaying it to no avail.My Target for now is going to be getting the ins and outs of the protocol and leaving the 16L8 as it is, I don't know my way round the AVR well enough to go down that rabbit hole. The modem is built around a Nordic Semi nRF9E5 and spits out plain TTL serial. Each unit has a unique serial number so you can address each one. I'm not sure where/how the serial is set at this time, if it is at the modem level or in the 16L8.So I'm open to any ideas or suggestions as I go digging. Hopefully I can get these working in a useful way as I have a number of projects they would be ideal for. If someone else wants to have a crack at one please say, however I dont know if there would be any point without a controller and I only have the one right now.If someone DOES fancy decompiling the firmware (I think the nRF Firmware is 8085 and on a EEPROM of it's own) The SPI port for the 16L8 is exposed on a test connector, yell and I can drop a couple in the post.R

author: mark03
author_rank: Frequent Contributor
timestamp: November 27, 2018, 02:41:22 am
content: I know that for the E-Ink displays in older Kindles (and maybe new ones too? I haven't kept up), there are special "waveforms" used to manipulate the display. There was often some nonvolatile storage dedicated to this purpose, e.g. along the flex connecting the display to the motherboard, and the information about them was highly proprietary. I don't know if this is still true today, especially on smaller/simpler displays like these.I seem to recall reading another E-Ink hacking journey on the web several years back. Can't find it at the moment. But enough work has been done that I think your goal is very achievable.Sorry I can't offer more specific suggestions. If you know of a state-side supply of these things, please post it here. I too have projects this would be good for. Low-power display tech is one of those things that perennially never makes it into low-volume sales channels---very frustrating! Digikey is apparently to begin sales of JDI color MIP (memory in pixel) panels next year, although like most display tech they are ridiculously expensive in single quantities.

author: DaJMasta
author_rank: Super Contributor
timestamp: November 27, 2018, 04:34:20 am
content: They do need specific waveforms to change pixels, and generally wipe the screen a few times to reset before rewriting. Don't know about these specifically, but I know there are shields/hats for attaching eInk displays to RPi or Arduino projects, and I think the general scheme for them is to just output digital data to the display module then rely on a chip on the display to do the actual driving of the display. If you take it apart and there's a chip on the flex or on the glass, that's probably it, but it could be a chip on the PCB, and if you're unlucky, it could be just integrated into a single chip with whatever micro they're controlling it with. At that point you'd have to figure out how to reprogram the driver IC and hope it's not a PROM, or you could try to sample the required waveforms in a scope and recreate them with DACs to drive the display directly. Since it's only a monochrome screen and not one of the fancier multicolor ones, the waveforms may actually be simpler, so if you end up with a direct drive to the screen itself, you may be able to just try some waveforms in a sig gen and arrive at something reasonable.Well, seeing as you've opened one, the arduino likely isn't making any waveforms itself (unless you see some crude R2R DACs), so it's probably driving another chip built into the eInk module itself. The AVR rabbit hole is probably one of the best documented ones out there, the original Arduino boards used ATMega168s, so getting code up and running on one could be VERY simple and there could be sample sketches for driving common eInk displays.

author: Richard RT
author_rank: Newbie
timestamp: November 27, 2018, 02:25:13 pm
content: If you've followed the link, I've done a lot more digging and have now actually got Arduino code over there and running, this makes pooking around the pins easier.I've also got the driver chips and the pinout for the LCD cracked along with the connection to the 16L8 for the column drivers.Will get the wiring for the row drivers sorted out and then break out the logic anaylyser and scope. Looking at how the units are wired there isnt a lot of complex manipulation going on.There is a power supply section and this seems to be driven from the 16L8 although there do seem to be signs of a boost convertor in there too.Having "sucked the brains out" of the 16L8 I can also confirm that it is handling addressing so it looks like the tranceivers are just dumb devices as far as the rest of the board are concerned. That alone along with the micro and ultra low poer use makes these handy even without the display. Mark03 let me get a bit more info dug out on these and see if I can at least get a test pattern out then I can mail you a couple.

author: technix
author_rank: Super Contributor
timestamp: November 28, 2018, 04:47:33 am
content: E-ink: something I will not work with. There are only a few manufacturers making them, and all of which requires you sign a NDA and tell them a good amount about your project before they would send you the required driver files and waveform files. And oh that waveform file is a big binary blob that you don’t get the specs about.

author: mark03
author_rank: Frequent Contributor
timestamp: December 12, 2018, 07:14:05 pm
content: I have been intrigued by EPD (e-ink) displays for some time. I had some free time last week and this thread really sent me down the EPD rabbit hole. Thanks a lotIf simple black+white driving is the goal, there are now a few DIY projects out there showing how to drive EPDs from the e-reader market. Six-inch displays, ED060xxx type, can be had on Ebay for anywhere between $20-$60 each depending on vintage, resolution, integrated touchscreen and/or front light. It looks like these are eminently driveable with a little research. The pinouts vary but if you can find a so-called datasheet on the web, it should be possible as the basic drive scheme seems to be the same for all of them. (The datasheets suck uniformly but this is standard in the display industry, not just EPD.)One thing that surprised me is the energy consumption of these things. Instantaneous power can be quite huge during a display update (on the order of watts for the higher-resolution E-Ink Carta displays, or around a watt for the older E-Ink Pearl). Given that a display update is not *that* quick, you are looking at perhaps a joule per update on the e-reader displays. Partial-update technology will reduce energy consumption somewhat, but is harder to pull off well, which is why there is so much secrecy around the all-important "waveforms," to the point that even the EPD controllers in, e.g. i.MX application processors are essentially undocumented. There is a chapter in the reference manual, of course, but the controller requires waveform data in the form of a binary blob which is undocumented. From Linux kernel drivers we can ascertain that the blob contains waveforms that go from one grayscale value to another, for various panel temperatures, but no one has figured out how to dump the contents and actually study the waveforms. Assuming that you could get your hands on the waveforms or design your own, actually pulling off a proper controller is no picnic either: you basically need to track the state of every pixel over tens of display scan cycles, much trickier than a simple framebuffer.The industrial panels from Pervasive Displays, and this one from ZBD, seem to have lower energy requirements, but seemly obvious specifications like "average joules per full-screen update" are shockingly hard to come by. I am not sure if the power scales only with pixel count, or if there is a further penalty for smaller pixels. This would be interesting to know.All in all, I think the memory-in-pixel (MIP) LCD technology is more promising for applications where your display updates more than once a minute. (Apples and oranges, of course, there are many other differences.) Unfortunately, the cheapest way to get your hands on either of these technologies (EPD or MIP LCD) is often to buy some used electronics, strip out the display, and throw the rest away, so I am hoping for increased uptake of MIP displays. A strange world we live in

author: technix
author_rank: Super Contributor
timestamp: December 12, 2018, 07:40:20 pm
content: If you managed to get that waveform file, for example extracted from the device you took it out of, you might be able to roll your own PCB even with a MPU that does not officially support it, for example the Raspberry Pi or Allwinner chips. There are separate EPD controller chips from Epson and with some Google-fu you can find the docs.

author: grythumn
author_rank: Contributor
timestamp: December 12, 2018, 08:43:32 pm
content: Ben (Applied science) played with shortening the update waveform to improve refresh in one of his videos. Lots of links in the show notes:https://benkrasnow.blogspot.com/2017/10/fast-partial-refresh-on-42-e-paper.html-Bob

author: mark03
author_rank: Frequent Contributor
timestamp: December 12, 2018, 09:12:04 pm
content: Quote from: technix on December 12, 2018, 07:40:20 pmIndeed, and this was my line of thinking for a while. I glossed over this in my summary, but there is a guy who made a start on decoding the waveform data as part of his project:https://github.com/julbouln/ice40_eink_controller/tree/master/utilsI did not have much luck with his code and the handful of .wbf files I could find... seems like more reverse-engineering is required. And then I thought, wait, here I was looking for a low-power display to go with my project, and it is turning into a major project all by itself. Maybe time to step back...

author: amyk
author_rank: Super Contributor
timestamp: December 13, 2018, 02:42:36 am
content: Forget about the official docs and NDA; figure out the (not too complex) waveforms and you can go beyond the official capabilities:https://hackaday.io/project/11537-nekocal-an-e-ink-calendar/log/72153-can-you-get-32-level-grayscale-out-of-an-e-ink-display...but the ZBD displays aren't e-ink (electrophoretic) displays, the title is misleading; they're just regular LCDs with a bistable crystal. In fact, given that the datasheets for the row and column drivers are available, this isn't really an exercise in reverse-engineering so much as it is one in normalforward-engineering; all the data is available, you just need to make use of it. I suspect the bistable crystal just means it will retain whatever is last written without the need for a continuous refresh.

author: Richard RT
author_rank: Newbie
timestamp: December 20, 2018, 09:25:43 pm
content: The tech is this:https://en.wikipedia.org/wiki/Cholesteric_liquid_crystalThe drivers are well documented. I now have the wiring to ATMEGA Pins, so its having the time to sit down and do some tinkering. I want to poke about with the radios to and see if they can work as true tranceivers.Having just won a huge contract I have SIP PA Amplifiers, NVR and power management units to design so not had chance yet