Vaporlight:Anleitung

Lieber Entropianer!

Herzlichen Glückwunsch zum Kauf deines neuen Vaporlight Forever – oder so. Jedenfalls schön, dass du offensichtlich Interesse daran hast und damit spielen willst. Dabei soll diese Anleitung helfen. Wenn du tiefer einsteigen möchtest, musst du wohl oder übel mit uns sprechen, Entwicklerdoku gibt es noch nicht. Felix macht die Hardware und Andi die Software.

Du bist hier in einem Wiki. Wenn du also Fehler findest, etwas ungünstig formuliert ist oder so, korrigiere es einfach. Wenn du Vorschläge hast, wie man das Protokoll ändern sollte, korrigiere es nicht einfach; die Mikrocontroller lesen nicht diese Seite. Stattdessen kannst du unseren Bugtracker, E-Mail oder ein Gespräch benutzen, wir kümmern uns dann darum.

Diese Anleitung bezieht sich momentan auf Vaporlight Forever Mk. II und Vaporware V. -2.92 "Kalium". Die Software ist noch ein Prototyp, wahrscheinlich wird das Protokoll noch erweitert und weniger strikt.

Die LED-Boards

Mit dieser Ebene wirst der gemeine Animationskünstler wohl eher nicht zu tun haben (wer weiß...), trotzdem ist es nützlich, davon etwas zu verstehen, der Rest geht dann einfacher. Also los.

Immer 5 RGB-LEDs hängen an einem solchen Steuerboard. Ihre Helligkeit wird mit Pulsweitenmodulation (PWM) von einem darauf spezialisierten Chip geregelt. Momentan wird die PWM noch nicht randomisiert, das heißt in einer solchen Fünfergruppe kann es zu leichtem Flimmern kommen, wenn die Farbwerte gerade ungünstig liegen. Die einzelnen LED-Gruppen laufen natürlich asynchron.

Helligkeitskorrektur

Gesteuert wird das ganze von einem Mikrocontroller (ATmega88a, aber wen interessiert das), der über einen einfachen seriellen Bus (RS485) mit den LED-Daten versorgt wird (dazu gleich mehr). Die Helligkeitswerte werden in RGB mit 8 bit pro Kanal an den Controller gesendet. Der Controller kümmert sich dann selbst um die Gammakorrektur (mit Gamma = 2,1) und passt die Werte an die leicht verschiedenen LED-Helligkeiten an. Als User kann man also einfach davon ausgehen, dass die Farbwerte direkt der tatsächlichen Helligkeit entsprechen und hoffentlich keinen Farbstich haben.

Schutzmechanismen

In den LED-Modulen sind Temperatursensoren eingebaut, bei Überhitzung werden automatisch die LEDs eines Moduls ausgeschaltet und das Modul resettet. Das gleiche passiert bei anderen unangenehmen Dingen. Das Modul startet dann neu, es kann aber gut sein, dass es sofort wieder abschaltet (oder sich die LEDs gar nicht erst anschalten), wenn das Problem immer noch besteht (so schnell kühlen die nicht ab).

Was los ist, sieht man an der kleinen Debugging-LED direkt auf dem Modul. Sie gibt vor jedem Reset einen Blinkcode aus kurzem und langem Blinken aus. Die Codes stehen hier:

— — —	Das Modul wurde nicht konfiguriert und kann so nicht arbeiten.
— —	Das Modul startet im Konfigurationsmodus. Das sollte es nicht von selbst tun.
— · · ·	Das Modul hat einen Bug bemerkt. Hoffe, dass es nicht wieder passiert.
· · · ·	Das Modul ist überhitzt. Nach dem Abkühlen gehts weiter, vielleicht nicht ganz so hell leuchten?
· · —	Der serielle Bus ist anscheinend kaputt. Stecken alle Kabel noch?
· — —	Der TWI-Bus auf dem Modul hat Probleme. Ein Fall für die Werkstatt.

Der serielle Bus (RS485)

Über diesen Bus spricht der Busmaster mit den Boards. Alle Boards müssen sich den Bus teilen und der läuft auch nur mit 500 Kilobaud pro Sekunde. Weil das die Framerate ziemlich limitiert, gibt es zwei Modi, mit den Boards zu sprechen:

Asynchroner Modus: Dieser Modus ist der schnellere, aber etwas ungenauere. Dabei werden die Helligkeitswerte einfach so an die Module gesendet und sobald ein Modul ein Paket erhalten hat, setzt es die LEDs sofort auf die neue Helligkeit. Das dauert etwa 3,5 ms, während denen das Modul nicht für einen neuen Frame erreichbar ist. Andere Module können aber noch angesprochen werden. So erreicht man bei bis zu 10 Modulen 285 fps, darüber ist der Bus ausgelastet und die Framerate sinkt. Bei den für den Club angepeilten 24 Modulen erreicht man noch ca. 115 fps. Der Nachteil dabei ist, dass die Module nicht gleichzeitig die Farbe wechseln, vielleicht führt das zu Artefakten.

Synchroner Modus: Dieser Modus ist genauer, aber langsamer. Hier werden die neuen Frames von den Modulen zunächst zwischengespeichert und erst bei einem speziellen "Strobe"-Kommando von allen Modulen gleichzeitig zum PWM-Chip übertragen, wo sie gleichzeitig nach 3,5 ms ankommen. Deshalb sind aber auch alle Module nach dem Strobe für 3,5 ms nicht ansprechbar, diese Zeit geht also für Datenübertragung verloren. Bei 24 Modulen erreicht man hier nur ca 75 fps.

Bei einer Animation kann man sich den Modus aussuchen (und im Laufe der Animation wechseln), man sollte sich aber die maximalen Framerates im Hinterkopf behalten, um zu vermeiden, dass Frames gedroppt werden müssen.

Die Module müssen alle 400 ms ein Paket erhalten, auch wenn sonst nichts los ist (es empfiehlt sich ein Strobe, auch im asynchronen Modus). Das ist ein Sicherheitsfeature, um Ausfälle des Busses zu erkennen und die Module dann abzuschalten.

Low-Level-Dateiformat

Dieser Artikel bedarf einer Überarbeitung. Näheres dazu sollte auf der Diskussionsseite oder unter Entropia:FIXME stehen, sofern die Mängel des Artikels nicht ohnehin offensichtlich sind. Möglicherweise ist der Makel aber auch im Text mit dem Stichwort "FIXME" markiert. Hilf mit, den Artikel zu verbessern und entferne anschließend diese Markierung.