LED-Matrix mit Madrix ansteuern (nicht DMX)

  • Hallo Zusammen


    Ich bin im 4. Lehrjahr zum Elektroniker und plane langsam für eine Abschlussprüfung. Da ich nebenbei als Lichttechniker bei einem grösseren Konzertlokal arbeite, schwebt mir folgendes vor:


    Ein LED Screen ähnlich wie dieser
    32x16 RGB LED Matrix - modular und aus Ping Pong Bällen


    Die Ansteuerung der Pixel möchte ich jedoch mit dem WS2801 realisieren.


    Der Screen kriegt einen DMX Anschluss, um vorprogrammierte Visuals aufzurufen und abzuändern. Die Visuals werden zuvor am PC erstellt und auf einer SD-Karte abgespeichert.


    Andererseits würde ich den Screen gerne mit Madrix ansteuern. Und zwar nicht via DMX. Weil schon bei 512 Pixel bräuchte ich 3 DMX-Universen. Für mich als Lichttechniker ist das eine Vergewaltigung von DMX.
    Madrix unterstützt ja noch andere Protokolle wie DVI, T9, Philipps Color Kinetics etc.


    Hat jemand von euch Erfahrung mit einem dieser Protokolle? Welches ist das Beste? Scheint mir die sauberere Variante als DMX.


    Lieber Gruss


    Matthias

  • Ich habe auch etwas ähnliches vor, nämlich eine LED Matrix, die ein bischen wie diese Lichterketten aufgebaut ist, bei denen an einem waagerechtem Kabel Streifen mit Leds gehängt werden. Da ich auch viel mit Bühnentechnik zu tun habe, soll die WS2801-Pixel auch mit einem DMX Anschluss ausgestattet werden.
    Wenn du also dazu schon was gefunden hast, kannst dus ja mal schreiben.
    Tim

  • Wenn es nicht DMX und nicht unbedingt Madrix sein soll, warum nimmst Du dann nicht gleich einen Controller für die WS2801. Da gibt es ja reichlich Alternativen. Neben dem "einfachen" Ledwalker, der seine Animation nur von SD-Karte abspielen kann, gibt es noch den Online-Controller wie von 2bl im Projekt verwendet.


    hier ein paar Links:
    "Digitaler RGB-Strip" mit WS2801
    [Sammelthread] RGB Pixelcontroller und Controller-ICs Übersicht


    Dann gibt es auch noch das SEDU-Board. Die Ausgabe für WS2801 ist da ja schon realisiert, allerdings bisher nur bis 64 RGB-Kanäle. Aber die Erweiterung auf mehr Pixel sollte kein großes Problem sein. Pesi ist da sowieso schon dran, denke ich. Und, für das SEDU gibt es auch eine DMX nach WS2801-Umsetzung für ein gesamtes Universum, soweit ich weiß. Also mit ein wenig Programmierung sollte da etwas möglich sein.

  • Ich habe schon ne SW gemacht, die 3.072 Kanäle über USB empfängt, und an 1.024 WS2801 ausgibt - nur, die hilft auch nix, weil die Daten wie bei mini-DMX empfangen werden, und das kann Madrix ja wiederum nicht ausgeben...


    T9 sagt mir nix, rohe RGB-Daten aus DVI raus zu bekommen stelle ich mir recht schwierig vor, und auch bei Color Kinetics deutet der Satz:

    Zitat

    Die Steuergeräte konvertieren die von MADRIX gesendeten Ethernet-Daten in Daten, die von jedem einzelnem Color-Kinetics-Lichtpunkt verstanden werden.

    darauf hin, dass das nicht so einfach wird (eben weil's über Ethernet geht, und man muss auch erst mal das Protokoll rausfinden). Das geht dann schon weit über "ein wenig Programmierung" hinaus... ;)


    kleine "Vereinfachung" wäre höchstens, statt dem Weg, DMX-Interface an Madrix, und dann aus DMX wieder WS2801 zu machen, eben gleich mit ner SW (auf dem SEDU z.B.) dem Madrix ein USB-Interface (z.B. uDMX o.ä.) "vorzugaukeln", also den direkten Weg USB -> WS2801...


    aber mit der selben Einschränkung, dass man dann 3 solche Konverter bräuchte, weil ja jeder dem Madrix nur ein DMX-Interface mit eben einem Universum vorgaukelt...


    grundsätzlich stimme ich schon zu, dass DMX für sowas eher nicht geeignet ist, aber *einfacher* wäre es in diesem Fall (bei 3 Universes) wohl schon, 3x ein günstiges kompatibles DMX-Interface und 3x ne Umsetzung DMX -> WS2801 dran...


    Turi: Madrix ist halt Madrix, das hat schon seine Berechtigung (schon mal damit rumgespielt...?) - da zu sagen "wenn's nicht unbedingt Madrix sein soll" ist halt ungefähr so, wie wenn man jemandem, der Final Scratch mit Plattenspielern benutzen will, sagt, er kann doch auch mit Kassetten auflegen... :D

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Danke für eure Antworten!

    Wenn es nicht DMX und nicht unbedingt Madrix sein soll, warum nimmst Du dann nicht gleich einen Controller für die WS2801. Da gibt es ja reichlich Alternativen. Neben dem "einfachen" Ledwalker, der seine Animation nur von SD-Karte abspielen kann, gibt es noch den Online-Controller wie von 2bl im Projekt verwendet.


    Wenn ich "einfach einen Controller nehme", wird das ganze eben zu einfach. Es soll ja eine Abschlussarbeit werden, wo man Hardware-, wie auch Softwaremässig etwas umsetzen muss.

    Zitat

    grundsätzlich stimme ich schon zu, dass DMX für sowas eher nicht geeignet ist, aber *einfacher* wäre es in diesem Fall (bei 3 Universes) wohl schon, 3x ein günstiges kompatibles DMX-Interface und 3x ne Umsetzung DMX -> WS2801 dran...


    So wies scheint, werde ich um DMX wohl oder übel nicht rumherum kommen. Jedoch hatte ich die Idee mit Artnet.
    Hat jemand von euch schon was mit Artnet gemacht?
    Für diejenigen die nicht wissen was es ist, es ist ein Ethernetprotokoll für DMX über TCP/IP.

  • wirf mal einen Blick in dieses Thread: <a href="http://www.ledstyles.de/ftopic17543.html" wcf_href="http://www.ledstyles.de/ftopic17543.html">USB DMX Interface für mehrere DMX Universen</a><br><br>bzw. auf die dort verlinkten Seiten (DMXcontrol-Forum, ArtNetKnoten auf Basis des Pollin-NetIO-Boards, weiterentwickelte ArtNet Knoten...)<br><br>Edit: Wenn Du Dir Arbeit machen willst - wie wäre es damit, das Netzwerkprotokoll des Onumen 2100 COntroller reverse-zu-engineeren, und dann einen Software-ArtNet-Knoten zu schreiben, der eben dieses Protokoll ausgibt? <br><br>Damit hätte man dann eine relativ lowcostige Lösung für ArtNet -&gt; 8xWS2801 Universum (bzw. alle anderen Chips, die der Onumen-Controller ausgeben kann), ganz ohne teure kommerzielle ArtNetKnoten plus DMX-&gt;WS2801-Umsetzer...<br><br>Hatte mir das mal überlegt, aber auf die lange Bank geschoben, weil andere Sachen dringender sind...<br>

  • Es soll ja eine Abschlussarbeit werden, wo man Hardware-, wie auch Softwaremässig etwas umsetzen muss.

    Ach, *darum* geht's hier, hätte gedacht, Du brauchst das für nen Einsatz in ner Disco, Bühne, o.ä.

    Hat jemand von euch schon was mit Artnet gemacht?

    Ja, viele hier, aber (m.W.) die meisten nur als Anwender... Einer wollte so nen Umsetzer Artnet-WS2801 programmieren, da hat dieses Pollin-Net-I/O aber wohl zuwenig Rechenleistung für...

    Wenn Du Dir Arbeit machen willst - wie wäre es damit, das Netzwerkprotokoll des Onumen 2100 COntroller reverse-zu-engineeren, und dann einen Software-ArtNet-Knoten zu schreiben, der eben dieses Protokoll ausgibt?

    Das wäre natürlich ne gute Idee, um die HW-Beschränkung des Pollin-Artnet-Knoten zu umgehen...


    wobei der Onumen ja auch nicht gerade billig ist...? - da kann man ja dann fast schon die Original-Madrix-HW verwenden..? (Jagut, hängt halt auch immer davon ab, was man für Bezugsquellen hat etc. ;))

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ach, *darum* geht's hier, hätte gedacht, Du brauchst das für nen Einsatz in ner Disco, Bühne, o.ä.


    Also schlussendlich kommts schon in nem grösseren Konzertlokal zum Einsatz. Es soll daher auch schlussendlich wirklich gut funktionieren. Aber Hauptgrund ist eben die Abschlussarbeit.




    Das wäre natürlich ne gute Idee, um die HW-Beschränkung des Pollin-Artnet-Knoten zu umgehen...


    wobei der Onumen ja auch nicht gerade billig ist...? - da kann man ja dann fast schon die Original-Madrix-HW verwenden..? (Jagut, hängt halt auch immer davon ab, was man für Bezugsquellen hat etc. ;))


    Sorry, aber da sehe ich jetzt irgendwie grad nicht so durch. Wieso das Onumen-Protokoll reverse engineeren, wenn man doch gleich ein ArtNet zu WS2801 Interface machen könnte? Oder verstehe ich da etwas falsch? Mit der Rechenleistung werde ich kein Problem haben.
    Lieber Gruss
    Matthias

  • Sorry, aber da sehe ich jetzt irgendwie grad nicht so durch. Wieso das Onumen-Protokoll reverse engineeren, wenn man doch gleich ein ArtNet zu WS2801 Interface machen könnte? Oder verstehe ich da etwas falsch? Mit der Rechenleistung werde ich kein Problem haben.

    Na ja, es ging mir darum, das man dann die existierende Hardwareplattrorm (Ethernet -> 8x WS2801, LPD6803, TM1804, DMX, etc) mit ArtNet ansprechen koennte, und sich die Entwicklung eben dieser sparen koennte :)

  • wenn man doch gleich ein ArtNet zu WS2801 Interface machen könnte? Oder verstehe ich da etwas falsch? Mit der Rechenleistung werde ich kein Problem haben.

    Ja, wie kommst Du denn zu der Aussage...? - das hat doch jemand hier schon probiert, und eben festgestellt, dass die Rechenleistung eines AVR dafür nicht reicht...


    oder willst Du ne andere HW-Plattform (ARM o.ä.) nehmen...?


    im Prinzip, bevor man da groß rumprogrammiert, kann man doch einfach diesen fertigen Artnet/DMX-Knoten nehmen, und dann halt noch nen Mega8 dran, der aus DMX wiederum WS2801 macht, das zusammen in ein Gehäuse, und Du hast Deinen Artnet/WS2801-Knoten - interessiert doch keinen, ob in dem Gerät nun 2 oder 3 ICs drin sind.... ;)


    aber hier, wie auch wenn Du es schaffst das auf einem µC zum laufen zu bringen, hast Du wieder die "DMX-Beschränkung", dass Du je 512 Kanäle (also pro 170 WS2801) ein Gerät brauchst...


    sinnvoller wäre es da wirklich, wenn man rausfinden könnte, wie eines dieser anderen Protokolle mit mehr Kanälen aufgebaut ist, die Madrix auch ausgeben kann...


    dann könnte man z.B. ne SW schreiben (für den PC), die dieses Protokoll (auf dem selben Rechner) "abfängt", und die Daten einfach über USB über nen VCP rausgibt...


    ne funktionierende SW, die über USB mit 1 Mbit/s bis zu 3.072 Kanäle empfängt und an bis zu 1.024 WS2801 weitergibt, hätte ich schon hier... ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ja, wie kommst Du denn zu der Aussage...? - das hat doch jemand hier schon probiert, und eben festgestellt, dass die Rechenleistung eines AVR dafür nicht reicht...


    oder willst Du ne andere HW-Plattform (ARM o.ä.) nehmen...?


    Ich werde mir die Hardware komplett selber aufbauen. Basierend auf einem LPC1768 aus der ARM 3 Reihe. Habe schon etliche Projekte mit dem realisiert. Und wenn sich ein WLAN-Webradio mit gutem Audiostreaming realisieren lässt, kann ich mir nicht vorstellen, dass ich es nicht hinbringe, einen direkten ArtNet - WS2801 Knoten zu realisieren.


    Wobei ArtNet - WS2801 stimmt nicht ganz. Der ARM 3 wird lediglich das ArtNet entschlüsseln. Das generieren des Signals für den WS2801 werde ich mit einem FPGA realisieren, damit ich wirklich die volle Geschwindigkeit ausnützen kann.


    aber hier, wie auch wenn Du es schaffst das auf einem µC zum laufen zu bringen, hast Du wieder die "DMX-Beschränkung", dass Du je 512 Kanäle (also pro 170 WS2801) ein Gerät brauchst...


    Nein nicht unbedingt. Was spricht dagegen, dass ich mit einem uC gleich mehrere DMX-Kanäle entschlüsseln kann? Der WS2801 ist ja rein theoretisch unendlich kaskadierbar? (Solange es mit dem Timing aufgeht natürlich)



    Ich hoffe ihr könnt mir irgendwie folgen. Bis sehr dankbar um eure Beiträge!


    Lieber Gruss
    Matthias

  • Klar, mit nem ARM3 geht das natürlich, das ist ja ein ganz anderes Kaliber... nachdem von der HW bis jetzt nicht die Rede war, bin ich natürlich eher von den hier üblichen AVRs ausgegangen... ;)


    und, natürlich, der kann ja dann auch gleich mehrere Artnet-Knoten verwalten (also mehrere *Universes*, das meintest Du wohl..?), das sollte kein Problem sein.


    Ob der FPGA unbedingt nötig ist, k.A. - max. Datenrate beim WS2801 ist ja 25 MHz, aber in der Praxis zickt das Teil bei den hier (von den Usern im Forum) verwendeten Datenraten (2-16 MHz) schon mal gerne rum, bei 25 MHz hat man dann evtl. noch mehr Probleme bei zu langer Leitung o.ä.


    ... hat der ARM nicht auch nen HW-SPI, schafft der das nicht selbst, also ohne extra FPGA, serielle Daten mit 25 MHz rauszugeben...?

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Hallo Zusammen


    Zuerst mal sorry, dass ich mich so lange nicht mehr gemeldet habe. War ziemlich beschäftigt. Aber es hat sich auch einiges getan beim Projekt.


    Ich könnte mir vorstellen, das Matthias den FPGA verwenden möchte, um mehrere SPI-Universen zeitglicvh auszugeben? Keine Ahnung wieviele Hardware-SPIs der ARM hat?


    Aus Interesse: wie stellst Du die (Hardware/Protokoll) die Kommunikation ARM -> FPGA vor?


    Viele Grüße
    Andre


    Mein ARM3 hat ein Hardware SPI. Mein Ziel wäre es, die Anzahl SPI-Universen möglichst tief zu halten und die Frequenz möglichst hoch. Da die WS2801 nicht einzeln ansprechbar sind, hab ich mir gedacht, dass das schicken der Daten ein FPGA übernehmen könnte, damit ich auf dem ARM3 nicht zu viel Rechenleistung dafür verliere. Im FPGA würde ich ein Bitmap mit den Farbinformationen anlegen. Soll sich etwas auf dem Screen ändern, ändert der ARM3 das Bitmap im FPGA. Der ARM3 ändert also nur die Pixel welche auch wirklich geändert werden sollen, und der FPGA schickt alle Pixel raus. Ich hoffe ihr könnt mir in etwa folgen?!
    Zum Protokoll habe ich mir noch nicht gross Gedanken gemacht. Aber es wird wohl eine synchrone serielle Übertragung, SPI, sein.
    [Pixelzeile][Pixelspalte][Rot][Grün][Blau]
    Aber ob das ganze wirklich nötig ist, wird sich noch heraus stellen.


    Im Internet habe ich mir WS2801-Breakouts bestellt. Dazu habe ich einen Adapter gemacht, welcher auf mein LPC1768-Board passt(Siehe Bild unten). Nun bin ich mit den WS2801 am "rumspielen". Und da hat sich folgendes Problem ergeben.


    Die WS2801 latchen erst bei einer Zeit von >940us und nicht wie im Datenblatt beschrieben bei >500us. Hatte jemand schon ein ähnliches Problem?


    Unten habe ich noch Bilder des Signales angehängt. Das SPI wird momentan Softwaremässig generiert. Aber auch wenn ich das Hardware SPI nehme, verhalten sich die WS2801 genau gleich. Es wäre wirklich schade, wenn ich so viel Zeit mit latchen verlieren würde.


    Wie ihr auf dem Foto sehen könnt, befinden sich auf dem Print 3 WS2801. Mit diesem Protokoll sollte jedoch nur einer angesteuert werden, jedoch schiebt der erste die Daten ab und zu durch. Die Zeiten sind jedoch alle immer Exakt gleich. Weiss ech nicht mehr weiter, wie ich diese Zeit auf die 500us kriegen könnte. Ich hoffe ihr könnt mir helfen.


    [Blockierte Grafik: http://s7.directupload.net/images/110913/mkdeqy3c.jpg]


    [Blockierte Grafik: http://s1.directupload.net/images/110913/u9okceic.jpg
    [Blockierte Grafik: http://s1.directupload.net/images/110913/i56sfnz3.jpg]

  • Die WS2801 latchen erst bei einer Zeit von >940us und nicht wie im Datenblatt beschrieben bei >500us. Hatte jemand schon ein ähnliches Problem?

    Ja, das Problem haben turi und ich i.M. auch - unsere SW (für das SEDU-Ambilight etc.) ist ja auch auf 500 µs ausgelegt, hat auch immer funktioniert, bei der neuen Lieferung Stripes nicht mehr - anscheinend haben die Chinesen ohne Ankündigung da die Spezifikation geändert, oder ne große Charge Murks produziert... :D


    aber das ist doch eigentlich kein Problem, man erreicht trotzdem genügend hohe Refreshraten... ich schiebe das mit SW-SPI raus, also nur ca. 1 MHz Pixeltakt, mit 1 ms Pause komme ich da bei 512 Pixel in einer Kette auch noch auf 75 fps...


    mehr in einem Strang ist auch nicht üblich, der Onumen-Controller macht das z.B. auch so, aber an 8 Ausgängen gleichzeitig - dafür (also 8 Ausgänge gleichzeitig) habe ich auch ne SW-SPI gemacht, die braucht dann aber etwas länger als 16 Takte/Bit, da komme ich mit hoher Framerate (60 fps) dann nur noch auf ca. 300 Pixel/Ausgang...


    wie viele Pixel willst Du denn nun mit dem Teil ansteuern...? - soll der FPGA das auch auf mehreren Leitungen parallel raus schieben, oder nur auf einer...?


    ich meine nur, wenn Du HW-SPI hast mit meinetwegen 1.024 Pixel dran, sollte das doch kein Problem sein, direkt den SPI vom ARM zu nehmen, ohne den FPGA zusätzlich... wie gesagt, 1.024 Pixel bekomme ich sogar mit SW-SPI auf nem AVR noch mit vernünftiger Framerate (ca. 33 fps) raus...


    nur aus Neugier: Wo hast Du denn diese WS2801-Pixelplatinen her (Sparkfun?), und was hast Du dafür bezahlt...? - der Andy_KEH hier im Forum verkauft sowas auch, könnte mir denken, dass seine billiger sind.. ;)

    It's only light - but we like it!


    Da es sich in letzter Zeit häuft: Ich beantworte keine PNs mit Fragen, die sich auch im Forum beantworten lassen!
    Insbesondere solche von Mitgliedern mit 0 Beiträgen, die dann meist auch noch Sachen fragen, die bereits im entsprechenden Thread beantwortet wurden.
    Ich bin keine private Bastler-Hotline, technische Tipps etc. sollen möglichst vielen Lesern im Forum helfen!

  • Ja, das Problem haben turi und ich i.M. auch - unsere SW (für das SEDU-Ambilight etc.) ist ja auch auf 500 µs ausgelegt, hat auch immer funktioniert, bei der neuen Lieferung Stripes nicht mehr - anscheinend haben die Chinesen ohne Ankündigung da die Spezifikation geändert, oder ne große Charge Murks produziert... :D

    Da bin ich ja froh, bin ich nicht der einzige. Dann kann ich ja endlich aufhören an meinem SPI rumzubasteln, dann gehts eifach nicht.


    Wegen dem FPGA. Grundsätzlich soll mein System über 512Pixel verfügen. Aber ich gehe fest davon aus, dass ich es stetig vergrössern werde. Daher möchte ich mich auch nicht von Anfang an beschränken. Ich muss ganz ehrlich sagen, dass ich die Performance noch nicht fix durchgerechnet habe mit Taktfrequenzen, SPI Frequenzen etc. Bin bis jetzt immer davon ausgegangen, dass es eh nicht reichen wird, mehrere SPI Universen Plus Ethernet zu haben. Der FPGA würde also mehrere rausschieben können, je nach dem wie gross der Screen dann halt wäre. Deine Argumente leuchten mir ziemlich ein. Als nächstes werde ich einen 8x8 Prototyp aufbauen und mal schauen, wie ich mit der Performance fahren kann, um abzuschätzen, ob es den FPGA wirklich braucht.


    nur aus Neugier: Wo hast Du denn diese WS2801-Pixelplatinen her (Sparkfun?), und was hast Du dafür bezahlt...? - der Andy_KEH hier im Forum verkauft sowas auch, könnte mir denken, dass seine billiger sind.. ;)

    Ja die sind von Sparkfun. Da hast du mich erwischt. ;) Bezahlt haben wir 5$, fixfertig bestückt und gelötet. War gleich am einfachsten so, da wir die WS2801 auch gerade dort bestellten. Aber danke für den Tipp.
    Als nächstes werde ich 3 eigene Pixelplatinen für meine Wunsch-LEDs herstellen. Wenn die dann was taugen, gehts ab hinter den Prototypen. Habe da schon Interessante pläne.


    Danke und Gruss.

  • Ja, die Pixelplatinen waren mir auch gleich aufgefallen

    Bezahlt haben wir 5$, fixfertig bestückt und gelötet.

    Na dann weißt du ja jetzt, dass es sich lohnt hier im Forum mal zu suchen. Ich kenn jetzt gerade nicht den aktuellen Dollarkurs, aber günstiger wäre es hier dann schon geworden :P
    Wäre nur noch interessant, ob ihr die WS2801 beim Turi nicht auch billiger bekommen hättet.... ^^

  • Wäre nur noch interessant, ob ihr die WS2801 beim Turi nicht auch billiger bekommen hättet.... ^^

    Ja in seinem Shop wären sie effektiv günstiger gewesen. Hätte auch sehr gerne dort bestellt. Nur macht bei uns die Buchhaltung Stress. Die wollen entweder nur gegen Rechnung oder Kreditkarte. Alles andere geht nicht. Daher ist der Shop nicht möglich gewesen...