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

Wanted to know a bit more ... wireless network connection, network speed, configuration, accesspoint, the artnet node itself (modell, manufacturer), other artnet sender/receiver in the network (if yes, addressing) ? As much info as I can get

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.

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:

OK, wenn ich die 512er Version drauf habe, kann ich da ja schauen warum es da hakelt, mal sehen wie das mit meinen SGMs zusammenspielt. Theoretisch sollte das nicht passieren, nun ja werden wir schon finden

Zitat von Pesi

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:

Zitat

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.

Zitat von Counterfeiter

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.

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.

Zitat von Pesi

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.

Zitat von Pesi

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: http://www.ftdichip.com/Suppor…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.

Zitat von Pesi

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.

Zitat von Pesi

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

Zitat von Counterfeiter

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.

Zitat von Counterfeiter

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.
http://msdn.microsoft.com/en-u…/windows/desktop/aa363190(v=vs.85).aspx

Zitat

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.

Zitat von Counterfeiter

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.

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.