LED dimmen mal anders

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!

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.

@ 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

}

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:
> 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

}

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.