Blinkencontrol: Difference between revisions

From Chaosdorf Wiki
(update pending)
(Update)
Line 12: Line 12:
[[File:Blinkencontrol.png|Schaltplan für RGB|200x200px|framed|right]]
[[File:Blinkencontrol.png|Schaltplan für RGB|200x200px|framed|right]]


Eine Instanz hängt in der [[Laptop Lounge]] und steuert den RGB-Streifen im Schaufenster. Angeschlossen per GPIO an {{H|donationprint}}, Ansteuerung wie gewohnt per [http://dorfmap/blinkencontrol/lounge_rggb dorfmap] (siehe auch [[Lichtsteuerung]]).
Eine Instanz hängt in der [[Laptop Lounge]] und steuert den RGB-Streifen im Schaufenster. Angeschlossen per GPIO an {{H|donationprint}}, Ansteuerung wie gewohnt per [http://dorfmap/blinkencontrol/lounge_rggb dorfmap] (siehe [[Lichtsteuerung]]).


== Protokoll ==
== Protokoll ==


Nicht mehr aktuell, wird bald™ aktualisiert.
Die Firmware führt beliebige Animationen aus, wobei eine Animation aus bis zu 24 Schritten aus Farbe und Fadedauer besteht. Nach einer Übertragung wird die Animation immer vom ersten bis zum letzten übertragenen Schritt ausgeführt.


<strike>
Eine Animation mit nur einem Schritt entspricht Dauerleuchten, über die Fadedauer kann aber eingestellt werden, wie schnell der Übergang von der aktuellen Farbe dauert.
Sechs Byte: <tt>mode red green blue addrhi addrlo</tt>. Zuerst wird <tt>mode</tt> übertragen, danach die Farben, dann die Adresse.
Jeweils most significant bit first.


<tt>red</tt>, <tt>green</tt> und <tt>blue</tt> sind PWM-Level von 0 (aus) bis 255 (maximale Helligkeit). Beachten: Es findet derzeit keine Helligkeitsanpassung statt, d.h. es wird linear gefadet, während das menschliche Auge Helligkeit [http://www.mikrocontroller.net/articles/LED-Fading logarithmisch wahrnimmt].
Animationen können immer nur schrittweise übertragen werden, da sie beim letzten übertragenen Enden, sollte der letzte Schritt auch zuletzt gesendet werden.


<tt>mode == MMMS SSSS</tt> setzt sich aus dem Betriebsmodus (MMM) und der Fade- / Blinkgeschwindigkeit (SSSSS) zusammen. Geschwindigkeit 0 ist am schnellsten, Geschwindigkeit 31 am Langsamsten. Die Farb-Bytes werden nicht bei allen Modi berücksichtigt.
Das Datenformat ist <tt>slot delay red green blue addrhi addrlo</tt>, wobei <tt>slot</tt> der Animationsschritt (0 .. 23) ist.
Beispiel für rotes Pulsieren (wechselnd an/aus):<tt>0 64 255 0 0 0 1</tt>, <tt>1 64 0 0 0 0 1</tt>.


{| class="wikitable"
<tt>red</tt>, <tt>green</tt> und <tt>blue</tt> sind PWM-Level von 0 (aus) bis 255 (maximale Helligkeit). Beachten: Es findet derzeit keine Helligkeitsanpassung statt, d.h. es wird linear gefadet, während das menschliche Auge Helligkeit [http://www.mikrocontroller.net/articles/LED-Fading logarithmisch wahrnimmt].
! Modus (Bits) !! Wat
|-
| 000 || steady (Dauerleuchten)
|-
| 001 || RGB, kein Fading
|-
| 010 || Zufallsfarbe, kein Fading
|-
| 011 || An/Aus Blinken
|-
| 100 || steady (Dauerleuchten), Fading zur neuen Farbe
|-
| 101 || RGB Fading
|-
| 110 || Zufallsfarbe Fading
|-
| 111 || An/Aus Fading
|}


== netcat-API ==
== netcat-API ==


Obiges Protokoll kann zur Ansteuerung diverser Geräte benutzt wrden. Die erste Zeile wählt das Blinkendevice aus (z.B. "blinkencontrol1" oder "charwrite1"), alle weiteren gehen an das jeweilige Programm. Nach den Daten muss teilweise noch die 16bit-Adresse übertragen werden, erst high byte, dann low byte. Der Daemon lauscht auf <tt>donationprint:25465</tt>.
Obiges Protokoll (teils in Variationen) kann zur Ansteuerung diverser Geräte benutzt wrden. Die erste Zeile wählt das Blinkendevice aus (z.B. "blinkencontrol1" oder "charwrite1"), alle weiteren gehen an das jeweilige Programm. Nach den Daten muss teilweise noch die 16bit-Adresse übertragen werden, erst high byte, dann low byte. Der Daemon lauscht auf <tt>donationprint:25465</tt>.
 
=== blinkencontrol1 ===
 
Nach blinkencontrol1 kommen (jeweils durch newline getrennt) die Werte für mode, red, green, blue, addrhi, addrlo als Zahlen (ASCII) von 0 bis 255. Die Werte werden entweder durch "push" oder Beenden der Verbindung übernommen.
 
Zu beachten: Bei Eingabe von Zahlen, die nicht innerhalb von 0 bis 255 sind, kann irgendwas undefiniertes passieren (Garbage in, garbage out).


Beispiel für Strobo mit Zufallsfarben:
Diese netcat-API wird bald abgeschaltet und durch eine API in der [[Lichtsteuerung]] (dorfmap) ersetzt.
<source lang="bash">
(
echo blinkencontrol1
while sleep 0.05; do
echo "0\n0\n0\n0\n0\n1\npush"
sleep 0.05
echo "0\n$((RANDOM%256))\n$((RANDOM%256))\n$((RANDOM%256))\n0\n1\npush"
done
) | nc donationprint 25465
</source>
</strike>


=== charwrite1 ===
=== charwrite1 ===

Revision as of 13:08, 8 August 2013

Blinkencontrol beta
Blinkencontrol hardware.jpg
generischer Blinkenlightfoo
Ort Laptop Lounge
Beteiligt derf
Quelltext github


Schaltplan für RGB

Eine Instanz hängt in der Laptop Lounge und steuert den RGB-Streifen im Schaufenster. Angeschlossen per GPIO an donationprint, Ansteuerung wie gewohnt per dorfmap (siehe Lichtsteuerung).

Protokoll

Die Firmware führt beliebige Animationen aus, wobei eine Animation aus bis zu 24 Schritten aus Farbe und Fadedauer besteht. Nach einer Übertragung wird die Animation immer vom ersten bis zum letzten übertragenen Schritt ausgeführt.

Eine Animation mit nur einem Schritt entspricht Dauerleuchten, über die Fadedauer kann aber eingestellt werden, wie schnell der Übergang von der aktuellen Farbe dauert.

Animationen können immer nur schrittweise übertragen werden, da sie beim letzten übertragenen Enden, sollte der letzte Schritt auch zuletzt gesendet werden.

Das Datenformat ist slot delay red green blue addrhi addrlo, wobei slot der Animationsschritt (0 .. 23) ist. Beispiel für rotes Pulsieren (wechselnd an/aus):0 64 255 0 0 0 1, 1 64 0 0 0 0 1.

red, green und blue sind PWM-Level von 0 (aus) bis 255 (maximale Helligkeit). Beachten: Es findet derzeit keine Helligkeitsanpassung statt, d.h. es wird linear gefadet, während das menschliche Auge Helligkeit logarithmisch wahrnimmt.

netcat-API

Obiges Protokoll (teils in Variationen) kann zur Ansteuerung diverser Geräte benutzt wrden. Die erste Zeile wählt das Blinkendevice aus (z.B. "blinkencontrol1" oder "charwrite1"), alle weiteren gehen an das jeweilige Programm. Nach den Daten muss teilweise noch die 16bit-Adresse übertragen werden, erst high byte, dann low byte. Der Daemon lauscht auf donationprint:25465.

Diese netcat-API wird bald abgeschaltet und durch eine API in der Lichtsteuerung (dorfmap) ersetzt.

charwrite1

Nimmt vier Zeichen (ASCII, 0-9a-zA-Z) an und überträgt sie bei einer Newline. Zum Beispiel:

echo "charwrite1\nohai" | nc donationprint 25465