Jinx! - LED Matrix Control ... und die nächste Matrix Software ...

    11MBit should be fast enough, how good is the signal ? I never used this arduino based node, can you try if it works via cable, so that we definitly know if there is something wrong with the wlan or if we have a problem between jinx and this node. Stucking pixels sounds a bit like the node isnt able to process the incoming frames fast enough, but it can also stuck within the wireless connection.

    //EDIT
    Looked inside the source code of the artnet node, do you send 312 channels or complete 512 channels ? Looks like the node doesnt handle frames < 512 channels, so if not yet done, try to set the channel count in the device config in Jinx to 512.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Seddi“ ()

    So, mal wieder ne neue Version im ersten Post (0.92).

    -kleiner Bugfix für Starfield, unter bestimmten Umständen konnte es zum AppCrash kommen
    -bei Artnet Output ist nun auch Broadcasting möglich (IP 255.255.255.255)
    -kompletter Rewrite der logarithmischen Skalen/Bänderberechnung im Spektrum Analyzer
    -Spectrum Analyzer lässt nun eine frei wählbare Zahl an Bänder zu, somit kann man auch bei krummen Matrixdimensionen ein vollflächiges Bild erreichen. Kleinste Bandanzahl ist 4, die grösste entweder die Matrixbreite bzw. max. 64 falls die Matrix breiter ist als 64 Pixel
    -Linienmodus für Spectrum Analyzer, es lässt sich nun das Spectrum auch als einzelne Linie (oder Fläche) anzeigen, auch eine zweite Linie als Peak Hold ist möglich

    Vor allem im Linienmodus sollte erwähnt sein das es ein besseres Bild gibt wenn man es mit den Bändern nicht übertreibt, wählt man hier Bandanzahl=Matrixbreite gibt es keine schöne Linie (wie auch ist ja kein Platz zum interpolieren), hier bietet sich die halbe Pixelzahl als gutes Bild an (Matrix 32 Pixel breit -> 16 Bänder). Balkenabstand, Peakhold ist alles wie gehabt, probierts einfach mal aus.

    Hier noch ein Screenshot mit 42 Bänder auf einer 128x64 Matrix:

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Seddi“ ()

    Vielen Dank für die Änderungen! :thumbsup:

    tpm2-remote funktioniert jetzt auch mit 512 Kanälen - allerdings geht es ein bisschen "ruckelig" - also wenn man z.B. den Fader für Master hochzieht, geht der im Programm nicht gleichmäßig mit, sondern springt in Stufen nach oben - bei nur 3 gesendeten Bytes geht er super-geschmeidig mit...

    für mich jetzt nicht so schlimm, ich stell' mein Interface halt auf Adresse 250 (benutze meist den E:Cue Nano, der nur 256 Kanäle hat) und 3 Kanäle, dann funzt das super.

    Dir schicke ich die Version mit 512 Kanälen zum rumprobieren, da ist dann auch ein Bootloader drauf, kannst Du also auch jederzeit andere SW drauf machen... ;)
    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:

    tpm2-remote funktioniert jetzt auch mit 512 Kanälen - allerdings geht es ein bisschen "ruckelig" - also wenn man z.B. den Fader für Master hochzieht, geht der im Programm nicht gleichmäßig mit, sondern springt in Stufen nach oben - bei nur 3 gesendeten Bytes geht er super-geschmeidig mit...


    So nun selber mal nachgetestet, da kann ich gar nicht viel daran machen. So wie es aussieht hakt es da am FTDI Treiber. Bei einem 512er Frame kommen ja quasi kontinuierlich Daten, in Realtime abgreifen geht ja nicht (USB Frames, etc). Ausserdem bin ich ja selbst auch getaktet und Frage den virtuellen Com alle 40ms ab und hol mir dann alles was im Buffer ist. Da spielt nun aber nicht nur der Windows Buffer eine Rolle sondern auch derm vom FTDI und da kommt dann folgendes vom FTDI ins Spiel:


    6.3 Setting a Custom Default Latency Timer Value
    The latency timer is a form of time-out mechanism for the read buffer of FTDI devices. When a FT_Read instruction is sent to the device, data will not be sent back to the host PC until the requested number of bytes has been read. If the requested number of bytes never comes, the device would not send data back.
    The latency timer counts from the last time data was sent back to the PC. If the latency timer expires, the device will send what data it has available to the PC regardless of how many bytes it is waiting on. The latency timer will then reset and begin counting again.
    The default value for the latency timer is 16ms.


    Diese 16ms sind quasi deine Sprünge bei einem 512er Frame. Wenn ich nun die Anschlusseinstellungen bearbeite und dieses Timeout auf das Minimum stelle (1ms), dann läufts auch bei 512er Frames Smooth, allerdings mit einer kleinen Verzögerung. Bei 3er Frames spielt das keine Rolle da deutlich weniger Daten kommen.

    Ich hab jetzt die DMX Spec nicht vor mir (von wegen Break und so), aber wenn du 512 Kanäle + Startbyte bekommst via DMX macht 513 Bytes (wie lange ist der Break davor nochmal, 2 oder 3 Bytes ?) Bei 3Bytes wären es dann 516 Bytes emfpangen, ausgegeben werden aber 517 Bytes bei tpm2 (4 Headerbytes + 512 Daten + Stoppbyte). Bekommen wir nicht hier schon probleme wenn die 250k Baudrate bei DMX voll ausgenutzt wird, der SEDU schickt ja auch mit 250k Baud weiter. Kann es sein das es hier schon Probleme gibt ? Bei kleineren Frames würde das ja auch keine Rolle spielen. Oder habe ich mich da jetzt komplett verrechnet ?

    *grübel*
    Könnte man den SEDU FTDI mässig nicht einfach auf 500kBaud setzen ? Dann haben wir in diese Richtungen eigentlich gar kein Problem mehr ?

    //EDIT
    Hab gerade die 3 Kanal Variante ausprobiert, hier läuft es mit den 16ms Latency Timeout smooth aber auch mit leichter Verzögerung, geh ich auf 1ms runter ist die Verzögerung kleiner aber immer noch sicht-/spürbar.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Seddi“ ()

    Seddi schrieb:

    Ausserdem bin ich ja selbst auch getaktet und Frage den virtuellen Com alle 40ms ab und hol mir dann alles was im Buffer ist.


    Hier würde ich eher das Problem sehen... man sollte ja immer mit min. der doppelten Rate abtasten...
    wenn das SEDU auch aller ca. 40 ms einen kompletten Frame schickt, dann hinkst du immer 80 ms hinterher... und das sollte schon deutlich sichtbar sein...

    Ist doch in Windows ganz einfach ne Callback-Funktion mit Bytes in threshold < 2 auf den seriellen Eingang zu legen...

    Grüße

    basti

    Counterfeiter schrieb:

    Hier würde ich eher das Problem sehen... man sollte ja immer mit min. der doppelten Rate abtasten...


    Nun ja nicht ganz, hab ja ne grossen Buffer im Windows und arbeite dann alle 40ms auch alles ab was im Buffer ist und bin somit sofort wieder auf dem laufenden, ich arbeite ja nicht nur ein Frame dann ab, sondern alle. Mach ich mit den eingehenden Netzwerkdaten ja nicht anders und bekomme keine Verzögerungen. Da ich ja eh ne Masterframerate von 25 fps habe, passiert eh nur alle 40ms Sekunden was, daher ist es auch unnötig zwischendrin Daten auszuwerten. Ich nehm da lieber den Mastertimer und arbeite die gesammelten Daten dann in einem Rutsch ab.


    //EDIT
    Hab jetzt mal für den Sedu neu assembliert und auf 500kBaud umgestellt, nun läufts auch mit den 16ms TimeOut im Treiber geschmeidig, also gleich wie bei der 3 Kanal Variante, nur eben die leichte Verzögerung.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Seddi“ ()

    Achso, na dann hat nicht viel Sinn schneller abzutasten ;)

    ich könnte mir vorstellen, dass die 1 zu 1 Geschwindigkeit durch leichte Differenzen im Takt, bei langen Frames, dazu geführt hat, dass der UART Sendebuffer beim SEDU übergelaufen ist... bei 512 Byte Senden braucht ja der Takt zum FTDI nur 0,4% langsamer sein, als der eingehende von DMX und dann ist nen Zeichen "lost" ... wenn ich mich jetzt nicht verrechnet habe...
    Im SEDU (also zumindest bei meiner SW) gibt es keinen Sendebuffer, da kann also auch nix überlaufen.... ;)

    das ist halt immer so ne Timing-Sache: wie gesagt, schicke ich die Bytes dicht an dicht raus - das ist Q&D, immer Flag abfragen, ob der USART das Byte verschickt hat, wenn ja, kommt das nächste - da sind nur ein paar Takte dazwischen...

    die meisten DMX-Pulte und -Interfaces schicken aber langsamer, mein Billig-Pult habe ich mal an's Oszi gehängt, da ist zwischen zwei Bytes ne Pause von fast einer Bytelänge... auch der E:Cue nano schickt nur mit ca. 31 fps, obwohl er theoretisch (hat nur 256 Kanäle) max. 88 fps könnte (bei Bytes dicht an dicht raus)

    i.a. sind die Daten also deutlich schneller versendet als empfangen, es macht also nix, dass es (bedingt durch den Protokoll-Overhead von tpm2) ein paar Bytes mehr zu verschicken sind...

    übrigens, das erhöhen auf 500 Baud und das verkleinern der Framegröße läuft bei meiner Firmware letztlich auf das selbe raus: es kommen mehr fps in den Rechner rein... ;)

    das (Edit: 500k benutzen) wollte ich halt nicht machen, weil dann der Bootloader-Aufruf per String nicht mehr funktioniert - warum auch immer... und ich will das Teil ja im Gehäuse haben, kann also nicht den Reset-Knopf drücken zum flashen.

    dieses FTDI-Buffer-Problem hatte ich andersrum verstanden, also dass das eher zu Verzögerungen führt, wenn man kleinere Frames schickt - da hatte der Pepe mich schon mal bei der Entwicklung des tpm2-Protokolls drauf hin gewiesen, als es um die Länge der Rückmeldung/Ack ging...

    also so: die Pause macht der FTDI dann, wenn der Buffer nicht ganz gefüllt wird, also Beispiel, ich schicke 5 Bytes, dann ist der Buffer nicht voll, dann wartet er und schickt erst nach 16 ms die Daten über USB raus - schicke ich mehr Daten, gehen sie immer sofort raus, wenn der Buffer gefüllt ist (was in deutlich kürzerer Zeit der Fall ist)...

    ich muss das Ganze mal mit nem Interface testen, i.M. habe ich folgenden unsicheren Punkt: das kleine Billig-Pult sendet nur 8 Kanäle und macht dann ne kurze Pause - das kann gut sein, dass das noch deutlich schneller sendet als die bei 512 Kanälen maximal möglichen ca. 44 Hz - und also bei 44 Hz senden vom SEDU zum PC also nicht alle Werte weiter gegeben werden...

    was aber wurscht sein sollte, es wird ja trotzdem 44x pro Sekunde gesampelt und ausgegeben, da sollte man kein Ruckeln sehen - das sieht halt ungefähr so aus, ich schiebe den Fader am Pult in 1 Sekunde von unten nach oben, der Fader (und die Helligkeit) in Jinx springt dabei in ca. 6 Stufen nach oben - also ca. nur alle 166 ms ein neuer Wert erkannt.
    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!
    Ist wie gesagt ganz schön komisch, beim abfragen bekomm ich halt nur ruckweise Daten vom FTDI, wenn ich die 16 ms auf 1ms schiebe bekomm ich sie direkt. Hab das in alle Richtungen in der Software debugged, aber ich kann halt nur Daten verarbeiten, die ich auch über die Schnittstelle bekomme. Und bei 512er Frames und den 16 ms timeout bekomm ich sie nur ruckartig, da kann ich in der Software nichts beeinflussen. Steig da selber noch nicht wirklich durch wo es da klemmt, aber ich vermute fast Treiber/USB Frames und vielleicht auch noch Windows selbst das auch puffert, da kann dann weder ich in der Soft noch du was im Sedu dran ändern. Wie gesagt bei 500kbaud läufts oder auch bei 250k wenn ich das timeout im Treiber runterstelle.
    Die Verzögerung die ich noch hatte liegt vermutlich am Pult. Mir ist vorhin noch eingefallen, dass am kleinen Scannerpult (SGM Pilot 2000) das ich zum testen nutze die Kanäle vermutlich auf Soft eingestellt sind, sprich das Pult fadet auf den neuen Wert. Dadurch eine sichtbare Verzögerung bis zum Zielwert.


    Pesi schrieb:

    ich schiebe den Fader am Pult in 1 Sekunde von unten nach oben, der Fader (und die Helligkeit) in Jinx springt dabei in ca. 6 Stufen nach oben - also ca. nur alle 166 ms ein neuer Wert erkannt.

    Die 160 ms beim ruckeln, kann ich nachvollziehen. In der Software bekomm ich da beim abfragen 3 mal hintereinander keine Daten von der Schnittstelle ( meldet einfach 0 Bytes in der Queue) , bei der 4. abfrage bekomm ich dann die ganzen Frames auf einen Schlag. Da ich alle 40 ms abfrage entsprechen die 3 Nullrunden ca 160 ms. Da gibt mir der Treiber einfach keine Daten, wenn ich den Timer verkürze und öfters abfrage bekomm ich entsprechend mehr Nullrunden. Ich hole prinzipiell alles aus der Queue was da ist, also lass mir vom Treiber auch nur 1Byte geben wenn er nicht mehr hat und bin Nonblocking. Also kann ich einen Fehler beim auswerten der Daten oder einem Bufferüberlauf in Jinx eigentlich ausschliessen. Vor allem da ich bei jeder Abfrage Daten bekomme, wenn ich im Treiber die 16ms auf 1 oder 2 runterstelle.

    Pesi schrieb:

    dieses FTDI-Buffer-Problem hatte ich andersrum verstanden, also dass das eher zu Verzögerungen führt, wenn man kleinere Frames schickt

    Der FTDI Buffer spielt ja, nach meinem Verständnis, nicht nur bei kleinen Frames eine Rolle sondern auch wenn der Frame nicht durch die Buffergrösse teilbar ist. Ist der Buffer mal angenommen 64 Bytes gross, hast du das Problem bei einem Frame kleiner 64 Bytes. Aber eben auch bei einem grossen Frame mit sagen wir 288 Bytes. Da bekomm ich dann direkt 256 Bytes (4x Buffer) und die restlichen 32 lassen auf sich warten weil der Buffer nicht voll ist. Da tpm2 aber ein Endbyte hat, werte ich den Frame erst aus wenn ich das Endbyte habe, also verzögert sich das Ganze auch bei grösseren Frames.
    So les ich das auch hier heraus: ftdichip.com/Support/Documents…2B-04_DataLatencyFlow.pdf

    Weiterhin müsste auch noch die Blocksize im FTDI eine Rolle spielen. Standardmässig sind das 4k, sprich der USB wartet auf 4096 Bytes bevor er was weitergibt, auch das trägt dann auch zum Delay bzw. dem ruckeln bei. Das Ganze dann auch in Abhängigkeit mit dem latency timer. Nach allem was ich in den letzten Stunden zu dem Thema an Infos aufgetrieben habe, auch von anderen Projekten, ist wohl das Problem die standardmässige Blocksize und der Latency Timer und die saubere und vermutlich einzige Lösung ist das verkleinern des Latency Timeout im Treiber oder das erhöhen der Baudrate, wodurch das Problem aufgrund einer höheren fps Rate umgangen wird.

    Pesi schrieb:

    das (Edit: 500k benutzen) wollte ich halt nicht machen, weil dann der Bootloader-Aufruf per String nicht mehr funktioniert - warum auch immer...

    Da hast du dir die Antwort doch schonmal selbst gegeben im SEDU Board Software Thread ;) ... "2. der Treiber wurde so modifizeirt, dass der FT232 mit 250 kBaud sendet/empfängt, wenn man am PC 115,2 k einstellt" ... Die Gui des Bootloaders öffnet die Schnittstelle mit 115,2k und somit mit 250k, deshalb funktioniert das mit dem String bei 250k Baud. Ist das SEDU Board auf 500k kann es mit den 250k nix anfangen, da müsste dann das Baud-Aliasing im Treiber so eingestellt sein, das beim öffnen der Schnittstelle 500k gefahren wird.

    Pesi schrieb:

    und ich will das Teil ja im Gehäuse haben, kann also nicht den Reset-Knopf drücken zum flashen

    2mm Loch an der richtigen Stelle im Gehäuse und du hast nen klassischen Reset Knopf den man mit der Büroklammer drücken kann, hat heutzutage jeder Router :P

    Dieser Beitrag wurde bereits 16 mal editiert, zuletzt von „Seddi“ ()

    Pesi schrieb:

    Im SEDU (also zumindest bei meiner SW) gibt es keinen Sendebuffer, da kann also auch nix überlaufen.... ;)


    Wenn du nicht gerade Software UART machst, dann hast du 1 Byte "transmit buffer" und 1 Byte "shift buffer" und das meine ich ;)

    @Seddi ich hab das so mitbekommen, dass der Pesi gute Ergebnisse mit einem Terminal Programm gemacht hat... also kanns ja nicht am FTDI Treiber oder Windows liegen?!

    Wie fragst du ab, ob Bytes im Buffer liegen? Mit dieser Structur -> msdn.microsoft.com/en-us/library/aa363200(v=vs.85).aspx ?

    Grüße

    Basti

    Counterfeiter schrieb:

    @Seddi ich hab das so mitbekommen, dass der Pesi gute Ergebnisse mit einem Terminal Programm gemacht hat... also kanns ja nicht am FTDI Treiber oder Windows liegen?!

    Ich denke mit einem Terminalprogramm kann man das nicht wirklich verfolgen, da allein die Textausgabe auf dem Schirm schon der Datengeschwindigkeit hinterher hinkt. Da ja alle Werte kommen und nichts verschluckt wird sieht das auf dem Bildschirm dann schon sauber aus, lässt sich aber zeitlich m.E. nicht wirklich bewerten. Das es nicht am FTDI Treiber liegen kann wiederleg ich indem ich im Treiber den besagten Timeout auf 1 stelle und ich plötzlich kontinuierlich sauber die Daten bekomme ohne Auszeiten dazwischen.
    Wie gesagt, ich hab das schon in alle Richtungen debugged, ich bekomm da einfach keine Daten.

    Counterfeiter schrieb:

    Wie fragst du ab, ob Bytes im Buffer liegen?

    Ich mach nen read auf den seriellen und da ich Nonblocking bin, gibt er mir was er hat und wenn er nix hat gibt er mir sofort eine Null zurück.
    msdn.microsoft.com/en-us/library/windows/desktop/aa363190(v=vs.85).aspx

    A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received.

    Damit kann ich ganz normal ReadFile auf den Port machen ohne das er blockt und erspar mir die vorherige Abfrage via COMSTAT.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Seddi“ ()

    hm, komisch... hatte mal nen Messsystem gebastelt, dass die Daten recht schnell ausgeben sollte... das ging mit dem FTDI alles ohne Probleme.. verwendet hatte ich allerdings das C# Comport Device... ist aber sicher auch nur eine Abstraktion der WinAPI Funktion und eine definierte Callback... Hatte mit unterschiedlichen Aktualiserungszeiten gespielt... war eigentlich nie ein Problem... hab letztendlich nur den Anzeigeintervall reduzieren müssen, wegen zu hoher CPU Last... das Empfangen der Daten (im Protokoll) hat aber wunderbar und ohne sichtbare Unterbrechungen funktioniert. Die Datenmengen sind aber um einiges größer gewesen... Hier mal das Beispielvideo in dem die Aktualisierungszeit schon reduziert war (100ms)...

    Daher interessiert mich auch das Problem so... Wäre ja interessant zu wissen, ob da was beim FTDI unter Umständen zu Problemen führen kann... mit Bulk Transfer wie es der FTDI macht, arbeite ich auch mit dem XMega und nativem USB, hatte da auch noch keine größeren Probleme... hmmm

    Counterfeiter schrieb:

    Daher interessiert mich auch das Problem so...


    Ist ja gut so, je mehr mitdenken desto eher kommen wir vielleicht auf den Punkt was da genau passiert. Mir persönlich ist es wurscht ob ich Mist programmiert habe, ob im Sedu was nicht stimmt (hab mir den Source von Pesi angeschaut, ich schliess den Sedu mal aus da sieht alles gut aus und lässt sich sowas auch nicht weiter beeinflussen) oder ob es da Treiberinterferenzen gibt. ich wills nur gern verstehen :)

    Der Punkt der mir zu denken gibt ist einfach die Latency Timeout des Treibers, wenn ich die verstelle funkioniert ja alles wie es soll. Ich kann mir nur nicht herleiten wie aus einer theoretischen Verzögerung des Frameendes von 16ms, ca 160ms werden in denen ich nix vom device bekomme.
    Hi,
    ich habe nun eine Matrix.:D Angesteuert wird das ganze mit dem Glediator-Protokoll.
    Wenn ich jedoch alles eingestellt habe und auf "Start output" klicke, kommt je nach Effekt nur ein Bild oder der Effekt läuft.
    Bei einem Bild hängt sich dann die Software nach ner Weile auf. Bei dem funktionierendem Effekt, hängt sich die Software nach herumklicken auf.
    Woran liegt das? War 0.92.
    Gruß Matthias
    @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.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Seddi“ ()

    Ich nutze ein Arduino Uno mit 8x8 WS2801 Pixeln und der Glediator Library.
    Bautrate ist 500.000. Es ist eine Schlange von unten rechts.
    Ich ändern zuerst immer unter "Matrix Size" meine Matrixgröße, dann patche ich (nochmal die Pixelzahl korrigieren), wähle meinen Effekt aus und drücke dann auf start.
    Es muss aber halt nicht zwingend an der Software liegen, denn ich habe die Matrix erst heute aufgebaut :whistling: