electronic ink failure report

[depot]

I thought I'd try putting together an eink project based on other projects at essentialscrap and spritesmods.  When I write rows to it though, every row covers the entire screen in succession -- or that's what it looks like now.  I can easily make vertical stripes like in this sample picture though.  It looked like CKV was the pin that drove row changes?  I had thought it'd be an easier version of normal display hardware.  Another problem for the future would be disconnecting the power supply -- the eink is bistable but I think I need to disconnect the 20v instantly instead of letting it decay for the image to stay crisp.

image link

Not a terrible way to blow a hundred bucks and hours and hours of spare time though.  Was super happy that KiCAD has "push" for routing dense traces.

I've put it on github so anyone can see my mistakes.  This isn't my first project but an early one.  And like I said in the readme, there are a few mistakes in that project and the schematic for it as you can see with my jumper wire in the upper right.

I don't know what kind of help I would like--possibly the whole approach is wrong and I should just use an easy driver part for it.  I was hoping to learn something about driving displays myself for some reason.  Mostly I want to work on something else for a bit but it'd be neat to have a better description of how the thing is supposed to work (why can't I control the rows!) since apparently two blog write-ups and the logic analysis of a working thing isn't enough for me yet.  I suspect I'll bang on it again later though. 

I wasn't expecting this much effort for the thing though!  I'll have to remember this when it comes to project management.

[deon]

Sorry, don't have time to study the schematics at the moment. Did you use essentialscrap or spritesmods latest design? I built mine on the essentialscrap design and I have trouble with certain panels and also fading of the display.

Can you display anything other than the "lines" shown in the picture.

It's been a while since I built mine, but think I had similar problems with certain panels showing lines like that

My intention is to soon build a new board based on spritesmods to improve panel comparability and hopefully fix the fading issue

[amyk]

When I write rows to it though, every row covers the entire screen in succession -- or that's what it looks like now.

Are you making sure only a single one bit gets clocked into the column driver? It's a shift register with one output for each of the row's gates, and you should be driving it so it outputs 0000...0000 -> 1000...0000 -> 0100...0000 etc., selecting each row at a time. The symptom you're seeing suggests you're shifting in more ones so it's outputting 0000...0000 -> 1000...0000 -> 1100...0000 -> 11100...0000 etc. which will eventually cause all the rows to respond to the column data being shifted in.

I wrote a little more explanation on driving waveforms (the pixel data itself) and how to get grayscale here: https://www.eevblog.com/forum/microcontrollers/interfacing-epd-(e-ink)-display-from-kindle-anyone-tried/msg557842/#msg557842

[depot]

That thread looks super helpful as I am using ED060SC4.  And I made mine based on sprites mods for the hardware as it looked more recent of the two projects and had the oscilloscope outputs.  It does fade after removing power, but it looks better if I disconnect the FPC connection before the power supplies decay.

What you (amyk) say about the column driver makes sense.  I can change the order of the vertical lines but everything shows up as vertical lines down the screen.  I'm confused about what pins connect where though.

There's a CL pin which IIRC is the clock for the 8 bits of data going directly to transistors in the display.  And the U1 and U2 CKV pins are the clocks for the gate drivers?  For every CKV clock flip, I also flip LE and SPH.  I thought that was normal for writing a row, as described here: http://essentialscrap.com/eink/waveforms.html

So which is the column pin?  Is SPV the one I'm looking for a single pulse high to control the column?  In both the example projects, they pull it low briefly at the start of a "frame" and never pull it low again.  It doesn't look like it's OE or LE.

I have seen some funny things with this PIC32 where some compiler optimization prevents my pin controls from happening.  If I am expecting something wrong with some pin, that might be part of it.  I'll look at it with an oscilloscope tomorrow at work.  It's a simple thing to check at least.

[amyk]

Look at the LH1692 datasheet linked from the other thread, and study the waveform carefully - SPV is an active-low input to the vertical shift register, so if you want to select only one row at a time, it needs to be low for one clock pulse, then remain high for the rest of the frame. It goes low again for one pulse at the start of the next frame. You can think of it as like a Vsync.

For the fading, you should try sending a full frame of Vss, as that drains away any charge differences between the electrodes to stop any further electrophoresis of the pixels. Otherwise the remaining charge leaks out slowly and redistributes itself when you turn off the power, causing the pixels to change. I'm pretty sure the "official" waveform files do that too. This is a datasheet for a slightly different driver but is worth reading just for the driving waveform description:

http://www.onsemi.com/pub/Collateral/ENA2223-D.PDF

The best part about EPDs is they have no minimum drive frequency, so you could wire everything up to pushbuttons and mainpulate/visualise the signals at "human speeds" while watching the display change.