Bastelprojekt WLAN RGB Controller für ca. 6€

[Pf@nne]

Direkt am GPIO? (Ich hab mir das schematic noch nicht angesehen) Da sollte aber auch ein Widerstand zwischen. Ich weiß ja nicht wie das C in den verwendeten MOSFETs so ist, aber da können beim Umladen recht hohe Ströme entstehen die ohne Vorwiderstand die GPIO Ports in die ewigen schicken kann...

Ich war der Meinung da schon was zu geschrieben zu haben, ist aber irgendwie verschwunden....

Die verwendeten MOSFETs sind zwar LL (LogicLevel) aber die direkte Ansteuerung mit einem GPIO sehe ich da auch noch nicht.
Funktionieren tut das Ganze, die Frage ist bis zu welchem Strom.
Das Gate des FETs ist ein Kondensator, der GPIO muss diesen umladen. Von daher hast du recht, dass es hier zu Stromspitzen am GPIO kommen kann. Mit dem Widerstand wird der Umladestrom begrenzt, was aber auch die Zeitkonstante erhöht.
Das heißt, die Spannung am Gate ändert sich langsamer.
Die Verluste am FET (Wärme) zeigen sich im linearen Bereich, also immer beim Umladen.

Von daher gilt: Je schneller und Stromstärker die Ansteuerung (daher sollte man auch einen Treiber verwenden) , desto kleiner sind die Verluste (Wärme) beim Umladen des Gate-Kondensators. Je schneller die Umladung erfolgt desto größer wird aber auch das dU/dt bzw. dI/dt, was wiederum für die Störungen verantwortlich ist.

Im Gegenzug werden die Störungen bei langsamerer Umladung kleiner, dafür wird aber Wärmentwicklung größer.

Daher die Frage, wie viel Strom habt ihr bei dieser HW-Anschaltung schon getestet?
Bei 1m LED-Band passiert sicherlich erst mal nix. Bei mehreren Ampere dürfe die Wärmeentwicklung schon interessant werden.

EDIT:
Der Vorteil eines LL-MOSFETs liegt darin, dass er bereits bei kleinen Spannungen sein RDSon erreicht und somit die statischen Verluste klein hält. Daher sind die Dinger, mit direkter GPIO-Ansteuerung, zum Schalten (also mal ab und an EIN/AUS) sehr gut geeignet.
Bei der Ansteuerung über PWM mit 1000 Schaltungen/s müsste der maximal mögliche Strom ohne Kühlung sehr weit unter dem Datenblatt liegen. Ist nur die Frage wie weit drunter.......

Ich bin in der FET-Materie auch nicht mehr so tief drin, vielleicht kann sich da nochmal ein Spezi zu äußern.


Gruß
Pf@nne

 

[ext23]

An einer LAN Version hätte ich auch Interesse.
Eventuell lässt sich ja in die Software/ESP noch ein W5100 oder ein ENC28J60 anflanschen.
Dann würde z.B. wenn LAN einen Link bekommt das WLAN deaktiviert. So ist das bei vielen der günstigen WebCams.
WLAN ist eben nicht LAN wenn es um die Verfügbarkeit geht.
(Ich habe z.B.: tageszeit- und witterungsabhängig sporadische Aussetzer bei meinem Mediaplayer)

Sehe ich ganz genauso WLAN ist eine Krücke, und das noch nach Jahren, außerdem bin ich auch kein Freund der Strahlung Von der Sicherheit mal ganz zu schweigen.

[mrpj]

Hi,
Ich antworte mal kurz

1kHz ist sehr gut, wenn er das sauber schafft bei 5 Kanälen gibt es da nichts zu meckern. Bei 1kHz sollte man aber EMV beachten, also Widerstände vor die MOSFETs in entsprechender Dimensionierung um die Flanken etwas abzuflachen.

1khz macht er ohne Probleme mit - ich hatte jetzt nur gestern bei meinem billig Netzteil Zuhause feststellen müssen, dass es bei 1khz das surren anfängt. Wenn wieder etwas mehr Zeit vorhanden ist, messe ich das nochmal mit vernünftigen Geräten.

Beim testen mit 200hz war das Netzteil ruhig.

Btw. ich hätte allgemein noch ein paar Feature Requests für die Software Entwicklung:

- SSL für die Kommunikation
- Eventuell WLAN via Radius

Diese Punkte schiebe ich weit hinten an und sehe ich mehr als ein NiceToHave an.
SSL: hängt von dem verwendeten (Web)server/MQTT Clienten ab.
Wlan und Radius direkt von dem SDK des Herstellers (espressif)

- IR Empfänger (Um normale IR Fernbedienungen weiter zu nutzen (WAF))

Bei einem Vorschlag wie mit den übrigen vorhanden IOs das ganze integriert werden kann, erweitere ich das Layout. (Insofern die Maße von 50x50mm nicht überschritten werden und die Komponenten optional bleiben).
Softwaremäßig gebe ich diese Funktion aus der Hand

Gibt es eigentlich das ganze auch als LAN Version?

An einer LAN Version hätte ich auch Interesse.
Eventuell lässt sich ja in die Software/ESP noch ein W5100 oder ein ENC28J60 anflanschen.

Sicherlich nice to have - aber ich möchte mich damit nicht auch noch auseinander setzen  . Aber da die LED Bibliothek und die "Firmware" getrennt entstehen - steht einem Fork ja nicht viel im Weg oder?

Die verwendeten MOSFETs sind zwar LL (LogicLevel) aber die direkte Ansteuerung mit einem GPIO sehe ich da auch noch nicht.

Nochmals das Datenblatt:
http://www.irf.com/product-info/datasheets/data/irlz44n.pdf

Die Lasten von LED Streifen sollten kein Problem sein.
Wenn ich nun 5A annehme, dann habe ich 0.3V (DS); Sprich ich hab eine Abwärme von 0.3V&5A = 1.5W

Wenn ich nun die Maximal Wärmewiederstand zur Umwelt von 62C/W annehme, dann kriegt der Mosfet 93Grad über Umgebungstemperatur. - Bleibt also definitiv unter seinen 170 Maximalspezifikation.

[ext23]

Ich bin in der FET-Materie auch nicht mehr so tief drin, vielleicht kann sich da nochmal ein Spezi zu äußern

LogicLevel ist aber nicht gleich LogicLevel, da musst du aufpassen, 5V ist auch LogicLevel.

Also bei meinem RGB Board habe ich mal 20 A gestestet, die Dinger wurden nicht mal pupwarm. Das Einzige was warm wurde waren die Leiterbahnen die langsam das Rauchen angefangen haben Aber ich habe auch andere verwendet.

Ansonsten ist ein Treiber mit Sicherheit immer besser, aber ich hatte kein Platz mehr auf meinem Board. Und ich glaube bei den Strömen über die wir reden oO Der Großteil hier wird eh irgend welche LED billig Ware aus China verwenden weil man keine Lust hat 160 Euro für 5 Meter Osram LED Band zu bezahlen. Von daher liegt der Verlust noch an ganz anderen Stellen Ansonsten stimmt das natürlich, man sollte schon Energie sparen wo es nur geht.

Sollte man wirklich hohe Ströme schalten, dann rate ich immer Tempfühler bzw. Temp Sicherungen an die MOSFETs zu klemmen. Wenn die Hütte erst mal brennt ist es zu spät.

[mrpj]

Zum Thema Maximal - Verweiss ich ganz Dezent dass ich schon in Github geschrieben habe, dass ich maximal ~4.5A pro Kanal vorschlage 
(https://github.com/patrickjahns/esp_rgbww_controller/tree/v1.1#esp8266-wifi-rgbww-led-dimmer)

Dann aus eigener Erfahrung:
Ich nutze das Board gerade mit 5x IRLZ34N - 1 RGB 5050 und 1 Weiss 0603 stripe
Die Mosfets werden dabei nichtmals handwarm ....
Der IRLZ34 verkraftet weniger Strom als der IRLZ44, also sollte da sogar noch mehr Spielraum nach oben sein

Ich kann heute Abend nochmal den Strom messen (Wieviel Pro Kanal und Insgesamt)

Und beim Controller Layout - irgendwann ist auch auf der Leiterplatine Schluss - die Leiterbahnen der einzelnen Kanäle sollten ohne bedenken 10A abhaben können - bei der gemeinsamen Masse wird es kritischer - da würde ich nicht mehr als insgesamt 30-40A 20-30A fließen lassen.

Aus den Leiterbahnen und den Mosfet Daten sind die 4.5A für mich als Safe enstanden.
Oder gibt es Einwände? (z.B. etwas außer acht gelassen?)

LogicLevel ist aber nicht gleich LogicLevel, da musst du aufpassen, 5V ist auch LogicLevel.

Siehe Datenblatt - der IRLZ ist voll ab 2.5V gesättigt - mit den 3,3V die wir vom ESP haben ist das Gewährleistet. (Vorrausgesetzt man bekommt keine gefälschten aus China - ist mir passiert.)

Ansonsten ist ein Treiber mit Sicherheit immer besser, aber ich hatte kein Platz mehr auf meinem Board. Und ich glaube bei den Strömen über die wir reden oO Der Großteil hier wird eh irgend welche LED billig Ware aus China verwenden weil man keine Lust hat 160 Euro für 5 Meter Osram LED Band zu bezahlen. Von daher liegt der Verlust noch an ganz anderen Stellen Ansonsten stimmt das natürlich, man sollte schon Energie sparen wo es nur geht.


Sollte man wirklich hohe Ströme schalten, dann rate ich immer Tempfühler bzw. Temp Sicherungen an die MOSFETs zu klemmen. Wenn die Hütte erst mal brennt ist es zu spät.

Wenn man einen extra Treiber verwenden möchte, kann man auch gleich die FETs austauschen und einen Treiber nehmen der z.B. die 12V schalten würde. Gibt günstigere MOSFETs als die IRLZ44. Ich hab für mich die "direkte" Steuerung gewählt. Sparrt Bauteile - wenn aber gewünscht ist und jemand einen passenden Treiber + FETs raussucht, kann man das Layout noch umändern

Bezüglich dem Wiederstand vor dem Gate - ich sehe ihn nicht als nötig, da wir nur die FETs ansteuern und die Umladelast sehr klein ist.
Aber es tut mir nicht weh noch 5 120Ohm Wiederstände einzubauen. (Der ESP liefert maximal 14mA pro Pin)

Aber da würde ich gerne nochmal einen Testaufbau machen um zu sehen inwiefern es Auswirkungen hat.

mMn würde der Wiederstand nur als Schutz für den ESP dienen, viel enstören tut er nicht.

[mrpj]

Heya,

Ich greif diese beiden Punkte nochmal auf: SSL, Radius

- SSL für die Kommunikation

Der ESP SDK (espiff SDK) bietet keine server library für SSL an. Es ist möglich ausgehend Verbindungen via SSL zu benutzen. (z.B. einen webserver aufrufen um daten zu laden), aber ein Server ist bisher nicht implementiert.

Ich persönlich sehe nicht die Notwendigkeit für SSL - Um die Sicherheit im eigenen Heimnetzwerk zu erhöhen, ist SSL die falsche Stellschraube.


Der Controller bietet von sich aus 2 Sicherheitsmerkmale:
- Im Accesspoint Modus kann das Netzwerk mit WPA2-PSK gesichert sein
- Die OTA Webseite ist nur erreichbar, wenn der ESP mit einem AccessPoint/Router verbunden ist
- Die OTA Webseite kann zusätzlich mit einem Passwort gesichert werden*

*) Wenn der Angreifer sich schon im Heimnetzwerk befindet, könnte er es auslesen. Aber mal ehrlich, wenn der Angreifer schon im Netzwerk ist, ist der RGBW Controller die geringste Sorge 

- Eventuell WLAN via Radius

Fällt flach, solange - der SDK von espressif  kein WPA Enterprise unterstützt

[ext23]

Naja wie leicht man in WLANs kommt muss man ja niemanden erklären. Vor allem wenn man sein Key nicht öfter mal ändert... Und das ist ein Spass bei vielen WLAN Geräten wenn man kein WPA Enterprise hat. Die WPA Keys lassen sich auf den Geräten ja wunderbar auslesen, da reicht ein kleiner Trojaner

Aber mei, nicht jeder benutzt wie mein Nachbar sein Zunamen als WPA Key, aber er rafft es nicht obwohl ich schon 10 schwarze Seite auf seinem Tintenspritzer gedruckt habe oO, also stimmt schon.

Aber gut wenn man tagtäglich mit zu tun hat wird man wohl etwas paranoid

/Daniel

[Porky666]

Off Topic
Daniel bestaetigt den Eindruck und mein Bild von Ihm.
no more words.

[herrmannj]

Last uns nicht abschweifen bitte.

Hier gehts um den controller - ein aufregendes Projekt finde ich.

vg
joerg

[mrpj]

Hallo zusammen,

ich hab jetzt mal kurz den Code (HSV2RGB & Farbkorrektor)  etwas gesäubert und in dem dev-branch auf Github geschoben

https://github.com/patrickjahns/RGBWWLed/tree/dev-v0.1

Anmerkung: Nach herumexperimentieren mit verschiedenen Rechenmodellen bin ich wieder bei einer einfachen IF/ELSE Abfrage für die Sektoren gelandet. Es gibt sogesehen 7 Grenzen - 6 Wertebereiche. Die 24byte Speicherbedarf dafür sind effektiver geutzt als komplexe Rechenmodelle 

@ Joerg
Ich bräuchte mal kurz deine Meinung wegen der Gamma/Helligkeits Korrektur:

Ich hatte bei RGB (ohne W) keinen Unterschied sehen können, wenn die Helligkeits Korrektur vor bzw. nach der Berechnung der Werte statt findet.


Warum würdest du nur die Korrektur auf Value ansetzen? Die Sättigung ist doch auch nicht Linear?
Oder hab ich da einen Denkfehler?

Im Moment berechne ich die Werte nach der Rechnung von der Englischen HSV Seite

Das entspricht dem von dir bisher genannten Vorgehen - erst werden die jeweiligen Farbanteile berechnet und zum Schluss der Weißanteil (m) auf R,G,B addiert.






SSL+Wifi Diskussion
Ich hatte es vorher schon geschrieben, dass es Limitationen vom SDK gibt.
Diskussion zu WPA Enterprise im ESP
(Siehe: https://github.com/esp8266/Arduino/issues/1032 und http://www.esp8266.com/viewtopic.php?f=6&t=1243&start=28)

Wenn die Dringlichkeit dieser Aspekte für jemanden sehr hoch ist, dann schlage ich vor, dass er sich daran macht, das Projekt zu Forken und es zu implementieren und dann der Community zur Verfügung zu stellen. Meine Augenmerkt ist im Moment auf zentraleren Funktionen (Led Ansteuerung, Einbindung) und alles was sich außerhalb diesen Dimensionen bewegt kommt auf eine "Vielleicht" Liste von mir.


Hardware Modifikationen
Für mich primär ist gerade wichtig, dass die Funktionalität von 5 PWM Kanälen für die Ansteuerung von LED Streifen via Wifi gewährleistet ist. Falls Erweiterungen gewünscht werden, dann wäre es mir wichtig, einen konkreten Vorschlag für die Umsetzung zu bekommen 
(z.B. ich hätte gerne Z - dafür musst du GPIO A mit einem pull down versehen und auf eine Stifleiste nach außen führen.....)
Wenn die Modifikation mit der Grundfunktionalität vereinbar ist, dann kann ich das gerne in der Bestellung berücksichtigen. Falls die Modifikation aber wesentlich mehr ändert muss es auf eine Extra Ausführung verschoben werden.

Im Moment ist nur noch 1 GPIO frei - der ADC GPIO kann eventuell noch genutzt werden - GPIOs die für den Boot process pull ups/downs haben, könnten verwendet werden - wenn jemand eine entsprechende Logik/Schaltung entwirft. (Diese muss aber Gewährleisten, dass der ESP im "Normalbetrieb" ohne manuelle Eingriff startet).

[herrmannj]

boah, ich bin kurz raus

das aufaddieren von W (m) ist ja nur notwendig wenn es ein RGB gemischtes Weiß ist.
Die Sättigung (in HSV) ist schon linear.

Um die logarithmische Helligkeitskorrektur anzuwenden gibt es ja grundsätzlich zwei Stellen:
Vor dem HSV2RGB(W) auf dem V Kanal oder danach auf jedem Kanal einzeln.

Wenn man das danach macht passieren aber zwei Sachen. Im Modell steigt (Sektor 1) ja grün linear an. Wenn man die Korrektur auf die einzelnen Kanäle anwendet wäre der Anstieg (hier GRÜN) nicht mehr linear sondern logarithmisch. Das führt zu einem breiteren ROT und schmalerem GELB. Dazu kommt das bei Mischfarben (bsp unkorrigiert 80%ROT, 20%GRÜN) ein reiner fade über die Helligkeit die relativen Farbanteile verändert. Damit verändert sich bei einem V-fade auch die Farbe.

Daher sehe ich die Korrektur vor dem HSV2RGB, also im HSV und dort nur auf dem V Kanal.

vg
joerg

[bloodybeginner]

Hi,

wo ich bei den ganzen Thread noch nicht so richtig durchblicke, für welchen Typ von LED Stripes ist denn nun die BastelPlatine geeignet?
RGBWW
RGB
WW
oder gar alle drei Varianten (natürlich mit Einschränkung)

//bb

[mrpj]

So mal kurz den Hauptthread ergänzt:

Die "Hardware" des Controller stellt folgendes bereit:

• 5 Ausgänge zur Ansteuerung von LEDs via PWM (Primär gedacht als RGB, WarmWeiss und KaltWeiss*

*) Eine Änderung/Modifikation ist via der Firmware + Ansteuerung möglich - primär wird aber für RGB+W+W entwickelt



Beudetet - alles 3 ist möglich, sogar mehere Kombination.
Hauptfokus für mich liegt aber gerade auf RGBW (Wobei W aus kalt und WarmWeis gemischt wird).
Es ist später alles nur eine Frage der Erweiterung der Firmware/RGBWWLibrary um andere Funktionalität zu ermöglich.
(Es wird immer möglich sein, jedem Kanal "manuell" eine bestimmte Helligkeit zu geben - bedeutet theoretisch wären auch 5 Weiße Stripes möglich)

[mrpj]

Zur hardware hab ich im anderen Thread schon was geschrieben - hab nen paar Sachen die letzten Tage nochmals getestet (auch aus Anregung der Gespräch zu Mosfets von hier)


Zur Software:
Mir hat dadurch die Zeit gefehlt viel weiter zu machen, aber ich hab mir noch ein paar Gedanken gemacht:
- die Library wird eine "AnimationsQueue" erhalten - Wechsel zu einer anderen Farbe ist nichts mehr als eine Animation; Effekte sind eine "besondere" Animation
- wenn intern schon eine Queue verwendet wird, dann kann man diese gleich nach außen zur Verfügung stellen -> man kann z.B. mehrere Farbwechsel in Auftrag geben die dann nacheinander abgearbeitet werden. In abstrackter Form sind so einfache Effekte auch vom Benutzer programmierbar über die API (für komplexeres kann man sich ja noch überlegen wie es implementiert werden kann)

Ich suche gerade aber nach einem Weg, wie man in C++ mit Structs/Unions und Klassen das am einfachsten implementieren kann, ohne den Speicher des ESP gleich zum überlaufen zu bringen.

Ideen? Vorschläge?

@Joerg

Du hattest doch einen Code zur Weißkorrektur für RGB, kannst du mir den mal zukommen lassen?
Falls du anderen Code/Codefetzen hast, die hilfreich sind für Animationen/Effekte dann auch gerne weiterleite - ich schaue dann mal was/wie ich das implementieren kann

[kadettilac89]

Hallo,

ich verfolge das Projekt schon eine Weile. Hört sich sehr gut an und ich finde es auch sehr gut dass du eine Sammelbestellung auf die Beine stellst.

Wie  ich lese ist aktuell noch nicht implementiert das Modul in eine bestehendes Wlan mit WPA2 Verschlüsselung zu hängen. Die Einschränkung ist aber nur softwareseitig oder? Dann ist es nur eine Frage der Zeit.