Hallo! LEDs zu dimmen (und faden bei RGB) ist an sich ja was ganz einfaches. Für die meisten Fälle reichen 12 oder 16 Bit PWM. Bisher habe ich das immer mit einem Mosfet pro Farbkanal und einem Arduino für das PWM realisiert. Das PWM zerhackt das Leuchten der Dioden ja einfach entsprechend schneller als man schauen kann (paar hundert Hz reichen, dazu später mehr). Allerdings könnte man doch genauso einen Transistor nutzen um den Strom durch die LEDs zu regeln. Dazu wird ein DAC an das Gate des für einen Farbkanal zuständigen Mosfet angeschlossen, über das Ausgangssignal des DAC lässt sich dann der Strom regeln. Das habe ich so bei mir gerade testweise aufgebaut und es funktioniert ganz gut. Allerdings wird der Mosfet relativ warm, wenn man auf bspw. halber Helligkeit verweilt. Wenn man auf dieses Signal jetzt noch eine PWM aufmoduliert, verliert man doch quasi garkeine Farbauflösung auch bei geringeren Helligkeiten, oder? Man könnte also immer mindestens einen Kanal auf 100% Tastverhältnis laufen lassen, und die Helligkeit nurnoch über den Strom regeln. Hintergrund ist, dass das menschliche Auge sehr hohe Dynamische Reichweite hat, da Helligkeit ja generell logarithmisch wahrgenommen wird. PWM erlaubt zwar bei 16 Bit 65536 Stufen, die sind aber linear verteilt. Dann hat man bei hoher Helligkeit zu viel Auflösung (man sieht nichtmal Sprünge um 100 Stufen, bspw. von 65436 auf 65636), bei geringer Helligkeit jedoch zu wenig Auflösung, sodass man einzelne Stufen klar erkennt. Wenn dann noch Farben gemischt werden oder gefadet werden soll, stößt man leicht mal an diese Grenzen. Die Stromregelung hat natürlich auch Grenzen, vor allem Thermische. Bei der popligen 36W-Leiste werden die Mosfets schon unangenehm heiß. Für einen 200W+ Aufbau bräuchte man da schon entsprechend Kühlung. Als Ersatz für die Stromregelung könnte man natürlich auch einfach eine viel schnellere PWM (zwecks Vermeidung von Interferenz mit den farb-PWMs) nehmen, die auf alle Farbkanäle wirkt. Dazu hab ich aber noch nichts gescheites gefunden. Gibt es ICs die sowas können? PWM über ~10 KHz mit 8 oder 10 bit Auflösung? Die nächste Sache ist, dass die oben genannten paar hundert Hertz nur nicht stören, wenn sich nichts bewegt. Falls die LEDs die einzige Lichtquelle im Raum sind, ergibt das einen wunderschönen Stroboskopeffekt. Ein sich mit 5m/s bewegender Gegenstand (schnelle Handbewegung oder so) leuchtet bei 500Hz PWM-Grundfrequenz dann jeden Millimeter einmal auf. Das ist deutlich sichtbar. Ich frage mich nun, ob es vielleicht nicht schon fertige Lösungen für meine Problemchen mit LED Dimming und Fading gibt, oder ob ich tatsächlich der einzige bin der dieses Geflacker bei geringer Helligkeit überhaupt bemerkt. Habt ihr da viellecht Ideen?
Wie du vom 'Gate des Mosfet' an den DAC gehen willst ist mir schleierhaft, ich will es lieber auch gar nicht wissen ... Aber, wenn du nur den Strom regelst wirst du den Effekt feststellen, das die LED ausser der Helligkeit auch die Farbe ändern. Wenn deine Mosfet bei den 3A pro Kanal schon heiss werden sind es entweder die Falschen oder die Ansteuerung ist zu lahm. Ein Schaltplan ersetzt hier 1000 Zeilen Prosa!
Obba schrieb: > Als Ersatz für die Stromregelung könnte man natürlich auch einfach eine > viel schnellere PWM (zwecks Vermeidung von Interferenz mit den > farb-PWMs) nehmen, die auf alle Farbkanäle wirkt. Dazu hab ich aber noch > nichts gescheites gefunden. Gibt es ICs die sowas können? Ja. z.B. der PCA9633 von NXP. Siehe hier: http://www.nxp.com/products/power-management/lighting-driver-and-controller-ics/i2c-led-display-control/4-bit-fm-plus-i2c-bus-led-driver:PCA9633D16?fsrch=1&sr=2&pageNum=1
Wow, da hat einer entdeckt dass Transistoren gesteuerte Stromquellen sind. Dein Problem ist schlüssig, die logarithmische Kennlinie des Auges deckt sich nicht mit der ungefähr linear verlaufenden Helligkeit bei PWM Dimmung. Also willst du einen Konstantstrom fließen lassen und darauf dann noch ne PWM. Wäre es nicht besser wenn du mehrere µC Pins und Transistoren kombinierst um einfach auf mehr Stufen Auflösung zu kommen? Den der Wirkungsgrad leidet bei deiner Lösung dann doch stark. Sag mal was über deine Anforderungen.
Naja, also im Widerstandsbetrieb wäre es komisch, wenn die Fets nicht warm werden, die 3A sind wohl der maximal Strom. 500 1/s und 5 m/s sollten die Hand jeden cm aufleuchten lassen, nicht jeden mm ;) Um den Strom linear zu regeln brauchst du auch ne lineare Stromquelle und da fällt viel Verlustwäre an. Alternativ musst du ne Schaltung aufbauen, wo du mit nem kleinen Widerstand (1/10 Ohm oder so) eine Spannung abgreifst, die über einen OP verstärkst und auf eine Feedback Spannung zurück gibst, die das Tastverhältnis für die Stromquelle einstellt. Wird oft bei Buck-Konvertern so gemacht, um neben der Spannung den Strom regeln zu können. Das ist allerdings deutlich aufwändiger als mit PWM ein Mosfet zu schalten.
@ Christian: Perfekt, genau sowas brauch ich! Danke für die Empfehlung. Mal sehen ob ich das SMD gelöte hinbekomme, diese SO-Gehäuse(?) sind doch ein wenig fummliger als DIP. @ Sascha: Das mit der Konstantstromquelle ist schon eine feine Idee, gell? Zu den Anforderungen: Es sollen 24V-LED Streifen mit jeweils 4 Kanälen betrieben werden (RGBW). Bei ca. 20W/m und 10m wären das 200W zu Schalten insgesamt. Ich werde dabei allerdings 5m mit Warmweiss und 5m mit Kaltweiss ordern, deshalb brauche ich 5 Kanäle. Aber das ließe sich ja einfach erweitern wenn man mal einen Kanal designed hat. Im Moment hab ich hier einen Arduino DUE liegen, von dem ich noch nicht wirklich weiß, wie die Register zu manipulieren sind damit der auch die volle Pracht seiner 84Mhz und 32 Bit im PWM Betrieb zeigt. Der Nano der daneben liegt hat für den 16 Bit Timer leider nur 2 Compareregister, aber zum experimentieren reichts. Da kommen mit 16Mhz Takt dann leider nur 244Hz PWM raus, das gefällt mir nicht. Ja und dann hab ich noch zehn IRF3708 hier liegen, die bei den 3.3V die der DUE ausgeben kann auch brav schalten. @ Tom: Also da ich kein studierter E-techniker bin, tu ich mir mit den OPVs doch ein wenig schwerer, da klingt PWM schon besser :) Wegen der Linearität: Dazu hätte ich mir einfach ne Photodiode geschnappt, jede LED-Farbe einzeln vermessen (die fangen bei unterschiedlichen Strömen an zu leuchten) und aus den Werten jeweils eine Lookup-Table gebastelt, sodass ich mir keine Gedanken machen muss was die Schaltung überhaupt macht. Die einzelnen Farben kann ich ja nachher noch mit dem Luxmeter vom Smartphone normieren. Ich denke, dass das Problem mit dem PCA9633 so ziemlich perfekt gelöst ist, dann verbrate ich auch keine 150W in den MOSFETs. Vielleicht finde ich ja noch nen Weg das als DIP zu bekommen... aber die Teile sind ja billig da kann ich auch gut und gern 5 kaputt löten bevor es mal klappt ;) Oder hat jemand nen besseren Vorschlag? P.S.: Die Streifen wären die hier: http://de.aliexpress.com/item/New-arrival-RGBW-LED-strip-waterproof-24V-5050smd-60LED-m-5m-Roll-RGBW-LED-strip-light/32258292361.html?isOrig=true#extend
Obba schrieb: > 84Mhz und 32 Bit im PWM Betrieb Bleiben 19Khz bei 32bit. Trotzdem: Kanone -> Spatz 10bit / 100Hz reicht für RGBWW aus. 5 Kanäle oder mehr kann man sich per PDM erzeugen, dafür bedarf es auch keinen sonderlich schnellen Controller. https://en.wikipedia.org/wiki/Pulse-density_modulation PCA9633 >Each LED output has its own 8-bit resolution (256 steps) fixed frequency 8bit sind für Farbverläufe sehr grob, da sieht man die Sprünge.
Mit 84MHz und 32 Bit sind das 19mHz und nicht 19kHz, das wäre etwa eine Minute. Mit 16 Bit käme man immerhin auf ~1,28kHz, das wäre doch schonmal was. PDM ist keine schlechte Idee, damit wäre das Geflacker zumindest weniger regulär. Ich glaube trotzdem, das der globale Dimmer im 100kHz Bereich die beste Lösung ist, da in dem Fall immer eine der Farben auf 100% Tastverhältnis laufen kann und dann zumindest diese eine Farbe nicht flackert (und der globale Dimmer so schnell ist, dass man ihn eh nicht flackern sieht). Das Problem mit PDM ist ausserdem dass ich keine Ahnung hab wie man sowas realisiert. Die Arduinos können zwar Hardware PWM, PDM müsste man allerdings per Software machen, und da ist mit viel Glück vielleicht ein zehntel des Taktes drin. Die 8Bit mit 97 kHz würde ich an sich ja auch mit dem DUE hinbekommen, da wären sogar 328kHz möglich. Nur würde das halt mit den 16Bit Farbkanälen interferieren da alles von der selben clock kommt... Naja werde ich wohl einfach ausprobieren müssen... @blubber: Sorry, hatte deinen Post übersehen. Zum DAC+Gate: Dazu hab ich einfach einen Signalgenerator (Analog Discovery 2, hat nen 14 Bit DAC) an das Gate des MosFET angeschlossen. Die Spannungsquelle für die LEDs hing entsprechend an Drain und Source. Dazu wird eine 0.1Hz Dreieckswelle (0-5V) erzeugt und die LEDs leuchten periodisch auf. In der Schaltung verhält sich der MosFET dann ja an sich wie ein regelbarer Widerstand, oder? Schaltplan ist angehängt.
Obba schrieb: > Mit 84MHz und 32 Bit sind das 19mHz und nicht 19kHz, das wäre etwa eine > Minute. Ups, das minus im exponenten übersehen. Obba schrieb: > Mit 16 Bit käme man immerhin auf ~1,28kHz, das wäre doch schonmal was. Alles unter 17Khz pfeift wie hulle. Obba schrieb: > Das Problem mit PDM ist ausserdem dass ich keine Ahnung > hab wie man sowas realisiert. Das habe ich mal vor Jahren für einen 24Mhz Silabs 8051 geschrieben. In PDM_DATA[x] liegt der jeweilige Sollwert der LED. Der Vergleichswert wird weiter unten hin und herspringend erzeugt um das PDM Muster zu bekommen. Hier 9bit (die magic number 0x0200) mit 100hz Wiederholrate
1 | //-----------------------------------------------------------------------------
|
2 | // T0_ISR = PDM Routine, alle 10us
|
3 | //-----------------------------------------------------------------------------
|
4 | void Timer0_ISR (void) __interrupt (1) |
5 | {
|
6 | unsigned char i; |
7 | |
8 | //ws
|
9 | if (PDM_DATA[0] > PDM_VGL) P0_0 = 1; |
10 | else P0_0 = 0; |
11 | |
12 | // denn obigen zweizeiler beliebig oft wiederholen für beliebig viele ausgänge
|
13 | |
14 | if (!PDM_VGL) // Check ob Zyklus vorbei ist |
15 | {
|
16 | PDM_VGL = 0x200; // Startwert wieder herstellen |
17 | time_10us_flag = 1; // Flag für RS485 Failcounter |
18 | if (RX_COMPLETE) // Übernehme RX Daten , wenn vorhanden |
19 | {
|
20 | for (i=0; i<=3; i++) |
21 | {PDM_DATA[i] = RX_DATA[i];} |
22 | RX_COMPLETE = 0; // RX_DATA[] wieder für Empfang freigeben |
23 | }
|
24 | }
|
25 | else
|
26 | {
|
27 | if (TOGGLE_VGL) |
28 | {
|
29 | ///PDM_VGL = 0x200; // Complement MSB
|
30 | if (PDM_VGL & 0x0200) {PDM_VGL &= 0x01FF;} // MSB = 0 |
31 | else {PDM_VGL |= 0x0200;} // MSB = 1 |
32 | TOGGLE_VGL = 0; // Beim nächsten Durchlauf Decrementieren |
33 | }
|
34 | else
|
35 | {
|
36 | if (PDM_VGL & 0x200) // Check ob MSB 1 ist |
37 | {
|
38 | -- PDM_VGL; // Decrementiere |
39 | PDM_VGL != 0x200; // MSB wieder herstellen |
40 | }
|
41 | else { --PDM_VGL;} // Decrementiere, MSB war schon 0, muß icht wieder hergestellt werden |
42 | |
43 | TOGGLE_VGL = 1; // Beim nächsten Durchlauf MSB Toggeln |
44 | }
|
45 | }
|
46 | |
47 | }
|
Obba schrieb: > Dazu wird ein DAC an das Gate des für einen > Farbkanal zuständigen Mosfet angeschlossen, über das Ausgangssignal des > DAC lässt sich dann der Strom regeln. Die Schaltung ist Unsinn, weil der Strom, der durch den MOSFET bei vorgegebener Gate-Spannung fliesst, von Spannung, Temperatur und Laune des MOSFET abhängt. Du REGELST nicht, sondern du STELLST bloss (irgendetwas ein). Zum Regeln müsstet du den Strom auch messen. > Das habe ich so bei mir gerade > testweise aufgebaut und es funktioniert ganz gut. Allerdings wird der > Mosfet relativ warm Ach. Daß eine lineare Strombegrenzung zu Verlusten führt, sollte nicht überraschen. Während also der Rest der Welt gelernt hat, daß es schlauer ist, eine Spannung durch einen Schaltregler runterzuregeln weil der nicht so viele Verluste und damit Wärme erzeugt wie ein Linearregler, meinst du gerade die Weisheit gefunden zu haben, statt PWM endlich wieder unsägliche lineare Strombegrenzung "erfunden" zu haben. Wenn man schon eine LED nicht pulsweise leuchten lassen will, dann setzt man eine Spule davor, die mit ihrer Induktivität den STROM glättet trotz nur ein- und ausschaltendem PWM Transistor. Aber dazu müsste man lernen, wie Spulen funktionieren... Michael K. schrieb: > Das Problem mit PDM ist ausserdem dass ich keine Ahnung > hab wie man sowas realisiert. Oha. Schön, daß man mal die Gründe hört, wie manche Leute zu unsäglichen Lösungen kommen.
Michael B. schrieb: > Michael K. schrieb: >> Das Problem mit PDM ist ausserdem dass ich keine Ahnung >> hab wie man sowas realisiert. Moment mal, das hat Obba geschrieben, von mir kommt der Code. Nicht nur rummotzen sondern wenigstes richtig zitieren wenn Du schon zum Gelingen nichts beitragen kannst.
Ach seid doch mal nicht so negativ... Ich bin halt kein Elektrotechniker, und habe ja auch nie davon gesprochen was neu erfunden zu haben. Dann würde ich das auch nicht in ein Forum posten, sondern zum Patentamt rennen. Eigentlich bin ich mir ziemlich sicher, dass es zu meinem "Problem" schon eine perfekte Lösung existiert. Nur fehlt mir einfach das know-how. Deswegen bin ich hier. Nun zum Thema: Durch anbringen einer Spule hinter den Mosfet ist mir ja wohl nicht geholfen, weil der Mosfet ja einfach dicht macht. Die Spule kann da so viel glätten wie sie will, da wird nix kommen. Oder sehe ich das falsch? Mit PDM ist das so eine Sache, ich hab den Pseudocode von Wikipedia mal implementiert, für 5 Kanäle gleichzeitig ist der DUE allerdings zu langsam. Dafür bräuchte ich dann entweder mehrere DUE oder ich hol mir gleich nen FPGA..? Gibt es nicht vielleicht auch ICs die digital angesteuert werden können (mir schwebt da SPI vor) und ein PDM-Signal ausgeben? Wie gesagt, ich bin kein Elektrotechniker und hab erst recht keine Ahnung von Bauteilen und welcher Hersteller für was bekannt ist. Bisher habe ich nur ein paar Audio-ICs von Linear gesehen, aber ob das das richtige ist? Die Implementierung ist nicht perfekt, da pdm() periodisch aufgerufen werden muss. Mit dem Beispiel-loop funktioniert das aber ganz gut.
1 | int pin = 8; |
2 | double qe = 0; |
3 | |
4 | void setup() { |
5 | pinMode(pin, OUTPUT); //Pin 8 ist Output |
6 | }
|
7 | |
8 | void pdm(double val){ //Nimm ein Sample und führe einen PDM-Schritt aus |
9 | if(val >= qe){ |
10 | g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin; //pin = high |
11 | qe += 1.-val; |
12 | }
|
13 | else{ |
14 | g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin; //pin = low |
15 | qe += -1.-val; |
16 | }
|
17 | }
|
18 | |
19 | void loop() { //mache PDM mit einem Sinus |
20 | for(double i = 0; i < 100000; i+=0.001){ |
21 | pdm(sin(i)); |
22 | }
|
23 | }
|
Obba schrieb: > Oder sehe ich das falsch? Natürlich. Siehe Grundlagen zum Buck step down Tiefsetzsteller. Obba schrieb: > Die Implementierung ist nicht perfekt Floating-Point-Zahlen sind wahrlich nicht perfekt. Der Modulationsalgorithmus wäre ok, wenn für und pdm im exaktem Zeitraster, also aus einem Timer-Interrupt heraus aufgerufen wird.
Obba schrieb: > Allerdings könnte man doch genauso einen Transistor nutzen um den Strom > durch die LEDs zu regeln. Jedenfalls nicht "genau" so gut. Viele der neueren LEDs ändern in Abhängigkeit vom Strom merklich ihre Farbe. Meist wird das Licht mit zunehmendem Strom kurzwelliger, also bläulicher. Diese Farbänderung ist auch der Grund, weshalb man vorzugsweise mittels PWM dimmt, denn bei Verwendung unterschiedlich langer/häufiger Stromimpulse in stets gleicher Höhe ändert sich die Farbe kaum. Geringfügig ändert sich aber auch dabei die Wellenlänge des emittierten Lichts, allerdings in entgegengestzter Richtung, weil sich der LED-Chip je nach Leistung unterschiedlich erwärmt.
Obba schrieb: > Mit PDM ist das so eine Sache, ich hab den Pseudocode von Wikipedia mal > implementiert, für 5 Kanäle gleichzeitig ist der DUE allerdings zu > langsam. Quatsch ! Schau Dir meinen Code an, das hat ein 24MHz 8051 auf einer Backe mit erledigt für 4 Kanäle + eine Menge anderer Aufgaben. Jeder zusätziche Kanal ist nur ein Vergleich zusätzlich. Was zum Geier willst Du mit Float und Sinus Berechnung ? Damit zwingst Du nun wirklich alles die Knie.
Okay, das mit dem Buck Converter ergibt schon ziemlich Sinn. Da ist ja einfach eine Diode über die der Strom nachgezogen werden kann. Ja mir ist schon bewusst, dass der Code nicht hübsch ist. Der Beispielcode mit doubles erzeugt Pulse von etwa 80µs, während mit dem internen PWM Controller theoretisch 11ns drin wären. Selbst wenn man nur 110ns annimmt ist das immer noch knapp Faktor 1000. Dank deinem Tipp hab ich mal auf uint32_t gewechselt, jetzt ist es nurnoch 1µs pro Puls, so kommen wir der Sache schon näher! Trotzdem sehe ich ein Problem darin, dass ich 5 Kanäle habe und die separat aber dennoch gleichzeitig ansteuern werden muss. Es gibt ja immer noch die Hoffnung die internen PWM Controller zum laufen zu bringen und dann zusätzlich den Buck-Converter zu nutzen um die Spannung runterzuregeln. Ich komme nur mit den Registern des DUE nur noch nicht so wirklich zurecht. Falls jemand weiß wie man den DUE zu 16Bit PWM mit 1,2kHz überzeugen kann, ich würde mich über ein paar Tipps freuen :) @Hp M. Ja sowas kenne ich von Laserdioden: https://youtu.be/5PquJdIK_z8?t=20s Der Effekt sollte durch die sich ändernde mittlere Energie des Elektronengases hervorgerufen werden, sodass sich die Bandlücke ändert und die Emittierten Photonen entsprechend weniger Energie haben. Warum sich die Farbe bei verschiedenem Strom ändert verstehe ich nicht ganz, aber das kann auch gut sein. Meine LEDs scheinen allerdings relativ resistent dagegen zu sein. @ Michael: ja, ich arbeite dran ;) Hier noch der verbesserte Code:
1 | uint32_t pin = 8; |
2 | uint32_t qe = 0; |
3 | uint32_t m = 4294967295; //maximalwert |
4 | void setup() { |
5 | pinMode(pin, OUTPUT); |
6 | }
|
7 | |
8 | void pdm(uint32_t val){ |
9 | if(val >= qe){ |
10 | g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin; |
11 | qe += m-val; |
12 | }
|
13 | else{ |
14 | g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin; |
15 | qe -= val; |
16 | }
|
17 | }
|
18 | |
19 | void loop() { |
20 | for(uint32_t i = 0; i < m; i++){ |
21 | pdm(i); |
22 | }
|
23 | }
|
Obba schrieb: > Falls jemand weiß wie man den DUE zu 16Bit PWM mit 1,2kHz > überzeugen kann, ich würde mich über ein paar Tipps freuen :) Wenn dir 12bit reichen: PCA9685 http://www.ebay.de/itm/PCA9685-16-Channel-12-bit-PWM-Servo-motor-Driver-I2C-Module-For-Arduino-Robot-ZE-/121904894266?hash=item1c6219113a:g:q3EAAOSw~OVW0P7I Alternativ implementier dir die PWMs in nem CPLD http://www.ebay.de/itm/MAX-II-EPM240-CPLD-Minimum-System-Core-board-Development-board-/200942149129?hash=item2ec915de09:g:gfkAAOSwg3FUcwR5
Ich hatte mich mal vor geraumer zeit mit dem dimmen von RGB-Strips beschäftigt. Vielleicht helfen diese Links: http://www.mikrocontroller.net/articles/LED-Fading Beitrag "RGB-Farbe dimmen" http://codefactory.dead-men.de/index.php?content=51
Ein Buck wird nicht funktionieren. Ohne Strommessung + Regelung ohnehin nicht, denn ein Buck ist mehr als blind ein / aus. Du hast eine Menge LED Segmente mit Serienwiderstand auf den Strips. Regeln könntest Du mit dem Buck nur die Eff. Spannung für alle LED Segmente. Da VF der LEDs nie gleich ist werden die unterschiedlichen Segmente dann unterschiedlich hell leuchten und auch den Farbort verändern. Zudem hast Du einen relativ großen Spannungsabfall über die Strecke, d.h. die vorderen Segmente sehen mehr Spannung als die hinteren. Das merkt man bei 100% Spannung + PWM nur nicht weil das Auge sich da leicht betrügen läßt. Du legst Dir die Latte auch viel, viel zu hoch auf. 10bit, vieleicht 12bit reichen mehr als aus um keine Sprünge mehr zu sehen. Dein befürchteter Stroposkopeffekt würde auch nur bei drehenden Teilen zum Tagen kommen. Eine schnelle Handbewegung würde nur ruckartig aussehen wenn Du wie wild damit herumfuchtelst. Wie gesagt 10bit / 100Hz und damit habe ich recht anspruchsvolle Kundeninstallationen beleuchtet. Ich bin damals von PWM weg hin zu PDM weil es einen weiteren Effekt gibt der erheblich reinhaut. Du hast eine gemeinsame V+ bzw. GND für alle LEDs. Die PWM Hardware schaltet immer alle zugleich an und dann je nach Sollwert unterschiedlich früh wieder aus. D.H. es gibt einen Zeitpunt an dem ALLE LEDs Strom ziehen und der Spannungsabfall auf dem common dramatisch wird. Dabei verzieht sich die Farbe komplett ins rote weil rot die geringste VF hat. PDM verschleift das über den ganzen Zyklus.
Bitte 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.