 Nächste Tag ist Service Point, das Display eine Geschichte von vier Generationen. Und die Sprecher sind Peter Stucker und Felix Niedlers. Es gibt Ihnen einen großen Applaus. Thank you. Thanks for having us. I'm Felix. Ich bin Felix, das ist Peter. Hallo. Yeah, we're gonna tell you four tales about this place. Wir wollen euch vier Geschichten über das Display erzählen. Der Anfang des Displays war, dass einer unserer Clubmitglieder es auf eBay gekauft hat. Wir wussten nicht genau, was es ist. Es kam von einer Metallverarbeitung-Firma, die ein Elektronikabteilung hatte, die die Elektronik davon hatte und ein Metallwerkstatt, die die Hardware gebaut hat. Und die haben es abverkauft, weil es wohl für sie nicht funktioniert hatte. Und wir haben es halt auf eBay bekommen. Und es war am Anfang sehr, sehr langsam. Das ist hier, wie es bei uns im Club aussieht. Wir reden über die Hardware von der ersten bis zur vierten aktuellen Generation und dann über die Software und die API, die Websockets, die wir haben und ein paar lustige Anwendungen, die wir dafür gemacht haben. Peter, möchtest du bitte Hardware anfangen? Die erste Generation war mit einem 6502-Kontroller-Bord ausgeliefert worden. Ich war nicht da, als das benutzt wurde, aber ein paar Leute haben es geschafft, das zum Laufen zu kriegen, indem sie über serielle Kontrollport-Komandos an den Kontrollern geschickt haben und wir konnten zugucken, wie die Buchstaben auf dem Display einzeln angezeigt wurden. Das Ding besteht aus einem ganzen Haufen 8x8 LED-Modulen. Oh, keine Ahnung. Das ist der Kontroller. Das ist der 6502-Kontroller. Das sind die 8x8 LED-Module, die in diesem Display sind. Insgesamt gibt es 20 Teilen und 56 Balken von diesen Modulen. Insgesamt 1120 LED-Module mit 8x8 sind das 71.000 Buzzerquetsch der LEDs. Ein 71-Kar-Display. Das war die erste Generation. Dann haben wir die Hardware ein bisschen kennengelernt und ein paar Leute in Berliner ZCC haben einen neuen Kontroller dafür gebaut, weil der 6502 einfach nicht sehr lustig war. Es war, wie gesagt, sehr langsam. Und es war natürlich nicht am Netzwerk. Natürlich brauchten wir es am Netzwerk. Die zweite Generation war ein Atmel X-Mega. Ich glaube, wir haben leider keine Bilder davon. Und in dieser Zeit war also der Anfang eines Protokoll-Designs, um Informationen an das Display zu schicken. Das besteht aus beim UDP-Paket. Das hat ein 10-byte Header. Das enthält 516-Bit Wörter in Netzwerk-Byte-Order enthält. Das Erste ist das Kommando. Und dann sind da 4 Parameter, die einen Wert enthalten können oder nicht. Wenn ein Parameter nicht benutzt wird, dann ist der Wert einfach 0. Nach diesen 10-bytes kommen vielleicht, oder vielleicht auch nicht, die Daten in dem UDP-Paket. Das sind die Kommandos am Anfang. Die ersten Kommandos, die implementiert wurden. Ich glaube, da sind ein paar Lücken in der Nummer in Form. Ich weiß nicht, was die Kommandos oder die Zahlen dazwischen waren. Aber klar, was haben wir? Bildschirmlöschen, Textsenden. Dann haben wir ein paar Helligkeits-Kommandos. Diese LED-Module, diese 8x8-Module, hinter jedem sitzt ein Maxim-Max LED-Driver, der für diese Displays gemacht und entwickelt wurde. Und in diesem LED-Driver ist ein digitales Register, um die Helligkeit einzustellen. Und wir haben das über ein paar Kommandos sichtbar gemacht. Hier ist ein Demo dafür. Hier ist ein Demo, das wir kann nur 8x8-Felder die Helligkeit einstellen. Es ist kein Graustufen-Display für die einzelnen 8x8-Pixel, aber man kann diesen netten Effekt darüber machen. Und zu erklären, was wir hier sehen, hier ist das gesamte Display mit Plus-Zeichen gefüllt. Also jedes Modul zeigt ein Plus-Zeichen. Und das Einzige, was sich verändert, ist die Helligkeit und die Lichtintensität dieser einzelnen Module. Und das macht ein noch niedriger aufgelösten, aber hübschen Effekt auf diesem relativ niedriger aufgelösten Display. Zurück zu den Kommandos. Das war Zeichen Helligkeit. Da gibt es Helligkeit für den gesamten Bildschirm. Da gibt es einen Reset-Kommand. Das hilft manchmal. Da hatten wir einen Graphics-Kernel-Fade-Exzent, wo ein Graphic-Kern über die Display läuft und dann die Abland-Effekt aussieht. Aber das wurde nicht viel verwendet. Und das wichtigste neue Feature in unserer Dings war Bitmap-Übertragung zu unterstützen. So dass dieses Display auch beliebige Grafiken anzeigen kann. Das allererste Kommando, weil es einfacher ist, die Bitmap-Daten auf eine Art zu schicken, wie die Hardware funktioniert. Das ist nicht sehr einfach für Software-Entwickler. Das ist Pixel-Daten in einem vertikalen Layout. Die Daten wurden so geschickt, dass jedes Byte eine 8-Pixel-Balte ist statt 8-Pixel-Horizontal. Wir konnten damit Bitmaps machen, und es war viel Spaß. Und dann haben wir zu der... Wir wollen natürlich schneller sein. Wir haben festgestellt, dass die Hardware, so wie sie aus der Fabrik kommt, ziemlich beschränkt und ziemlich langsam, nicht nur wegen des, weil die 6502 eine relativ langsame Maschine ist, sondern auch, wie der gesamte Datentransfer in diesem Display implementiert war. Wie der Feier zeigt, würde der 6502 Prozessor jedes einzelnen dieser 1120 LED-Module nacheinander sequenziell, in der Reihe nach. Das heißt, dass die anderen 1119 LED-Module machten einfach gar nichts die meiste Zeit. Nur ein Einzelnes erhält zur Zeit Daten. Das wurde in Hardware-Generation 2.5 geändert. Da haben wir nicht mehr den 6502-Kontroller benutzt. Das ist einfach nur ein Symbolbild. Der Hauptkontroller schickt Daten zu diesen neuen Zeilenkontroller, die beim Pilot und beim CCC Berlin entwickelt wurden. Die haben verteilte Bildspeicher. Also, jedes Speicher hat ein Bildspeicher für den Inhalt, der da sein muss. Und Parallelisierung der Masterkontroller schickt Daten an alle Zeilenkontroller nur zu den Zeilenkontrollern. Und die Zeilenkontrollern schicken dann die Daten zu den LED-Modulen und den Treiberchips. So sieht das aus. Da ist ein Back in der Hardware. Den haben wir gefixt. Das war gut. Das hat uns mehr Bildrate verschafft. Also quasi mehr beim Bitmap-Transfer. Und dann war uns das aber in Wien noch nicht genug. Das war uns immer noch zu langsam. Wir haben experimentiert mit einem Mikro-Kontroller, welcher stärker ist. Einiges stärker ist das der X-Mega. Das ist ein Cortex-M3. Das Spezielle daran ist, die hat ein Internet-Mac und FI schon eingebaut. Das ist nicht so gewöhnlich, aber natürlich sehr praktisch für unser Projekt. Wir hatten immer auch das Hautproblem, dass die Bitmaps in diesen speziellen Anordnungen gesendet werden mussten, also vorum nach vorn. Statt von links nach rechts, wie üblicherweise. Aber innerhalb dieser Zeile müsste man die vertikalen Bytes senden. Das war nicht immer lustig. Das haben wir in Generation 3 geändert. Da haben wir neue Kommandos implementiert, um die Bitmaps zu transferieren. Um an den normalen Bitt und Beiternordnungen von gewöhnlichen Bitmaps zu unterstützen. So wie das üblicherweise Bitmaps gespeichert werden. Wo Pixels quasi von links nach rechts horizontal gespeichert werden. Dann geht es auf die nächste Zeile usw. Wir hatten mehr Rechenpower und diese Power haben wir benutzt, um es einfacher zu machen für die Entwickler. Die arme Architektur hat auch praktische Befehle, wo man diese Bitmaps-Transformation einfacher lösen kann. Das 2,5 Generation Display, dieser Controller, springt ein bisschen zurück. Der hat ein paar Optimierungen auch, um die Datentransferate zu minimieren. Es flickerte manchmal, aber es wurde dann besser. Mehr Thruput hat dagegen gut geholfen. Es hat uns erlaubt, immer noch viele Informationsänderungen zu verhindern. Es hat uns immer noch geholfen, immer noch viele Informationsänderungen zu übertragen, aber Dinge, welche nicht geändert wurden, wurden dann halt nicht mehr abgedeutet. Ein Beispiel an eines dieser 8x8-Module hatte keine LEDs an. Dann wurde dieser Chip auch in den PowerSafe-Mode gesetzt, um die Stromstumfer aber auch zu minimieren und zu optimieren. Bei der Generation Hardware haben wir mal gemessen, glaube, wir haben da gewessen, dass das Ganze über ein Kilowatt braucht, wenn alle LEDs an waren. Mit jeder Hardware-Generation haben wir das ein bisschen verbessert. Es nutzt jetzt halt je länger, je weniger Strom. Das war dann nicht perfekt. Ich erinnere mich, da war es mit dem Ethernet, mit dem Linear-Kommando, wo man nun ein Teil des Bildes updaten kann. Mit diesem Kommando hatten wir das Problem, dass der Cortex-M3 also der hat Internet-Marken-File. Die Network-Konnektivität war einfach. Es hatte Beispielcode für IP-Stack und so weiter, alles okay. Aber leider hat die Hardware mit einem Paket-Buffer. Das heißt, wenn wir diese 71.000 Pixel nehmen und alle in ein Paket packen möchten, dann geht das nicht, weil der Buffer so klein ist. Das wären dann etwa 9 Kilobytes in Daten. Mit diesem Microcontroller, der nur 2 Kilobytes Paket-Buffer hat, ging halt Pakete verloren. Das war natürlich unschön. Wir haben wieder ein Workaround gemacht. Anstatt ein großes UDP-Paket zu senden mit dem gesamten Bild, würde man halt das machen, was normalerweise der IP-Stack macht. Man zerkleinert das große 9-Kilo-Bytes-Paket in Kleiner-Pakete und wird dann halt aufgeteilt in 6 bis 7 Pakete, die klein genug sind, um das Display zu senden. Das Problem war dann aber, dass das Display zum Beispiel nur das erste, das dritte und das fünfte Paket empfangen hat. Inzwischen war es halt beschäftigt mit dem Anzeigen dieser Pakete. Wenn der nächste Workaround war, wie soll ich das sagen, zähl ich ein bisschen das Geheimnis dazu. Bereits beim Sender muss das Bild in mehrere Teile geteilt werden. In der Applikation, nicht erst auf dem IP-Stack, wir haben eine Applikation geschrieben, welche das macht, welche das Beil in Kleiner-Pakete teilt und haben da auch eine künstliche Verzögerung eingebaut zwischen den Paketen. Das ist sehr unschön, das haben wir, hat uns nicht gefallen, aber, ja, das Ziel natürlich immer mehr, frames per second zu erhalten. Wir wollten da Video drauf auch spielen können, das war immer das Ziel. Die 2. Generation Hardware hatte etwa 2, 3 frames per second in der Nation. Wir haben schon etwa um die 10, manchmal 12 FPS an einem guten Tag. Das ist natürlich immer noch ein bisschen unschön, weil 24 werden schön. Dann haben wir den Vorschlagkammer genommen und haben das Ball gesagt, jetzt haben wir ein Beaglebogen Black. Der hat ein PRU, das ist ein Programmable im Unit, also Real-Time-Einheit. Ein kleines Linux-Bord, eigentlich zu einem anderen fruchtigen Board, das ich jetzt hier nicht erwähnen möchte. Es ist ein Linux-Bord, es ist sehr hübsch, es hat etwa ein Gigahertz-Prozessor, also C. Es hat aber auch zwei Co-Prozessor-Cores, die 200 Megahertz schnell sind. Die sind komplett getrennt, sind vom Arm und vom Linux. Man kann kleine Programmesnippets erstellen, die dann nach diesen laufen, und zwar sehr schnell. Die können dann in einem Zyklus-Input-Output-Operation GPIO lesen und schreiben. Das dachten wir, wäre eigentlich ein guter Weg, um die Performance zu verbessern mit diesem letzten Teil, den wir noch brauchten. Wir haben schon mehrere Schritte gemacht, schon viele Dinge optimiert, der Datentransfer war gut, und es ging es für dieses Flachbank-Kabel, dass ihr da ein bisschen sieht. Zuerst war das noch seriell, und mit der zweiten Generation ist es immer noch seriell. Mit der zweiten Generation war das dann parallel. Das kann der Reihenkund der Zeilenkontroller weiter machen. Mit dem Beagle of Bone Black haben wir jetzt in diese Richtung weitergearbeitet. Wir haben ein PRU-Firmware geschrieben für diese Zeilenkontrolle. Das PRU hat ein Share-Memory, das heißt, das Linux empfängt die Bitmap-Pakete oder Pakete, und es speichert die Bitmap-Daten in diesen geteilten Speicher. Share-Memory macht sonst nichts. Einfach nur das in einem Endlosschleife. Und unabhängig davon arbeitet das PRU und liest diese Daten aus dem RAM, aus dem Share-Memory, und zeigt diese an. Also haben wir noch viel mehr parallelisierung, und so haben wir es dann bis etwa 40 FPS geschafft. Ja, wir sind accomplished. Das hier zeigt ein paar Bilder aus dem Inneren. Das ist der aktuelle Zustand der Dinge. Wir haben den Beagle Bone Black oben links mit einem Platine da drüber mit ein paar Levelshifter und IO-Puffer und so was, und ich weiß nicht genau, was alles da drauf ist, um den Bus nach unten anzutreiben. Und man sieht auch die Leistungsversorgung, die Stromversorgung. Das ist eine ziemlich kleine, kleines Netzteil. Es ist nicht genug für das ganze Gerät. Das ist nur für den Beagle Bone Black. Es gibt eigentlich Netzteile für die LEDs. Es gibt tatsächlich 2, 2 solche Netzteile wie dieses hier auf dem Bild. Die werden benötigt, um alle die LEDs anzutreiben. Ich glaube, wir sind hierbei 500 Watt oder so, aber wir brauchen eigentlich nicht wirklich so viel. Es gab nur 3, weil es kein 2 gab, die genug Kapazität hat und keine Lüfter hatte. Da waren vorher andere Netzteile drin aus den 1990er oder so, die sehr ineffizient waren. Die haben wir selbst ausgetauscht durch diese modernen LEDs. Diese nette Verkabelung haben auch wir im CCCB gemacht, das Rot und Schwarz und diese Kupfer. Die Kupfer-Leisten und Sicherungen, die waren alle schon da, die kommen so aus der Fabrik. Das kleine Board in der Mitte ist ein analog-digital-Wandler, um die Spannungsausgang der Netzeile zu überwachen. Mal gucken, was passiert. Kommen die Netzeile damit klar, wenn wir alle 71.000 LEDs gleichzeitig an und aus schalten und tatsächlich, ja, sie schaffen das. Die rechte Ecke, wo der Ethernet-Konnektor dran ist und ein nicees, nette Gravierung, die unser Logo zeigt. Lass uns über zur Software übergehen. Wo wir vielleicht gesehen haben, ich weiß nicht viel über die Hardware, aber es war immer, hat immer Spaß gemacht, im CCCB zu sein und darüber zu hören, was die anderen Mitglieder des Clubs gemacht haben. Jeder machte halt das, wo er gut war und ich mache halt Web-Entwicklung und ich konnte halt nur Dinge machen, nachdem sie ein Web-Saver darauf implementiert haben und mir Web-Sockets gegeben haben. Als Erste, lass uns über den Fund reden. Der Fund ist ein Code-Page 437-Fund, ein eigener, ihr kennt den vielleicht auch vom Boot-Screen, das ist das gleiche und MS-DOS. Das ist die gleiche Zeichen-Layout, wie der benutzt. Es gibt Funds, die es gibt, warum brauchen wir unseren eigenen? Das Problem ist, wir haben 8x8-Pixel-Module und es gibt 8x8, es ist keine 8-mal-Ans-Fond, es gibt nicht, es gibt 8x16, das ist zu groß. Aber es gibt ein Problem, unsere Module sind einer neben den anderen und wenn man Texte in einem Standard 8x8-Fond darauf macht, gibt es keinen Fischenraum zwischen den Buchstaben. Das war das, was wir ändern mussten. Wir brauchen einen Fischenraum zwischen den Buchstaben. Am Ende brauchen wir tatsächlich einen 7x7-Fond und das hier ist die Bitmap von diesem Fund. Das ist ein grundlegender Satz an Zeichen. Ich weiß nicht, ob ihr das an dem Bitmap sehen könnt. Es gibt eine hellgraue Sprich. Neben den Dingern, das ist die Lücke des 8.Pixel zwischen den Zeichen. Markus hat diesen Fund in MS Paint in Wine gebaut, weil er sagt, das ist immer noch das beste Programm, wenn man Pixel machen will. Dann hat er ein paar Tripte darum gemacht, um das zu exportieren. Er hat einen C-Header generiert, der auf dem Beagleboard benutzt wird und er hat auch Web-Fonds daraus generiert, sodass wir einen Web-Editor für das Interface benutzen können, damit das Interface in der Webseite und das eigentliche Display fast gleich aussehen. Die nächste große Aufgabe, das nächste Aufwand war das Dithering. Ich weiß nicht, ob ihr das Konzept kommt, aber nehmen wir an, wir haben ein Bild. Das ist Farbbild, die haben natürlich keine Farbe. Wir müssen es etwas wie weiß konvertieren. Aber dann, wir haben über die Helligkeit erzählt, wir können die Helligkeit nur in einem 8x8-Bereich ansteuern. Wir können kein richtiges Grau darstellen, wir können dann immer nur in dem Bereich immer nur grün oder gar nichts machen. Dithering ist halt ein Effekt, eine Technik, bei der man den gleichen Effekt benutzt, um halt den Eindruck von Grau erzeugt. Das ist fast der gleiche Technik, wie Drucker benutzen, die halt nur schwarz und weiße Punkte machen können. Hier, wenn man jetzt rein zoomt, so sieht dieses Image, dann geht das halt aus. Markus hat viel Aufwand da rein und viel Liebe da reingesteckt und hat dann viel Aufwand getrieben. Verschiedene Dithering Algorithmen zu testen, Floyd Steinbar, man ist ein ganz guter, aber der ist nicht gut genug für den Standard, auf den erzielte. Nur hat eine Anwendung gebaut, wo er gemacht und dann hatte so, dass man oben das Originalbild sehen konnte und dann konnte man zwei verschiedene Dithering Algorithmen vergleichen. Und am Ende hat er sich entschieden, ich weiß nicht, den Namen nicht mehr genau, er heißt irgendwie mit O an und ist ein russischer Name als ein Basis Algorithmen und dann hat er ein bisschen mehr Pre-Processing hinzugefügt, um die Resultate zu vergessen. Er wird vorher ein wenig unscharf gemacht, da sieht man nicht mehr alle kleine Dithers und das Dithering entfernt diese Details ohnehin und dann macht man ein bisschen scharfen hinterher, um dann die übrig gebliebenen Feature im Bild zu schärfen und links sieht man eine besonders gute Darstellung, weil es skaliert ist oder so, da sieht man dann halt das Resultat. Packages Pakete, ja, UDP-Pakete. Neun Kilobyte Bitmap Frames hatten wir schon gesagt, genau. Das hatten wir schon erzählt, aber wir sind uns ein bisschen beleidigt. Das nächste, das Großartige für mich war WebSockets. Ich habe mich nie vorher mit UDP beschäftigt, nur eine Rückkopplung im Saal und mit WebSockets konnte ich plötzlich Pixel an das Display schicken aus dem Browser. Mit JavaScript. Die WebSocket-API ist nicht die volle API, es ist nur, schickt nur Pixel. Dann hat also eine, du kennst was, eine Leinwand und drückt dann einfach Pixel-Daten hin und das Display. Es gibt eine einfache Demo-Anwendung, die über, zeigt wie man die WebSockets benutzt. Ich weiß nicht, ob es groß genug ist, ob es zu erkennen, aber am Ende ist WebSockets, zwei-weg-Kommunikation wie TCP, um Daten aus dem WebSappel hinzuschicken. Man macht einfach die Verbindung auf, sagt, dass man Buffer-Data schicken, greift durch ein paar Pixel aus dem Canvas, dann geht man durch die Pixel, packt sie in Bytes und schickt sie einfach über den WebSocket hinaus. Das war eine relativ einfach, zu implementieren. Ein sehr einfaches Protokoll. Ja, und das hat auch sehr gut funktioniert. Dann sprechen wir mal über weitere Applikationen vom CCC Berlin spezifisch, also die, erst ist es natürlich ein Willkommensbildschirm, es ist halt an der Wand montiert, wo man reinkommt und da macht sowas sehr Sinn. Eigentlich fast immer eingeschaltet, aber wie ist es der Willkommensbildschirm und eine der ersten Implementationen, als wir hier noch keine Bitmaps anzeigen konnten, war das Quasi der ASCII Star Wars filmt. Den findet man auch immer noch im Internet. Es ist einfach ein Teilnet, das euch dann diese Daten sendet. Das war natürlich sehr schön zum Anfang. Aber später, ja, das habt ihr auch schon live gesehen, haben wir Videos geschaut. Mark hat ein hübsches CheeseDriver-Plugin geschrieben, welches sich um das Dithering und so weiter um alles Pre-Processing kümmert. Und so kann man halt einfach einen Film abspielen und der wird dann korrekt an das Display gesendet. Etwas Kleines. Im Mord haben wir noch unseren Datenrat optimiert, in dem wir komprimiert haben. Das war irgendwo zwischen der dritten und vierten Generation. Also ja, in Generation 4 wollte das ergänzt, dass man die Bitmap-Kommandos, also der benötigt halt nur zwei der vier Parameter im Protokoll und dann haben wir ein paar Unterkommandos implementiert, welche verschiedene Algorithmen unterstützen. Da waren wir zeitlang beschäftigt, all diese Algorithmen auszuvergleichen und mal zu schauen und uns auf einen Standard zu einigen. Also insbesondere die Endkomprimierungsrate ist dann halt relevant, weil das das Display erledigen muss. Was ihr auch seht, es hat immer so Zeilen dazwischen, die sind dann halt dunkel. Und da muss man dann zu einem G-Streamer-Plugin zum Beispiel explizit beibringen, dass es diese Pixel halt ausschneiden soll. Es funktioniert so, man sagt im Quasi schickt mir ein Graustufenbild und das hat ein bisschen mehr Pixlers eigentlich auf das Display passen. Diese Lücken, wo das Metall ist, da wird dann halt quasi null drüber kopiert, leider nicht in einer ganz effizienten Art, aber ja es ist noch kein Problem und so sieht das dann halt viel besser aus als einfach die genaue Pixel-Auflösung des Displays zu berechnen. Und es gibt ein Web, wenn man sich auf diese IP-Adresse verbindet, weil hier auf dem Display stehen würde, dann sieht man dieses Webinterface, ein kleiner Texteditor, wo man Dinge eintippen kann und es gibt auch eine kleine Zeichenapplikation, wo man etwas hineinzeichen kann auf das Display. Etwas anderes Lustiges ist unser Bitcoin-Infostream mit Echtzeit-Updates von der Flugplan, Flugfahrplan. Was ich auch sehr mag, ist die Abfahrtzeiten von Busen und so weiter. Bei uns in der Nähe ist die Aderstelle Friedersstraße in der Nähe und am Wochenende vor allem gibt es dann auch gegen ja, wenn es später wird, mal weniger Züge und so weiter. Und dann hilft es natürlich, dass man noch rechtzeitig auf den letzten Zug es schafft. Etwas anderes Lustiges war ein Multiplayer-Panzer-Spiel, wo man mit dem Telefon oder der Laptop sich verbinden kann, direkt auf die IP. Dann hat es im Browser auf dem Laptop ein Controller angezeigt und mit Touch-Eingabe konnte man das dann steuern und gegeneinander spielen. Das Display war dann die Anzeige des Spiels. Das Letzte war auch eine Demo-Applikation, wo man einfach mit dem iPhone-Kamera auf das Display streamen kann. Die seht ihr hier. Ja. Danke an allen, die an dem Projekt geduldig gearbeitet haben. Das war nicht nur Felix und Dicht. Da haben viele Leute dann mitgearbeitet, dem CCC. Es hat mir immer sehr viel Spaß gemacht, an diesem Ding zu arbeiten. Ich habe es ein bisschen vermisst, aber es hat funktioniert. Offen wir mal, dass man wieder was Neues machen kann. Ich vermisse es nicht so, weil es immer relativ gefährlich war, wenn die da 150 Kilo Schweres Display im Klub umhertragen. Vielen Dank, haben wir Fragen. Sehe ich ein weißes Licht? Einmal ins Internet. Eine Frage aus dem Internet. Du hast gesagt, dass die Module gedimmt werden können. Man benutzt der Dithering-Algorithmus auch, das Dimmen der Module, oder sind die alle Leichel? Soweit ich das weiß, benutzt das Dithering die Intensität nicht. Es war auf einem 8x8 Level. Es wurde versucht, aber es sah nicht wirklich gut aus, weil die Pixel kleiner sind, als die Bereiche, wo man die Intensität einstellen kann. Man würde auch verschiedene Kommandos haben müssen für die Pixel. Wir hätten vielleicht ein Kommando hinzufügen können, aber es sah nicht so gut aus. Eine andere Frage hier vorne. Vielleicht habt ihr andere Ideen, wie man andere alte Geräte updaten könnte. Habt ihr Ideen? Ja, weiß ich nicht. Ich meine, das Display ist jetzt viel besser als das Original. Vielleicht habt ihr Ideen für andere solche Projekte. Wenn wir irgendwelche zukünftige Projekte haben, wieso? Nein. Unglücklicherweise nicht. Es gibt Arbeiten an anderen Displaytechnologien, Flipdots. Aber nicht so viel im Club. Es gibt nicht so viel im Club. Die gleichen Leute, die haben halt andere Hacking, also Flipdots Hacking machen oder so. Wenn nicht im Moment. Ihr könnt einfach auf eBay und sendet es uns, aber sendet uns nicht euren Müll, bitte. Haben wir noch eine weitere Frage? Die Frage ganz hinten. Oder doch keine Fragen mehr? Das sieht nicht mehr nach Fragen aus, das steht einfach nur jemand. Vielen Dank für's Zuhören und einen großen Applaus. Damit verabschieden auch wir uns auf dem Übersetzungskanal. Ihr könnt Feedback geben auf Twitter unter dem Hashtag C3.