Vaporlight:Anleitung: Unterschied zwischen den Versionen

aus dem Wiki des Entropia e.V., CCC Karlsruhe
K (fixme)
Keine Bearbeitungszusammenfassung
(9 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
[[Datei:A28_OhICAAEgeec.jpg-large.jpg|400px|thumb|right|Immer feste druff! - Bohren der Löcher für die Anschlüsse]]
Lieber Entropianer!
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. [[Benutzer:Felix|Felix]] macht die Hardware und [[Benutzer:Andi|Andi]] die Software.
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. [[Benutzer:Felix|Felix]] macht die Elektronik, [[Benutzer:Le|Le]] und [[Benutzer:DeviDave|DeviDave]] machen die Mechanik, [[Benutzer:Nervengift|Nervengift]] auch ein bisschen, [[Benutzer:Andi|Andi]] die Software und [[:Kategorie:Entropianer|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.
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.
Diese Anleitung bezieht sich momentan auf '''Vaporlight Forever 23''' und '''Vaporware V. -2.76 "Calcium"'''.


__TOC__
__TOC__
Zeile 11: Zeile 12:
=Die LED-Boards=
=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.
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) 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.
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==
==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.
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==
==Schutzmechanismen==
Zeile 26: Zeile 27:


{|
{|
| — — —  || Das Modul wurde nicht konfiguriert und kann so nicht arbeiten.
| — ·    – · – ·  || 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 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?
|-
|-
| · · · · || 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
|-
|-
| · · —  || Der serielle Bus ist anscheinend kaputt. Stecken alle Kabel noch?
| ''schnelles, unregelmäßiges Blinken'' || Der serielle Bus ist anscheinend kaputt. Stecken alle Kabel noch und stimmt die Baudrate?
|-
|-
| · — —  || Der TWI-Bus auf dem Modul hat Probleme. Ein Fall für die Werkstatt.
| ''langsames Blinken'' || Der Prozessor ist über einen schweren Interrupt gefallen. Lösung: siehe Bug.
|}
|}


==Der serielle Bus (RS485)==
==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:
Ü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.


'''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.
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:


'''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.
* ''<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.


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.
Im Konfigurationsmodus gibt es andere Kommandos, aber damit muss sich der gemeine Animator nun wirklich nicht herumschlagen.


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.
=Protokolle=


=Der Busmaster=
Die verschiedenen verwendeten Protokolle sind im git-Repo dokumentiert: [https://github.com/entropia/vaporlight/blob/master/HACKING link].
 
=Netzwerkprotokoll=
 
=Low-Level-Dateiformat=


[[Kategorie:Projekte]]
[[Kategorie:Projekte]]
[[Kategorie:Blinkendes]]
[[Kategorie:Blinkendes]]
{{FIXME}}
{{FIXME}}

Version vom 11. Dezember 2013, 01:17 Uhr

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.