Open Source Led Matrix Steuerung: PixelController

    Open Source Led Matrix Steuerung: PixelController

    Hallo zusammen

    Ich habe für meine Led Panels eine Software unter Open Source Lizenz veröffentlicht, PixelController. Die Software besteht aus Generatoren, Effekten, Mixer und Fader, ist Modular aufgebaut und unterstützt in der aktuellen Version LPD6803 Led Pixel. Um andere Hardware zu unterstützen kann einfach ein neues Modul erstellt werden.

    Als Frontend verwende ich PureData, das hat den Vorteil, dass der User das GUI einfach selber umgestalten kann und MIDI und OSC Signale zur steuerung verwendet werden können.

    Die Source ist unter github.com/neophob/PixelController zu finden. Ich habe ein Video mit der Software in Action gemacht: vimeo.com/27453711

    Was meint ihr dazu

    EDIT Pesi: Mit Einverständnis des TE verlinke ich hier immer die aktuelle compilierte Version, diese kann man also einfach runterladen und starten, ohne selbst den Sourcecode kompilieren zu müssen.

    Aktuelle Version ist 1.2.0

    Hier gibt es eine Bedienungsanleitung für die SW.

    Für die GUI braucht man noch Puredata, dieses gibt es hier zum download.

    Dieser Beitrag wurde bereits 8 mal editiert, zuletzt von „Pesi“ ()

    Klingt schon recht interessant, wobei das Video mir noch nicht so viel zur Software zeigt (außer den Effekten). Ist das eine Software, die Daten online ausgibt? Wie sieht denn das Protokoll aus bzw. aus welcher Hardware besteht das Interface zum PC?

    Edit: sieht nach Arduino aus, richtig?
    Hey Turi

    Die Software kannst du unter pixelinvaders.ch/PixelController-1.0-SNAPSHOT.zip herunterladen, eine erste Version des Handbuches ist unter pixelinvaders.ch/handbuch.pdf zu finden. Dort sollte mehr Informationen vorhanden sein.

    >Ist das eine Software, die Daten online ausgibt?
    ich denke du meinst, ob ein rechner die daten dem "dummen" panel rüberschiebt zum aktualisieren? dazu wäre die antwort ja.

    >Wie sieht denn das Protokoll aus bzw. aus welcher Hardware besteht das Interface zum PC?
    Arduino würde gehen, ich verwende aber ein Teensy board, grund dazu: Latenz (siehe auch neophob.com/2011/04/serial-latency-teensy-vs-arduino/)
    Interessante Sache! :thumbup:

    noch mal genauer zum Protokoll: Daten gehen über USB vom PC zum Teensy, richtig...? Wohl über nen VCP...?

    also praktisch am Teensy einfach seriell Daten empfangen - wie kommen die denn da...? - einfach "roh", also halt von links oben nach rechts unten RGB RGB RGB...?

    oder ist noch irgendein Header dabei, wie bei mini-DMX o.ä.?

    würde ich das wissen, könnte ich ne SW machen, die das auf WS2801 umsetzt, dann könnte man (also ich auch, solange was eigenes noch nicht fertig ist :D) das Programm auch mit den hier im Forum weiter verbreiteten WS2801-Pixeln benutzen... ;)
    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!
    Oder aber das Protokoll miniDMX o.ä. in die Software mit implementieren. Ist wahrscheinlich genauso einfach. Ich habe mal versucht, die Software zu starten. Läuft bei mir unter Win7 64Bit erst mal nicht. Verlangt der eine bestimmte Hardware am COM-Port beim Start?

    Mit dem Handbuch komme ich beim Überfliegen noch nicht so richtig klar. Liegt aber vielleicht auch daran, dass der Software eine ganz andere Philosophie als die bekannten Tools zum Onumen etc. zu Grunde liegt.

    turi schrieb:

    Oder aber das Protokoll miniDMX o.ä. in die Software mit implementieren. Ist wahrscheinlich genauso einfach. Ich habe mal versucht, die Software zu starten. Läuft bei mir unter Win7 64Bit erst mal nicht. Verlangt der eine bestimmte Hardware am COM-Port beim Start?


    Nein, die Software sollte auch ohne Hardware laufen. Was mir spontan einfällt ist, das er keine 64b version der lib rxtx findet. Versuch mal in Verzeichnis "lib" die Datei rxtxSerial64.dll nach rxtxSerial.dll zu kopieren (die andere Datei überschreiben). wenn immer noch nicht tut, paste doch mal den consolenoutput hier.

    Ich hoffe, wenn PixelController läuft, sollte das GUI auch mehr oder weniger selbsterklärend sein.

    cheers

    Pesi schrieb:

    Interessante Sache! :thumbup:

    noch mal genauer zum Protokoll: Daten gehen über USB vom PC zum Teensy, richtig...? Wohl über nen VCP...?

    also praktisch am Teensy einfach seriell Daten empfangen - wie kommen die denn da...? - einfach "roh", also halt von links oben nach rechts unten RGB RGB RGB...?

    oder ist noch irgendein Header dabei, wie bei mini-DMX o.ä.?

    würde ich das wissen, könnte ich ne SW machen, die das auf WS2801 umsetzt, dann könnte man (also ich auch, solange was eigenes noch nicht fertig ist :D) das Programm auch mit den hier im Forum weiter verbreiteten WS2801-Pixeln benutzen... ;)


    Unter github.com/neophob/PixelContro…ree/master/data/ArduinoFw findest du die Arduino/Teensy Firmware (und die LPD6803 Library). Dort habe ich ein ganz primitives Protokoll gemacht, zum pingen und daten senden. Und die Daten gehen vom PC über USB zum Teensy/Arduino, richtig.

    Prinzipiell bist du dann frei, wie du die Daten an den uP schickst. Aber im LPD6803 fall habe die oben beschriebene Firmware gemacht. Ob sich da ein Genereller Ansatz lohnt weiss im im Moment nicht. Ich denke da vorallem an die bit Tiefe, von 5bit (zb rainbowduino) bis 8bit ws2801 gibts da ja alles. Momentan schicke ich pro 32 Pixel eine message raus, sprich pro Panel muss ich 2 messages schicken um alles zu aktualisieren.

    Muss wohl mal schauen, was mini DMX ist, tönt noch interessant...

    michuNeo schrieb:

    Muss wohl mal schauen, was mini DMX ist, tönt noch interessant...
    Schau' doch mal hier...

    michuNeo schrieb:

    Prinzipiell bist du dann frei, wie du die Daten an den uP schickst. Aber im LPD6803 fall habe die oben beschriebene Firmware gemacht.
    Ja, für mich wäre die interessante Stelle, wie das über USB aus dem PC raus kommt - ob dann ein Arduino oder Teensy mit der LPD6803-Firmware oder SEDU mit WS2801-Firmware dran hängt, *sollte* im Idealfall egal sein...

    Ich habe mir das mal angesehen, die eigentliche Ausgabe passiert doch in der Datei "Lpd6803.java" in src\main\java\com\neophob\sematrix\output\lpd6803...? - zumindest steht da irgendwas mit Arduino drin und diese Umrechnung in die 3x5 Bit...

    aber da was zu ändern, dafür reichen meine Java-Kenntnisse leider nicht... :(

    michuNeo schrieb:

    Ob sich da ein Genereller Ansatz lohnt weiss im im Moment nicht. Ich denke da vorallem an die bit Tiefe, von 5bit (zb rainbowduino) bis 8bit ws2801 gibts da ja alles.
    Ich fände einen "generellen Ansatz" schon gut, in der Art, dass Deine SW einfach über USB (also als seriellen Datenstrom) die RGB-Daten von links oben nach rechts unten ausgibt.

    Natürlich mit nem "Header" zum synchronisieren dazu, z.B. eben wie bei Mini-DMX... da kommt ja "Startcode" 0x5A, dann ne Zahl je nach Frame-Größe... mein Kumpel und ich haben das inoffiziell für uns erweitert, dass dann 0xA3 bedeutet 768 Byte Nutzdaten (= RGB-Matrix 8x8 ) und 0xA4 3.072 Byte Nutzdaten (= RGB-Matrix 16x16) - mehr ist dann mit nem AVR auf 16 MHz schon nicht mehr drin, bei 0xA4 senden wir auch mit 1 Mbit/s...

    bei uns ist dann der Ansatz, dass die Umsetzung auf ein spezielles Datenformat (ob nun TM1804, LPD6803 oder WS2801 oder wasauchimmer) dann im Controller stattfindet - weil der "gehört" praktisch zur Matrix "dazu", der "weiß", wie die Pixel das brauchen - also könnte in Deinem Fall eben diese Firmware aus den 3x 8 Bit RGB-Daten dann 15 Bit LPD-Daten machen - bei mir sortiert sie z.B. die Bytes um, weil meine Matrix nicht von links oben nach rechts unten durchverkabelt ist, usw.

    also dass die SW am PC eben die Daten immer "generisch" als "rohe RGB-Daten" rausgibt, und spezielle Anpassungen dann in der FW auf dem Arduino/Teensy/SEDU/... stattfinden, weil *da* muss die FW sowieso an die verwendeten Chips angepasst werden...

    was hältst Du davon...?

    andere Frage: ist Deine SW nun fest auf 8x8 bzw. 16x8 ausgelegt, oder kann man das auch skalieren..? - weil ich baue gerade ne Matrix mit 20 x 10, wenn man die mit Deiner SW ansteuern könnte, wäre das natürlich ne super Sache! :thumbup:
    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!

    Pesi schrieb:

    Ja, für mich wäre die interessante Stelle, wie das über USB aus dem PC raus kommt - ob dann ein Arduino oder Teensy mit der LPD6803-Firmware oder SEDU mit WS2801-Firmware dran hängt, *sollte* im Idealfall egal sein...

    Ich habe mir das mal angesehen, die eigentliche Ausgabe passiert doch in der Datei "Lpd6803.java" in src\main\java\com\neophob\sematrix\output\lpd6803...? - zumindest steht da irgendwas mit Arduino drin und diese Umrechnung in die 3x5 Bit...

    Genau in diesem File bereite ich die Daten so auf, dass sie direkt in den arduino buffer kopiert werden können. einersetzt gebe ich den offset an (da ich nur 32 pixel übertragen kann, wegen des usb buffers), andererseits wandle ich den buffer von ursprünglich 24bit in 15bit um - so dass ich den arduino buffer einfach kopieren kann, ohne noch rechenzeit auf dem uP zu verbraten.

    Pesi schrieb:


    aber da was zu ändern, dafür reichen meine Java-Kenntnisse leider nicht... :(
    Ich fände einen "generellen Ansatz" schon gut, in der Art, dass Deine SW einfach über USB (also als seriellen Datenstrom) die RGB-Daten von links oben nach rechts unten ausgibt.

    denke der ws2801 ist da einfacher, da dieser controller ja 24bit pro pixel will, sprich man muss nix umrechnen. nur in der richtigen reihenfolge den buffer füllen. wenn du konkret ein paar led's hast, die du ansteuern willst sags nur, dann schauen wir zusammen, das sollte man schon zum fliegen bringen.

    Pesi schrieb:


    Natürlich mit nem "Header" zum synchronisieren dazu, z.B. eben wie bei Mini-DMX... da kommt ja "Startcode" 0x5A, dann ne Zahl je nach Frame-Größe... mein Kumpel und ich haben das inoffiziell für uns erweitert, dass dann 0xA3 bedeutet 768 Byte Nutzdaten (= RGB-Matrix 8x8 ) und 0xA4 3.072 Byte Nutzdaten (= RGB-Matrix 16x16) - mehr ist dann mit nem AVR auf 16 MHz schon nicht mehr drin, bei 0xA4 senden wir auch mit 1 Mbit/s...

    bei uns ist dann der Ansatz, dass die Umsetzung auf ein spezielles Datenformat (ob nun TM1804, LPD6803 oder WS2801 oder wasauchimmer) dann im Controller stattfindet - weil der "gehört" praktisch zur Matrix "dazu", der "weiß", wie die Pixel das brauchen - also könnte in Deinem Fall eben diese Firmware aus den 3x 8 Bit RGB-Daten dann 15 Bit LPD-Daten machen - bei mir sortiert sie z.B. die Bytes um, weil meine Matrix nicht von links oben nach rechts unten durchverkabelt ist, usw.

    also dass die SW am PC eben die Daten immer "generisch" als "rohe RGB-Daten" rausgibt, und spezielle Anpassungen dann in der FW auf dem Arduino/Teensy/SEDU/... stattfinden, weil *da* muss die FW sowieso an die verwendeten Chips angepasst werden...

    was hältst Du davon...?

    andere Frage: ist Deine SW nun fest auf 8x8 bzw. 16x8 ausgelegt, oder kann man das auch skalieren..? - weil ich baue gerade ne Matrix mit 20 x 10, wenn man die mit Deiner SW ansteuern könnte, wäre das natürlich ne super Sache! :thumbup:


    generisch wäre theoretisch sicher der beste weg, aber praktisch sehe ich da probleme. ich denke es wird sich zeigen was sinn macht. schlussendlich hast du diverse technische limiten die dich einschränken (zb. usb buffer, sprich maximale messagegrösse) andererseits gibt ganz verschiedene anforderungen.

    osray hat gerade sein coffeetable mit pixelcontroller betrieben (picasaweb.google.com/100582568014548321452/RGBCoffeetable) und noch einen artnet output hinzugefügt.. scheint sehr gut funktioniert zu haben

    michuNeo schrieb:

    generisch wäre theoretisch sicher der beste weg, aber praktisch sehe ich da probleme. ich denke es wird sich zeigen was sinn macht. schlussendlich hast du diverse technische limiten die dich einschränken (zb. usb buffer, sprich maximale messagegrösse) andererseits gibt ganz verschiedene anforderungen.
    Ah, jetzt verstehe ich das - Du schickst praktisch ein Telegramm an den Arduino, das kann aber nur ne max. Größe haben, eben weil's dort erst mal in nem Puffer landet, wo Du es dann raus lesen kannst...?

    bei mir ist das ja anders, ich mache das in Assembler, da wird immer ne ISR aufgerufen wenn ein Byte rein kommt, und das dann direkt verarbeitet, ich kann also kontinuierlich Daten empfangen, da gibt es keinen Puffer, der die Größe beschränkt...

    michuNeo schrieb:

    Genau in diesem File bereite ich die Daten so auf, dass sie direkt in den arduino buffer kopiert werden können.
    Ja, wäre es denn ein arg großer Aufwand für Dich, das so umzuprogrammieren, dass einfach die kompletten Daten da in einem Rutsch direkt als RGB-Daten über nen VCP rauskommen...? - halt so aufgefüllt (Nullbytes hinten anhängen), dass es insg. 512 Byte sind, davor dann 0x5A 0xA2 und danach 0xA5, das wäre dann mini-DMX... ;)

    dafür gibt's schon ne SW hier im Forum, die das auf WS2801 umsetzt - würde ich dann noch mal mit Doku in nen extra Thread machen - das wäre bestimmt für viele interessant, für mich mal zum spielen, für den praktischen Einsatz ist mein Rechner leider zu matt (Pentium M mit 1,7 GHz), da läuft deine SW zwar, aber seeehr zäääh...

    michuNeo schrieb:

    osray hat gerade sein coffeetable mit pixelcontroller betrieben (picasaweb.google.com/10058256801?/RGBCoffeetable) und noch einen artnet output hinzugefügt.. scheint sehr gut funktioniert zu haben
    Ja, witzig, das sind ja die von mir gelayouteten Pixelplatinen hier aus dem Forum.. ;) - auf den Fotos hat er da aber noch Madrix dran... ;)

    aber verstehe ich das richtig, es gibt also schon ne Erweiterung Deiner SW, die dann Artnet ausgibt...?

    Übrgens, dieser Thread enthält ja ne Projektvorstellung mit funktionierender SW drin, habe den also mal nach "LED Schaltungen, Treiber und µC" verschoben, da ist er besser aufgehoben und leichter wieder zu finden...
    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!

    Pesi schrieb:

    Ah, jetzt verstehe ich das - Du schickst praktisch ein Telegramm an den Arduino, das kann aber nur ne max. Größe haben, eben weil's dort erst mal in nem Puffer landet, wo Du es dann raus lesen kannst...?

    Genau - weil der Arduino (resp. die library) hat max. 92 oder 128 bytes platz für eine usb message.


    Pesi schrieb:

    Ja, wäre es denn ein arg großer Aufwand für Dich, das so umzuprogrammieren, dass einfach die kompletten Daten da in einem Rutsch direkt als RGB-Daten über nen VCP rauskommen...? - halt so aufgefüllt (Nullbytes hinten anhängen), dass es insg. 512 Byte sind, davor dann 0x5A 0xA2 und danach 0xA5, das wäre dann mini-DMX

    Extrem ja, weil ich da die arduino libraries nicht mehr brauchen könnte. es ist aber nicht wirklich ein nachteil, da ich so effektiv daten rausschreibe - ich schicke nur eine akualisierung raus, wenn sich der buffer auch wirklich geändert hat.

    noch ein grund gegen "immer alles raushauen", ich weiss ja nicht wieviele panels da vorhanden sind - sprich wenn du z.b. 8 panels hast, würde das bei 15 (16) bit farbtiefe
    64pixel * 2bytes = 128bytes * 8 Panels = 1kb (und 1.5kb für ein ws2801).
    bei 20 fps müsste da pro sekunde 20kb nutzdaten rauskommen, wobei effektiv vielleicht nur 15kb reichen würden. ich spare zwischen 25-50% der datenmenge, wenn ich nur daten rausschicke, wenn sie sich geändert haben.

    Pesi schrieb:


    Ja, witzig, das sind ja die von mir gelayouteten Pixelplatinen hier aus dem Forum.. - auf den Fotos hat er da aber noch Madrix dran...
    aber verstehe ich das richtig, es gibt also schon ne Erweiterung Deiner SW, die dann Artnet ausgibt...?

    Genau, er hat eine erste artnet erweiterung gemacht (github.com/neophob/PixelContro…/output/ArtnetOutput.java) und mir das gestern abend geschickt. ich habe das dann gerade eingecheckt. wie du siehst ist die erweiterung relativ simpel. er wird die artnet erweiterung jedoch noch verbessern, sprich die konfiguration flexibler gestalten.

    und danke fürs verschieben...

    michuNeo schrieb:

    Extrem ja, weil ich da die arduino libraries nicht mehr brauchen könnte.
    naja, ich dachte da an eine zusätzliche Version (so wie eben die Artnet-Erweiterung), nicht dass Du Deine Matrix umbaust... ;) - halt ein weiteres "Plugin" (?) das dann eben mini-DMX ausgibt, das wäre für viele hier von Vorteil...

    ich verstehe das noch nicht ganz, aber die SW, die da am PC läuft, ist doch vom Arduino unabhängig..? - also *da* hast Du doch die Möglichkeit nen Frame mit z.B. 259 Byte rauszuschicken...?

    klar, mit nem Arduino läuft das dann natürlich nicht mehr, aber selbst auf nen Arduino kann man doch eigene SW raufladen, die nicht mit der Arduino-IDE entwickelt wurde, also dann eben z.B. die von mir (könnte ich ja anpassen).

    michuNeo schrieb:

    noch ein grund gegen "immer alles raushauen", ich weiss ja nicht wieviele panels da vorhanden sind - sprich wenn du z.b. 8 panels hast, würde das bei 15 (16) bit farbtiefe
    64pixel * 2bytes = 128bytes * 8 Panels = 1kb (und 1.5kb für ein ws2801).
    bei 20 fps müsste da pro sekunde 20kb nutzdaten rauskommen, wobei effektiv vielleicht nur 15kb reichen würden. ich spare zwischen 25-50% der datenmenge, wenn ich nur daten rausschicke, wenn sie sich geändert haben.
    Ja, siehe hierzu auch die Überlegungen in diesem Thread - bei mir (Matrix für Bandhintergrund oder auf Partys) wäre das so, dass da recht schnelle Animationen laufen (so in der Art wie hier), sich also praktisch eh' *alle* Pixel von Frame zu Frame ändern, also kein Vorteil dadurch, dass man nur geänderte Pixel sendet...

    michuNeo schrieb:

    wie du siehst ist die erweiterung relativ simpel.
    Ja, womöglich für jemanden, der Java kann, ich kann's halt nicht... :D - war ja auch nur ne Frage, ich hätte halt gedacht, für Dich (der Du Dich auch nicht erst da rein denken musst, die SW ist ja von Dir) wäre das ne Sache von 15 Min., die Routine so zu machen, dass sie einfach die RGB-Daten + Blockstart- und Blockende-Bytes über seriell rausschiebt...
    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!

    Pesi schrieb:

    naja, ich dachte da an eine zusätzliche Version (so wie eben die Artnet-Erweiterung), nicht dass Du Deine Matrix umbaust... - halt ein weiteres "Plugin" (?) das dann eben mini-DMX ausgibt, das wäre für viele hier von Vorteil...

    ich verstehe das noch nicht ganz, aber die SW, die da am PC läuft, ist doch vom Arduino unabhängig..? - also *da* hast Du doch die Möglichkeit nen Frame mit z.B. 259 Byte rauszuschicken...?

    klar, mit nem Arduino läuft das dann natürlich nicht mehr, aber selbst auf nen Arduino kann man doch eigene SW raufladen, die nicht mit der Arduino-IDE entwickelt wurde, also dann eben z.B. die von mir (könnte ich ja anpassen).


    ahaaa jetzt weiss ich was du meinst, ja genau, das wäre dann ein mini DMX output plugin. das sollte gehen ja. jetzt musst du mir nochmals helfen, deine beschreibung ist ja die folgende:

    Natürlich mit nem "Header" zum synchronisieren dazu, z.B. eben wie bei Mini-DMX... da kommt ja "Startcode" 0x5A, dann ne Zahl je nach Frame-Größe... mein Kumpel und ich haben das inoffiziell für uns erweitert, dass dann 0xA3 bedeutet 768 Byte Nutzdaten (= RGB-Matrix 8x8 ) und 0xA4 3.072 Byte Nutzdaten (= RGB-Matrix 16x16) - mehr ist dann mit nem AVR auf 16 MHz schon nicht mehr drin, bei 0xA4 senden wir auch mit 1 Mbit/s...

    ->
    0x5a (start)
    ne Zahl je nach Frame-Größe ??? das wäre anzahl pixel (immer quader)
    0xA3 - 768b data ODER 0xA5 - 3072b

    das würde dann so aussehen?

    und wie wird mini dmx angesprochen, seriell?

    cheers

    michuNeo schrieb:

    das wäre dann ein mini DMX output plugin. das sollte gehen ja.
    Das wäre natürlich ne super Sache, sehr nett! :thumbsup:

    Ja, einfach die Daten über nen virtuellen Comport seriell rausschicken - gut wäre, wenn es mit 250 oder 500 kBaud ginge, weil man dann am µC keinen Baudratenquarz braucht...

    und eben immer in ner Schleife (oder auch nur, wenn sich was geändert hat):

    5A - B1 - 1.536 Byte Nutzdaten - A5 (es sind doch 32x16 Pixel, also 1.536 Byte, oder...?) - diese Größe ist im Original-mini-DMX nicht vorgesehen, deswegen B1 statt A2 o.ä..

    siehe dazu auch diesen Thread, es wäre schön, wenn man sich auf bestimmte Bytes für bestimmte Framegrößen einigen könnte - Du nimmst halt dann das, das bei Dir passt, bei z.B. 32x16 muss man ja nicht 3.072 Byte raus schicken... ;)

    zu Mini-DMX ist auch noch diese Seite interessant, wo das Protokoll vorgestellt wird.

    das ist eben schon ein bisschen verbreitet, Vorteil an nem mDMX-Plugin für Deine SW wäre eben, dass man also ohne großartige Änderungen an der SW z.B. kleinere Matrixen dann eben mit der selben HW alternativ auch über DMXcontrol oder Freestyler steuern könnte... bzw. andersrum eine schon über mini-DMX gesteuerte Matrix auch über Deine SW - also einfach insgesamt mehr Zeug, das untereinander kompatibel ist...
    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!

    Pesi schrieb:

    Ja, einfach die Daten über nen virtuellen Comport seriell rausschicken - gut wäre, wenn es mit 250 oder 500 kBaud ginge, weil man dann am µC keinen Baudratenquarz braucht...

    und eben immer in ner Schleife (oder auch nur, wenn sich was geändert hat):


    hmm zur seriellen geschwindigkeit, librxtx (die library, welche die low level kommunikation regelt) unterstützt:
    case 9600: return B_9600_BPS;
    case 19200: return B_19200_BPS;
    case 38400: return B_38400_BPS;
    case 57600: return B_57600_BPS;
    case 115200: return B_115200_BPS;
    case 230400: return B_230400_BPS;

    mehr geht da momentan nicht. was meinst du, reichen 230kbps?

    und das vonwegen daten raussenden, in der main applikation wird die framerate geregelt, zb. 20 fps. dann wird der das plugin 20 mal pro sekunde angekickt, in diesem fall das minidmx output plugin. im plugin wird dann geregelt, was und wie die daten rausgehen (sofern überhaupt was rausgehen soll).

    wenn du eine matrix via mini dmx ansprichst, wirst du da immer nur genau eine matrix haben, oder kannst du auch mehrere matricen betreiben?

    wenn das mit der geschwindigkeit passt, werde ich mal eine erste version machen.

    michuNeo schrieb:

    mehr geht da momentan nicht. was meinst du, reichen 230kbps?
    Kommt jetzt auf die Framegröße an - bei 1.536 Byte hast Du halt nur noch 14 fps...

    aber noch mal nachgesehen, bei Dir ist das ja 16x8 - da reicht also auch ein Frame mit 512 Byte, und dann reichen 230 k auch - dann mach' doch einfach 5A A2 als Startcode, mini-DMX mit 512 Kanälen...

    mal ne ganz blöde Frage (kenne mich da ja nicht aus): was passiert nun, wenn Du in diese Lib noch "case 250000: return B_250000_BPS;" rein schreibst...? ;)

    ich habe hier z.B. nen FT232 am USB, VCP-Treiber dazu installiert - im Terminalprogramm (hTerm) kann ich auch nur bestimmte Geschwindigkeiten aus ner Liste aussuchen, aber ich kann z.B. "250000" direkt rein tippen, und dann macht der das auch (bei "500000" noch nicht probiert).

    michuNeo schrieb:

    wenn du eine matrix via mini dmx ansprichst, wirst du da immer nur genau eine matrix haben, oder kannst du auch mehrere matricen betreiben?
    Also ich baue "gerade" :D ne Matrix aus 200 Plastikkugeln, wollte dann auch noch mit diesen Stripes ne "Lattenzaun-Matrix" bauen (der LEDsepp ist nur leider gerade verschollen) - die haben dann z.T. auch versch. Größen, je nachdem wo/wie sie aufgebaut werden...

    aber eben immer über mini-DMX angesteuert - das ist ja nur das Protokoll zum Daten übertragen, die Framegröße muss halt ausreichen, aber ansonsten ist das ja egal, wie groß die Matrix ist, ob nun 16x16 oder 32x8 oder 8x32...

    die SW von meinem Kumpel soll eben im Prinzip so werden wie Deine bzw. Madrix - also bei uns nicht auf ein festes Panel (bzw. mehrere) mit 8x8 festgelegt, sondern so wie bei Madrix, dass man eben die Größe der Matrix in der SW einstellen kann (bzw. sich die SW die Info selbst von der Matrix holt, wenn man die ansteckt...)
    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!
    das mit den unterstützten baudraten, wenn man weitere baudraten will, muss man für jede platform ein binary erstellen. und dann muss das os die baudraten noch unterstützen.

    aber eben immer über mini-DMX angesteuert - das ist ja nur das Protokoll zum Daten übertragen, die Framegröße muss halt ausreichen, aber ansonsten ist das ja egal, wie groß die Matrix ist, ob nun 16x16 oder 32x8 oder 8x32...

    was ich meinte ist, wird die matrix als EINE matrix angesprochen (z.b. 16x8) oder wir diese unterteilt, sozusagen als ZWEI virtuelle matricen (je eine als 8x8) angesprochen?

    meine pixelinvaders panels sind immer 8x8 pixel gross, ich kann jedoch auch mehrere panels als ein grosses panel ansprechen, sprich wenn ich 2 panels verwende, kann ich entweder jedes panel einzeln ansprechen (unabhängig) oder ich kann ein visual auf beiden panels (als ein grosses) ausgeben.

    cheers

    michuNeo schrieb:

    was ich meinte ist, wird die matrix als EINE matrix angesprochen (z.b. 16x8)
    Ja, genau, ist immer eine Matrix, halt mit max. (so wie i.M. vorgesehen) 1.024 Pixel, also z.B. 32x32 oder 64x16... oder eben kleiner, und dann kleinere Framegröße...

    Deine SW würde hier dann also 16x8 ausgeben, einfach als Strom von 384 Bytes (128 x RGB) von links oben nach rechts unten... diese Framegröße ist aber in mini-DMX nicht vorgesehen, also müsstest Du hinten noch Füllbytes anhängen, um auf insg. 512 zu kommen - und dann den Stratcode 0xA2 nehmen...

    ist das zu viel Aufwand, dann schick' halt nur die 384 Byte, und nimm' nen anderen Startcode, wie gesagt (oben verlinkter Thread), man sollte sich halt irgendwie auf einen einigen... ;)
    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!
    so unter github.com/neophob/PixelContro…inidmx/MiniDmxSerial.java habe ich mal eine erste version gemacht. ich denke aber diese erste version wird kaum funktionieren, ohne das ganze zu testen. hast du noch irgendwelche dev boards/ausschuss ware rumliegen?

    was ich weiter noch wissen sollte, kann ich überprüfen, ob am Seriellen Port wirklich ein miniDMX device hängt (so etwas wie ein ping)?

    ich unterstütze momentan folgende payloads:
    private static final byte SEND_96_BYTES = (byte)0xa0;
    private static final byte SEND_256_BYTES = (byte)0xa1;
    private static final byte SEND_512_BYTES = (byte)0xa2;
    private static final byte SEND_768_BYTES = (byte)0xa3;
    private static final byte SEND_3072_BYTES = (byte)0xa4;


    cheers