Electronics > Projects, Designs, and Technical Stuff
ZBD EPOP Blade-C E-Ink Displays
(1/3) > >>
Richard RT:
Hi!

I have ended up with a shedload of the above displays, as detailed at http://www.realitytech.co.uk/rich/?p=231
I'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
mark03:
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.
DaJMasta:
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.
Richard RT:
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.

technix:
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.
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod