Beiträge von Seddi

    Nun ja, wär ja nicht wirklich DMX turi, sondern ArtNet. Die ArtnetNodes die er verlinkt hat können jeweils 16 Universen und geben direkt auf die Stripes aus. Insofern schon mal ein recht cooles Interface. Aber wie turi schon gesagt hat, sind das schon ganz schön viele Pixel. bei 60/m wäre das dann eine Auflösung von 300x60 Pixel, das ist schon was. Von den erwähnten Arnet nodes würdest du 7 Stück benötigen. Und vom Strom her ist das auch ne Hausnummer, aber warum nicht :)


    Was Jinx! betrifft ist es im Moment softwaretechnisch auf 128x96 Pixel beschränkt, aber 300x60 sollten schon machbar sein, das bekommen wir schon hin wenn du das wirklich durchziehen willst :)

    MatrixMarc
    Was für eine Software hast du auf dem Uno ? Wie steuerst du die Matrix sonst an ? Das Protokoll hängt ja von der Software im Uno ab, bzw. wird von dieser bestimmt.


    @All
    Ich hänge gerade mal kurz die V0.95a im ersten Thread an, lediglich ein paar kleine fixes:
    -fix typo: chaser->chase, chasers->chases, Artnet->Art-Net, hyperbel->hyperbola
    -kleiner bugfix für gedockte scenen/chase fenster. Nach dem minimieren von Jinx wurden diese nicht immer korrekt positioniert
    -im chase fenster kann nun ein chase auch mit einem rechtsklick direkt editiert werden


    Dazu gibt es eine erste Version des user manuals: http://www.live-leds.de/jinx-usermanual-0.95a.pdf
    Vorwarnung: ist bisher nur runtergeschrieben und noch nicht gegengelesen oder auch nur annähernd korrigiert. Wer gut in Englisch ist darf hier aber gerne behilflich sein und mal durchkorrigieren.


    Und ich hab ein neues richtig geiles Video vom Argentinier:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    So, weiter gehts. Wie schon versprochen mal wieder ein etwas grösseres Update, ich versuch mich trotzdem kurz zu fassen ;)
    Die Version 0.95 (nein ihr habt nichts verpasst 0.93 und 0.94 hab ich gar nicht erst released) häng ich wie immer am ersten Post hier an.


    Bugfixes und Anpassungen:
    -nach dem Beenden des Showmode gab es manchmal Grafikfehler im Szenenfenster
    -für die Position des Szenenfensters werden nun beim Docking die richtigen Werte genommen und alle Windows Styles inkl. Aero berücksichtigt (Rahmenbreite)
    -Kleines Memleak beim Beenden behoben, ein Buffer wurde nicht richtig freigegeben
    -Pixelstep wird bei Dancing Lines und Spotlights (Simple Line) nicht mehr berücksichtigt, diese Effekte werden winkelbasiert berechnet und sind in der Geschwindigkeit nicht pixelbasiert
    -SineWave bei Scrolling Text ignorierte den Pixelstep, somit hatten wir bei Pixelstep=2 eine stehende Welle
    -Autocolor nun auch bei Strobe und Scrolling Text implementiert
    -Dock Menüeinträge (Szenenfenster,...) sind vom Setup ins View Menü umgezogen
    -kleine Fehlerbehebung beim Dateien laden, bessere .jnx Versionkontrolle für neue Dateiversionen
    -Masterstrobe Button muss nun nicht mehr gehalten werden, sondern rastet ein
    -Showmodebuttons sind nun ebenfalls einrastend, somit wird die aktuell gewählte Szene besser erkannt
    -Buttonabstände im Hauptfenster grafisch angepasst
    -komplette Überarbeitung aller Dialoge/Fenster (Matrixsetup, Output, Patch, Remote, Scene, Effectconfig, ...)
    -Artnetpoll für Output Devices implementiert, bei den Output Devices kann nun nach Artnet-Nodes gescannt werden
    -Remote Control config zeigt nun die steuerbaren Funktionen mit Kanälen an
    -Remote Control auf 4 Kanäle erweitert sowie kleine Änderungen bei der Aufteilung: Für Szenen und Chaser (gleich mehr dazu) wird die 0 nun ignoriert (Lichtpulte senden grundsätzlich erst mal eine 0). Sprich bei den Szenen wird nun eine empfangene 1 für die erste Szene genutzt (statt bisher 0), somit sind "nur" noch 255 Szenen anwählbar. Werden die Szenen auf 32 beschränkt, so gilt 1-7 = Szene 1, 8-15 = Szene 2, usw. hier wurde auch lediglich der Wert 0 ausgeklammert, gleiches gilt für Chaser.


    Und nun zu der grösseren Änderung:
    Nachdem ich einen einfachen automatischen Szenenwechsel zu langweilig fand, hab ich Jinx! kurzer Hand eine komplette Chaser-Engine spendiert. :D


    Das bedeutet, ihr könnt so viele Chaser (Programme) anlegen wie ihr wollt und innerhalb diesen so viele Schritte einbauen wir ihr wollt. Als Schritte stehen natürlich Szenen zur Verfügung, sowie die Automation des Masterstrobes und des Master-Crossfader. Jeder Schritt kann mit einer variablen Zeitdauer angegeben werden, bei Szenen wird zusätzlich auch noch für jede Szene das Scenefade eingestellt. Ein Chase kann als loop laufen oder aber als einmaligen Durchlauf und bleibt dann nach dem Ende auf der letzten Szene des Chase stehen.
    Hiermit ergeben sich viele Möglichkeiten und ihr könnt komplette Shows programmieren. Die Chaser werden natürlich mit abgespeichert und können im Chaserfenster verwaltet, gestartet (Doppelklick oder Play Button), gestoppt werden. Im Showmode werden nun zuerst die Chaserbuttons angelegt, anschliessend dann die Szenenbuttons. Ihr könnt also jederzeit einen Chaser oder wie gehabt eine Szene starten, sobald eine Szene gestartet wird, stoppt ein evtl. laufender Chaser automatisch. Wie schon erwähnt lassen sich die Chaser auch via Remote abrufen.
    Das ganze ist natürlich mit vielen Details behaftet, will euch damit aber nicht endlos langweilen ;) Aber ihr glaubt gar nicht wie viele Stunden man in Kleinigkeiten stecken kann: das die einzelnen Fenster bzw. Buttons und Fader sich gegenseitig updaten, beim Chaseredit eine Vorschau für jeden Step da ist auch wenn man wahllos einen Step auswählt (klingt trivial, aber um das aktuelle Bild zu erhalten müssen alle vorherigen Steps durchgegangen werden da sich die Schritte z.T. gegenseitig beeinflussen), das nach dem Beenden eines Chaser die vorherigen Werte (Scenefade, Strobe) wieder hergestellt werden, usw.


    Nun ja, egal ;) Ich hoffe ihr kommt mit dem Chaser nun auch erstmal ohne grosse Anleitung klar, aber ich denke es ist einigermaßen intuitiv geworden. Kurz noch was zu den Zeiten die ihr den einzelnen Schritten gebt. Dies sind die Zeiten wie lange die Szene bzw. der Schritt läuft, oder mit anderen Worten: Die Wartezeit bevor der nächste Schritt ausgeführt wird. Das bedeutet ihr könnt auch mit 0 Werten arbeiten und Szenen beim starten beeinflussen, z.B. ihr nehmt eine Szene und gebt ihr die Dauer 0s als nächsten Schritt legt ihr ein Masterstrobeevent (mit Strobe) an mit 10s, als drittes ein Masterstrobeevent (Strobe aus, sprich regler nach links) mit 0s und anschliessend wieder eine Szene. Dann habt ihr folgendes Bild: Szene einschalten -> 0 -> sofort Strobe einschalten -> 10s warten -> Strobe ausschalten -> 0 sofort nächste Szene anzeigen
    Ach ja, wenn Szenen einem Chaser zugeordnet sind lassen diese sich nicht mehr löschen, diese müssen erst aus dem Chaser entfernt werden oder eben der ganze Chaser gelöscht werden. Werden Szenen umsortiert, so wird dies in den entsprechenden Chasern automatisch angepasst, sprich er findet seine Szene egal wie gut ihr sie auch versteckt :P


    Ich habe die Chaserengine nun die leztzten 2 Tage intensiv überarbeitet und debugged, ich hoffe es sind keine grossen Bugs mehr drin. Ich hab im Demofile mal einen kleinen Chaser angehängt, probiert es einfach aus.


    Viel Spaß damit und Grüße
    Seddi


    //EDIT
    Da fällt mir ein, muss das eigentlich nicht chase heissen und in der Mehrzahl dann chases ? Lauflicht -> light chase -> Licht jagd, nicht Licht Jäger (light chaser)... somit dann also auch scene chase und scene chases ... bei uns in der schäbisch-deutsch-englischen Veranstaltungstechnik heisst das immer banal Chaser ... da soll man mal nicht durcheinanderkommen :) Ich glaub ich mach da mal ein Typo Update im Programm ...

    Coole Videos :) Thx


    Genau so hab ich mir das vorgestellt mit der DMX Steuerung. Ich bin auch gern am basteln und hab viel um mich rum, aber wenn ich nen Job mache, dann will ich alles zentral steuern können und da ich das Lichtpult eh brauche soll das auch die Matrix mitsteuern. Und so nebenbei, es schmeichelt das Ego wenn die Software produktiv eingesetzt wird :D In diesem Sinne auch mal Danke für die Unterstützung.


    Ich hab dafür die Tage fleissig weiter programmiert, wir nähern uns der Version 1.0 ... in den nächsten Tagen gibts ein etwas grösseres Update, ich denke da wird das ein oder andere brauchbare auch für dich dabei sein ;)

    Ich habe bei Reichelt gerade einen USB - SPI Chip für 70 Cent entdeckt:: MCP2210


    Mit diesen arbeitet ja der Argentinier: http://www.pantallafacil.com.ar/Interfaz%20USB%20UART.html, nur die SPI-Seite muss die Speed halt auch noch abkönnen. Man sollte m.E. einfach die Matrix in Panels aufteilen und kleinere Segmente pro Port antsteuern anstatt alles über einen Port, bei Jinx! kann ja auf mehrere Ports gepatcht werden. Zu schnelle Baudraten auf SPI Seite macht halt auch die Signalführung aufwändiger, sonst ist das Signal kaputt bis es beim ersten Pixel ankommt.

    Laut dem was er mir noch geschickt hat inzwischen hatte er wohl das dran:
    http://www.pantallafacil.com.ar/Interfaz%20USB%20UART.html


    Zitat


    Use a USB SERIES Microchip MCP2200 1Mbps to send data to my LED matrix.
    Each panel has 100 pixels (LP6803) and receiver UART-SPI number to assign to each panel and LED matrix construct differently 4:3 or 16:9.


    Hatte das hier mit einer seriellen Loop in der Simulation mal nachgestellt, wurde dann bei 1MBit auf 12,5 fps runtergedrosselt. Er will das die Tage mal mit mehreren Ports betreiben, hat wohl mehrere Matrizen und Steuerungen im Selbstbau und nutzt das glediator protokoll.
    Das ist übrigens seine Homepage: http://www.pantallafacil.com.ar


    Hat da auch ein paar nette Spielereien :)

    Mich hat heute ein Video aus Argentinien erreicht:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.


    http://www.pantallafacil.com.ar




    Er meinte noch er hat mit der 0.92a Probleme mit dem glediator Protokoll bei seiner 50x40 Matrix, bei der 0.92 würde es gehen. Ich hab das Glediator Protokoll selbst getestet mit der 0.92a (bei 32x16) und habe keine Probleme, auch nicht in der Simulation mit mehr Pixeln. Hat von euch mal jemand die serielle Ausgabe mit der 0.92a getestet ?
    Ich muss da aber nochmal nachfragen, bei 50x40 Pixel wären das rund 1.3MBit/s auf der seriellen wenn er nur einen Port hat, das sollte dann eigentlich auch mit der 0.92 nicht klappen. Da ich ja die Framerate nicht drossel sollte alls bis zur 0.92 da früher oder später einfrieren und die 0.92a sollte eigentlich mit frameskips weiterlaufen ...

    Da steht zumindest im Titel, dass zusätzlich DMX ausgegeben wird. Pesi wird das schon wissen...


    Ah jetzt blick ichs. Ich hab immer den Post darüber angesehen und die Soft war für WS2801, die Dimmersoft hatte gar nicht gesehen. Wer lesen kann ist klar im Vorteil :D


    @All
    Die serielle Ausgabe ist inzwischen erfolgreich getestet bei der 0.92a (siehe 4 Posts drüber), ich häng sie also mal zusätzlich im ersten Post mit an.

    So, nochmal eine neue Version (0.92a), ich häng sie (vorerst) ausnahmsweise mal hier mitten im Thread an, da ich sehr viel an der seriellen Ausgabe gearbeitet habe und hier nicht alles selber testen kann. In der Simulation über eine virtuelle Com-loop funktioniet es zwar sauber, aber trotzdem hätte ich da gerne eine Bestätigung mit echter Hardware ;)


    Wenn also jemand Zeit, Lust und die Möglichkeiten dazu hat wäre es super wenn ihr die seriellen Ausgaben (Glediator, tpm2 und MiniDMX) testen könntet. Glediator Protokoll kann ich morgen auch selbst kurz testen, hab nur die Matrix im Büro und nicht hier zu Hause.


    Folgendes hat sich geändert:
    -kleiner Bugfix beim Screencapturing, hier gab es einen Stride-Fehler, sprich verzerrte Bilder bei Matrixauflösungen die nicht ein vielfaches von 4 waren
    -kleiner Fix beim tpm2 Eingang (Remote), hier konnten (wenn auch sehr selten) Frames verschluckt werden
    -Fix für generelle Ausgabe/Patch, wurden gleichzeitig verschiedene Interface-Arten angelegt (kommt in der Praxis wohl selten bis gar nicht vor, daher ist das auch noch nie aufgefallen), wurden ab dem zweiten Interface die gepatchten Pixel verschoben
    -Umbau der seriellen Ausgabe (tpm2, Glediator, MiniDMX) auf OVERLAPPED mode, dadurch kann ich die Out-Queue von Windows abfragen und kontrollieren
    -Automatischer Frameskip bei der seriellen Ausgabe wenn nötig


    Dies bedeutet nun im Klartext: Wenn man ausversehen zu viel Kanäle auf eine zu kleine Baudrate einstellt (also mehr senden will als die Baudrate bei 25fps hergibt), friert das Programm nun nicht mehr aufgrund des Staus an der seriellen Schnittstelle ein sondern lässt solange Frames bei der Ausgabe aus bis die serielle wieder frei ist und die alten Daten vom Empfänger abgearbeitet wurden (die Software selbst läuft mit vollen 25fps weiter). Sollte aus irgendeinem Grund der Empfänger gar keine Daten mehr annehmen (z.B. Kabel ausgesteckt), werden auch keine Daten mehr gesendet, so dass auch hier die Software nicht mehr einfrieren kann.


    Ach ja, und damit ein Update auch Spass macht:
    -Neuer Effekt für "Simple Lines": Dancing Snakes (siehe angehängte Szenen im Demofile)


    anderes Thema ... Pesi und turi
    Fast ein bisschen Offtopic, aber ich wollte keinen neuen Thread aufmachen. Mir ging gerade so der SEDU durch den Kopf, es wird ja immer wieder danach gefragt wie es mit der Ausgabe von DMX aussieht, da wohl viele ihre RGB Tubes als Matrix steuern möchten (auch bei Glediator wird da immer mal wieder rumgebohrt). Bevor ich jetzt anfange die ganzen unzähligen USB2DMX Dinger zu programmieren, die z.T. wirklich fürchterliche Treiber und APIs haben (vor allem die günstigen ebay Dinger die meist auf dem Elektor Bausatz basieren und man Windows in den Testmodus schalten muss das man den Treiber ans laufen bekommt), hab ich gedacht können wir da nicht ein tpm2->DMX mit einem SEDU machen ?
    Die ersten brauchbaren USB2DMX (Enttec Open, Digital Enlightment) fangen so bei 100,- EUR an, da wär ein SEDU deutlich günstiger und tpm2 kann schon jede hier vertretene Matrix-Soft (Pixelcontroller, Glediator, Jinx), das Teil ist also somit sofort einsetzbar. Wenn dann wieder die Frage kommt kann man den User sagen, OK, kauf dir für knapp 200,- EUR das billigste Artnet/DMX Node von Botex, bastel was selber oder nimmer hier den SEDU mit tpm2->DMX z.B. fertig bei Turi für 39,- EUR (oder was auch immer die SEDUs gerade kosten, ich hab nicht nachgeschaut). Da hat dann vielleicht auch Turi was davon ;) Ich könnte dann noch eine kleine handliche Artnet->tpm2 Node Software (als Open Source) mit in die Runde schmeissen und somit wäre das Ding als richtiges DMX Interface für DMXControl, Freestyler und Konsorten auch noch nutzbar. Und dazu noch deutlich günstiger und stabiler/zuverlässiger als die billigsten USB2DMX Interfaces die man einmal in der Stunde vom USB abziehen und neu anstecken muss damit sie weiterlaufen. Was meinst ihr dazu ?

    Glediator hat hier den Vorteil das es nur mit einem Timer arbeitet, wenn dieser ausgebremst wird (weil keine Daten ander seriellen abgenommen werden), dann wird einfach die Framerate langsamer aber das Programm bleibt bedienbar. Bei Jinx arbeite ich mit mehreren Timern, das hat viele Vorteile aber auch den Nachteil das bei einem blockierenden Ausgang die Timer sich überlagern und somit Gegenseitig ins Nirvana schiessen, sprich die einzelnen Generatoren wollen weiterarbeiten aber der Ausgang blockt, somit gibts dann nen ganz bösen Stau im Programm. Wenn du den Ausgang in so einem Fall wieder anklemmst und ein weilchen wartest bist der Stau aufgelöst ist, lässt sich Jinx auch wieder bedienen. Es stürzt also nicht wirklich ab, ist aber so etwas unpraktisch geb ich zu :D
    Deshalb muss ich diesen "Fehlerfall" noch abfangen, steht auch schon seit Ewigkeiten auf meiner ToDo Liste, mach ich die Tage versprochen. Ging mir diese Woche schon selbst auf die Nerven als ich beim testen öfters umgesteckt habe. Wenn man im laufenden Betrieb die Matrix absteckt (bei serieller Übertragung), hat man ja den gleichen Fall.

    wo stellst Du denn die Latency auf 1 ms runter, mit diesem FTDI-Config-Tool...?


    Ganz einfach Gerätemanager, Doppelklick auf den Com-Port und dann unter Port Settings -> Erweitert. Insofern halte ich es für praktikabel das einfach runterzustellen und die 512er Version läuft ohne Probs.


    oben rechts ist doch so ein Auswahlfeld mit Baudraten...?


    Ooops .. hab gar nicht gesehen das ich hier die anderen Baudraten (250k und 500k) einblenden kann, hab nur immer die 115200 gesehen und kleiner.


    Da hast Du natürlich recht! - da müsste ich dann in den empfangenen Daten gucken, da sind dann die Stufen bestimmt auch drin.


    Die Stufen sind ja nur zeitlich, alle Werte kommen ja an, nur blockweise, also müsste man trotzdem ne schöne Reihe 1-> 255 sehen im Terminal, die Daten gehen ja nicht verloren.

    NoNameStriker
    Hauptsache es funktioniert, hab mir schon den ganzen Tag den Kopf zerbrochen wo das am Ausgang noch stocken könnte. Ich bau die Tage erstmal ne Sicherheitsroutine ein, dass das Programm nicht hängen bleibt wenn der Abfluss verstopft ist oder jemand die serielle Verbindung trennt während die Ausgabe läuft.


    Und Danke für die Blumen, wobei ich das Lob ja weitergeben muss. Was die übersichtliche Oberfläche angeht hab ich mir ja auch einige Ideen bei Glediator ausgeborgt ;)

    Mit Glediator kann ich gar nicht erst den COM-Port anwählen, da keiner zum Auswählen erscheint.


    rx/tx lib ? Die bekommst du z.B. hier: http://mfizz.com/oss/rxtx-for-java Musst halt die richtige auswählen 32 oder 64 Bit, wobei das nichts mit deinem Betriebssystem zu tun hat sondern mit deiner Java Runtime. Auch wenn du ein 64 Bit Windows hast, hast du im Regelfall ein 32Bit Java, somit brauchst du auch die 32Bit lib, diese einfach in das Glediator Verzeichnis werfen. Hatte ich schon mal verlinkt: Glediator - Freeware LED Matrix Steuerung - Software


    Hmm irgendwas läuft da mit der seriellen noch schief, im Gerätemanager ist sie sauber drin ? Der Arduino Uno läuft ja auf gleiche weise wie der USb2serial Light mit nem Atmega. Den nutze ich um meine Solderlab Boards anzusteuern, insofern seh ich hier nichts ungewöhnliches. Evtl. läuft auch die Firmware auf dem Arduino nicht rund, vielleicht hab ich auch noch einen Bug. Insofern wäre es interessant das du noch mal versuchst Glediator ans laufen zu bekommen, wenn es da geht muss es auch mit Jinx gehen (oder ich hab nen Bug :D ). Ich hab keinen Arduino zum testen hier und hab mir auch die Firmware noch nie angeschaut, daher tue ich mich gerade ein bisschen schwer mit Fehler suchen, aber wie schon erwähnt wenn Jinx einfriert kann es nur an der seriellen Kommunikation liegen und das hier die Daten sich stauen (warum auch immer).

    dort x=16 statt x=8 steht


    Ja gut das ja nur ist die Vorbelegung für den Fastpatch. Der Patch spielt hierbei auch erstmal keine Rolle, wenn der Patch falsch ist bleibt die Software nicht stehen. Was bedeutet schmiert ab, laufen die Effekte noch auf dem Bildschirm oder friert dort die Anwednung ein ?
    Wie gesagt einfrieren kann das eigentlich zu dem Zeitpunkt nur, wenn die Daten an der seriellen nicht abgenommen werden und ein Stau entsteht (da muss ich endlich mal eine Sicherheitssperre einbauen). Wenn also die Kanalzahl stimmt (du hast auch nur dieses einen Outputdevice angelegt ?) und die Baudrate dann darf da eigentlich nix schief gehen. Wenn du ein Bild bekommst auf der Matrix müsste ja auch die Schnittstelle mal grundsätzlich stimmen, oder kommt überhaupt was auf der Matrix an ?
    Hattest du mal mit Glediator getestet ? Hat es da ohne Probleme funktioniert ?

    Als erstes die Matrixsize setzen , dann den Ausgang anlegen ( schau da, das die Kanalzahl stimmt), dann patchen. Wenn du den Ausgang anlegst bevor du die Matrixsize anpasst, dann hast du ( falls nicht manuell korrigiert) die alte Matrixsize als Kanalzahl. Wenn du zu viele Kanäle rausschickst hast du genau das beschriebene Problem. Bei 8x8 sind es 64 Pixel, bei 3 Farben dann 192 Kanäle. Das sollte auch beim Ausgang als Channel eingestellt sein.

    NoNameStriker
    Ein paar Infos mehr wären schon ganz gut. Also Gled. Protokoll nutz ich hier selbst, da gibts keine Probleme über Stunden hinweg. Welche Schnittstelle (Arduino Serial2USB light?) Welche Baudrate ?
    Wieviel Solderlab Boards/Pixel ? Wie verkabelt ? Wie ist das Output-Device in Jinx konfiguriert ? Einfach mal alles an Infos was du hast, dann ists einfacher den Fehler zu finden :)


    Ich vermute mal dein Ausgangsdevice hat eine viel zu hohe Kanalanzahl, mehr als die Baudrate kann. Jinx gibt so viel Kanäle aus wieviel angegeben sind egal ob gepatcht oder nicht und wenn dann der serielle überlauft bleibts stehen und knallt. Da hab ich noch keine Auffangroutine drin, falls da Werte eingestellt sind die nicht zusammenpassen.