Hallo zusammen,
war wohl doch nicht mehr die Zeit für einen Beitrag. Erst einmal das einfache: ja, es ist ein TWS beteiligt. Mein ex960Q gibt die Signale aus. Sowohl jetzt als 950Q (nach dem FreshUp) als auch davor. Die Software-Version ist so eine Sache. Aktuell ist die 4.0 IP1 installiert. Aber das Phänomen besteht schon länger. Eventuell auch seit meinen ersten Gehversuchen mit der Beleuchtung am Testbrett (Q1 2021 glaube ich), aber da habe ich tatsächlich nicht so genau drauf geachtet, weil ich schon begeistert war einen LED-Spot zum leuchten zu bringen und dabei auch noch dessen Farbe zu steuern. Da hatte ich auch einen anderen Decoder im Einsatz. Entsprechend würde ich es nicht zwingend EINER Version zuordnen wollen.
Wie soll ich es handhaben bzw. wie hilft es euch/anderen am besten?
Ich will den TWS eigentlich auch nicht vorrangig unter Verdacht stellen. Ich möchte im ersten Schritt das Zusammenspiel besser verstehen. So kann ich nämlich nicht so ganz nachvollziehen, warum 8 Bit ansteuerungsseitig zu Stufen bei der Ausgabe führen sollen. Die Änderungen von Wert zu Wert sind ja mit 1/256 = 0,39% von der Gesamthelligkeit eher klein. Wären es 1/256 vom jeweiligen Sprung, entsprechend noch kleiner.
Weiß zufällig jemand aus dem Hut, wie sich die Fadetime im DMX_Test-Modul errechnet? Ist sie unabhängig von der Sollsprungweite oder wird diese berücksichtigt. Soll heißen:
Sind für
eingestellt, macht er dann den Sprung von 0-->100% (0-->255) in 0,8s und einen Sprung von 20% nach 80% in 0,48s (0,8s*(80%-20%)) oder auch in 0,8s. Bei den kurzen Zeiten würde ich gefühlt sagen: die sind alle gleich, aber gemessen bekomme ich es nicht. Setze ich die Fadetime auf gut über 2s um einen Unterschied sehen zu können, erkenne ich wiederum keinen, denke aber hier greift ohnehin die 0,8s Begrenzung vom Co-Prozessor (oder die meiner trüben Augen).
Gehen wir mal von einer Unabhängigkeit aus, also 0,8s für jeden Sprung: 0%-->100% in 0,8s, macht bei 8 Bit (256 Schritte) 3,125ms Haltedauer (800ms/256) je Schritt, bis das nächste Signal kommt. Macht man nur eine Sprung von 10%, dann sind das ja auch nur 25 Schritte. Wäre bei unabhängiger Fadetime eine Haltezeit von 32ms. Im Vergleich zu 30 Bildern/s bzw. 33ms Bildhaltedauer, damit das menschliches Auge eine fließende Bewegung wahrnimmt, liegt also selbst das noch voll im Rahmen (davon abgesehen, dass ich bei 10% Wertänderung nicht all zu viel wahrnehmen kann).
Gemäß der
Beschreibung von StefanW, schafft das DMX locker. Sofern der TWS im entsprechenden Tempo auch neue Werte liefert gehen die auch so auf den Bus. Der Decoder könnte zwar zwischen diesen Schritten interpolieren, aber einen unterschied würde es meines Erachtens nach nicht machen. Oder verstehe ich die Interpolation falsch? Immerhin sind die Schritt zu kurz um wahrgenommen zu werden und zu klein um Sprünge zu sehen.
Im Testmodus sehe ich das ein. Da wurde bestimmt eine feste Kennlinie hinterlegt der gefolgt wird und gut.
Unterm Strich bleibt für mich also die Frage: gibt der (Co-Prozessor des) TWS die Werte nicht schnell genug aus oder verarbeitet mein Decoder die Befehle nicht ordnungsgemäß. Da ich das Phänomen bei beiden im Einsatz befindlichen sehe, schließe ich einen Hardware-Defekt aus. Zwar kommen beide vom gleichen Hersteller, aber da Jochen mit Eldo's ähnlich Erfahrungen gemacht hat, würde ich auch die Decoder-Firmware ausschließen. In meinem konkreten Fall ist noch ein Splitter zwischengeschaltet. Den könnte ich mal testweise umgehen, aber ich mutmaße, der ist es auch nicht.
Ich meine mal irgendwo was gelesen zu haben, dass bei Elabnet mal für eine Test des Co-Prozessor eine sehr große Anzahl an Treiber angesteuert wurden. Weiß jemand was ich meinen könnte und findet den Beitrag entsprechend? Falls ich mich nicht täusche und dieser Test wirklich lief, dann wäre das Phänomen bestimmt da schon aufgefallen, wenn es existiert hätte.
Vielleicht habe ich ja glück und es was ganz banal zu behebendes.
Vielen Dank soweit.
Viele Grüße aus Sachsen
Tobias
TWS 950Q ID:458, vormals 960Q mit FreshUp, VPN offen, Reboot erlaubt nach Rücksprache
TWS 950Q ID:488, offline
PBM SN 1048