Mal ne prinzipielle Frage zum Thema Multiplexen

[deep-image]

Hi zusammen,

ich hab da mal eine prinzipielle Frage zum Schaltungsdesign:

Welche Vor- und Nachteile bringt Multiplexen (MUXen) ?

Die Matrix, die ich bauen will, hat ihre einzelnen Pixel in einem Abstand von 25-30 cm, angedacht ist eine Größe von zunächst 10x10 Pixeln, später evtl. mehr. Mein erster Ansatz war - einem Projekt im Netz folgend - dass jedes Pixel autark ist, d.h. vollkommen selbständig arbeiten kann. Die Ansteuerung soll durch DMX erfolgen. Die Rechenarbeit macht ein kleiner PIC. Dafür gibts fertige Schaltungen und Quellcode, die ich nur ein bißchen anpassen muss (andere LEDs).

Jetzt habe ich bei anderen Matrixprojekten gesehen, dass da öfter MUX eingesetzt wird, wohl nicht ohne Grund. Allerdings sind das meist eher Anzeigen, bei denen die Pixel recht nah beisammen sind, also so wie bei den Anzeigetafeln an Haltestellen etc. Da wären autarke Pixel nicht machbar, weil der Platz dafür gar nicht vorhanden ist. Die Vorteile sehe ich vor allem darin, dass nicht ständig alle LEDs betrieben werden, die Gesamtstromaufnahme also zu einem bestimmten ZeitPUNKT geringer ist. Dafür wird mit höheren Impulsen gearbeitet, was bei gleicher Helligkeit über einen ZeitRAUM betrachtet den gleichen Verbrauch bedeuten muss (?).

Wenn ich jetzt durch den großen Pixelabstand längere Wege zu überwinden habe, dann spielt ja auch die Leitung ein Rolle, so dass bei 30cm wohl nicht mehr als 3x3 oder 4x4 Multiplexing gut machbar ist.

Dem entgegen steht ein höherer Aufwand :

- die Steuerschaltung muss mehr Ausgänge haben oder mit Schieberegistern arbeiten

- die Programmierung wird komplexer, wenn man das MUXen in Software erledigt bzw. die Schaltung wird komplizierter, wenn Schieberegister eingesetzt werden. An einem Controller, der 9 Pixel bedient ist auch mehr Kabelchaos, als an einem, der nur 1 Pixel steuert (das kann ggf. sogar mit auf die Platine).

- Ich muss das Timing entwerfen und umsetzen, was eine komplett neue Baustelle wird, die ich bei autarken Pixeln vermeiden kann.

- Pro Pixel muss ich 4 Kabel (RGB und Masse) führen, die von zentraler Stelle aus zum Pixel führen, beim autarken Pixel hätte ich auch 4 Leitungen (Versorgung und Daten), könnte das aber per Daisychain immer von Pixel zu Pixel weiterreichen.

- Ggf. bekomme ich eher Probleme, die Impulse über längere Wege zu führen ? Ich weiss aber noch nicht, ab welchen Entfernungen das relevant wird. Ich will ja keine Antennen bauen


Irgendwie gefällt mir die Lösung mit autarken Pixeln besser, weil ich zwar mehr, dafür aber einfachere Schaltungen bauen muss. Dafür ist das Gesamtsystem leichter zu verstehen (zu bauen, zu warten) und insgesamt habe ein weniger komplexes Gesamtsystem. Das kann ich dann vergleichsweise leicht in Einerschritten erweitern und bin flexibler, weil ich nicht in n x n Blöcken denken muss, sonder in einzelnen Pixeln.


Bis jetzt sehe ich noch nicht den Killervorteil für MUXen, vielleicht könnt ihr mir da weiterhelfen ?


Viele Grüße,

Oli

[Beatbuzzer]

Die Vorteile sehe ich vor allem darin, dass nicht ständig alle LEDs betrieben werden, die Gesamtstromaufnahme also zu einem bestimmten ZeitPUNKT geringer ist. Dafür wird mit höheren Impulsen gearbeitet, was bei gleicher Helligkeit über einen ZeitRAUM betrachtet den gleichen Verbrauch bedeuten muss (?).

Hierzu kann ich dir was sagen:
Wenn du die LED für ein drittel der Zeit mit dreifachem Strom betreibst, kommt am Ende (fast) der gleiche Strombedarf heraus. Das stimmt. Aber ob das unbedingt ein Vorteil ist, lasse ich mal dahingestellt. Irgendwann wenn die LED für ein 10tel der Zeit mit 10fachem Strom betrieben wird, weiss ich nicht wie toll die LED das auf dauer noch findet. Ausserdem muss der Leitungsquerschnitt steigen. Auch wenn der Stromimpuls noch so kurz ist, der Spannungsabfall auf der Leitung entsteht trotzdem.

Und die Frequenz muss natürlich hoch genug angesetzt werden, damit man es nicht flackern sieht. Hierbei ist das noch kritischer, als z.B. bei einem Fernseher. Denn an diesen Pixeln geht man nachher auch vorbei, und sitzt nicht nur davor. Durch die Bewegung fällt ein flackern aber viel deutlicher auf. Siehe Stroboskop in der Disco. 200Hz sollten locker reichen, aber ich wollte es nur mal erwähnt haben

[CRI 93+ / Ra 93+]

Man multiplext aus folgenden Gründen:
1.) um IO-Ports bzw. IO-Extender einzusparen
2.) um Leitungen einzusparen
=== um Material, Aufwand, Zeit und Geld zu sparen.

Man kann auch Latches (das sind Schieberegister mit Zwischenspeicher) benutzen (z.B. CMOS 4094), die Dinger kosten in Stückzahlen ca. 14-18 Cent pro Stück. Allerdings kann man dann die Daten nur noch relativ langsam ändern. Will man nun noch verschiedene Helligkeitsstufen pro Pixel, dann muss man das mit verschiedenen Widerständen o.Ä. realisieren. Gut für Linienbus-Displays, ungeeignet für Diskobeleuchtung.

Die Leitungslängen von 3 Metern halte ich nicht für all zu kritisch. Mit abgeschirmten Leitungen dürften auch EMV-Vorschriften einzuhalten sein, aber auch mit normalen Litzen dürfte sich die Störabstrahlung in Grenzen halten. Strom spart das multiplexen nicht und die LEDs schont es auch nicht. Wenn man die gleiche Helligkeit wie mit Dauerstrom erreichen will, schadet es eher den LEDs und dem Wirkungsgrad. (Ein zehntel der Zeit mit 10fachen Strom -> 10facher Strom ist meist egal wie kurz gar nicht zulässig)

Für eine 10x10-Matrix kommt Du beim Multiplexen aber mit nur 10+10=20 Leitungen aus (einfarbig) *UND* Du kannst noch dazu per PWM jedem einzelnen Pixel eine andere Helligkeit verpassen, ganz ohne weitere Bauteile, rein in Software. Bei RGB sind es 10+30=40 Leitungen.

Da Du beim Multiplexen ohnehin sehr schnell zwischen den Zeilen oder Spalten durchschalten musst, ist eine Änderung des Pattern oder der Helligkeit sofort sichtbar, Animationen, auch sind absolut flüssig machbar. Mit optimierter Programmierung sind auch feine Helligkeitsabstufungen für jedes einzelne Pixel machbar.

Mit einer Schieberegistern/Latch-Lösung kämst Du zwar theoretisch mit nur 5 Leitungen (+,-,Clock,Data,Strobe) für *ALLE* LEDs aus, musst aber bereits für eine einfarbige Darstellung ohne Helligkeitsabstufungen die Daten 100 Bits weiter schieben, wenn sich das angezeigte Muster ändern soll. Das dürfte für ruckelne Animationen (einfarbig, nur eine Helligkeit) zwar reichen, aber die Grenzen sind doch sehr schnell erreicht. Du hast bei der Latch-Lösung trotz viel mehr Verdrahtungsaufwand viel weniger Möglichkeiten als beim Multiplexen.
(Latch-Lösung: 13 x 4094 kommen dazu und müssen untergebracht werden, bei High-Power-LEDs noch ein Leistungs-MOSFET + Widerstand für jede einzelne LED, also 100 Transistoren statt 20 wie bei der Multiplex-Lösung)

Der einzige echte Vorteil der Lösung mit Latches ist die absolute Flimmerfreiheit (gut für sich bewegende Objekte wie Linienbusse). Und es ist mehr absolute Helligkeit herauszuholen, wenn das wichtig ist, dann evtl. doch Latches...

Mein klarer Favorit: multiplexen.

Die Ansteuerung ist gar nicht so fürchterlich kompliziert (IMHO allerdings auch nichts für Anfänger oder nur für welche mit eisernem Willen und viel Geduld),

Eine Schieberegister-Lösung könnte man zwar - theoretisch - beliebig erweitern, aber die Update-Zeit für ein neues Muster wird immer länger. Eine Multiplexing-Matrix könnte man aber auch je mit einem Controller versehen und ggf. diese Einheiten von einem weiteren Zentralen Controller füttern, bzw. koordinieren lassen (es könnten einige Standardabläufe in jedem Matrix-Controller stecken, die dann nur noch ausgelöst werden müssen, man kann die auch ladbar machen und dann unsichtbar langsam in die Controller hineinkopieren und dann starten). Nur so ein paar Ideen...

Das Nonplusultra für maximale Helligkeit und Geschwindigkeit wären vermutlich mehrere Schieberegister-Kanäle, aber auch dann wieder: nur eine Helligkeitsstufe pro Pixel. Oder *NOCH* mehr Kanäle.

[deep-image]

Danke für die Erklärungen, jetzt ist das etwas klarer. Ich neige noch zur Lösung ohne Multiplex, weil´s einfacher zu realisieren scheint und MUXen wohl doch einige Hürden bereitstellt...

> Man multiplext aus folgenden Gründen:
> 1.) um IO-Ports bzw. IO-Extender einzusparen

Die denkbaren uC für Einzelpixel wären im Bereich 1 Euro, das lässt sich verschmerzen, wenn ich dadurch die MUX-bedingten Hürden umschiffen kann. Bremst mich, wenn ich da falsch denke ...

> 2.) um Leitungen einzusparen

Hm ? Wenn ich bei "ohne-MUX" einen Versorgungs- und einen Datenbus habe, wo spare ich dann Leitungen ? In beiden Fällen sind´s pro Pixel 4 Adern, die bei MUX zentral vom MUXer abgehen und bei autarkem Betrieb von Pixel zu Pixel laufen ? Ist doch ein bißchen wie bei 10MBit Ethernet, da sind die Kabellängen bei Sternverkabelung doch auch größer als beim (uralten) Bus ? Den Spareffekt bei MUX seh ich eher darin, dass ich nicht an jedem Pixel eine Schaltung brauche, allerdings sind das Teure an dem Projekt eh die LEDs und löten üben schadet nicht .

Zur Lebensdauer:

Durch die für gleiche Helligkeit notwendigen höheren Stromimpulse kommt es mir so vor, als wäre MUX für die LED sogar weniger gesund ? PWM ist eh in beiden Fällen im Spiel, aber um bei MUX die Helligkeit aus den "Sendepausen" vorzutäuschen, werden die LEDs doch bewußt übersteuert ? Geht sicherlich in Grenzen, aber wenn die z.B. 350mA ab können, dann betreib ich sie doch lieber dauerhaft mit 300mA als geMUXt am Limit ?

Was die Flüssigkeit der Animationen angeht, wird eine PC-basierte Software auf MIDI-Clock bzw. Beat-Detection synchronisierte Muster erzeugen, die dann per DMX ausgegeben werden. So wird´s in den Clubs und live gemacht (Artnet als Transportprotokoll mal außen vor), was dann aber heisst, dass die "letzte Meile", sprich DMX, mit 44 Hz Updates ausgeben kann. Mehr geht nur bei Auslassen von Kanälen, dann muss man mehr DMX-Universes aufmachen.

Wenn also in dieser Größenordnung die Änderungen rein kommen, dann müsste MUX schon ziemlich flott sein, um das abzubilden, da fehlt mir noch ein bißchen die Vorstellungskraft. Ich wär mir auch nicht sicher, wie ich das synchronisiert kriege.



So unterm Strich hab ich das Gefühl, dass MUX nicht zwingend ist.... zwar elegant, aber für ein Projekt, das eher am Anfang der Bastelkarriere steht, einfach eine Baustelle mehr, die man nicht _unbedingt_ aufmachen muss. Ich behalt das Thema mal im Hinterkopf, derzeit entstehen ja grad erstmal die Einzelpixel und bevor die große Matrix kommt, gibt´s sowieso erstmal eine 4x4 Variante, bei der ich sehe, ob das Löten autarker Pixel oder das Entwerfen einer MUX-Lösung mir mehr Spass machen wird . Wenn ich die einzelnen Komponenten aber - auch gemessen an meiner Erfahrung - erstmal möglichst simpel halten will, dann probier ich´s erstmal mit Material zu erschlagen und MUX dann evtl. bei einer Version 2. m x n DMX gesteuerte RGB-Pixel ja für den Anfang eh schon ein gewagtes Unterfangen aber bis jetzt hat jeder Schritt so geklappt, wie gedacht und das in ziemlich kurzer Zeit *freu*. So darf´s gerne weitergehen...

Ich bin jetzt mal so weit, dass ich die Seoul P5 über Transistoren bunt blinken lassen kann, als nächstes kommen PWM und DMX, dann ist mal ein Einzelpixel fertig, das auch ganz flott in eine Moodlamp wandern wird. Bis das fertig ist (im Juli hoff ich), kann ich mir ja noch ein paar Gedanken um MUX oder nicht-MUX machen.


Danke nochmal für euren Input,

Oli

[CRI 93+ / Ra 93+]

Ein Controller pro Pixel? Auch bei nur 1€ pro Stück immer noch viel zu teuer, ein Leistungstransistor muss auch noch her, aber vor allem: komplizierter kann man die Ansteuerung IMHO nicht mehr machen. Du müsstest dann ja 100 MCUs parallel mit neuen Daten füttern... dann doch lieber 4094 o.Ä.

300 x 300 mm sind eigentlich nicht der übliche Abstand für eine Matrix, üblicherweise hat man z.B. 30x7 (6stellige Matrixanzeige) oder 1920x1080 (HDTV-Fernseher) sehr dicht zusammen. Da ist multiplexen auf jeden Fall angesagt.

Bei der Matrix durchzieht einfach ein Gitter aus Leitungen die ganze Anzeige. Bei Deinen Riesenabständen von 30 cm könnte der Bus "eigentlich" Leitungen sparen, aber Du musst ja pro Latch-IC dann doch wieder die 8 Ausgänge zu den entfernten LEDs führen. Und nicht zu vergessen die 100 statt 20 MOSFETs, die dann nötig werden.

Die Änderung des Bildes einer gemultiplexten Anzeige/Matrix kann sehr schnell erfolgen, da ohnehin sehr schnell gemultiplext werden muss, damit es nicht flimmert. Bei 10 Reihen sollte jede Reihe max. 10 ms eingeschaltet sein, damit das komplette Bild mindestens 100x pro Sekunde aufgebaut wird. Schaltet man einzelne Pixel kürzer ein, ergibt sich für diese weniger Helligkeit. Das ganze ist nur per Timer-Interrupt-Steuerung vernünftig realisierbar, nicht mit Delay()-Aufrufen.

Bis 70 Vollbilder pro Sekunde kann man noch ein sehr deutliches Flimmern Wahrnehmen, da ja bei LEDs nichts nachleuchtet. Ich persönlich nehme Flimmern bis 85..90 Hz wahr, allerdings ist das bei dieser Anwendung lange nicht so kritisch wie bei einem Röhrenmonitor vor dem man stundenlang sitzt und direkt und nur da drauf guckt.


Wenn Du ein Bus-System bauen willst, dann nimm' einen 4094 pro RGB-LED, da hast Du dann 8 Ausgänge und kannst damit z.B. für blau den Strom über 2 und für rot und grün über 2 oder gar 3 Widerstände auf die LED geben, über den einen, den anderen, keinen oder beide zusammen. Das ergäbe mit "aus" 4 Helligkeitsstufen pro RGB-Farbe bei 2 Transistoren pro Farbe. Hierbei wäre dann immer ein 4094 an einer RGB-LED. So hast Du ggü. multiplexen dann tatsächlich nur eine Leitung mehr ("Strobe" nämlich, wenn die geschaltet wird, übernehmen alle 4094 gleichzeitig und schlagartig das vorher beliebig langsam unsichtbar hineingeschobene Muster)

Um das ganze schneller zu machen kannst du ja jeder Spalte oder Zeile ein eigenes DATA-Signal aus der MCU spendieren (Clock und Strobe musst Du nicht trennen). Dann kannst Du das Muster schneller in die 4094 kopieren.

Übrigens wäre es von Vorteil (sowohl von der Hardware-Seite, als auch von der Software-Seite) das Muster 8x8 oder 16x16 groß zu machen, 10x10 geht allerdings auch, den geringfügigen Overhead stecken heutige MCUs locker weg, bzw. sind billig genug dafür. Bei Dimensionenmit dem Vielfachen eines Bytes lässt sich aber i.d.R. der doch eher geringe Speicherplatz besser nutzen.