3 ms·

60Hz for total, full screen refresh would indeed be a staggering feat, however I don't believe that's what these figures are. One of the things that makes e-in

60Hz for total, full screen refresh would indeed be a staggering feat, however I don't believe that's what these figures are. One of the things that makes e-ink so hard in the first place is the multiple and proprietary algorithms for doing partial paints or clears on the screen in the most time-optimal way. I can only assume the 60Hz figure refers to a partial paint on screen, so "60Hz refresh of the line you're drawing", not "60Hz fullscreen video". That, or it's 60Hz with incredible ghosting, which I believe has been done before.

megous 5y ago
60Hz at that resolution would be ~20 MHz on a 16bit parallel bus (2bits per pixel), which sounds about manageable. The display spec says the display has max 85Hz raw refresh rate. https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED103TC2%20Formal%20Spec%20V1.0_20190514.pdf https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED...
- spijdar 5y ago
  You're correct; another project using this display panel documented their process towards getting it running: https://www.zephray.me/post/archer_bringup_notes https://www.zephray.me/post/archer_bringup_notes They go into some detail on the display and getting it to display a picture, along with some pitfalls. Worth a read for anyone else interested.
zozbot234 5y ago
"Multiple and proprietary algorithms"? It's just an ordinary control problem, how hard can it be to come up with an openly-available solution? Ultimately, quality/latency/etc. will be a matter of how much effort the user will put in calibrating the driver to their screen.
- spijdar 5y ago
  I've not worked in this space, but see: https://news.ycombinator.com/item?id=17993174 https://news.ycombinator.com/item?id=17993174 and https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declara... for a description of some available display modes within a waveform table, along with a description of the waveform firmware itself: The waveform flash memory file contains temperature look-up tables (LUTs), waveform sequence data, algorithm data, voltage data, controller settings, and manufacturing data. Each AF waveform is specifically adjusted for a particular display module lot. This specification document is for use by E Ink Corporation and their customers under non-disclosure agreements. E Ink Corporation will be responsible for maintaining and controlling specification revisions. To my knowledge, there are very few reverse engineered waveform files or custom controllers for eink displays, and those that exist have inferior display properties compared to the e-ink provided waveform tables.
- megous 5y ago
  Inputs: temperature, particular display's batch characteristics, what you want to draw, what was drawn on the display in the past, available timing options for how long you can leave gate open for each row, vcom voltage, other voltages (there are 4), how long since last full refresh clear, ... It's not so much of a problem to have a nice output if you can always do a full screen clear and then paint your image. But that's quite power intensive thing to do and disruptive to the user. Other than that, with no prior knowledge or know how from eInk, you'll be struggling with previous image reappearing from the dead in parts of the display even after "full screen clear" after a few updates, ghosting, grayscale support, and crap like that. And you'll have to do all the calculations in real-enough time on a CPU so that you can keep up with raw refresh rate requirements (85Hz). On this high a resolution it will probably be quite a lot of work, and you'll need to code everything up in NEON C intrinsics or assembly. So while it may be an ordinary control problem, it will be a bit of a struggle. I'm not aware of anyone going this deep. Most of the semi-open implementations are using proprietary waveform data/violating GPL (Pocketbook) with a closed source kernel driver/or hiding the complexity in the HW controller. It will certainly be interesting to watch how will people deal with this, because it will need a unique intersection of knowledge and dedication. I guess whatever display controller is in the SoC will help with some of that in some way. But it will still be quite complicated, because it's undocumented, and the driver is only available as a binary blob.
- solarkraft 5y ago
  I follow EPDiy, a project to drive ED097OC4, ED060SC4 and ED097TC2 displays with an ESP32 [0]. While I’m not going to shrug off Valentin’s work as trivial, it doesn’t seem like magic. The hype around the difficulty driving e-ink displays appears over-hyped. There may be many details to get it perfect, but displaying a basic (pretty good!) image does seem to be quite doable. [0]: https://hackaday.io/project/168193-epdiy-976-e-paper-controller https://hackaday.io/project/168193-epdiy-976-e-paper-control...

megous 5y ago

60Hz at that resolution would be ~20 MHz on a 16bit parallel bus (2bits per pixel), which sounds about manageable. The display spec says the display has max 85Hz raw refresh rate. https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED103TC2%20Formal%20Spec%20V1.0_20190514.pdf https://files.pine64.org/doc/quartz64/Eink%20P-511-828-V1_ED...

spijdar 5y ago
You're correct; another project using this display panel documented their process towards getting it running: https://www.zephray.me/post/archer_bringup_notes https://www.zephray.me/post/archer_bringup_notes They go into some detail on the display and getting it to display a picture, along with some pitfalls. Worth a read for anyone else interested.

zozbot234 5y ago

"Multiple and proprietary algorithms"? It's just an ordinary control problem, how hard can it be to come up with an openly-available solution? Ultimately, quality/latency/etc. will be a matter of how much effort the user will put in calibrating the driver to their screen.

spijdar 5y ago
I've not worked in this space, but see: https://news.ycombinator.com/item?id=17993174 https://news.ycombinator.com/item?id=17993174 and https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf https://www.waveshare.net/w/upload/c/c4/E-paper-mode-declara... for a description of some available display modes within a waveform table, along with a description of the waveform firmware itself: The waveform flash memory file contains temperature look-up tables (LUTs), waveform sequence data, algorithm data, voltage data, controller settings, and manufacturing data. Each AF waveform is specifically adjusted for a particular display module lot. This specification document is for use by E Ink Corporation and their customers under non-disclosure agreements. E Ink Corporation will be responsible for maintaining and controlling specification revisions. To my knowledge, there are very few reverse engineered waveform files or custom controllers for eink displays, and those that exist have inferior display properties compared to the e-ink provided waveform tables.
megous 5y ago
Inputs: temperature, particular display's batch characteristics, what you want to draw, what was drawn on the display in the past, available timing options for how long you can leave gate open for each row, vcom voltage, other voltages (there are 4), how long since last full refresh clear, ... It's not so much of a problem to have a nice output if you can always do a full screen clear and then paint your image. But that's quite power intensive thing to do and disruptive to the user. Other than that, with no prior knowledge or know how from eInk, you'll be struggling with previous image reappearing from the dead in parts of the display even after "full screen clear" after a few updates, ghosting, grayscale support, and crap like that. And you'll have to do all the calculations in real-enough time on a CPU so that you can keep up with raw refresh rate requirements (85Hz). On this high a resolution it will probably be quite a lot of work, and you'll need to code everything up in NEON C intrinsics or assembly. So while it may be an ordinary control problem, it will be a bit of a struggle. I'm not aware of anyone going this deep. Most of the semi-open implementations are using proprietary waveform data/violating GPL (Pocketbook) with a closed source kernel driver/or hiding the complexity in the HW controller. It will certainly be interesting to watch how will people deal with this, because it will need a unique intersection of knowledge and dedication. I guess whatever display controller is in the SoC will help with some of that in some way. But it will still be quite complicated, because it's undocumented, and the driver is only available as a binary blob.
solarkraft 5y ago
I follow EPDiy, a project to drive ED097OC4, ED060SC4 and ED097TC2 displays with an ESP32 [0]. While I’m not going to shrug off Valentin’s work as trivial, it doesn’t seem like magic. The hype around the difficulty driving e-ink displays appears over-hyped. There may be many details to get it perfect, but displaying a basic (pretty good!) image does seem to be quite doable. [0]: https://hackaday.io/project/168193-epdiy-976-e-paper-controller https://hackaday.io/project/168193-epdiy-976-e-paper-control...