DMX: Timing / RGB-LED-Matrix

[deep-image]

Hi,

soweit ich mich bisher eingelesen habe, gilt für DMX folgendes :

- 512 Kanäle werden mit einer Refresh-Rate von 44 Hz gesendet
- schneller geht´s nur mit weniger Kanälen, weil dann einfach weniger Werte gesendet werden.

Wenn man jetzt eine größere RGB-LED-Matrix bauen will, seh ich ein paar Probleme:

Bei RGB = 3 Werten pro Pixel kann man mit DMX 170 LEDs ansteuern. Das Senden aller 512 Kanäle dauert nach Wikipedia 23 ms, was im Audiobereich schon eine nicht zu vernachlässigende Latenz ist. Wenn also alle Pixel von "aus" auf irgendeine Farbe gestellt werden, dann ist das letzte Pixel 23ms zu spät dran. Macht sich das praktisch bemerkbar, so dass man doch lieber weniger Pixel pro DMX-Universum ansteuert ? Für Deckenbeleuchtung natürlich egal, aber für eine LED-matrix mit bewegten Mustern, also eine Lichtorgel auf Steroiden, vielleicht doch relevant ?

Bei den kommerziellen DMX-Interfaces gibt es anscheinend Unterschiede im Timingverhalten:

- manche lassen alles vom PC machen, andere haben eigene Intelligenz
- die einen senden immer alle 512 Kanäle (=konstante Verzögerung) , andere nur die jeweils geänderten, was natürlich ständig schwankende Verzögerungen bedeutet.

Wie sieht das da bei den Selbstbauprojekten aus ?

Für mehr als ein DMX Universum kann man entweder mehrere Interfaces an den PC hängen, also USB oder seriell, aber das ist mir nicht so ganz geheuer. Alternativ gibt´s die Möglichkeit, DMX über Ethernet zu verschicken (Art-Net), was auch heißt, dass deutlich weniger Kabelsalat anfällt. Auch hierfür gibt´s kommerzielle Teile (z.B. EntTec ODE, um die 250 Euro) und Selbstbauprojekte (auf AVR Basis als Bausatz für 25 Euro). Habt ihr da Erfahrungen ? Faktor 10 ist schon ein Wort, da neige ich doch zum Selbstbau, wenn´s denn funktioniert


Viele Grüße,

Oliver

[root]

Also für größere Sachen würde ich nicht umbedingt DMX nutzen um jede LED einzeln ansteuern zu können, dafür gibt es sicherlich andere Lösungen. Wenn man es doch über DMX machen will, würde mir spontan zwei Sachen einfallen, um diese Verzögungung zu unterdrücken.

1.) Varinate: Du speicherst in einem Controller die gewünschten Animationen und rufst diese dann z.B. über nur einen DMX Kanal auf.
Bsp.: DMX Kanal 1. Im Wertebereicht 0-10: alle LED's grün
11-20 obere hälfte blau unten rot
21-30 Strichmännchen auf roten Hintergrund

Die genaue Ansteuerung für die LEDs liegt dann im Controller und wird nicht über DMX gesendet.

2.) Varinate: Du wartest immer ab bis ein ganzes Universe empfangen wurde, also alle 512Kanäle und machst dann erst die Ausgabe. Somit hast du die Änderung quasi sofort, zwischen zwei verschiedenen "Bildern" liegen dann aber immernoch 23ms. Bis halt alle Daten erneut übertragen wurden. Damit könntest du theoretisch nen Film mit ca. 44Hz ablaufen lassen. Bei 25Hz solltest du auf jeden Fall nen flüssigen Bewegungsablauf im Film erhalten

[deep-image]

Hi,

die zweite Variante passt glaub ich besser. Ich komm ja eigentlich aus der Ecke Musikmachen / MIDI / Videos schneiden, da arbeite ich sowieso mit SMPTE und 25fps. Selbst wenn man auf US-Norm gehen würde und 30 fps fährt, wäre da zu 44 Hz immer noch Luft. Bei normalen LCDs am PC hat man zwar 50 oder 60 Hz und die PC Zocker können auch nur mit dreistelligen Framerates spielen , aber um ein paar Muster an der Decke tanzen zu lassen sollte irgendwas zwischen 24 und 30 fps reichen.

Variante 1, nur mit Mikrocontroller, ginge schon auch, wäre aber deutlich komplexer als "nur" eine DMX-to-LED Steuerung, letztere gibt´s ja in mehreren Varianten zum Nachbauen. Schneller wär´s bestimmt, aber dann müsste ich sowohl die Grafikprogrammierung im uController machen und mir auch für die Steuerung noch was einfallen lassen, wenn´s nicht DMX sein soll. Weil das ganze ja auch noch synchron zum Beat kommen soll, wäre dann MIDI-to-DMX bzw. Audio-to-DMX auch noch zu lösen - das kann ich mir alles hoffentlich sparen, wenn ich das PC mache, denn dafür gibt´s auch schon nette Software wie z.B. Max/DSP, vvvv und andere.

Im Endstadium würde das dann so aussehen, dass z.B. vvvv sich auf MIDI-Clock, MTC, SMPTE synchronisiert oder das Tempo aus einem Audiosignal herausrechnet. vvvv generiert dann auch die Muster und setzt das auf Art-Net / DMX um und schickt es an die einzelnen Pixel.

Ich glaube in der Form ist der Löt- und Programmieraufwand am geringsten, das wird ja eh ein Monsterprojekt, das mich mit Sicherheit locker bis Jahresende beschäftigt...