Close
0%
0%

PaperBack: Desktop E-Paper Monitor

A secondary E-Paper desktop monitor driven by a standard monitor interface.

PK
Similar projects worth following
PaperBack is a secondary E-Paper Display on your desktop. The first revision uses a WiFi connected ESP32 to drive it. The final version will take VGA input and update at roughly .91 frames per second, 800x600, 16 bit greyscale.

E-Ink, or E-Paper has become popular for its ease of reading. Generally, E-Paper closely matches the readability of a piece of paper. We've learned more and more about the harmful effects on vision (and sleep!) from certain wavelengths of blue light as well as the eye strain issues that come from staring at backlit displays. E-Paper is a great technology to occasionally give our eyes a rest while fulfilling the need for a (moderately) dense display technology for the desktop.

E-Ink has a secondary benefit: it doesn't need to be refreshed. While each frame rewrite does take a fairly large amount of power, by carefully picking a lower framerate we'll use significantly less power than whatever you've got on your desktop today.

Targets:

  • 6" and/or 9.7" E-Paper Display
    • ED060SC4 // LB060S01 // LB060S04
    • ED097OC1
  • 800x600 or 1200x825 (Probably reduced to 1024x768)
  • User-selectable refresh rate
  • VGA and/or DVI (HDMI?) Input

Hackaday Prize Prompts:

License:

  • MIT

  • Brainstorming on Video Input

    PK5 days ago 0 comments

    The next step is taking some monitor input and getting it to display on the ePaper Display.

    I'm going with VGA - I'll try to use a MST9883 (that's what was on eBay). The canonical part is the Analog Devices AD9883; essentially it will save a lot of steps with this project. It takes RGB input and recovers a pixel clock from HSync and dumps all of the pixel colors in parallel.

    Also, there is an I²C component - EDID on VGA and settings on the MST9883. I'm going to just use a microcontroller to do these.

    Add up memory plus the MST9883 plus a couple SPI busses plus the ePD signals and you're looking at a minimum of 68 to 83 I/Os on the FPGA/BIG_CPLD (depending on color depth), probably 71 minimum to get 4-bit 'color'.

    Any suggestions on FPGAs here? I'm reasonably agnostic, I just want something reasonable with plenty of LEs.

  • Sent Out For v2 PCBs

    PK6 days ago 0 comments

    I may have missed that IoT deadline, but eye on the Prize - I'm targeting Best Product anyway.

    Above is what I've got working so far.

    I sent out for a second round of PCBs, Green/ENIG. I added a few creature comforts, but sorry to say I kept it safe and stayed with the LT1945 for high voltage generation. The TI all-in-ones still had a lot of parts and I'm not super confident I can solder unexposed leads.

    Anyway, hopefully this one doesn't need a bodge and I'll be publishing it. Here are the differences:

    • 10 Control signals (down from 10, I'm tying off RL and SHR, keeping the 3 voltage on/offs)
    • 8 Data lines
    • Switching to DPAKs on the 15V/-15V Regulators (nice to sit flat this time)
    • Adding a resistor divider to one of the ADCs on the ESP32
      • (Even though it isn't going to be part of the final build, I might keep a few around with the '32 onboard)
    • Switched some TH components to SMD

    ... and that's about it. Again, I'll publish it if I got it right this time - I don't want people to have to read all my entries to know not to build a version, haha.

    And in the meantime I'll work on the second board: converting video inputs into something that can be displayed onePaper. From what I've seen, we can make this work - probably at 1.1 frames per second maximum, heh.

  • Software and Firmware Posted on Github

    PK06/11/2017 at 04:43 0 comments

    I've put what I've got up in Github; get it while it's hot! I've got firmware for the ESP32 and my Python desktop image conversion utility so far. I'll work on something internet-ty next [Ed: see below].

    I'll go back and fill in some more comments when I get some time; hopefully it's understandable as is.

    Here are the numbers on screen clears and screen draws after my cleanup:

    # Clear the screen
    
    Clear cycle.
    Took 1075 ms to redraw the screen.
    Going active again.
    
    # Next to draw an image
    
    Draw cycle.
    Took 1531 ms to redraw the screen.

    There are probably some bugs in there, but... I'll plow ahead with that IoT (I-o-Useful-T) deadline looming [Editor: Never did get it running before Monday morning...]. Call it 1 second to clear and 1.5 seconds to draw.

  • Getting the Code Ready to Post...

    PK06/10/2017 at 18:20 0 comments

    I'm not sure how useful it'll be to you all, but I'm cleaning up and commenting my code before I post.

    I'm using the Arduino Core for the ESP32 and the standard signal names for these ePaper displays - so even though the boards aren't working, maybe you can borrow my timings or look at how I'm driving the screen. As I promised, I'll spin up another board - but since I have two more days and an ESP32 I'll be working mainly on Internet features this weekend.

    Also, I'm adding greyscale support to the display, using a similar method to NekoCal's. I use progressively greater number of refresh cycles to change the brightness of an area. I'm experimenting with 16-grays or 4-bit color and it doesn't look so bad right now.

    Once I lock that in I'll post.

    Here are my current timings so you'll know if I made progress when the code goes up:

    4 output cycles coming!
    
    // The next one is a clearscreen
    Took 1327 ms to redraw the screen.
    Did anything happen?  Adding one and trying again.
    4 output cycles coming!
    
    // The next one is drawing a picture.
    Took 6351 ms to redraw the screen.
    Did anything happen?  Adding one and trying again.
    

    And what am I drawing in those 6.3 seconds? E-Paperception, of course!

    Okay, more soon - and more speed. Stay tuned.

  • It Works! Here's the Hackaday Logo in 1 Bit Color

    PK06/07/2017 at 07:54 0 comments

    A picture is worth 1,000 words.... or in this case, 120,000 unsigned 8 bit integers.

    I'll have a better write-up soon and publish some code (c'mon, it's 1:00 AM now here), but here are the details:

    • 6" ePaper Display (this model is a LB060S01-RD02)
    • Bodged PCB (see earlier article)
    • ESP32

    Pretty excited about this - now I can turn this into an Internet of Thing while I work on the "standard monitor" part.

  • Again... Without the Oops

    PK05/31/2017 at 03:45 0 comments

    A series of (both unfortunate and scheduled) events kept me busy in the last few weeks, but I did have some time to send out v1 of the PCBs.

    Unfortunately, in my haste my schematic was (very) wrong - I messed up the negative feedback stage on the LT1945. Pretty badly too - the one I powered up is no longer with us.

    Umm, don't build this. Just shake your head with/at/near me:

    I was able to bodge a few by removing C1 and building some nonsense on protoboards, but I'll spin a new board. @Johnny Karamello suggested I take a look at TI's selections and specifically the TI TPS65185x, so I'll gather my courage and think about how to hand solder a QFP with a bottom pad (Suggestions? Big hole on the bottom, flood with flux and paste?).

    Here's a bodge in all its glory!

    All you can do is laugh... and design then spin up some new boards. I'll try to get some v1 boards going, regardless.
    Captain Steven Hiller: What do you say we try that one again?
    David Levinson: Yes, yes. Yes. Without the "oops".

    Send me your funniest/most impressive/most hacky bodges for motivation? Haha - stay tuned, I'll sort it out.

  • E-Paper Plane: The View from 36,000 Feet

    PK04/30/2017 at 22:37 3 comments

    While I would have preferred to start on a breadboard or protoboard, the fine pitch FFC on E-Paper displays pretty much rules that out. Instead, I started on the paper I've scanned in and dropped into the article above.

    The way I see it, there are four parts of this project:

    Power Supply

    This actually might be the hardest part of the project - you need to generate a hodgepodge of random voltages to drive a screen like the ED060xxx or ED097xxx:

    • +22V
    • -20V
    • +15V
    • -15V
    • 3.3V (Logic)
    • Somewhere between 0 and -2.5V (a common/contrast/reference)

    Great fun. My first shot will emulate some of the SMPS -> Linear regulator designs from other examples I've seen.

    Driver Logic

    The driver will both switch on and off the various power supplies and well as generate the data and latch combinations needed to get data onto the screen.

    The lowest risk move here is probably to get a fast, high resourced microcontroller. The project examples I linked use the ESP8266 and various STM32xxx products here.

    I think I lean a microcontroller with sufficient pins in case I do try to juice the refresh rates - we need about 15 outputs or so and I'd prefer not to push them through a GPIO expander. Maybe ESP32 here?

    Input Logic

    For my first effort, this will probably be Logic Level Asynchronous Serial. However, my final target, and what will motivate my entry is using a common display interface as input.

    I think one of DVI-A or VGA would be the most fun, since it'd require an A/D converter and reversing some timings. DVD-D (or HDMI) would require just the second bit. Of course, most modern computers will output all of those, but analog display interfaces are on the way out and dongles/converters are hated. I'll think on the fun/product/'why not both?' aspects of this one.

    If I'm particularly ambitious, maybe NTSC or PAL? Those protocols have everything mixed into the same signal, so it's add some fun analog to the project - separating color, sync, etc. I wouldn't count on this one though, even if I worked on that you'd still have pretty low resolutions. Also they're old. Give me some feedback below if you think they deserve their renaissance.

    Case / Presentation

    My 2015 entry didn't really need a case - it was just a video card on a PCB, haha. This time I'll need to take it seriously and take my first shot at what's sure to be some clumsy industrial design.

    A stand for sure, but I'd love to log some frustrating hours with the 3D Printer. Any words of wisdom here? This category has the potential to dominate all others, haha.

    For other parts of the presentation in general, I'll work up to them. As I get closer, that'll be writing up a guide, creating the video(s), packaging everything up - and possibly a web site and supporting documentation as well. Que sera, sera.

  • Answering the Hackaday Prize Prompts

    PK04/30/2017 at 21:44 0 comments

    To organize my thoughts - and, of course, hit all the contest checkmarks - let's go through the list of Hackaday Prize prompts and answer them for PaperBack.

    • Discuss the challenge the project addresses

    PaperBack addresses two main challenges - eyestrain and power consumption.

    For those of us who stare at various computer monitors too many hours a day, eyestrain can be a constant battle. We've learned that certain wavelengths of blue light can affect both your eye health and your sleep cycle. Even with some programs that can address the colors, backlights themselves can be fatiguing.

    There was a large drop in average display power consumption when the world moved from CRT monitors to the ubiquitous LCD monitors most often used today. However, even with an LCD you're doing many refreshes, sometimes of static content. Additionally, the backlights in monitors require quite a bit of power.

    • Discuss how the project will alleviate or solve the problem that the project addresses

    An E-Paper display conveniently sidesteps the blue light issue - the targets I'm evaluating will support some shade of gray. For the type of content that E-Paper does well with - slowly moving graphics or high contrast static images and text - there's no need to stare at it on your main display. If you're like me and often have an API Reference or Datasheet open on a secondary monitor, maybe parking those on an e-paper display instead would help your eye fatigue at the end of the day.

    E-Paper also requires the majority of its power when it is updating or refreshing. For static images, you could theoretically unplug the display and bring it elsewhere while retaining the image - for certain content, the power savings could be huge. Again, for an API Reference or Datasheet or some other rarely updating text or image you'd be saving power.

    Of course, the biggest gain on that side would be in the aggregate. If enough people offloaded some content to an e-paper screen - with appropriate refresh rates - you'd be talking some significant savings.

    • Discuss how the project might be world changing

    I don't foresee the world moving away from the information economy. In the future, we will be using more and more computing power, and likely will still need a physical display to convey information (until those brain to computer interfaces are ready!).

    If a different display technology is enough to save some power and reduce a bit of eyestrain, multiplied over the number of knowledge workers you'd see huge power savings... and less end-of-day headaches. In this case, the big win would be lower power and higher productivity.

    • Publish at least one (1) image illustrating how the project might be used. This may be a sketch, schematic, flow chart, rendering, or other type of image.

    Here is a clipart rendering of a secondary display. I've put some initial feature targets on it.

    For the ubiquitous ED060SC4 // LB060S01, we'd get 6" diagonally and 800x600 resolution. For the 9.7" Kindle's display, the ED097OC1, we'd get (ahem) 9.7" diagonally and an 1200x825 resolution. Either would, of course, solve the problems we'd be looking at solving.

    • Link to any repositories (e.g., Github)

    They're coming - this is just the planning stage, haha.

    • Document all open-source licenses and permissions as well as any applicable third-party licenses/restrictions

    I plan on doing everything with an MIT or Berkeley or Apache like license, so if you see a part you like you can carve it off and work on it for your own projects. That presumes, of course, that the current subsystem is compatible with those licenses - for example, the Linux Kernel Modules I worked on in my 2015 entry were GPL'd because of the kernel.


  • E-Paper Design Resources & Feasibility

    PK04/30/2017 at 16:21 0 comments

    While researching the product, I came across four excellent projects where people drove raw E-Paper displays:

    I'll stand on the shoulder of giants for this - my strategy will be to approach it in a few steps.

    1. Reproduce the results the others have had with an initial breakout.
    2. Work on the A/D or protocol decoding for some monitor interface
      1. VGA?
      2. DVI?
      3. HDMI? (Probably not, HDMI -> DVI adapters are common enough)
    3. Wrap it up in a decent looking package

    Feasibility

    Feasibility isn't an issue here, it seems that raw E-Paper displays have been driven enough times to give this a go without it being a large risk. By doing this in a modular fashion I should have a useful part even if, say, I only get through 2 out of 3 of my steps.

    As for me? I do have graphics experience from past entries - although that was emitting graphics, not consuming them, haha. See my VGATonic 2015 Graphic Card Best Product entry as well as my 2014 initial project logs.

    I'm hopeful I can get something going here.

  • Kicking around a Hackaday Prize Best Product Entry: "PaperBack"

    PK04/30/2017 at 16:05 0 comments

    As soon as I saw that the 'Best Product' category was coming back to the Hackaday Prize, I got to thinking about what product I'd like to see on the market. I kicked around a few, but after polling my wife and some coworkers, it seems that there would be some demand for a desktop E-Paper display.

    And yes, that's a product *I'd* love to have. From my perspective, I'd love to have a secondary monitor where I can park slow moving graphics or static text and images. Something small and readable would be perfect for API References and Datasheets - the sorts of things I'm staring at late at night, haha.

    The Market Potential and Prior Art

    I did some searching on what's out there in the marketplace.

    The current gold standard for a secondary e-ink display is the Paperlike, a 13.3" E-Ink display. It is fully spec'd out with tons of features and display modes, a beautiful stand, and a reasonably sized team backing it. The current tradeoff is the pricetag: only a pre-order on a second batch is open right now, but I believe the cost is somewhere north of $1,000 (please correct me if that's wrong!).

    Optionally, you could also get a developer kit and build out the driver yourself. One nice large-format example is Visionect's developer kits for 32" and 42" displays. That's a size where you could theoretically replace your primary monitor - but again, you're looking at a few thousand dollars.

    As for competing technology, the cheapest somewhat comparable class of displays is reflective displays. Think your Game Boy Color or perhaps more recently the Pebble Smartwatch: color displays that perform well in direct sunlight.

    Market Demand

    While you don't necessarily need to validate your exact product versus the market (Henry Ford's possibly apocryphal "If I had asked people what they wanted, they would have said faster horses."), it's nice if you see some demand.

    Well, you don't even need to leave Hacker News to see the demand. [1] [2] [3].

    Also, again, I could use one. That's a factor I overweight, haha.

    Would It Make a Good Product?

    I think PaperBack would be a good entry.

    My target specifications are modest:

    • Use a ubiquitous 6" and/or 9.7" E-Paper display.
    • Use VGA, DVI, HDMI or some common input as input.
    • 800x600 or higher resolution.
    • Some grayscale levels.

    ... perhaps even 9.7" is a bit small for a primary display (noticed that the smallest laptops you can generally buy are 10.1"?) but as a secondary display those sizes work well for some definitions of well.

View all 10 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates