Ambilight

[derKosta]

Hab die Anleitung vom eBay Verkäufer bekommen.

http://www.world-of-alien.de/temp/Vor-B ... oLight.zip

Jetzt muss ich mir nur noch ne Box mit Wechselschalter bauen, wo ich zwischen Receiver und PC hin und her schalte.

[Scorpion]

Wow kannst du dir mit der anleitung das ding nachbauen??? das wäre ja eine hammerleistung da nichtmal ein schaltplan vorhanden ist! und kann man das teil auch upgraden zu 3 oder 4 Seiten Ambilight?

[luckylu1]

naja, bin schon etwas skeptisch, auf den bildern bei ibäh, sieht man das die ausleuchtung nicht sehr gleichmässig
ist. zwei atmega werden eigentlich nicht gebraucht, einer dient nur zur rgb signal-wandlung (ad-wandler) der zweite zur auswertung der synchron signale vom fbas signal, damit ist das ganze nicht am rechner betreibbar.
hier besteht also noch nachbesserungsbedarf.

[jm2_de]

naja, bin schon etwas skeptisch, auf den bildern bei ibäh, sieht man das die ausleuchtung nicht sehr gleichmässig
ist. zwei atmega werden eigentlich nicht gebraucht, einer dient nur zur rgb signal-wandlung (ad-wandler) der zweite zur auswertung der synchron signale vom fbas signal, damit ist das ganze nicht am rechner betreibbar.
hier besteht also noch nachbesserungsbedarf.

Sieht in der Anleitung eher so aus als hätte er wirklich einen uC pro Seite benzuzt,
also beide haben das selbe Programm, nur jeweils auf die linke oder rechte Seite angepasst.

Ich fang auch erst an mit dem uC kram, aber es war warscheinlich einfacher ein Programm zu
schreiben und dann für zwei Seiten zu modefizieren, als ein grosses Programm das beide Seiten
auswerten muss.
Es könnte auch sein das günstige uCs mit relativ wenig MHz benutzt wurden, aus Kostengründen
vieleicht, die hätten zwar genug ein und Ausgänge, wären aber zu langsam.


Das ganze finde ich sowieso nicht so toll, es gibt ja wirklicht nur einen Kanal pro Farbe und
Seite des Bildes, dazu stimmt die Farbe oft nicht.
Auf dem einen Bild ist sie rechts lila, müsste aber leicht orange sein ....

[UnregisteredGuest]

damit ist das ganze nicht am rechner betreibbar.
hier besteht also noch nachbesserungsbedarf.

Das ist doch genau der Reiz an der Sache. Ein Ambilight, das keinen PC benötigt.

[luckylu1]

jörg/ du irrst, alles andere als die von mir angeführten gründe machen keinen sinn.


nö der reiz wäre, und das stellt im grunde genommen auch kein grösseres problem dar, das für viele verschiedene auflösungen nutzbar zu machen, hier wird per hand eine umschaltung auf 4:3 vorgenommen, weil eine automatische erkennung aufwändiger wäre.

[synvox]

jm2_de hat absolut recht. Der einzige Grund warum hiet zwei ATmega8 verwendet werden, ist, dass der linke und rechte Kanal unabhängig von je einem ATmega8 gesteuert werden (die beiden ATmegas sind in der geposteten Anleitung sogar mit "linker Kanal" und "rechter Kanal" bezeichnet), wahrscheinlich aus dem Grunde, dass er HW-PWM für die Farbsteuerung verwendet. Ein ATmega8 hat nunmal 'nur' 3 HW-PWM-Ausgänge. Hätte er einen ATmega88 oder ATmega168 benutzt, wäre er auch nur mit einem µC ausgekommen.

Generell finde ich den Ansatz absolut richtig, dies vollkommen ohne Rechner zu machen (einen PC für die Auswertung zu verwenden, macht eigentlich nur dann Sinn, wenn man auch mit dem PC TV schaut), allerdings überzeugen mich die Ergebnisse des Moduls anhand der Bilder überhaupt nicht. Die Farbe rechts auf dem einen Bild liegt ziemlich daneben, und ansonsten zeigt er eigentlich nur Bilder mit viel Blau.

Gruss
Neni

[jm2_de]

jörg/ du irrst, alles andere als die von mir angeführten gründe machen keinen sinn.

Kuck mal auf den Plan in der Anleitung, auf den uCs steht "linker Kanal" und "rechter Kanal",
ausserdem sitzen sie so nach an anderen Komponenten das da garkeine Leiterbahnen mehr passen
würden die nötig wären beide uCs zu verbinden.

Ich sage da ist wirklich je ein uC mit dem selben, nur je Kanal angepassten, Programm drauf.
Um was willst Du wetten ?

[synvox]

Auch nur rein schon aus den verwendeten Bauteilen ist relativ gut nachzuvollziehen, wie die Schaltung funktioniert. Der LM1881 ist ein Video-Sync-Separator. Damit gewinnt er aus dem FBAS-Signal die Triggersignale für die Vertikalbild- und Zeilenfrequenz (plus noch ODD/EVEN-Zeilen-Markierung). Diese führt er jeweils beiden ATmegas zu und steuert damit den Zeitpunkt der AD-Wandlungen. Die Analogen RGB-Signale führt er über 3 als einstellbare Verstärker/Impedanzwandler geschaltete NE5534 (rauscharme OPs mit relativ grosser Bandbreite: 10MHz) jeweils drei AD-Wandler-Eingängen der beiden ATmegas zu.

Damit wird aber auch schon klar, dass die ganze Schaltung eigentlich nur bei relativ breiten, uniform farbigen Farbrändern ein einigermassen brauchbares Ergebnis liefern kann. Ein PAL-Signal hat, wenn ich mich noch richtig erinnere, eine Zeilenfrequenz von ca. 15 kHz. Wenn wir jetzt eine horizontale Auflösung von auch nur 300 Bildpunkten pro Zeile annehmen, kommen wir schon zu wechselnden Spannungswerten im Bereich von 4,5 MHz. Der ATmega kann aber mit seinem integrierten AD-Wandler bei 16 MHz Prozessortakt einen AD-Wandler-Takt bis maximal 8 MHz benutzen, dann aber mit einer effektiven Auflösung deutlich unter 8 Bit (10 Bit Auflösung ist bis maximal 200 kHz AD-Wandler-Taktrate möglich). Nehmen wir aber trotzdem an, er hätte die höchstmögliche Taktrate gewählt, dann braucht der AD-Wandler aber trotzdem minimal 13 Taktzyklen für eine einzige Wandlung, d.h. bei 8 MHz hätten wir eine Wandlungsrate von 0,6 MHz pro Wert pro Farbe. Nur schon bei einer solchen sehr wohlwollenden Annahme zeigt sich, dass so praktisch maximal Messungen 'nur' alle 7,5 Bildpunkte von links nach rechts gemacht werden können, und das auch noch nur für jeweils einen Farbwert. D.h. bei der angenommenen Horizontalauflösung wären die Werte von Rot, Grün und Blau eigentlich je 7,5 Bildpunkte auseinander. Anders gesagt liegt unabhängig von der Auflösung die maximale Messauflösung dieser Schaltung bei 40 einzelnen Farbwerten oder 13 kompletten RGB-Werten pro Zeile. Deshalb würde ich das Ding NIE kaufen... es kann gar nicht gut funktionieren, auch mit aller Software nicht (diese Messschwäche kann man nicht mehr ausbügeln).

Mit einer besseren Eingangsaufbereitung liesse sich jedoch etwas sinnvolles daraus machen. Man müsste die OP's als Integratoren mit Sample&Hold-Schaltung (CMOS-Analog-Schalter plus Kondensatoren etc.) aufbauen. D.h. man würde mit dem ATmega die Integrationszeit (zweimal pro Zeile, eine gewisse Zeit abhängig von der gewünschten zu erfassenden Randbreite am Anfang und am Schluss) der drei OP's synchron steuern und eben dann jeweils stabile Spannungswerte messen. Mit 6 Messungen (RGBlinks und RGB rechts) pro Zeile hätte man ein gutes Mass für die Mittlere Farbe des entsprechenden Randbereiches.

Gruss
Neni

[luckylu1]

Mit einer besseren Eingangsaufbereitung liesse sich jedoch etwas sinnvolles daraus machen. Man müsste die OP's als Integratoren mit Sample&Hold-Schaltung (CMOS-Analog-Schalter plus Kondensatoren etc.) aufbauen. D.h. man würde mit dem ATmega die Integrationszeit (zweimal pro Zeile, eine gewisse Zeit abhängig von der gewünschten zu erfassenden Randbreite am Anfang und am Schluss) der drei OP's synchron steuern und eben dann jeweils stabile Spannungswerte messen. Mit 6 Messungen (RGBlinks und RGB rechts) pro Zeile hätte man ein gutes Mass für die Mittlere Farbe des entsprechenden Randbereiches.

synvox/ das war in etwa auch mein gedanke, wobei die integration zumindest teilweise, direkt an den leds mit kondensatoren erfolgen könnte. mit 2. atmega sollte auch ohne probleme eine automatische frequenzumschaltung, sowohl für vertical als auch für horizontal möglich sein.

jörg/ sorry, manchmal sollte man eben nicht zu schnell und oberflächlich sein, du hattest doch recht, für mich machte das keinen sinn, deswegen hab ich mir das nicht genau genug angesehen.

[jm2_de]

synvox/ das war in etwa auch mein gedanke, wobei die integration zumindest teilweise, direkt an den leds mit kondensatoren erfolgen könnte. mit 2. atmega sollte auch ohne probleme eine automatische frequenzumschaltung, sowohl für vertical als auch für horizontal möglich sein.

Die Schwäche ist der uC, der ist einfach zu langsam.
Eigentlich müsste es auch ohne uC funktionieren, das wäre sogar eine perfekte Lösung für den lucky,
der kann ja auch noch nicht mit uCs umgehen, aber warum auch wenn es auch mit analogen Bauteilen geht.

jörg/ sorry, manchmal sollte man eben nicht zu schnell und oberflächlich sein, du hattest doch recht, für mich machte das keinen sinn, deswegen hab ich mir das nicht genau genug angesehen.

Ist mir auch nur aufgefallen weil es im Plan auf den uCs steht,
bin genauso erfahren mit den Dingern wie Du

[Mirfaelltkeinerein]

Nur schon bei einer solchen sehr wohlwollenden Annahme zeigt sich, dass so praktisch maximal Messungen 'nur' alle 7,5 Bildpunkte von links nach rechts gemacht werden können, und das auch noch nur für jeweils einen Farbwert. D.h. bei der angenommenen Horizontalauflösung wären die Werte von Rot, Grün und Blau eigentlich je 7,5 Bildpunkte auseinander. Anders gesagt liegt unabhängig von der Auflösung die maximale Messauflösung dieser Schaltung bei 40 einzelnen Farbwerten oder 13 kompletten RGB-Werten pro Zeile. Deshalb würde ich das Ding NIE kaufen... es kann gar nicht gut funktionieren, auch mit aller Software nicht (diese Messschwäche kann man nicht mehr ausbügeln).

13 komplette RGB-Werte pro Zeile sind schon ein bisschen dürftig, zumal sie nicht an den selben Positionen aufgenommen sind. Aber alle 8 Pixel einen Messwert zu bekommen, dafür aber bei jeder Zeile, ist völlig ausreichend. Ich benutze sowohl horizontal als auch vertikal nur jedes 4te Pixel, also insgesamt nur jedes 16te! Das reich völlig aus, weil sich der Bildinhalt räumlich im Allgemeinen nicht so stark und dann auch noch regelmäßig ändert. Allerdings scheint man bei der angegebenen Schaltung nur jedes 55te Pixel eine neue Farbkomponente bekommen. Das erscheint mir nun doch ein bisschen wenig.

[synvox]

Naja, alle 8 Punkte eine Messung wäre es eben bei ca. 300 Bildpunkten pro Zeile. Alte Copmputerspiele für Fernsehgeräte und Arcade-Spielkästen hatten Auflösungen von 320 x 240 Bildpunkten, deshalb diese Minimalannahme von mir. Aber eben, bei jeder besseren Zeilenauflösung sähe es noch schlechter aus für das System. Wie gesagt, für eine vollständig digitale Auswertung der Farbwerte müsste man erstens einen deutlich schnelleren µC (etwa in der Leisungsklasse eines ARM von Atmel) und zweitens Video-ADCs verwenden, beides alles andere als günstig und einfach zu handhaben.
Die bessere Variante scheint mir hier, eben µC- und Analogtechnik zu kombinieren, das schont sowohl Geldbeutel als auch Hirnschmalz .

Gruss
Neni

[Mirfaelltkeinerein]

Man will ja kein neues Bild machen, sondern fasst die Messwerte sowieso zusammen, bildet also einen Mittelwert. Und der muss nur halbwegs repräsentativ sein, aber nicht jedes kleinste Detail beinhalten. Das fällt sowieso nicht auf. Ob da jetzt von 200000 Pixeln pro Bildhälfte ein paar mehr oder weniger in einer bestimmten (Misch-)Farbe berücksichtigt werden, ist eigentlich ziemlich egal. Dafür aber, dass man einen repräsentativen Querschnitt erhält, benötigt man halt ein paar Messungen.
In meinem Ambilight basiert die Farbbeurteilung eines Bildviertels auf ca. 6500 Stützwerten. Das reicht im Allgemeinen aus. Das reicht auch dann noch aus, wenn oben und unten automatisch der Mittelungsbereich angepasst wird, weil da der Film schwarze Balken hat und sich damit die Anzahl der Stützstellen reduziert.

[Ragnar Roeck]

Ich habe da gerade wohl ein Verständnissproblem. Von den angenommenen 13 RGB Werten pro Zeile brauche ich letztlich bei Zweikanalbetrieb nur 2. Diese zwei Werte müssen noch über die Anzahl der Zeilen gemittelt werden, um den entsprechenen Farbeindruck der linken bzw. rechten Seite anzuzeigen. Die Schaltung ist also weit schneller als nötig, nicht etwa zu lahm.

[synvox]

Das Problem ist, dass du eben nicht genügend Werte zum Mitteln hast. Ein RGB-Wert ist ja derjenige eines einzelnen Bildpunktes, und wenn du da einfach nur einen links und einen rechts nimmst, dann stimmt das Ergebnis wohl bei Bildern mit sehr gleichmässig gefärbten Rändern zwar gut, aber bei Bildern mit Streifen- oder Karo-Mustern am Rand kannst du unter Umständen ein völlig falsches Ergebnis bekommen, da du eben auch bei Messung auf allen Zeilen nicht wirklich gut über den zu analysierenden Bereich mittelst, sondern dich auf ein Mittel über die Summe von wenigen Einzelpunkten oder bestenfalls dünnen senkrechten Streifen stützst. Ein weiteres Problem ist ja eben auch noch, dass die Werte von Rot, Grün und Blau jeweils nicht vom selben Bildpunkt stammen sondern gegeneinander verschoben sind. Durch gute Programmierung könnte man zwar sicherstellen, dass man für Rot, Grün und Blau dann wenigstens drei untereinander auf einer Spalte liegende Bildpunkte erfasst, aber auch das kann in die Hose gehen, wenn genau an diesen Stellen Bildinformationswechsel zu sehen sind.

Aber wie gesagt, genau das was du dir vorstellst (2 RGB-Messungen pro Zeile genügen und dann nicht mal notwendigerweise für jede einzelne Zeile, sondern auch jede 2. oder 3.) könnte man erreichen, wenn man synchron steuerbare, analoge Integratoren an den Eingängen verwenden würde. Schaltungstechnisch wäre das gar nicht so ein Riesenaufwand, aber da könnte Lucky wohl besser was direkt aus dem Ärmel schütteln .

Gruss
Neni

[luckylu1]

es gibt noch ein weiteres problem, weswegen beim "normalen" fernsehbild jede 2 erfasste zeile ausreicht, das bild setzt sich aus 2 halbbildern zusammen.

als erstes müssten die notwendigerweise zu erfassenden bereiche festgelegt werden, sind es zu wenig, wird das ergebnis auch nur sehr mangelhaft sein. ich hab hier mal eine mögliche aufteilung skizziert. dabei wird klar, das der aufwand dafür mit 14 OPV pro farbe doch recht hoch ist. es wäre also zu überlegen, welche bereiche entfallen könnten oder in welchen bereichen das raster vergrössert wird. zusätzlich könnte eventuell überlegt werden, jeden OPV für 2 bereiche, die möglichst weit auseinander liegen, zu verwenden. die gesamte signalverarbeitung wäre analog und der avr übernimmt "nur" die steuerung. das ist nur ein erster ansatz, selbst bei verwendung von 4fach
OPV und weglassen zweier der 14 bereiche sind das noch 3 OPV IC´s pro farbe. um weitere überlegungen zur reduzierung des aufwandes anstellen zu können, ist es auf jeden fall auch notwendig die anzahl der anzusteuernden leds und deren leistung festzulegen, da sich damit unter umständen weitere vereinfachungen ergeben könnten.

1856_ambilight_aufteilung_1.jpg (10.59 KiB) 18781 mal betrachtet

[synvox]

Nun, wenn man dem AVR etwas mehr Arbeit anvertraut, wäre der Analoge Aufwand entsprechend geringer. Man könnte die Integration/Mittelung der Werte über die Zeilen hinweg dem AVR überlassen. Dann wäre man eigentlich mit einer Integrator- und S&H-Einheit pro Farbe dabei. Eigentlich dürften ein oder zwei OPV plus zwei MOSFET-Schalter (einer um das Signal zum Integrator-OPV ein-/auszuschalten und einer um den Integrator zu entladen) pro Farbe dann ausreichen. Der AVR würde aufgrund der Signale vom Sync-Separator immer genau 'wissen' wo er sich im Bildaufbau gerade befindet und zusätzlich einen eigenen Taktzähler mitlaufen lassen. Dadurch könnte er die Integrationen gemäss vorher im Programm festgelegter Messfelder mittels Taktzählung nach Zeilenimpuls genau steuern. Er würde natürlich auch die Zeilenimpulse nach Vertikalimpuls zählen, so dass er 'wüsste', wo er sich gerade vertikal befindet. Aufgrund dieser Informationen könnte er die Integratoren steuern, wobei je nach Felddefinition in der jeweiligen Zeile eine oder zwei Integrations- und Messphasen auszuführen wären. Jede Messphase bestünde aus drei Einzelmessungen (RGB). Diese würden vorerst nur in der jeweiligen Felddefinition entsprechende Feldvariablen gespeichert werden ohne irgendwelche Kalkulationen (wegen dem Zeitfaktor). Man würde auch nur jede zweite Zeile eines Halbbildes (ODD oder EVEN) berücksichtigen (also schlussendlich damit jede vierte Zeile), damit bei linker und rechter Randmessung pro Zeile die Integrations- und Messphasen nicht zu schnell aufeinander folgen (sonst wären das Ende einer Zeile und der Anfang der nächsten für die Messung zu eng aufeinander). Das zweite Halbbild (ca. 20 ms) würde man komplett ignorieren und in dieser Zeit die Kalkulationen (Aufsummieren und Mittelung der in den Feldvariablen gespeicherten Werte) und Ausgabe der ermittelten Farbwerte als PWM-Werte auf die Output-Compare-Ausgänge zur Steuerung der LEDs legen. 20 ms sind für den AVR bei 16 MHz Prozessortakt ne halbe Ewigkeit und reichen dicke für den gesamten Vorgang.

Ich denke, so müsste es funktionieren, jetzt müssen wir's nur noch bauen .

Gruss
Neni

[jm2_de]

Zuerst wäre es mal interessanz zu wissen welche Quellen über TV-Signale (FBAS / RGB Analog)
Ihr verwendet, wenn jemand eine sehr ausfürhliche Quelle findet kann er ja mal den Link posten.
Es wäre sehr nützlich wenn alle die selbe Quelle nutzen

Bisher sehe ich hier zwei Lösungsansätze, den digitalen mit einem uC und den analogen mit OPs.
Mit den uC´s kenne ich mich nicht aus, aber bei den SPS (siemens usw) erhöht sich die Zeitdauer
eines Prozesszyklus bei grösser werdenden Programmen.
Bei einem atmel uC dürfte das nicht anders sein, soweit ich mir das angesehen habe scheint es
für mich so als wären selbst die schnelleren atmel uC´s zu langsam um so ein recht grosses
Programm schnell genug abzuarbeiten, so das es noch mit dem TV Signal mitkommt.


Meine Idee geht daher eher in den analogen Bereich, denn analoge Bauteile für hohe Frequenzen,
wie Transistoren gibt es genug und günstig.
Ein weiterer Vorteil ist das man bei der analogen Bauweise nicht von der Anzahl der I/O Ports
eines uC´s eingeschränkt wird - je RGB LED bräuchte man ja 3 outputs,
bei einem uC mit 20 output pins sind das nur 6 RGB LEDs, ziemlich wenig.

Ich will hier jetzt noch nichts weiterführendes posten, auch wenn ich schon Ideen habe,
aber ich muss mich erst noch in den FBAS/RGB Kram einlesen.
Bin mir aber ziemlich sicher das luckylu mit einem kleinen Schubs in die richtige Richtung
auch drauf kommen wird - im Forum gibt es schon Schaltungen von luckylu / RPH bei denen die
Grundlagen zu sehen sind


Frage:
Welcher ist der schnellste (und einfach zu bekommende) OPV den Ihr kennt ?

@luckylu
Der Brief ist angekommen, das meiste kann ich gut gebrauchen.

[luckylu1]

Man würde auch nur jede zweite Zeile eines Halbbildes (ODD oder EVEN) berücksichtigen (also schlussendlich damit jede vierte Zeile), damit bei linker und rechter Randmessung pro Zeile die Integrations- und Messphasen nicht zu schnell aufeinander folgen (sonst wären das Ende einer Zeile und der Anfang der nächsten für die Messung zu eng aufeinander).

synvox, was hältst du von der variante, für den linken teil even und für den rechten teil odd auszuwerten? das verschafft einen zeitlichen vorteil. ausserdem, dürften billige OPV´s etwas zu langsam sein um alle felder bedienen zu können, weiterhin müsste ja eine kanal (feld 1-14)erfolgen, dadurch wäre der transistoraufwand doch recht hoch, ich muss mir das nochmal durch den kopf gehen lassen. eventuell noch mal etwas probieren, bei genügend
hochohmiger beschaltung der ausgangsfets könnte eventuell auch der gatekondensator zur integration mitgenutzt werden, das funktioniert allerdings nur, wenn der eingang zum fet abgeschaltet werden könnte (ev. mit einem fet?)
zur strombegrenzung kommen dann allerdings nur widerstände in frage, da sonst der schaltungsaufwand zu hoch wird.

jm2_de / das mit der selben quelle zur information hat was für sich!

Bisher sehe ich hier zwei Lösungsansätze, den digitalen mit einem uC und den analogen mit OPs.

sowohl die eine als auch die andere alleinige variante hat hier deutliche nachteile, eine mischung dürfte das beste ergebnis bringen. da kommt mir gerade eine idee.....

[jm2_de]

jm2_de / das mit der selben quelle zur information hat was für sich!

Solche Sachen werden ja sogar in verschiedenen Lehrbüchern anders erklärt,
benutzt jeder einen anderen Text mit unterschiedlichen formulierungen / Grafiken usw,
dann gibts hier bald ein riesen durcheinander

sowohl die eine als auch die andere alleinige variante hat hier deutliche nachteile, eine mischung dürfte das beste ergebnis bringen. da kommt mir gerade eine idee.....

Schubs ...


Bin mal gespannt auf welche Idee du gekommen bist, vieleicht die bei
der man den uC so benutzt das pro RGB LED nur ein output belegt wird ?

[Mirfaelltkeinerein]

1856_ambilight_aufteilung_1.jpg (10.59 KiB) 18782 mal betrachtet

Ihr habt viel zu hohe Ansprüche .
Insbesondere wenn die Glotze etwas von der Wand entfernt steht und zusätzlich auch eine ordentliche Farbmischung ohne Farbränder erzielt werden soll, benötigt man sehr diffuses Licht für das Ambilight. Deshalb macht es eigentlich keinen großen Sinn, das Bild in so viele Einzelfelder aufzuteilen (es sei denn, ihr habt alle Riesenfernseher). Bei meiner Lösung ist werden Viertelbilder entsprechend 1-5 (oben), 1+6+8+10 (links), 5+7+9+14 (rechts) und 10-14 (unten) ausgewertet. Meiner Ansicht nach reicht das völlig aus, obwohl natürlich bei feineren Unterteilungen starke Helligkeitskontraste, die sich über das Bild bewegen, besser aufgelöst werden. Allerdings steigt halt der Steuerungsaufwand stark an.
Jedenfalls benötigt man bei 4 RGB-LED-Clustern (einzelne RGB-LEDs werden nicht reichen oder keine schöne flächige Ausleuchtung machen) nur 12 Controllerpins. Wenn man einen Controller bekommt, der 12 Hardware-PWM-Kanäle hat, hat man sogar sehr viel Zeit für andere Sachen, wenn nicht muss man sich fast ständig um die Portpins kümmern.
Bei einer Mikrocontrollerlösung möchte ich für die feine Version aber mal den Controller sehen, mit dem man (kostengünstig!!!) 42 Software-PWM-Kanäle realisieren kann (14*(R+G+B)). Meistens wird da alleine schon die Löterei etwas anspruchsvoller...

[jm2_de]

Bei einer Mikrocontrollerlösung möchte ich für die feine Version aber mal den Controller sehen, mit dem man (kostengünstig!!!) 42 Software-PWM-Kanäle realisieren kann (14*(R+G+B)).

Wieso 42 PWM Kanäle, die brauchst Du doch garnicht.
Bei der Analog-Digital Mischbauweise mit uC reichen 14 normale Ausgänge
Dafür aber 42 Transistoren mit 500mA oder mehr, dazu ein paar Widerstände und Kondensatörchen,
aber für all das bezahlst man unter 5 Euro.

Meistens wird da alleine schon die Löterei etwas anspruchsvoller...

Passt doch dann zu dem recht Anspruchsvollen Ziel

[Mirfaelltkeinerein]

Bei einer Mikrocontrollerlösung möchte ich für die feine Version aber mal den Controller sehen, mit dem man (kostengünstig!!!) 42 Software-PWM-Kanäle realisieren kann (14*(R+G+B)).

Wieso 42 PWM Kanäle, die brauchst Du doch garnicht.
Bei der Analog-Digital Mischbauweise mit uC reichen 14 normale Ausgänge
Dafür aber 42 Transistoren mit 500mA oder mehr, dazu ein paar Widerstände und Kondensatörchen,
aber für all das bezahlst man unter 5 Euro.

Willst du dann rot grün und blau multiplexen oder wie? Bei 14 Feldern mit je drei Farbkanälen braucht man insgesamt 42 unabhängige Kanäle.

[synvox]

1844_ana_1.jpg (11.04 KiB) 18794 mal betrachtet

So, ich habe hier mal eine Version der Eingangsaufbereitungsschaltung gezeichnet (Integrator plus Sample&Hold), aber noch ohne konkrete Dimensionierung (Widerstände und Integrationskondensator). Das Ganze müsste man nun mindestens 3-fach aufbauen (für jede Farbe einmal), oder wenn man unbedingt möchte auch noch pro Analysefeld jeweils ein 3er-Set. Aber durch die Steuermöglichkeit mittels µC reicht ein 3er-Set vollkommen aus, die Integration steuert man dann einfach zeitabhängig pro Zeile.
Die Schaltung benötigt allerdings noch eine negative Versorgungsspannung neben +5V. Aber dafür könnte man einfach eine geregelte + 9V Spannung als Gesamtversorgung nehmen und dann noch bezogen auf + einen -5V Regler nachschalten. Dann hätte man +5V und -4V, und das würde bereits völlig ausreichen.

Gruss
Neni