Das erste würfelförmige LED-Display faszinierte mich Ende 2005 auf einem Chaos Communication Congress in Berlin, gebaut und ausgestellt vom Hackerspace Das Labor aus Bochum. Mein Würfel ist ein Nachbau dieses Projekts mit leicht veränderter Hardware.
Mein Würfel besteht aus insgesamt 512 roten LEDs, die in 8 horizonalen Ebenen á 64 LEDs unterteilt sind. Die Ebenen werden von einem ATMEGA32 im Zeitmultiplexing-Verfahren angesteuert, sodass zu einem Zeitpunkt nur jeweils eine einzelne Ebene aktiv ist. Aus der Geschwindigkeit der Ansteuerung und der Trägheit des Auges ergibt sich am Ende ein flimmerfreies, vollständiges Bild.
Der Aufbau
Beim Aufbau des Würfels habe ich mich nicht am Projekt der Bochumer orientiert, die die LEDs in vertikalen Ebenen würfelförmig angeordnet hatten, die untereinander nur an wenigen Stellen verbunden waren. Ich wollte den Würfel symmetrisch "massiv" bauen, so dass jedes Segment in allen Richtungen mit seinen Nachbarn verbunden ist. Einen echten Würfel eben.
Meinem Plan nach sollte der Würfel aus übereinander angeordneten horizontalen Ebenen bestehen. Das Gerüst jeder Ebene bildet die gemeinsame Kathode aller LEDs auf dieser Ebene. Untereinander sind die Ebenen durch 64 Säulen verbunden, die jeweils die Anoden aller genau übereinander liegenden LEDs verbinden.
Die ganze Struktur besteht aus 0.8 mm versilbertem Kupferdraht. Dieser Draht kommt auf Rollen und muss erst gestreckt werden. Das klappte gut mit einem Schraubstock und einer Zange: Das eine Ende wird eingespannt, und am anderen Ende zieht man so, dass der Draht dadurch ein Stück länger wird. Das Ergebnis sind schnurgerade, aber knickempfindliche Stücke. Die Herausforderung ist, diese Stücke während des gesamten Aufbaus _nie_ zu knicken, weil alle Knicke später im Würfel sichtbar sein werden.
Mit Hilfe einer Schablone (siehe Bilder) baute ich zuerst die 8 einzelnen Ebenen. Da es voraussichtlich sehr schwer sein würde, im vollständig aufgebauten Würfel einzelne LEDs auszutauschen, war es sehr wichtig, die Ebenen vor dem Einbau zu testen. Hierfür hing ich sie jeweils ca. 12-24 Stunden an meinen improvisierten Ebenentester[tm].
Kleine Anekdote: Dieses Gerät lag gerade auf dem Boden in meinem Heizungskeller herum und testete Ebenen, als der Ableser meines Stromversorgers vorbeikam, und auf der Suche nach dem Zähler forsch diese Tür öffnete, einige Zeit drauf starrte, und die Tür wortlos wieder schloss.
Um die Ebenen über die 64 Säulen miteinander verbinden zu können, baute ich meine Schablone mit Gewindestangen und ein paar Leisten zu einem kleinen Gerüst um.
Für die ganze Aktion brauchte ich ca. 1-2 Wochen, wobei man sich mit dem perfekten Ausrichten der Ebenen übereinander beliebig viel Zeit lassen kann. Das kann auch zur Qual werden, wenn man Perfektionist ist. Die objektiv größte Schwierigkeit an diesen Schritten war das Einfädeln der Ebenen in die 64 nach oben stehenden Drähte für die Säulen. Diese Drähte sollten auf keinen Fall knicken, weil man sie nicht wieder austauschen kann. Kompliziert war insbesondere auch das Anlöten der unteren Ebenen an diese 64 Säulen, ohne die umliegenden Drähte zu knicken.
Die Elektronik
Der Plan für den Controller stammt vom Borg3D Projekt von den Bochumern. Meine Elektronik orientiert sich daran, abgesehen von einer kleinen Änderung: Meiner Ansicht nach fehlt da zw. PA7 -> CLR (Pin 9 am 74HC164) und GND ein Pulldown-Resistor1.
Die fertige Elektronik.
Ich erkläre kurz grob wie es funktioniert:
Auf der linken Platine befindet sich der Mikrocontroller ATMEGA32 (unten), ein 8-Bit Schieberegister (Mitte), und 8 MOSFETs (oben). Auf der rechten "Säulentreiber" Platine ist wieder ein 8-Bit Schieberegister (unten), sowie acht 8-Bit Latches für die Säulen.
Die Latches sind an den 64 Säulen angeschlossen, und halten jeweils den Zustand (an/aus) aller 64 LEDs einer einzelnen Ebene. Das Schieberegister dient dazu den Latch zu selektieren, der gerade programmiert werden soll. Das rote Kabel von der Controller- zur Säulentreiber-Platine ist ein 8-Bit Datenbus, der die zu schreibenden Daten des selektierten Latches überträgt. Die MOSFETs der rechten Platine schalten jeweils die Kathoden der aktiven Ebene von hochohmig auf GND. Dazu wird vom Controller eine "1" durch das Schieberegister geschoben, wodurch alle Ebenen in schneller Folge nacheinander aktiviert werden. So ergibt sich das Zeitmultiplexing:
Die Software schreibt alle Latches einer Ebene, aktiviert die Latches (gemeinsame enabled-Leitung), zeigt dieses Bild eine gewisse Zeit an, deaktiviert die Latches, schiebt die "1" zur nächsten Ebene, schreibt wieder alle Latches, aktiviert die Latches, zeigt das Bild an, und so weiter.
Obwohl immer nur eine einzige Ebene gleichzeitig aktiv ist, sehen wir durch die Trägheit des Auges ein vollständiges Bild. Nun hängt jedoch die Helligkeit der LEDs für unser Auge (logarithmisch) von der Menge emittierter Photonen ab. Eine LED in diesem Setup mit 8 Zeitscheiben, emittiert nur 1/8 der Photonen, und wäre damit für das Auge erkennbar weniger hell. Man wirkt dem entgegen, indem man die LED mit einem höheren Strom betreibt, und dafür die Abklingphase berücksichtigt, in der die LED auskühlt.
Im Datenblatt vieler LEDs findet man die Werte unter Peak Forward Current unter der Angabe von Duty-cycles o.Ä. Ich verwende L53LID low-current LEDs von Knightbright. Dort ist im Datenplatt die Rede von I(typ) 30mA, I(max) 155 mA, bei 1/10 Duty-Cycle, und 0.1ms Pulse Width. In meinem Würfel habe ich nur 1/8 Duty-Cycle, und eine von der Programmierung abhängige Pulsbreite, weshalb ich grob über den Daumen peile und ca. 120 mA verwende.
Zum Entwickeln, Portieren und Testen der Software verwende ich eine zusätzliche Kaskade aus Widerständen, um den maximalen Stromfluss auf 30mA zu beschränken, damit nichts kaputt geht. Die fertige Software integriert einen Watchdog, der die Einhaltung der Duty-Cycles anhand des Systemtakts des Controllers überwacht und notfalls abschaltet.
Der Würfel unterstützt drei Helligkeitsstufen, die erzeugt werden, indem je nach Helligkeit für eine LED einzelne Zyklen ausgelassen werden. Im Endeffekt ergibt sich dadurch eine Pulse-Width-Modulation. Die Software teilt einen "Frame" dazu in 8 Zyklen ein: 0 Zyklen pro Frame = aus, 1 Zyklus pro Frame = dunkel, 4 Zyklen pro Frame = mittelhell, 8 Zyklen pro Frame = hell. Da sich die Helligkeitswahrnehmung unserer Augen logarithmisch zur Anzahl der einfallenden Photonen verhält, wirkt diese logarithmische Verteilung auf unser Auge linear. Und das ist auch der Grund, weshalb es nicht mehr Helligkeitsstufen gibt: Um die logarithmische Verteilung beizubehalten, bräuchte man für jede weitere Helligkeitsstufe eine Verdopplung der Zyklen pro Frame. Wenn der Systemtakt des Mikrocontrollers sich nicht ebenfalls verdoppelt, müsste die Framerate sinken und der Würfel würde sichtbar flimmern.
Hier noch ein paar Bilder vom Bau des Sockels und dem fertigen Würfel:
Der fertige Würfel!
Momentan steht er in meinem Wohnzimmerschrank.