Vaporlight:Anleitung

aus dem Wiki des Entropia e.V., CCC Karlsruhe
Immer feste druff! - Bohren der Löcher für die Anschlüsse

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 Elektronik, Le und DeviDave machen die Mechanik, Nervengift auch ein bisschen, Andi die Software und etliche Einwohner Entropias helfen beim Löten der Boards.

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 23 und Vaporware V. -2.76 "Calcium".

Die LED-Boards

Mit dieser Ebene wird 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) 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 (STM32F100R, 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 = 1,8) 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 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?
– · – ·    – – – Es wurden zu viele Kommandos gesendet, eines musste gedroppt werden. Bitte Framerate senken
schnelles, unregelmäßiges Blinken Der serielle Bus ist anscheinend kaputt. Stecken alle Kabel noch und stimmt die Baudrate?
langsames Blinken Der Prozessor ist über einen schweren Interrupt gefallen. Lösung: siehe Bug.

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 mit 500 Kilobaud. Das reicht für 100-200 Frames pro Sekunde.

Das Protokoll ist relativ, aber nicht völlig einfach. Damit sich die Module selbstständig synchronisieren können, beginnt jedes Kommando mit dem Byte 0x55. Sollte das Byte in einem anderen Zusammenhang vorkommen, wird es folgendermaßen escaped: 0x54 wird als 0x54 0x00 dargestellt, 0x55 als 0x54 0x01.

Es sind folgende Kommandos definiert:

  • <Moduladresse>: Setzt die LEDs des angesprochenen Moduls auf die folgenden Werte. Das Kommando erwartet so viele Bytes als Argument, wie das Modul LEDs (d.h. einzelne Farbkanäle) hat.
  • 0xfd: Broadcast-Adresse. Sollte nur bei gleichartigen Modulen verwendet werden.
  • 0xfe: "Strobe". Erst wenn diese Kommando empfangen wurde, updaten alle Module ihre LED-Werte.

Im Konfigurationsmodus gibt es andere Kommandos, aber damit muss sich der gemeine Animator nun wirklich nicht herumschlagen.

Protokolle

Die verschiedenen verwendeten Protokolle sind im git-Repo dokumentiert: link.

Qsicon Ueberarbeiten.png 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.