Nabend, habe hier gerade meinen DMX gesteuerten LED Dimmer fertiggestellt, 4 PWM Kanäle, 970Hz PWM Freguenz - soweit funktioniert das. Problem ist das Fading. Wenn per DMX über so ca. 5s gefadet wird ist alle in Ornung und das Dimmergebnis sieht sehr gut aus. Bei ca. 2s Fading ist das aber anders. DMX überträgt bekanntlich 512 Kanäle und braucht dafür ca. 23ms per Zyklus. Wenn jetzt in nur 2s von 0 auf 255 gefadet wird, gibt es logischerweise größere Lücken im DMX Signal die sich dann in Helligkeitssprüngen bemerkbar machen. Idee ist nun die fehlenden Zwischenwerte vom Dimmer berechnen zu lassen und jeweils zwischen zwei DMX Zyklen auszugeben (Zeit dazu ist ja genug). Also wenn vom DMX Sender 0,4,8,12.. kommt daraus wieder intern 0,1,2,3,4.. zu machen. Nur habe ich noch keinen Ansatz wie ich mir die Werte ezeuge damit das Timing auch immer stimmt. Vielleicht hat jemand schon mal ähnliches gelöst? Jürgen
:
Bearbeitet durch User
Es dauert 5,78s wenn man von 0 -> 255 dimmt und bei jeden Frame inkrementiert. Das Problem stellt sich er andersherum wenn man z.Bsp 10min hoch fadet. Wenn der PWM 8bit Auslösung hat gibt es 255 Schritte die wie erwähnt nur alle 22,6ms also pro Frame gesendet werden können. Es gibt ein weiteres Problem das break das von 88µ-1sec definiert ist. Lässt sich der Sender mehr Zeit dauert es noch länger oder die Werte springen wenn im Sender nicht der DMX Frame berücksichtigt wird beim Timing. Bei sehr langen Zeiten springt der Wert bei 8bit deswegen haben viele Dimmer eine Auflösung von 14bit. Sie interpolieren die 8 Bit werte des DMX Signal oder benutzen 2 Channels -> 16bit. Es gibt mehre Wege das interpolieren zu lösen. Der Wert ist nicht das alleinige Maß sondern auch die Zeit in dieser sich ändert. Solche Kurven sind gut gehütetes Geheimnis von LED Herstellen und nicht selten mit Patenten behaftet. Wenn du alle 44 Frames in der Sekunde auswertest und der Sender dieser auch liefert flackert auch nichts bei 2 Sekunden. Das Signal läuft so schnell hoch das dies nicht auffällt.
:
Bearbeitet durch User
Wenn eine Verzögerung von einem DMX Frame akzeptabel wäre, könnte man die PWM Zwischenstufen per PI Regler nachziehen, wobei die Sollwerte von DMX vorgegeben werden und der Istwert die aktuelle PWM der LED ist (linearisiert hast du sie ja bestimmt schon). Das könnte im 970 Hz Takt passieren. Die P und I Parameter bestimmen dann, wie schnell die LED dem DMX folgen.
Ich würde einfach über einen DMX Frame (23ms) linear vom letzten Wert zum aktuell empfangenen Wert interpolieren. delta = neuer_wert - alter_wert; pro PWM Zyklus (970 Hz) addierst du dann 1/22 des deltas dazu (denn du hast 22 PWM Zyklen Zeit zwischen den DMX Frames). Eine (Halogen)Glühlampe würde das ähnlich machen. Du kannst ja noch eine Threshold einbauen, wenn der neue Wert und der alte Wert weiter als sagen wir mal 50 auseinanderliegen, dann wird sofort zum neuen Wert gesprungen. So kann man dann immer noch Blitzlicht machen, beim langsam Faden wird aber interpoliert.
:
Bearbeitet durch User
Marco H. schrieb: > Es dauert 5,78s wenn man von 0 -> 255 dimmt und bei jeden Frame > inkrementiert. Lineares Dimmen von 0 auf 255 in +1-Schritten ist ziemlich sinnlos, weil der Mensch Helligkeitsänderungen relativ wahr nimmt, i.e. (delte I)/I. Um dieser logarithmischen Wahrnehmung gerecht zu werden, muss man die Helligkeit für einen Zeitschritt um einen festen Faktor erhöhen, also z.B. 1, 2, 4, 8, 16, ...
Jürgen B. schrieb: > Wenn jetzt in nur 2s von 0 auf 255 gefadet wird, gibt es logischerweise > größere Lücken im DMX Signal die sich dann in Helligkeitssprüngen > bemerkbar machen. > > Idee ist nun die fehlenden Zwischenwerte vom Dimmer berechnen zu lassen Typischer Fall von: Wenn ich nur einen Hammer als Werkzeug kenne, sieht irgendwie alles wie ein Nagel aus... Nein: Normaldenkende erkenne in deiner Situation, dass das DMX-Protokoll schlicht ungeeignet ist, um deine Anforderungen zu erfüllen. Und sie machen dann das, was logisch ist: Sie verwenden KEIN DMX, sondern was anderes. Natürlich etwas, was besser für deinen Zweck geeignet ist...
erst mal danke für die interessanten Antworten. Ich glaube das mit dem 1/22 (970/44) pro PWM Zyklus addieren kann ich noch am ehesten verwirklichen, da ja ich ja intern schon mit 11Bit arbeite. Vielleicht kann man ja noch die Frame to Frame time mit in die Berechnung einfliessen lassen fals diese nicht konstant ist. Gruß Jürgen
Wolfgang schrieb: > Marco H. schrieb: >> Es dauert 5,78s wenn man von 0 -> 255 dimmt und bei jeden Frame >> inkrementiert. > > Lineares Dimmen von 0 auf 255 in +1-Schritten ist ziemlich sinnlos, weil > der Mensch Helligkeitsänderungen relativ wahr nimmt, i.e. (delte I)/I. > Um dieser logarithmischen Wahrnehmung gerecht zu werden, muss man die > Helligkeit für einen Zeitschritt um einen festen Faktor erhöhen, also > z.B. 1, 2, 4, 8, 16, ... Das kann der Dimmer aber auch selbst erledigen indem er die linearen DMX Signale entprechend verbiegt (Look-up tabelle)
:
Bearbeitet durch User
Jürgen B. schrieb: > Das kann der Dimmer aber auch selbst erledigen indem er die linearen DMX > Signale entprechend verbiegt (Look-up tabelle) Dieser (und jeder ähnliche) Ansatz ist kompletter BLÖDSINN. Der Slave kann schließlich niemals wissen, was als nächster Steuerwert über dieses unsägliche DMX-Protokoll reinkommt, denn nichts und niemand kann in die Zukunft sehen. D.h.: Jede Massnahme, die für eine Situation eine "Verschönerung" des Ergebnisses darstellt, wird für eine (sogar systematisch konstrierbare) andere Situation ein suboptimales Ergebnis erbringen.Ganz klar z.B. dann, wenn eben kein sanftes Dimming gewünscht wird, sondern tatsächlich ein harter Sprung. Die einzige wirkliche Lösung ist das Abwerfen der Beschränkungen des Protokolls! Das kann doch, verdammt noch mal, nicht so schwer zu verstehen sein?
Jürgen B. schrieb: > Vielleicht kann man ja noch die Frame to Frame time mit > in die Berechnung einfliessen lassen fals diese nicht konstant ist. Ja, gute Idee. Ich vermute, wesentlich langsamer als 44 Hz wird's nicht werden, da dies die Vollauslastung mit 512 Kanälen ist. Aber wenn ich es richtig verstehe, kann man DMX auch mit weniger Adressen, und dafür höherer Refreshrate laufen lassen. Dann könntest du deinen Teiler eben entsprechend (dynamisch) anpassen, und ab einer bestimmten Refreshrate macht Interpolieren vermutlich dann eh keinen Sinn mehr.
c-hater schrieb: > Die einzige wirkliche Lösung ist das Abwerfen der Beschränkungen des > Protokolls! Das kann doch, verdammt noch mal, nicht so schwer zu > verstehen sein? Ich mach mir die Welt, wiedede wie sie mir gefähälllt...
Joe F. schrieb: > Ich mach mir die Welt, wiedede wie sie mir gefähälllt... Ja, ich glaube auch, dass dein Verständnis der einschlägigen Mathematik ungefähr auf Pippi-Langstrumpf-Niveau ist... Du musstest das nicht unbedingt so explizit darstellen. Aber naja, wenn sich einer selber öffentlich als komplett unwissend outen will, sollte das meiner Meinung nach durchaus erlaubt sein: auch das ist eine schützenswerte Form der Meinungsfreiheit... Und immerhin: die Erwachsenen haben auch mal was zum Ablachen, das RL ist hart genug, da ist sowas mal eine schöne Abwechslung. Also in irgendeiner Form doch ein nützliches Posting. Nur leider nicht für den TO...
c-hater schrieb: > Aber naja, wenn > sich einer selber öffentlich als komplett unwissend outen will, sollte > das meiner Meinung nach durchaus erlaubt sein Das ist sehr nett von dir. Dir scheint aber nicht klar zu sein, dass DMX der Standard in der Lichttechnik ist, den man nicht eben so mal ändern kann. Wer einen Dimmer entwickelt, muss ihn so entwickeln, dass er zum Standard und den Lichtsteuerpulten passt. Die technischen Unzulänglichkeiten des Standards sind allerdings nicht so unglaublich groß, dass es nicht möglich wäre, mit einfachen Maßnahmen deutliche Verbesserungen zu schaffen. Und genau darum geht es hier.
Jürgen B. schrieb: > Vielleicht kann man ja noch die Frame to Frame time mit > in die Berechnung einfliessen lassen fals diese nicht konstant ist. Nochmal zurück zu deiner Idee. Ich denke am meisten Sinn macht es, die Zeit zu messen, die zwischen 2 DMX Updates des betreffenden Kanals liegt. z.B. direkt die PWM Zyklen zählen. Und diesen Wert legst du dann für die Interpolation als Teiler des Deltas zugrunde. Du berechnest sozusagen die Steigung des sich ändernden Signals nur für den entsprechenden Kanal. Angenommen du bewegst den Fader mit konstanter Geschwindigkeit. Wenn für den Kanal selten Daten kommen, hast du ein großes Delta und ein großes Zeitintervall. Wenn die Daten für den Kanal öfter kommen, ist die gemessene Zeit kürzer, das Delta aber auch kleiner. Die Steigung (Delta pro PWM Zyklus) dann also einigermaßen konstant, unabhängig vom Update-Intervall, und unabhängig davon, ob eventuell andere Kanäle mit einem anderen Update-Intervall versorgt werden. Du hängst halt immer 1 Update-Zyklus hinterher, bis die LED den neuen Wert endgültig erreicht hat.
https://github.com/tdicola/LinearInterpolation Erklärt das Prinzip ziemlich gut. Man schaut eben wie viel PWM Perioden vergangen sind und interpoliert das auf den 14bit PWM Bereich.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.