[OpenKNX-Ready] LED-Dimmer, Constant Voltage, 6-fach für UP, 12-fach für REG (6 TE)

[willisurf]

nicht in CPU machbar

Yepp, das Thema ist insgesamt nicht trivial und timingkritisch. Ich hatte mir das mal bei MDT angeschaut
https://knx-user-forum.de/forum/%C3%...r-akd-0424r-02

[LostWolf]

Bedeutet für die Netzteilauslegung?
Würde ungern das Netzteil einfach doppelt so groß auslegen wollen

[Alloc]

Die einzelnen Dimmer/Dimmkanäle sollte kurz und niederohmig möglichst direkt am Netzteil sternförmig verdrahtet werden (gibt dazu etliche Threads, sternförmig oder flackern sind gute Suchbegriffe).

Das sollte man sicher immer tun, ist aber auch keine Garantie für problemfreien Betrieb mehrerer PWM-Kanäle an einem Netzteil - kann ich hier aus eigener Erfahrung mit sauberer Verkabelung sagen
Vermutlich ist es dann weniger die Verkabelung, als vielmehr das Netzteil selber, dass dann mit sowas Probleme bekommt.


Thema HCL:
Ich werde "leider" dieses Gerät hier noch lange nicht einsetzen, da wir halt bereits alles mit MDT-Dimmern in Betrieb haben (und insbesondere die Dimmer, die nur über die LED-Panels zugänglich sind "schwer" erreichbar sind, weil die Panels nicht so leicht rausgehen, ohne den Rigips zu beschädigen). Aber ich kann ja dennoch mal allgemein etwas erklären, was ich mir unter TW/HCL Unterstützung vorstelle und was ich bei MDT schlecht finde in dem Bereich, vielleicht kann man ja hier was mitnehmen

Erstmal finde ich es immer wichtig, alles optional anzubieten:
- Reines TW: Also rein extern gesetzte CW/TW-Helligkeitswerte bzw. Helligkeit + Farbtemperatur - idealerweise sowohl Prozentual als auch als Farbtemperatur.
- HCL nur für Farbtemperatur: Helligkeit wird immer noch extern kontrolliert, aber solange HCL aktiv regelt diese dann die Farbtemperatur selber.
- HCL für Helligkeit und Farbtemperatur

Je nach dem ob HCL nur für die Farbe oder auch Helligkeit sollte entsprechend dann auch nur eine Änderung des zutreffenden Wertes von außen die HCL ausgeschaltet werden. Sprich wenn die HCL nur die Farbtemperatur steuert darf eine Änderung der Helligkeit die HCL nicht beenden.

Ein großes Problem bei MDT: Einschalten der HCL. Sprich, wenn durch manuelles Übersteuern (oder explizites Abschalten per Szene/KO) die HCL temporär deaktiviert wurde, bekommt man diese nur wieder eingeschaltet, wenn man (über Szene/KO/Einschaltverhalten) "HCL starten" nutzt. Bei MDT bedeutet das, ich kann die HCL nicht automatisch reaktivieren, wenn zum Beispiel der Lichtkanal ausgeschaltet wird, da dann direkt das Licht angeht. Ebenso nicht beim Einschalten, denn "HCL starten" setzt die Helligkeit dann auf 100%, obwohl die HCL hier nur die Farbtemperatur steuern sollte.
Hier fände ich es also praktisch, wenn man einerseits die "HCL-Funktion" einfach jederzeit ein/ausschalten könnte, ohne direkt irgendeine Auswirkung auf den Status des Ausgangs zu haben, und im Idealfall vielleicht einen Parameter, dass die HCL-Funktion automatisch aktiviert wird, wenn der Ausgang abgeschaltet wird, so dass ein Übersteuern der HCL immer nur für die aktuelle Benutzung des Kanals gilt.

Für diejenigen, die die HCL sowohl für die Farbe als auch Helligkeit nutzen, wäre es eventuell sogar noch schöner, intern beides zu trennen und dann drei Betriebszustände zu haben: HCL aktuell inaktiv, HCL regelt nur Farbe, HCL regelt Farbe und Helligkeit. Dann könnte man auch bei dieser Einstellung jederzeit die Helligkeit übersteuern, ohne dass die automatische Farbregelung mit abgeschaltet wird. Stattdessen würde einfach der Betriebszustand von HCL mit Farbe+Helligkeit auf HCL nur für Farbe zurückfallen.

Ansonsten natürlich Stützpunkte für die Berechnung der aktuellen Farbe/Helligkeit, am besten sowohl nach reiner Uhrzeit (also 10 Uhr soll es 4000 K sein und 80% Helligkeit) als auch mit Sonnenbewegung (Sonnenaufgang + 2 Stunden).


Auf Grund der Unzulänglichkeiten bei den MDT-Dimmern läuft bei uns die ganze HCL (nur Farbe) extern in der Logikengine, was natürlich echt unschön ist, da der Bus damit permanent diverse Nachrichten bekommt (einmal aktueller Farbwert pro Raum und dann die Rückmeldung Farbe absolut+prozentual pro Dimmerkanal - und alles im 3 Minutentakt). Da würde ich mir schon was anderes wünschen


Nur mal so als meine 2ct mit dem Wissen, dass ich auch nicht der Nabel der Welt bin

[abtools]

Vielen Dank für dein ausführliches Feedback, Chris!

Da können wir sicherlich die ein oder andere Anregung davon in unsere HCL-Umsetzung einfließen lassen.

Viele Grüße
Andreas

[willisurf]

Bedeutet für die Netzteilauslegung?

Nach meinem Verständnis müsstest Du damit aktuell das Netzteil für den Summenstrom aus CW und WW auslegen.

[willisurf]

Das sollte man sicher immer tun, ist aber auch keine Garantie für problemfreien Betrieb mehrerer PWM-Kanäle an einem Netzteil - kann ich hier aus eigener Erfahrung mit sauberer Verkabelung sagen

Ja, das ist auch meine Vermutung. Insbesondere, wenn Netzteile für Parallelschaltung geeignet sind, vermute ich einen höheren dynamischen Innenwiderstand. Habe ich aber nicht gemessen. Daher bin ich da etwas vorsichtig.

[Alloc]

In meinem Fall sind es ja die "klassischen" Meanwell HLG, keine Parallelschaltung oder ähnliches. Ich tippe auf Ausgangskapazität oder das einfach der Regelkreis selber schon Probleme mit diesen hochfrequenten 0/100% Wechseln hat, insbesondere wenn das dann noch "mehrstufig" passiert (zwei oder mehr TW-Kanäle -> (teilweise) Überlappung der Ansteuerung).

[LostWolf]

Nach meinem Verständnis müsstest Du damit aktuell das Netzteil für den Summenstrom aus CW und WW auslegen.

abtools
Hast du das mal gemessen, wie es hier aussieht?

---

Alloc

Danke für die Ausführung.
Tatsächlich würde das genau auch meine Anforderungen abdecken

[IPv6]

Ich denke eine doppelt so starke Auslegung des Netzteils sollte nicht erforderlich sein, die Pulse sind bei 1 kHz PWM Frequenz so kurz, dass die Kondensatoren im Netzteil (und im Dimmaktor) das ausmitteln dürften. Bei großen Bedenken könnte man auch noch weitere Pufferkapazität an das Netzteil hängen, sollte aber nicht erforderlich sein.
Gänge LED Netzteile haben meist eine Überlasterkennung und sind oftmals selbst kurzschlussfest, da braucht man wenig Sorgen haben, das Netzteil durch Überlast zu zerstören - wenn es überlastet wird, meldet es sich. Wenn das also beim Test einwandfrei funktioniert, kann es so bleiben.

die Aussage überrascht mich.
Grundsätzlich sind die Schaltverluste beim PWM Dimmen nicht zu vernachlässigen, vor allem bei 1kHz.

Mich hat das so rein vom ersten Gefühl her auch überrascht, aber die Simulation sagt die bereits erwähnten 30 mW Verlust am MOSFET bei 3,3 V durch 100 Ohm Vorwiderstand am Gate und bei 4 A Last. Voraussetzung ist, dass der GPIO auch die vollen 33 mA liefert und nicht in eine Begrenzung geht und dass der GPIO beliebig steilflankig schaltet. In der Praxis dürften daher die Verluste schon noch ein wenig höher ausfallen, aber ich denke sie liegen immer noch unter den ca. 100 mW, die der RDSon bei 4 A und 100 % dutycycle verursacht.
Viel höher sollte man mit der PWM Frequenz bei der Hardware wohl nicht gehen, bei 10 kHz sind dann die Verluste sicher nicht mehr zu ignorieren.
Zum Timing: Der Nachfolgetyp des verbauten MOSFETs (für den tatsächlich verbauten gibt es leider kein SPICE Modell) braucht bei 3,3 V über 100 Ohm am Gate etwa 2 us um voll durchzuschalten und etwa 1 us um voll zu sperren.
Das ist trotz den geringen Gatestrom und der geringen Gatespannung alles sehr harmlos, man muss aber auch beachten, dass die 4 A für den MOSFET nichtmal Standgas sind, die Dinger sind ja 100 A (pulsfest bis 400 A) Typen.

[LostWolf]

Dachte ich mir auch das hier das Netzteil so schnell nicht in Überlast gehen wird (wird entweder ein HLG oder ELG; je nachdem ob es das ELG in der nötigen Leistung gibt).
Wobei ich jetzt keine Pufferkondensatoren auf der Dimmer Platine sehen konnte.
Zu welcher Dimensionierung würdest du den raten, wenn alle Leuchten TW sind und z.B. 300W bei einer 50%/50% Betrachtung heraus kommen?

[Ing-Dom]

Voraussetzung ist, dass der GPIO auch die vollen 33 mA liefert

die GPIOs beim RP2040 liefern zumindest nach Spec. max. 12mA. Was da real fließt müsste man messen.


Aber auch wenn es etwas mehr wird wie 30mW sind das noch keine kritischen Bereiche..

[IPv6]

12 mA als Maximum der GPIOs steht so nicht im Datenblatt, auch wenn es eine Einstellung gibt, die das vermuten lässt.
Zugegebenermaßen sind die ganzen Angaben dort ein wenig verwirrend und es wird keine klare Aussagen als nackte Zahl getroffen.
Die wichtigste Angabe dazu scheint mir Figure 171 auf Seite 618 zu sein. Man bekommt demnach durchaus 30 mA aus einem GPIO Pin, dabei bricht aber die Spannung von 3,3 V auf 2,5 V ein.
Das Gate wird demnach zumindest anfänglich mit 30 mA geladen und der Strom auf das Gate sinkt ja dann mit steigender Ladung sowieso.

[Ing-Dom]

wo du recht hast hast du recht.
Es gäbe noch das "Maximum Total IOVDD current" das mit 50mA angegeben ist.
Dürfte aber keine Rolle spielen, die gemittelte Dauerlas ist ja viel niedriger.

[LostWolf]

nach der neuen Version 0.5:
Was ist den deine Erfahrung mit dem LED-Controller bis jetzt?

[Theees]

An wen ist die Frage gerichtet? Die 0.5 gibt es doch erst seit gestern Abend halb 11

Ich werde die im Laufe des Tages mal aufspielen. Werde aber erstmal nur den Einzelkanal testen können da das Gerät schon mehr oder weniger fest verbaut ist und da nur Einfarbige Spots dran hängen.