Forum: Mikrocontroller und Digitale Elektronik Ansteuern von 300 RGB-LEDs


von Dominique G. (dgoersch)


Lesenswert?

Hallo zusammen,

für eine dekorative Beleuchtung stehe ich vor der Aufgabe etwa 300 
RGB-LEDs anzusteuern. Ziel ist in dem Fall ganz klar die preisgünstigste 
Variante, weil das Projekt an sich schon teuer genug ist.

Meine erste Idee war es, die LEDs in 10er Gruppen mit jeweiles einem 
ATmega16 z.B. anzusteuern und die AVRs mittels UART zu "vernetzen". Ich 
frage mich allerdings, ob es der ATmega16 schafft, 30x Software PWM für 
die 10 LEDs hinzubekommen. 30 Anoden oder Kathoden (LEDs sind mit 
gemeinsamer Anode oder gemeinsamer Kathode verfügbar) zu bestromen 
schafft er ja vermutlich auch nicht selber...

Eine andere Möglichkeit wäre es, PWM-Treiber dafür zu nehmen. Ich habe 
hier ein paar Samples vom TLC5922 liegen. Ich habe den aber bislang noch 
nicht verbaut und habe auch noch nicht erkundet zu welchem Preis er 
bezogen werden kann.

Jemand hier vielleicht noch eine Idee, wie man die Biester möglichst 
"billig" einzeln ansteuern kann? Mehrere LEDs fest zusammen zu fassen 
wäre die letzte Notlösung um am Preis zu schrauben.

Danke und Gruß
Dominique Görsch

von avr (Gast)


Lesenswert?

Mit den PCA von NXP sollte das machbar sein.

mit I²C Bus leicht als Module zu verdrahten z.B. der

http://www.nxp.com/acrobat_download/datasheets/PCA9685_1.pdf

Man hat pro Baustein 16 Kanäle a 12 BIT und kann ext.
64 Adressen einstellen.
Klasse ist der Gruppenmode, also z.b. alle roten in eine Gruppe
und mit nur einem Befehl zusammen einstellen.

Wenn 25 mA Sink pro Kanal reichen keine weiteren Treiber nötig.

avr

von Dominique G. (dgoersch)


Lesenswert?

Das "Problem" bei diese 16-Kanal-Käfern ist halt, dass ich davon für 300 
RGB-LEDs stolze 57Stk benötige...

Ich denke ich werd mal im Versuchsaufbau testen ob ich dem mega16 30x 
Software PWM entlocken kann und er dabei noch UART schafft. Das ist wohl 
wirklich die günstigeste Variante mit rund 2 EUR für einen µC pro 10 
LEDs. Wie sähe es denn da mit Treibern aus, was will man da nehmen?

Gruß
Dominique Görsch

von chris (Gast)


Lesenswert?

Suche mal nach led driver rgb bei deine Lieferanten.
TI, Toshiba, ... . 100mA, 16 ports, pwm, spi kosten bei 1k ca 16cent.
Bei 19 Stück ca 42 cent.

von Bingo (Gast)


Lesenswert?


von Falk B. (falk)


Lesenswert?

@  Bingo (Gast)

>Vielleicht kann du bit-angle-modulation brauchen
>http://www.artisticlicence.com/WebSiteMaster/App%2...

Ist auch "nur" eine etwas clevere PWM-Implementierung. Soft-PWM kann 
man aber noch besser optimieren, wenn man weiss wie ;-)

@ OP

Vielleicht ist das was für dich. Mit vier dieser Boards kann man bequem 
324 RGB-LEDs per DMX512 steuern.

Beitrag "LED-Matrix, 9x9 RGB, Voll dimmbar"

MFG
Falk

von Sven P. (Gast)


Lesenswert?

> Bit Angle Modulation (BAM) ist a new LED drive technique
> invented by Artistic License.

Ganz schön vollmundig.

von Hans L. (hansl)


Lesenswert?

Hallo Dominique,

ich wollte schon lang für dieses RGB-Problem einen
Artikel einstellen.

Jetzt habe ich das etwas vorgezogen und auf die Grafik
verzichtet.

http://www.mikrocontroller.net/articles/%22Additive%22_PWM

Mit dieser PWM-(Ab-)Art sollte es gut möglich sein,
kleine MEGA (z.b. 8515) in Slaves für je 8 RGB-LEDs zu
verwandeln.

Gruß Hansl

von Falk B. (falk)


Lesenswert?

@  Hans L. (hansl)

>http://www.mikrocontroller.net/articles/%22Additive%22_PWM

Naja, nicht wirklich ein brauchbarer Artikel. Gedankenfetzen in drei 
Sätze pressen macht keinen Artikel, schon gar keinen guten.

>Mit dieser PWM-(Ab-)Art sollte es gut möglich sein,
>kleine MEGA (z.b. 8515) in Slaves für je 8 RGB-LEDs zu
>verwandeln.

Das ist stinknormale Soft PWM in Assembler, nur mit einer kleinen 
Optimierung, dass die Dekodierung der Ausgänge über das Carry-Bit 
gemacht wird. Mit additiv etc. hat das rein gar nix zu tun.

MFG
Falk

von Hans L. (hansl)


Lesenswert?

@ falk

Das es noch kein fertiger Artikel ist habe ich ja geschrieben.

Mit 2-3 Grafiken die den Signalverlauf zeigen wäre das Prinzip
auch deutlicher geworden.

Mit einer Optimierung der "SOFT-PWM" hat diese Variante nichts zu tun.

Es wird nicht in einem festen Zeitfenster für eine variable
Zeit eingeschaltet, also mit einer festen Frequenz gearbeitet.

Hier bestimmt der Additionswert nach einer festen Zeit ob
eingeschaltet wird oder nicht. Die Signalfrequenz ist wertabhängig,
es gibt auch Signalblöcke.

Man benötigt hier auch keine Sortierung oder CTC-Eigenschaften.

Einfach mal die Ausgabesignale beobachten um das Prinzip zu
verstehen.

Gruß Hansl

von Dominique G. (dgoersch)


Lesenswert?

Ich hab grad mal meine simple 5-Kanal-PWM-Routine für den tiny2313 aus 
der Wolke (http://projekte.dgoersch.info/avr/wolke) aufgebohrt auf 24 
Kanäle. Läuft auf 'nem mega16 bei 8MHz absolut problemlos. In C oder ASM 
würde das sicher noch effizienter gehen als in Basic.

Wenn's mit UART dazu auch noch so sauber geht, habe ich wohl meine 
Lösung gefunden...

von Dominique G. (dgoersch)


Angehängte Dateien:

Lesenswert?

War zu erwarten... die Timer0_ISR ist natürlich viel zu lang, so dass 
UART nimmer geht, schade. Mit dem nächsten kleinsten Prescaler (8) isses 
nur noch Blinken...

von Falk B. (falk)


Lesenswert?

Versuchs mal mit Soft-PWM

von Dominique G. (dgoersch)


Lesenswert?

Falk Brunner schrieb:
> Versuchs mal mit Soft-PWM

Ich bin zwar in C leider nicht sonderlich gut, aber das Ding macht doch 
nix anderes als ich mache, mal davon abgesehen, dass dort die Frequenz 
vorgewählt wird und bei mir die Frequenz so hoch wie möglich ist - was 
die CPU halt hergibt. Oder seh' ich das grundlegend falsch? Da wird doch 
auch nur auf Timer-Basis der Port getoggelt...

von Falk B. (falk)


Lesenswert?

@  Dominique Görsch (dgoersch)

>Ich bin zwar in C leider nicht sonderlich gut, aber das Ding macht doch
>nix anderes als ich mache,

> mal davon abgesehen, dass dort die Frequenz
>vorgewählt wird und bei mir die Frequenz so hoch wie mögoch ist

Was bringt das? 100 Hz reichen.

> - was die CPU hergibt.

jaja, diese Jugend wieder ;-) CPU überlastet aber cool!

> Oder seh ich das grundlegend falsch? Da wird doch auch
>nur auf Timer-Basis der Port getoggelt...

Der "kleine" Unterschied ist die CPU-Belastung. Lies den Artikel mal bis 
zum Ende.

MFg
Falk

P S Die Soft-PWM hab ich schon mal auf 32 Kanäle aufgebohrt, als DMX512 
LED-Treiber. Lief problemlos, und der uC hat noch massig Rechenzeit 
übrig.

MFG
Falk

von MaWin (Gast)


Lesenswert?

> wie man die Biester möglichst "billig" einzeln ansteuern kann?

In dem man moeglichst wenig Elektronik drumrumbaut.

Weder 38 ATMega8515 noch 57 PCA9685.

Statt für jede LED einen Ausgang vorzusehen, sollte man nur für jede 
Zeile und jede Spalte einen Ausgang vorsehen, also Multiplexbetrieb 
machen. Die meisten LED vertragen den 10-fachen Strom fuer 1/10tel der 
Zeit, also werden aus deinen 300 LEDs 30 Spalten a 10 LEDs, oder 10 
Reihen a 10 roten, grünen, blauen LEDs.

Bei 20mA LEDs fliessen also 200mA pro Spalte, pro Zeile 6A, da braucht 
es mehr als den Ausgang eines Microcontrollers oder HCMOS-ICs. Die 200mA 
schafft ein (4) ULN2803, für die 6A sollte man einfach einen richtigen 
Transistor BD224C oder so nehmen, der seinen Basisstrom auch von ULN2803 
bekommt.

Zur Ansteuerung brauchst du 30 Ausgänge (Spalten) und 10 Ausgänge 
(Zeilen), zu dem muss du die 30 Spalten PWM dimmen. Ich geh mal davon 
aus, du willst 256 Dimmstufen, aber du weisst, dass LEDs unterschiedlich 
hell sind und jede einzelne LED in der Helligkeit kalibriert werden 
sollte (blöderweise ist die Helligkeit der billigen LED auch noch 
Blickrichtungsabhängig, es ist also eh immer ein Kompromiss und für 
Videowände nicht geeignet). Für eine Helligkeit kann bei der einen LED 
eine Dimmzeit von 106, bei der anderen von 122 notwendig sein.

40 Ausgangspins sind für viele Microcontroller schon knapp, es kann 
notwendig werden, extern Schieberegister wie TPIC6B595 einzusetzen.

Du musst Software-PWM auf 30 Leitungen machen, der Code besteht aus 
einer engen (aufgerollten?) Schleife, die die Leuchtdauer der einzelnen 
LED mit dem aktuellen Zählerstand vergleicht und dann deren Ausgang 
aktiviert/deaktiviert, das macht man für die 30 LEDs und 256 mal, und 
dann schaltet man Multiplex-mässig um auf die nächste Zeile.

von Dominique G. (dgoersch)


Lesenswert?

Falk Brunner schrieb:
> Was bringt das? 100 Hz reichen.
> jaja, diese Jugend wieder ;-) CPU überlastet aber cool!

Nix, ich war beim schreiben der Routine einfach zu faul Rechenzeit übrig 
zu lassen. Sooo jugendlich bin ich ja nun auch nimmer... ;)

> Der "kleine" Unterschied ist die CPU-Belastung. Lies den Artikel mal bis
> zum Ende.

Ja, werde ich tun.

MaWin schrieb:
> Statt für jede LED einen Ausgang vorzusehen, sollte man nur für jede
> Zeile und jede Spalte einen Ausgang vorsehen, also Multiplexbetrieb
> machen.

Grundsätzlich gebe ich dir da recht, habe mich aber bewusst von 
vorneherein gegen's Multiplexen entschieden. Der Grund ist ganz einfach: 
Es ist keine Matrix, sondern ein Strang von LEDs im Wohnzimmer ringsrum 
an der Wand. Der Verkabelungsaufwand einer "abgerollten Matrix" wäre mir 
einfach zuviel.

Weiterhin geht es tatsächlich um 300 RGB-LEDs, ergo 900 einzeln 
anzusteuernde Elemente, nicht um eine 10x10 Matrix aus 100 RGB-LEDs.


Es soll so in etwa wie in [1] sein, jedoch nicht aus der Schattenfuge 
herab leuchten, sondern von einem Balken der auf 2m Höhe als Kranz an 
der Wand entlangläuft hinauf an die Decke strahlend.

Gruß
Dominique Görsch

[1] http://onlineflvplayer.com/?video=http://www.terjung.net/test3.flv

von Falk B. (falk)


Lesenswert?

@  Dominique Görsch (dgoersch)

>Es ist keine Matrix, sondern ein Strang von LEDs im Wohnzimmer ringsrum
>an der Wand. Der Verkabelungsaufwand einer "abgerollten Matrix" wäre mir
>einfach zuviel.

Logisch. Na dann nimm einen Mega16 und die Soft-PWM aus dem 
Tutorial, auf 32 Bit aubohren (einfach von uint8_t auf uint32_t ändern, 
Interruptroutine anpassen) und schwups kann man mit einem AVR 10 
RGB-LEDs steuern. Davon 30 Stück gebaut macht 300 RGB-LEDs. Kosten 
sollten sich bei 5 Euro/Platine bewegen.

MFG
Falk

von Dominique G. (dgoersch)


Lesenswert?

Nachdem ich erst heute Nachmittag ein paar Stunden damit verbracht habe, 
zu versuchen den C-Code zu Bascom zu portieren - mit mäßigem Erfolg - 
versuche ich es nun direkt mit C. Ich hab den Code aus deinem Link 
genommen (Variante 1 und 2 ersteinmal) und den Port entsprechend 
angepasst. Aber es tut sich nichts, absolut null. Ich kanns problemlos 
kompilieren und flashen, aber die LEDs bleiben aus.

Muss man an dem Code noch weitere Änderungen vollziehen, damit er auf 
einem mega16 statt mega32 läuft?

Gruß
Dominique Görsch

von vlad (Gast)


Lesenswert?

100Hz PWM ist bei LEDs grenzwertig.
150 sollten es schon sein.

Begründung:
leds haben keine engbaute Trägheit. das heißt sie glühen nicht nach.
wenn eine LED mir weniger als 150 Hz pulst und man bewegt seinen Kopf, 
gibt es den so genannten "Perlenschnureffekt".
Besonders oft bemerkt man dies bei LED-Rückleuchten von Fahrzeugen.

wenn die Nachts vor einem Fahren und man schaut nach rechts oder links, 
ist das bei älteren LED-Leuchten enorm störend.

Das kommt daher, das normalerweise das Auge (eigendlich das Gehirn) das 
Licht über eine Weile integriert, wodurch man das flackern ab ca 100Hz 
nicht mehr sieht.  Bewegt sich dieses Objekt aber im Gesichtsfeld 
funktioniert das nicht mehr so gut.
Auch an manchen Beamer fällt das auf, wenn man direkt auf die 
Projektionsöffnung schaut (wenn man daneben, nicht davor, sitzt), sieht 
man einfach weißes Licht. Schaut man aber im Raum hin und her, nimmt man 
oft einen Regenbogen war.

Zu Software-PWM:
das ist nicht wirklich aufwändig, ich hatte das schon mal in nem anderen 
Thread vorgerechnet, dass man für 16 Kanäle (inklusive Multiplexing für 
LED-Matrix) bei 8Mhz ca 3% Rechenleistung braucht.

von Dominique G. (dgoersch)


Lesenswert?

Kaum zu glauben, ich als C-Noob habs geschafft die 3. Soft-PWM-Variante 
aus dem Artikel auf mehrere File aufzuteilen, und Peter Fleurys UART-Lib 
hinzuzufügen.

Was ich leider nicht schaffe ist, den PWM-Part soweit aufzubohren, dass 
ich statt einem drei Ports - und somit 24 Channels nutze. Mit dem 
einfachen ändern der Variablen von uint8_t auf uint32_t wars leider 
nicht getan, danach tats erstmal garnixmehr.

Falk hast du vielleicht einen Tipp, was noch wo angepasst werden müsste?

Gruß
Dominique Görsch

von Fralla (Gast)


Lesenswert?

Es ist lässtig 10 oder gar 30 µC per ISP zu programieren wenn du das 
programm ändern willst. Vielleicht wäre es sinnvoll einen Bootloader zu 
verwenden und die AVRs via UART zu verbinden. (so ala sensor-chain)

MFG

von Jojo S. (Gast)


Angehängte Dateien:

Lesenswert?

ich bastel auch gerade an einer RGB Beleuchtung, d.h. schon etwas länger 
seit ich hier einige Osram Ostar 11W LEDs gekauft habe. Die Ansteuerung 
mache ich mit einer KSQ mit ZXLD1362, die lässt sich über einen 
Steuereingang modulieren. Für diese Powerteile möchte ich aber eine 
256stufige PWM mit 16Bit Auflösung, weniger Stufen sind doch recht 
'unsmooth' wenn es dunkel wird. Ich habe dazu die Hardware PWM mit der 
log. Tabelle von F.B. benutzt. Für einen RGB Kanal würde ich einen 
Mega128 nehmen, der hat ja 3x 16Bit PWM. Oder ein neuer Kandidat wäre ja 
der XMega128A1 mit 6x 16Bit PWM (wenn ich das richtig verstanden habe). 
Klar, der XMega hört sich erstmal wie Overkill an, aber der nackte µC 
kostet ja auch nur ca. 7€ und damit sogar noch weniger als Mega128. Der 
XMega64A1 wäre noch einen € billiger wenn man ihn denn hier bekäme, 
Bezugsquellen wie Farnell oder Mouser sind mit allen Nebenkosten 
deutlich teurer. Der einzige Haken am XMega ist der 0,5mm Pitch, dafür 
müsste man Platinen fertigen lassen.
Ich weiss, die Optimierungskünstler F.B. oder PeDa schlagen da die Hände 
über dem Kopf zusammen, aber ich denke mit dem XMega kriegt man die PWM 
+ Kommunikation schneller sauber hin.
Nur so als Anregung. Im Anhang die Excel Tabelle für die log. Steuerung, 
ich habe noch einen Button eingebaut um die Werte als Includefile in den 
C-Code übernehmen zu können (könnte man auch einfach für ASM oder Bascom 
anpassen). In C nutze ich das dann so:
1
uint16_t pwmtable_10[64]  PROGMEM = {
2
#include "pwmtab64-1024.inc"
3
};

von Dominique G. (dgoersch)


Lesenswert?

Die µC sollen alle über UART "vernetzt" werden. Vom TX des einen auf RX 
des nächsten, usw...

Das Programm wird so aussehen, dass über UART die Werte für die 
angeschlossenen Segmente kommen, und über UART wieder an den nächsten 
gehen. Ich erwarte eigentlich nicht, dass ich an dem Programm nochmal 
was ändern muss. Denn es ist recht simpel:

Ein Controller verschickt die Daten, dabei ist das erste Byte eine 
Adresse. Der empfangende AVR schaut, ob diese Adresse 0 ist, wenn ja 
setzt er die PWM-Werte die in den folgenden Bytes stehen. Ist die 
Adresse nicht 0, wird von der Adresse 1 abgezogen und das ganze wird 
weiter geschicht an den nächsten AVR. So kann ich die AVRs alle einzeln 
adressieren und die PWM-Werte gezielt setzen.

Die Idee ist übrigens nicht von mir, ich habe mich lediglich von 
http://www.ledstyles.de/ftopic7948.html inspirieren lassen und das ganze 
etwas abgeändert (LEDs einzeln ansteuern, mega16 statt mega8, ...).

Gruß
Dominique Görsch

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

@Dominique Görsch (dgoersch)

>Was ich leider nicht schaffe ist, den PWM-Part soweit aufzubohren, dass
>ich statt einem drei Ports - und somit 24 Channels nutze. Mit dem
>einfachen ändern der Variablen von uint8_t auf uint32_t wars leider
>nicht getan, danach tats erstmal garnixmehr.

Naja, nicht ALLE. Die richtigen. Hmmm. Ich geb dir einfach mal meine 
fertige Lösung, da sind noch ein paar zusätzliche Kniffe drin. Siehe 
Anhang.

>Fralla (Gast)

>Es ist lässtig 10 oder gar 30 µC per ISP zu programieren wenn du das
>programm ändern willst.

Das macht man aber nicht. Sinnvollerweise programmiert man erstz alle, 
wenn zwei, drei Prototypen sauber laufen.

> Vielleicht wäre es sinnvoll einen Bootloader zu
>verwenden und die AVRs via UART zu verbinden. (so ala sensor-chain)

Overkill. Heute muss in jedem Firlefanz ne Onlinezugang rein, was?
Wolfgang wirds freuen.

@Jojo S. (jojos)

>Ich weiss, die Optimierungskünstler F.B. oder PeDa schlagen da die Hände
>über dem Kopf zusammen,

Naja, so schnell schlage ich nicht. Da hab ich hier schon DEUTLICH 
unsinnigere Dinge gesehen.

> aber ich denke mit dem XMega kriegt man die PWM
>+ Kommunikation schneller sauber hin.

Ist genehmigt ;-)

>Die µC sollen alle über UART "vernetzt" werden. Vom TX des einen auf RX
>des nächsten, usw...

Grosser Unsinn. Wenn dir die Kette kaputt geht hast du viel "Spass" beim 
Fehlersuchen. Mach es richtig und nimm einen normalen Bus, an dem alle 
Teilenehmer parallel hängen. MAX485 ist deine Freund. Oder meinetwegen 
CAN.

MFG
Falk

von Dominique G. (dgoersch)


Lesenswert?

Falk Brunner schrieb:
> Naja, nicht ALLE. Die richtigen. Hmmm. Ich geb dir einfach mal meine
> fertige Lösung, da sind noch ein paar zusätzliche Kniffe drin. Siehe
> Anhang.

Danke, schau ich mir morgen/nachher mal an.

Gruß
Dominique Görsch

von MWS (Gast)


Lesenswert?

Aufgrund des "zu teuer", denn 50er Stückzahlen lassen sich nun mal nicht 
sampeln, werden 900 Widerstände verlötet.

Bei einer Ersparnis von vielleicht 60 Euro nenn' ich das doch mal ein 
SUPER Geschäft. :D

Hier in diesem Thread:

Beitrag "TLC5922, TLC5923, TLC5924 Ansteuerung für zB Mood Light"

hat Kai einen Treiber für den TCL5922 geschrieben, zwar in Codevision, 
aber sicher auf GCC umstellbar. Wenn man ihn nett fragt, würde er 
vielleicht sogar helfen, möglicherweise hat er auch noch 5922 rumliegen 
und stellt sein Platinenlayout zur Verfügung.

Wobei der MBI5030 von Macroblock noch ein Eck besser wäre, nur schwer zu 
beschaffen.

von Reinhard R. (reirawb)


Lesenswert?

Um nochmal auf das Multiplexen zurückzukommen...

> Grundsätzlich gebe ich dir da recht, habe mich aber bewusst von
> vorneherein gegen's Multiplexen entschieden. Der Grund ist ganz einfach:
> Es ist keine Matrix, sondern ein Strang von LEDs im Wohnzimmer ringsrum
> an der Wand. Der Verkabelungsaufwand einer "abgerollten Matrix" wäre mir
> einfach zuviel.

> Weiterhin geht es tatsächlich um 300 RGB-LEDs, ergo 900 einzeln
> anzusteuernde Elemente, nicht um eine 10x10 Matrix aus 100 RGB-LEDs.

Du könntest ja auch jeden LED-Baustein einzeln ansteuern und nur RGB 
multiplexen. Damit könntest Du z.B. mit einem ATmega16 ohne externe 
Decodierelemente 24 RGB-LEDs komplett ansteuern und hast noch Reserven 
für die Kommunikation. Die Verdrahtung von solch einem Mini-Multiplex 
sollte auch weniger aufwändig sein als eine komplette Einzelverdrahtung 
mit der dreifachen Anzahl an Steuerprozessoren.

> Es soll so in etwa wie in [1] sein, jedoch nicht aus der Schattenfuge
Sieht gut aus, gefällt mir.

Reinhard

von Dominique G. (dgoersch)


Lesenswert?

MWS schrieb:
> Aufgrund des "zu teuer", denn 50er Stückzahlen lassen sich nun mal nicht
> sampeln, werden 900 Widerstände verlötet.

In der Tat ein Punkt, über den ich auch schon mehrfach nachgedacht habe. 
Da das ganze für mich privat ist, hab' ich kein Problem damit, 'ne Woche 
lang Abends Widerstände zu verlöten. Jedoch vielmehr stört mich daran 
die über die Widerstände verbratene Energie.

von MWS (Gast)


Lesenswert?

> Jedoch vielmehr stört mich daran die über die Widerstände verbratene
> Energie.

Die "Constant-Current Sink" laut Datenblatt heist nicht, daß dort kein 
Strom verbraten wird, der wird nur im IC statt im Widerstand vernichtet. 
Bei den Stromsenken geht's nur darum den Aufwand für die Widerstände zu 
sparen.

Mir wäre meine private Zeit zu schade, als daß ich 900 Widerstände für 
die paar Euros verlöten möchte, vor allem in Anbetracht der restlichen 
Kosten.

Dann mal viel Erfolg damit und auf gute Stromzuführung achten, die ca. 
20A wollen gut verteilt werden.

von Henne (Gast)


Lesenswert?

Hallo zusammen,

@Falk:
Du hast die Auflösung ja ziemlich kastriert in dem DMX-Led-Dimmer. Hast 
Du immer noch ein stufenloses Fading?
Ansonsten finde ich die Unions eine gute Idee - ist wahrscheinlich nicht 
ganz eingängig für andere, beschleunigt aber den Zugriff :-)

@Hans:
Wenn ich das richtig sehe, erhält man bei Deinem Code keine konstante 
Frequenz mit einem variablen Tastverhältnis (Definition einer PWM) 
sondern eher einen konstanten Puls mit variabler Frequenz für jeden 
Kanal. Ist es nicht also eher eine Frequenzmodulation oder etwas 
Delta-Sigma-artiges?
(Klingt zunächst philosophisch - könnte aber in Verbindung mit LEDs 
patentrechtliche Folgen haben...)

von Falk B. (falk)


Lesenswert?

@  Henne (Gast)

>Du hast die Auflösung ja ziemlich kastriert in dem DMX-Led-Dimmer.

Warum? Weil dort "nur" 32 nichtlineare Stufen drin sind?

> Hast
>Du immer noch ein stufenloses Fading?

Probiers aus ;-)

Wenn es nicht zu langsam ist, dann auf jeden Fall.

MFG
Falk

von Alex H. (hoal) Benutzerseite


Lesenswert?

Falk Brunner schrieb:
> @  Bingo (Gast)
>
>>Vielleicht kann du bit-angle-modulation brauchen
>>http://www.artisticlicence.com/WebSiteMaster/App%2...
>
> Ist auch "nur" eine etwas clevere PWM-Implementierung. Soft-PWM kann
> man aber noch besser optimieren, wenn man weiss wie ;-)

Bezieht sich deine Antwort auf die im Soft-PWM-Artikel beschriebenen 
Optimierungen, oder meinst du etwas darüber hinaus gehendes?

von Falk B. (falk)


Lesenswert?

@  Alexander Horst (hoal)

>Bezieht sich deine Antwort auf die im Soft-PWM-Artikel beschriebenen
>Optimierungen,

Ja.

Aber ich bin offen für weitere Verbesserungen.

MFG
Falk

von Henne (Gast)


Lesenswert?

Zur BAM:

Hat nicht das geringste mit PWM zu tun vom Algorithmus her. Die 
Implementierung ist in der Praxis allerdings deutlich frickeliger als in 
öffentlichen Papers dargestellt. Bei einer einzelnen LED fällt es nicht 
auf - aber schließt mal ein Panel >15W an...

Zur additiven PWM / Carry-PWM:

Ich habe den Algorithmus gestern Nacht auf einem Spot mit ca. 30W 
implementiert. Durch das delta-sigma ähnliche Verhalten gibt es - gerade 
bei größerer Helligkeit - kein Flimmern. Die Geschichte scheint bei 
sinnvoller Wahl der Basisfrequenz auch videofähig zu sein. Allerdings 
ist die Sache nicht im Mindesten performant. In größeren Firmwares oder 
auch nur bei mehreren Kanälen kann man nicht für jeden ch 2Register 
verbraten. Die Zugriffe auf das SRAM kosten selbst bei 
Assembler-Implementierung sehr viel Zeit. Auf Grund dieser Skalierung 
wird der Algo relativ schnell unbrauchbar. (Bei einer Implementierung in 
HW sieht das bestimmt wieder anders aus...)

Zur (Soft-)PWM:
...dank Philips / Colorkinetics ein Minenfeld und verbrannte Erde...
Leider hat diese Firma stapelweise Trivialpatente durchbekommen - das 
läuft wohl wie geschmiert ;-)

VG,
Hendrik


PS: FM (fehlt hier noch) taugt bei hohen Intensitäten nichts.

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
Noch kein Account? Hier anmelden.