ESP RGBWW Wifi Led Controller - Support Thread

Begonnen von pjakobs, 07 Juni 2019, 10:48:27

Vorheriges Thema - Nächstes Thema

pjakobs

ich hab meine Überlegungen zum maximalen Strom nochmal upgedatet, es gibt einen kritischen Pfad auf der Platine, der aber relativ leicht zu umgehen ist. Siehe Post am Anfang des Threads.

pj

pjakobs

ich hab jetzt mal mein Labor upgedatet und kann jetzt 12V20A "sourcen" und 30A "sinken" (wie immer man das auf Deutsch sagen würde. Mir fehlen gerade bei solchen Dingen oft die Worte)

Ich hab heute früh mal einen Controller bis 7,5A pro Kanal getestet und im Grunde ist alles so, wie ich es oben schrieb:
bei konstant 6,5A wird das Gehäuse des Controllers so heiß, dass man es nicht mehr anfassen kann. Damit ist die Gehäusetemperatur über 60°C, was zu erwarten war, denn ich hatte ja sogar 115°C ausgerechnet.

Problematischer ist, dass bei einer ohmschen Last, die bei 12V 6,5A entspricht (nach Leitungsverlusten 1,3Ohm) und bei einem 50% Dutycycle (entspricht etwa der 70% Einstellung für einen Kanal) zwei Dinge passieren:
1. Sehe ich beim Einschalten des MOSFET ein deutliches Überschwingen, sprich der Mosfet schaltet auf Masse durch, aber durch irgendwelche Effekte steigt die Spannung kurz danach wieder auf ca. 50% an und bleibt dort für ca 10% des LOW cycles. Das heißt, dass für etwa 10% des gesamtzyklus 6V*6,5A=39W am MOSFET abfallen. Der Effekt ist wesentlich größer als die eigentliche steigende und fallende Flanke. Obwohl also weniger Energie an die LED gelangt, fällt in diesem Zustand wesentlich mehr Energie am MOSFET ab, der entsprechend heiß wird.
Dazu kommt, dass die steilen Flanken des PWM, wie schon beschrieben, in die Spannungsversorgung zurückwirken. Ih habe es nicht völlig durchgetestet, aber der ESP ist mir in dem Betriebsmodus ein paar mal abgestürzt, ich vermute, dass das an der entsprechend schwankenden Stromversorgung lag.

Kurz: bei 6,5A auf einem Kanal sollte man dringend einen Kühlkörper verwenden (ich würde eines einfaches Aluminiumprofil wie hier nehmen, allerdings halt so lang, dass es alle fünf MOSFETs abdecken kann. Zum verkleben gibt es wärmeleitende Klebepads)

Zudem muss für 6,5A die Stromversorgung schon wirklich gut sein. Haltet die Zuleitung kurz und sorgt für ordentlich Leitungsquerschnitt. Ich würde in dem Fall vermutlich sogar eine Sicherung einbauen, die bei 10A schmilzt.

pj

pj

pjakobs

So, heute hab ich mich mal hingesetzt und die Temperatur an einem MOSFET bei unterschiedlichen Strömen gemessen.

Der Versuchsaufbau war wie folgt:

Das 12V Netzteil lieferte eben 12V und bis zu 10A
Am Grün Kanal hing eine elektronische Last deren Stromaufnahme programmierbar ist.
Auf dem MOSFET für Grün lag eine Thermal Probe an der mein Messgerät hing.
Die Prozentwerte beziehen sich auf das FHEM Setting, nicht die PWM.

Zwei Dinge:
Erstes zeigt sich, dass meine Maximalberechnung stimmt, alle Messungen blieben bei 100% Helligkeit unter 125°C (die 6A Messung hatte ich vorher abgebrochen)
Zweitens: ich habe unterschätzt, wieviel Energie im Schaltvorgang am MOSFET "hängen" bleibt. In allen Kurven ist der Transistor zwischen 25 und 85% am heißesten, das Maximum liegt bei etwa 75%

Was ich jetzt nicht weiß ist: in wiefern spiegelt das das Verhalten mit "echten" LEDs wieder?
Ich habe hier an keiner Stelle einen Controller, der heiß wird (und ich betreibe die meisten üblicherweise bei 70% Helligkeit). Es ist möglich, dass die elektronische Last hier eigene Effekte einbringt und so das Ergebnis verfälscht. Ich hab noch etliche Meter LED oben liegen und teste später nochmal mit 5, 10 und 15m und werde berichten.

Grüße

pj

vbs

Dabei ist noch zu beachten, dass die PWM-Implementierung es SDKs nie 100% Duty-Cycle erreicht, sondern lediglich irgendwas um 90%.

pjakobs

Zitat von: vbs am 03 August 2019, 18:24:44
Dabei ist noch zu beachten, dass die PWM-Implementierung es SDKs nie 100% Duty-Cycle erreicht, sondern lediglich irgendwas um 90%.
die Temperaturen hier sind ja gemessen und ja, 100% geht nicht, aber es kommt näher ran als 90%.

vbs

Das hängt von der verwendeten Frequenz ab. Bei vollen 1000 Hz sind es 90 %. In unserem Fall geht es aber etwas höher.

db7

Moin Moin,

habe ein paar Probleme mit dem Controller, irgendwie will er nicht so wie ich es erwarte.
Um eine exakte Fehlerbeschreibung zu liefern habe ich via RST CLR den Controller zurückgesetzt.
Angeschlossen ist ein RGBWW LED-Streifen, bei diesem Streifen sind die Kabelfarben nicht wie am Anfang
dieses Threads beschrieben:

SW VCC
GN -> rt LEDs
BL -> gn LEDs
RT -> bl LEDs
WS -> Warmweiße LEDs

Also RST-CLR > Controller (..:88:c3) ist zurückgesetzt , RGB LEDs leuchten mit voller Leuchtkraft
Via 192.168.4.1 auf den Controller über das Controller-WLAN zugegriffen und ins Netzwerk eingebunden,
alles OK, Controller in meinem LAN erreichbar.

Als Firmware wird
Firmware vbs35
Web Interface 0.3.3-shojo7
RGBWW Version 0.8.1-vbs5
SMING Version 3

Frage: wird beim Rücksetzen des Controllers die Firmware ebenfalls zurückgesetzt, hatte zuvor auf Testing umgestellt?

Controller ist auf MRPJ eingestellt:
HSV steht auf normal, alle Regler auf 0 COLOR auf RGB, alle Regler auf 100

die RGB-LED leuchtet immer noch.

RGB, alle Regler auf 0, nur rt leuchtet noch,
mit dem Regler für gn und bl kann ich die Farben hinzuschalten, aber rt bleibt immer an.
Beim Speicher der Werte kommt häufig die Meldung "something went wrong", der Controller verliert die Verbindung

Schalte ich den Controller auf RGBWW, kann ich WW korrekt regeln, rt bleibt weiterhin an, aber bl und gn sind aus und lassen sich nun nicht
mehr regeln
Schalte ich um auf RGB, verhält sich der Controller wie zuvor.

Ein zweiter Controller (..:93:d1) verhält sich ähnlich beim Reset, die Farbregelung arbeitet wie folgt:

Mode RGB:
alle Regler funktionieren wie erwartet, rt regelt rt, gn regelt gn, usw
Mode RGBWW
WW funktioniert korrekt, rt und gn lassen sich regeln, aber nur mit deutlich verminderter Leuchtkraft, bl reagiert nicht.
Auch dieser Controller meldet "something went wrong"

Der dritte Controller (..:40:c2) lässt sich über RST-CLR nicht zurücksetzen, er macht nur einen Reboot, Reset via Web-Interface geht
Aber bei diesem leuchten gar keine LEDs :-(

Nun will ich nicht glauben, dass ich drei defekte Controller erhalten habe, aber etwas wundere ich mich schon. Vielleicht mache ich auch etwas falsch. Sorry bin leider nicht früher zu einem ausführlichen Test gekommen.

Freue mich über jede Hilfe

PSI69

Ich habe dann mal übers WE meinen Lasttest mit 2* 5m WW Stripes durchgeführt. Wie angekündigt habe ich die beiden Stripes parallel auf die Ausgänge von Controller gepackt. Versorgt wurde das Ganze über ein 60W 12V Schaltnetzteil, als Zuleitung zum Controller dienten 15m (alles, was ich zur Verfügung hatte) 1,5 mm2 Kabel (flexibel). Ausgeführt habe ich "set <name> raw 1023,1023,1023,1023,1023" und das dann eine Stunde laufen lassen.

Ergebnis: Die Transistoren und die Platine waren nur leicht warm, dito für die ausgerollten Stripes. Nur das Schaltnetzteil war gut warm...

Peter
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

Chris46

Mit welchem LED-Typ sind denn deine Streifen denn bestückt? 5630 kann es ja schon mal nicht gewesen sein, dass hätte dein 60 W Netzteil bei 10m nicht geschafft.

db7

Moin Moin,

hat keine eine Idee zu meinen Controllern? Bin ich hier im falschen Froum? Wer kann mir helfen?
Grüße Detlev.


Zitat von: db7 am 04 August 2019, 14:45:34
Moin Moin,

habe ein paar Probleme mit dem Controller, irgendwie will er nicht so wie ich es erwarte.
Um eine exakte Fehlerbeschreibung zu liefern habe ich via RST CLR den Controller zurückgesetzt.
Angeschlossen ist ein RGBWW LED-Streifen, bei diesem Streifen sind die Kabelfarben nicht wie am Anfang
dieses Threads beschrieben:

SW VCC
GN -> rt LEDs
BL -> gn LEDs
RT -> bl LEDs
WS -> Warmweiße LEDs

Also RST-CLR > Controller (..:88:c3) ist zurückgesetzt , RGB LEDs leuchten mit voller Leuchtkraft
Via 192.168.4.1 auf den Controller über das Controller-WLAN zugegriffen und ins Netzwerk eingebunden,
alles OK, Controller in meinem LAN erreichbar.

Als Firmware wird
Firmware vbs35
Web Interface 0.3.3-shojo7
RGBWW Version 0.8.1-vbs5
SMING Version 3

Frage: wird beim Rücksetzen des Controllers die Firmware ebenfalls zurückgesetzt, hatte zuvor auf Testing umgestellt?

Controller ist auf MRPJ eingestellt:
HSV steht auf normal, alle Regler auf 0 COLOR auf RGB, alle Regler auf 100

die RGB-LED leuchtet immer noch.

RGB, alle Regler auf 0, nur rt leuchtet noch,
mit dem Regler für gn und bl kann ich die Farben hinzuschalten, aber rt bleibt immer an.
Beim Speicher der Werte kommt häufig die Meldung "something went wrong", der Controller verliert die Verbindung

Schalte ich den Controller auf RGBWW, kann ich WW korrekt regeln, rt bleibt weiterhin an, aber bl und gn sind aus und lassen sich nun nicht
mehr regeln
Schalte ich um auf RGB, verhält sich der Controller wie zuvor.

Ein zweiter Controller (..:93:d1) verhält sich ähnlich beim Reset, die Farbregelung arbeitet wie folgt:

Mode RGB:
alle Regler funktionieren wie erwartet, rt regelt rt, gn regelt gn, usw
Mode RGBWW
WW funktioniert korrekt, rt und gn lassen sich regeln, aber nur mit deutlich verminderter Leuchtkraft, bl reagiert nicht.
Auch dieser Controller meldet "something went wrong"

Der dritte Controller (..:40:c2) lässt sich über RST-CLR nicht zurücksetzen, er macht nur einen Reboot, Reset via Web-Interface geht
Aber bei diesem leuchten gar keine LEDs :-(

Nun will ich nicht glauben, dass ich drei defekte Controller erhalten habe, aber etwas wundere ich mich schon. Vielleicht mache ich auch etwas falsch. Sorry bin leider nicht früher zu einem ausführlichen Test gekommen.

Freue mich über jede Hilfe



PSI69

Zitat von: Chris46 am 05 August 2019, 20:15:32
Mit welchem LED-Typ sind denn deine Streifen denn bestückt? 5630 kann es ja schon mal nicht gewesen sein, dass hätte dein 60 W Netzteil bei 10m nicht geschafft.
Ich habe diese hier:https://de.aliexpress.com/item/32575020716.html?spm=a2g0s.9042311.0.0.27424c4dNj4CSX; hatte ich schon geschrieben. Dort steht 'SMD 5050 chip' und in den Kommentaren stehen die 30W Leistungsaufnahme pro Stripe.
FHEM auf RPi 5 unter Bookworm mit inzwischen einem ganzen Zoo von Geräten...

pc1246

Zitat von: db7 am 06 August 2019, 06:51:31
Moin Moin,

hat keine eine Idee zu meinen Controllern? Bin ich hier im falschen Froum? Wer kann mir helfen?
Grüße Detlev.
Moin
Draengeln, und unnoetige Vollzitate bringen hier nichts!
Fuer mich hoert sich das so an, dass der erste ein Loetstellen Problem hat! Hierzu hatte Peter auch beschrieben, wie man das selbst schnell feststellen kann.
Der Zweite scheint ok zu sein, wobei es seltsam ist, dass der eine Kanal in einem anderen Modus nicht funktioniert. Die unterschiedliche Leuchtstaerke im RGB <-> RGBWW(CW) Modus wurde auch schon ausreichend diskutiert!
Der Dritte hat, wenn ich mich recht an die bisherigen Diskussionen erinnere, ansonsten noch mal selbst ueberfliegen, eine falsche Bestueckung.
Und nein, die Firmware aendert sich nicht mit dem Reset!
Aus meiner Sicht sollten wir die 3 austauschen.
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

db7

Danke für die Info,

werde die drei Controller nochmal testen
Detlev.

pjakobs

Zitat von: db7 am 04 August 2019, 14:45:34
Moin Moin,

habe ein paar Probleme mit dem Controller, irgendwie will er nicht so wie ich es erwarte.
Um eine exakte Fehlerbeschreibung zu liefern habe ich via RST CLR den Controller zurückgesetzt.
Angeschlossen ist ein RGBWW LED-Streifen, bei diesem Streifen sind die Kabelfarben nicht wie am Anfang
dieses Threads beschrieben:

SW VCC
GN -> rt LEDs
BL -> gn LEDs
RT -> bl LEDs
WS -> Warmweiße LEDs

Also RST-CLR > Controller (..:88:c3) ist zurückgesetzt , RGB LEDs leuchten mit voller Leuchtkraft
Via 192.168.4.1 auf den Controller über das Controller-WLAN zugegriffen und ins Netzwerk eingebunden,
alles OK, Controller in meinem LAN erreichbar.

Als Firmware wird
Firmware vbs35
Web Interface 0.3.3-shojo7
RGBWW Version 0.8.1-vbs5
SMING Version 3

Frage: wird beim Rücksetzen des Controllers die Firmware ebenfalls zurückgesetzt, hatte zuvor auf Testing umgestellt?

Controller ist auf MRPJ eingestellt:
HSV steht auf normal, alle Regler auf 0 COLOR auf RGB, alle Regler auf 100

die RGB-LED leuchtet immer noch.

RGB, alle Regler auf 0, nur rt leuchtet noch,
mit dem Regler für gn und bl kann ich die Farben hinzuschalten, aber rt bleibt immer an.
Beim Speicher der Werte kommt häufig die Meldung "something went wrong", der Controller verliert die Verbindung

Schalte ich den Controller auf RGBWW, kann ich WW korrekt regeln, rt bleibt weiterhin an, aber bl und gn sind aus und lassen sich nun nicht
mehr regeln
Schalte ich um auf RGB, verhält sich der Controller wie zuvor.

Ein zweiter Controller (..:93:d1) verhält sich ähnlich beim Reset, die Farbregelung arbeitet wie folgt:

Mode RGB:
alle Regler funktionieren wie erwartet, rt regelt rt, gn regelt gn, usw
Mode RGBWW
WW funktioniert korrekt, rt und gn lassen sich regeln, aber nur mit deutlich verminderter Leuchtkraft, bl reagiert nicht.
Auch dieser Controller meldet "something went wrong"

Der dritte Controller (..:40:c2) lässt sich über RST-CLR nicht zurücksetzen, er macht nur einen Reboot, Reset via Web-Interface geht
Aber bei diesem leuchten gar keine LEDs :-(

Nun will ich nicht glauben, dass ich drei defekte Controller erhalten habe, aber etwas wundere ich mich schon. Vielleicht mache ich auch etwas falsch. Sorry bin leider nicht früher zu einem ausführlichen Test gekommen.

Freue mich über jede Hilfe

hmm... für mich klingt das, als seien einige der PWM Pins kurzgeschlossen. Kannst Du nachmessen, ob nebeneinander liegende Pins des ESP kurzgeschlossen sind?

Grüße

pj

db7

Zitathmm... für mich klingt das, als seien einige der PWM Pins kurzgeschlossen. Kannst Du nachmessen, ob nebeneinander liegende Pins des ESP kurzgeschlossen sind?

Grüße

pj
Zwei Controller laufen nun korrekt, bei einem ist es, so glaube ich,  eindeutig.

Grüße Detlev.