Neue KSQ dimmbar 0-10V

[omega]

Hallo Robert,

Exponentiell gerechnet verläuft der Helligkeitsanstieg bei 30min. Sonnenaufgang anfangs derart zögernd , daß wohl einige User vermuten werden, daß die Steuerung defekt sei.

Ich will nicht an Deiner Programmiererehre kratzen, nein, wirklich nicht :wink: , aber tut sich bei Deinem Controller anfangs wirklich ausgangsseitig was, oder sind die Änderungen zunächst kleiner als der Quantisierungsabstand?

ja, da tut sich was. PWM-Level 1 wird synchron mit dem Rampenstart erreicht. Dafür sorge ich mit der Brechstange. PWM-Level 2 wird wohl etwas verzögert erreicht, hab die Zeit aber nicht gestoppt. Ab inkl. 2 bestimmt die Funktion den PWM-Level.
Zur Kontrolle läuft ein Lauffeuer aus 8 roten LEDs mit, die bei jeder PWM-Änderung durchgeschaltet werden. Bei 1/4095tel leuchten bei den COBs noch nicht alle Einzel-LEDs. Und ich sehe die COBs anfangs Schritt für Schritt heller werden, synchron mit dem Lauffeuer.

Was ich mit defekt andeute, ist die sehr langsame Änderung der Helligkeit zu Beginn der 30 Minuten. Dort ist n^x ja sehr flach, ok, ein Sinus auch, aber nicht so lange.

Grüße, Markus

 

[Wuestenrose]

Hallo Markus...

Ich will einen Sonnentag unter Wasser simulieren. Der verläuft nicht exponentiell.

Doch, tuter, jedenfalls über Wasser .

ja, da tut sich was.

Ok, war ja auch nur 'ne Idee. Die LOGO! löst nur auf 10 Bit auf. Bei exponentieller Dimmung bleiben dann von den 1024 Stufen nur echte 330 Schritte, die sich von der vorherigen Stufe unterscheiden übrig.

Edit: Tippfehler korrigiert, Halbsatz zur Erläuterung eingefügt.

Grüße
Robert

 

[MajorMadness]

Da noch unterwegs nur kurz eins als Erklärung bevor ich deine Formeln in Ruhe lese:

bei den Prozentangaben meinst Du PWM-Level oder die vom Auge wahrgenommene Helligkeit? Oder mischst Du gerade beide?

Ich meinte %, also bestromung led mit 350mA, dimmung 12bit, 8%~{8x40,95)/4095. Bei der linear dimmung über 60 Minuten mit 2 getrennten LEDs und Farben erscheint es dem Auge nicht so als ob das Mischungsverhältnis stimmt.
Sagen wir ich will meine 7000k LEDs 30 Minuten nach den 3500k LEDs eindimmen kommt es mir so vor als ob die 3500k schon fast ganz an sind bevor das 2te eindimmen beginnt.
Bei der PWM table von mir sind 50% aber wirklich halb so hell für das Auge wie 100%. Daher ja auch am Anfang mehrmals das 1/4095stel und am Ende springe ich in großen schritten von 4050 zu 4095.

 

[omega]

Hallo Moritz,

Sagen wir ich will meine 7000k LEDs 30 Minuten nach den 3500k LEDs eindimmen kommt es mir so vor als ob die 3500k schon fast ganz an sind bevor das 2te eindimmen beginnt.

ah, jetzt ist so anschaulich, daß auch ich's blicke. Ok, ich habe nicht vor, Lichtfarben zu mischen. Ich werde COBs verbauen. Die stehen weiter auseinander als viele kleine Einzel-LEDs, Disco-Effekt in den Schatten bei Mischlicht.

Bei der PWM table von mir sind 50% aber wirklich halb so hell für das Auge wie 100%. Daher ja auch am Anfang mehrmals das 1/4095stel und am Ende springe ich in großen schritten von 4050 zu 4095.

Zur Laufzeit errechnet ergibt sich die PWM-Schrittweite durch die Funktion und die Häufigkeit, mit der der PWM-Level errechnet wird. Bei z.B. einer 30 Minuten Rampe wird bei mir der PWM-Level 90.000x errechnet (alle 20ms). Hierbei wird jeder einzelne PWM-Level der 4095 angefahren, auch bei der Exponentialfunktion. Glatter geht's nicht mehr, bräuchte es aber gar nicht, da größere Schrittweiten bei starker Helligkeit eh nicht mehr wahrnehmbar sind. Aber der µC gibt's her. Warum also nicht nutzen.
Die mit großem Abstand meiste CPU-Zeit kostet hier die Comm. mit dem Display bei Benutzereingaben und den PWM-Treibern (I2C@400kHz).

Grüße, Markus

 

[omega]

Hi,

Ok, war ja auch nur 'ne Idee. Die LOGO! löst nur auf 10 Bit auf. Bei exponentieller Dimmung bleiben dann von den 1024 Stufen nur echte 330 Schritte, die sich von der vorherigen Stufe unterscheiden übrig.

Rampenanlaufprobleme hatte ich anfangs schon welche. Die hab ich aber eliminiert. Auch Präzisionsfehler - landläufig ja immer fälschlicherweise als Rundungsfehler bezeichnet - durfte ich kompensieren, allerdings nicht beim Ermitteln des PMW-Levels, sondern beim Ermitteln der Zeitdifferenz für die nächste Änderung des PWM-Levels.
Ich hatte ursprünglich vor, nicht alle x Millisekekunden den PWM-Level zu ermitteln, sondern timergsteuert den µC für jede Änderung aufzuwecken. Das hat sich allerdings (für mich) als nicht umsetzbar herausgestellt, viel zu aufwendig und fehlerträchtig (Zeitdifferenz kleiner als Programmablaufzeit oder gar 0.0 bei sehr kurzen Rampen (Wolken)).

Der Helligkeitsverlauf eines Tages ist bei mir abschnittsweise definiert, wird also nicht von einer einzigen Funktion sondern mehreren beschrieben. Beim Übergang von einem Abschnitt zum nächsten erzeugte das Ermitteln der Zeitdifferenz die Präzisionsprobleme (zu kurz gerechnet, die Zeitdifferenz schaffte es am Ende des einen Abschnitts nicht in den nächsten, die nächste Zeitdifferenz war dann 0.0, das Endekriterium: Licht aus), die aber nicht immer auftraten sondern von Parametern abhängten. Bekam ich aber auch gelöst und erinnerte mich wieder ans Studium: Numerische Mathematik.

Grüße, Markus