- Der 13,3-Zoll-Eink-Monitor aktualisiert sich mit 60 Mal pro Sekunde bei 300 ppi und wurde nach vier Jahren eigener Controller-, Hardware- und Firmware-Entwicklung zu einem realen Produkt
- Bestehende Eink-Controller tauschen wegen einer Wartezeit von etwa 100 ms pro globalem Update Geschwindigkeit gegen Kontrast, während ein pixelweises Updateverfahren geänderte Pixel sofort aktualisiert
- Pixelweises Aktualisieren erhöht bei einer 13-Zoll-Schwarzweißanzeige die benötigte Bandbreite von 20 MB/s auf 540 MB/s, wodurch DDR3 und DisplayPort erforderlich werden
- Graustufen ohne Blinken sind nicht möglich, daher werden Bayer-Dithering, Blue Noise, Error Diffusion und ein hybrider Anzeigemodus kombiniert
- Das Endergebnis ist ein Eink-Monitor mit hoher Bildwiederholrate mit Touchscreen, Frontlicht, Farboptionen, mehreren Anzeigemodi sowie Open-Source-Hardware, FPGA-Gateware und Firmware
Ausgangspunkt: Vom Eink-Laptop zum eigenen Controller
- Der 60fps-Eink-Monitor arbeitet mit 300 ppi und aktualisiert sich 60 Mal pro Sekunde, obwohl Eink nicht gerade für Geschwindigkeit bekannt ist
- Ausgangspunkt der Entwicklung war ein Eink-Laptop, und die SoCs mit Eink-Unterstützung waren damals für E-Book-Reader ausgelegt und dadurch an niedrigen Stromverbrauch, langsame Prozessoren und begrenzte Schnittstellen gebunden
- Um einen Laptop zu bauen, mussten SoC und Display voneinander getrennt werden, und dazwischen war ein FPGA-basierter Treiberchip nötig, also eine Architektur mit einem eigenen Eink-Controller
- Im frühen Laptop-Design gab es ein stabförmiges LCD, das wie eine große Touch Bar funktionierte; die Annahme war, dass für einige Aufgaben ein schnelles Display nötig ist, während Eink langsam sein darf
- 60fps war anfangs nicht das Hauptziel; es musste nur schnell genug für einen Laptop sein, und wenn 60fps nicht möglich wären, wären auch 15fps ein akzeptables Ziel gewesen
Geschwindigkeit und Qualität durch pixelweise Updates
- Herkömmliche Eink-Controller verwenden einen globalen Update-Timer und warten beim Aktualisieren des Bildschirms, bis das vorherige Update abgeschlossen ist
- Ein herkömmliches Update dauert etwa 100 ms, sodass im schlimmsten Fall bereits 100 ms gewartet werden muss, bevor ein neues Bild überhaupt verarbeitet wird
- Lässt man den Timer schneller laufen, steigt zwar die Framerate, aber die Eink-Partikel haben nicht genug Zeit zu reagieren, sodass das Bild wie ausgewaschen wirkt
- Der bisherige Ansatz erzwingt einen Kompromiss zwischen Bildwiederholrate und Kontrast; manche Controller mildern das, indem sie 4 bis 16 Bereiche unabhängig voneinander aktualisieren
- Diese bereichsbasierte Abschwächung verlangt, dass die Software die Bereiche direkt verwaltet, und hat weiterhin ihre Grenzen
- Das pixelweise Updateverfahren behandelt jedes Pixel wie einen unabhängigen Update-Bereich, und jedes geänderte Pixel beginnt sofort mit der Aktualisierung, ohne zu warten
- So lassen sich hohe Frameraten und hoher Kontrast gleichzeitig erreichen, wodurch der bisherige Kompromiss zwischen Geschwindigkeit und Qualität entfällt
- Der Nachteil ist die Speicherbandbreite: Bei einem 13-Zoll-Panel benötigt ein herkömmlicher Controller für ein Schwarzweißbild 20 MB pro Sekunde, dieses Verfahren aber 540 MB pro Sekunde
- Wegen der hohen Bandbreitenanforderungen wird statt einfachem SDRAM DDR3 benötigt und statt USB DisplayPort, was die Kosten erhöht
- Zum Lesen von Büchern ist diese Konfiguration unnötig, als Monitor macht sie jedoch einen großen Unterschied
Anzeigequalität: Dithering und hybride Graustufen
- Das Projekt verlagerte sich vom Laptop hin zu einem guten Monitor und wurde danach über mehrere Jahre in der Freizeit weitergeführt
- Da Eink Graustufen nicht blinkfrei darstellen kann, war Dithering unverzichtbar
- Implementiert wurden drei Dithering-Algorithmen: Bayer-Dithering, Blue Noise und Error Diffusion
- Bayer-Dithering ist schnell, erzeugt aber sichtbare Muster; Blue Noise sieht besser aus; Error Diffusion liefert die beste Qualität, lässt sich aber nur schwer auf hohe Auflösungen skalieren
- Dithering funktioniert, geht aber nicht über echte Graustufen hinaus; die Ausnahme waren blinkende Graustufen
- Bestehende Monitore setzten entweder einen langsamen Blinkmodus um oder übersprangen Graustufen vollständig
- Der hybride Ansatz wechselt bei Bildänderungen in einen schnellen Binärmodus und rendert nach einer kurzen Stabilisierung wieder in Graustufen
- Das eignet sich gut zum Lesen, ist für andere Einsatzzwecke aber weniger passend; dank des eigenen Controllers war man nicht an voreingestellte Modi gebunden und konnte stattdessen je nach Anwendungsfall optimieren
Hardware-Iterationen und der Weg zum Produkt
- Der erste Prototyp nutzte DisplayPort in voller Größe und wechselte später zu USB Type-C mit DisplayPort
- Als ein integrierter Power-Management-IC abgekündigt wurde, musste auf einzelne DC-DC-Wandler umgestellt werden
- Um das Display vor unerwarteten Latch-up-Ereignissen zu schützen, wurde auf dem Board eine vollständige Spannungs- und Stromüberwachung ergänzt
- Jede Änderung erforderte eine neue PCB-Revision, und jede Revision brachte neue Erkenntnisse
- Als der erste Gehäuseentwurf vom Auftragsfertiger zurückkam, sah es plötzlich nicht mehr nach einer freiliegenden PCB auf dem Schreibtisch aus, sondern wie ein echtes Produkt
- Das Gerät wurde auf Hackaday Supercon, LatchUp und bei der Teardown-Veranstaltung von Supply vorgeführt, und die Leute wollten, dass es wirklich erscheint
- Da die Technik funktionierte, Nachfrage vorhanden war und auch ein Design existierte, wurde für den letzten Schub der Job gekündigt
- Der Plan war, sich einige Monate lang voll darauf zu konzentrieren, das Design zu verfeinern, zu fertigen und auszuliefern
Komplett neu entworfen, Lieferantenprobleme und die finalen Funktionen
- Kurz nach dem Wechsel in die Vollzeitentwicklung kündigte Eink ein neues Panel mit höherer Auflösung, besseren Spezifikationen und niedrigerem Preis an
- Das neue Panel konnte zu einem besseren Produkt führen, erforderte wegen der höheren Auflösung aber einen Decoder-IC mit hoher Bandbreite, High-Bandwidth-DDR-Speicher, ein neues FPGA und eine Stromversorgung mit höherer Stromstärke
- Diese Änderung kam praktisch einem Austausch fast des gesamten Boards gleich und verursachte eine Verzögerung von mindestens einem halben Jahr
- Beim finalen Produkt wurde der bisherige Ablauf aufgegeben, zuerst das Board zu entwerfen und danach das Gehäuse anzupassen; stattdessen wurden Formfaktor, Chassis, genaue Maße und Montagepunkte zuerst festgelegt und das Board daran angepasst
- Dieser neue Ansatz machte das Gesamtdesign besser optimiert und konsistenter, erforderte aber erneut eine große Revision
- Ein vollständig montierter Prototyp wurde auf der Design Shenzhen gezeigt, war zum Ausliefern aber noch viel zu instabil wegen zufälliger Glitches, Bildaussetzern und fehlgeschlagenen Initialisierungen
- Der Lieferant des Videodecoder-Chips verweigerte trotz NDA und Servicevertrag jede Hilfe und hatte von Anfang an keinen Treibercode bereitgestellt
- Für den Quellcode zur Nutzung des Chips musste zusätzlich bezahlt werden, doch der Code funktionierte nicht, und für funktionierenden Code wurde noch mehr Geld verlangt
- Später wurde zu einem anderen Lieferanten gewechselt, mit dem die Zusammenarbeit deutlich besser war, aber zu Beginn des Projekts war dieser Chip noch nicht verfügbar
- Danach kam Touchscreen-Unterstützung hinzu, was die Integration eines neuen Touch-Controllers, das Schreiben von Treibern und die Kalibrierung erforderte
- Ergänzt wurden außerdem ein flimmerfreies Frontlicht, ein Framerate-Limiter für bessere Schärfe, ein Low-Power-Modus zum Stromsparen ohne angeschlossene Stromversorgung und ein On-Screen-Display zur Steuerung dieser Funktionen
- Jede dieser Funktionen klingt in einem Satz einfach, brauchte in der Praxis aber mehrere Wochen, und die Ziellinie verschob sich ständig
- Seit dem Wechsel in die Vollzeitentwicklung wurde noch mehr gearbeitet als zuvor im Angestelltenverhältnis; die Grenzen zwischen Nächten und Wochenenden verschwammen, und für Spiele und freie Zeit blieb weniger Raum
- Wer selbst entscheidet, kann Dinge sofort umsetzen; ist ein Problem gelöst, bleibt es gelöst; und um ein Feature zu implementieren, muss niemand anders erst überzeugt werden
- Nach vier Jahren ist das Ergebnis ein 13,3-Zoll-Monitor mit bis zu 60fps, sehr niedriger Latenz, mehreren Anzeigemodi, Touchscreen, Frontlicht und Farboptionen
- Hardware-Design, FPGA-Gateware und Firmware sind vollständig Open Source, sodass man das Gerät auch selbst bauen kann
1 Kommentare
Lobste.rs-Meinungen
Ich habe Alex dieses Jahr auf der FOSDEM getroffen und diese Demo gesehen; sah ziemlich gut aus
Es ist zwar noch ein Prototyp und auch das Gehäuse ist noch nicht fertig, daher war ich nicht völlig überzeugt, aber es wirkte sehr vielversprechend, und mein nächster E-Ink-Kauf wird vermutlich ein Produkt von modos sein
Ich habe noch ein Development Kit, das ich damals über die Crowd-Supply-Kampagne bekommen habe; falls jemand neugierig ist, kann er gern fragen
Mich würde auch interessieren, wie der Kontrast bei hellem Sonnenlicht ist und ob es auf der Software-Seite irgendwelche Probleme gab
Ein wirklich tolles Display. Ich fände es gut in einem Laptop oder Tablet, aber ich bin mir nicht sicher, ob ich für ein kleines externes Display allein Verwendung hätte
Die Erklärung „Unterwegs kann Flow mit nur einem USB-Type-C-Kabel mit bis zu 40 Hz betrieben werden, am Schreibtisch lässt sich mit zusätzlicher Stromversorgung die volle Bildwiederholrate von 60 Hz nutzen“ klingt etwas seltsam
Ich konnte keine Leistungsaufnahme finden, aber über ein einziges USB-C-Kabel kann sogar ein kompletter High-End-Laptop mit Strom versorgt werden; da erscheint es merkwürdig, dass ein einzelnes Display mehr verbrauchen sollte
Desktop-Monitore mit AC/DC-Eingang können PD mit 60 W oder 100 W ausgeben, aber mein Laptop gibt kein PD aus
Ich habe eine Kamera, die nur per PD geladen wird; sie verbindet sich zwar problemlos per USB-C mit dem Laptop, aber Laden geht nicht, weil sie etwa 25 W oder 30 W braucht
Andererseits funktionieren andere tragbare Monitore bei mir zu Hause nur über USB-C vom Laptop. E-Ink braucht zum Zurücksetzen der Zellen Spannungen über 5 V, daher könnte der Step-up bei 60 Hz einfach zu viel Strom verbrauchen
Das ist etwas schwer zu glauben. So wie ich es verstehe, sind niedrige Frameraten im Grunde eher eine Software-Grenze als eine Hardware-Grenze; warum hat sich das dann noch nicht viel stärker verbreitet?
Es gibt auch wenig Grund, teurere Controller einzubauen, die Kunden nicht brauchen, und wenn man E-Ink aggressiver ansteuert, verkürzt sich die Lebensdauer, womit sich das gesamte Wertversprechen verändert
E-Ink-Displays sind ohnehin teuer, wegen Patentkosten und anspruchsvollem mechanischem Design. Es ist ein bisschen so, als könnte man einen Toyota Corolla auf 150 mph bringen, müsste dafür aber interne Komfortkomponenten verändern, einige Sicherheitsvorkehrungen entfernen, und bewegliche Teile könnten schon nach einer einzigen Runde kaputtgehen
Letztlich stimmt zwar der Satz „jede Hardware ist ein Algorithmus und beginnt daher als Software“, aber beim E-Ink-Bereich ist der Controllermarkt nie an die über Jahrzehnte gereiften Märkte für DVI- oder VGA-Controller herangekommen
Alex’ Arbeit ist Open Source, daher halte ich es für gut möglich, dass das in nicht allzu ferner Zukunft irgendwann in größerem Maßstab reproduziert wird
Es scheint eindeutig Nachfrage nach reflektiven Bildschirmen mit hoher Bildwiederholrate und hohem Kontrast zu geben. Ich frage mich nur, warum die meisten Ansätze darauf hinauslaufen, „normales E-Paper irgendwie zu verwenden oder umzubauen“
Warum bauen Hersteller keine reflektiven LCD-Panels über 6 Zoll nach dem Vorbild der Sharp-Memory-Display-Familie?
Nebenbei bemerkt: Es wäre schön, wenn die Elektronikbranche auch kaufbare Electrowetting-Displays herstellen würde