RGB-LED-Panel für Ambilight - geeignete LEDs/Dimensionierung?

Hallo Daniel,

der TLC dürfte sowas um die 3€ kosten; ich hätte ihn nicht direkt die LEDs treiben lassen sonder wieder MOSFETs.

Klar, wenn man für jeden RGB Kanal eine 162 nimmt gehts. Ohne spez. IC wärs mir auch lieber, da kanns wirklich jeder nachbauen.
Mir wills nur noch nicht in den Kopf, warum wir einen Haufen Prozessoren verbauen sollten nur weil wir zu "faul" sind einen voll auszureizen .. preislich ist es wirklich egal.
Hast du schonmal AVR ASM Programmiert?

Wir sollten uns mal darauf einigen, was so eine Ansteurplatine können soll, vielleicht hat auch sonst noch jemand was dazu zu sagen?
Meine Vorschläge:
a) 2..4 Kanäle RGB
b) Möglichkeit zur Versorgung mit 12..48V
c) Es sollte 2 Bestückungsvarianten geben: MOSFET in + oder in -, dann können alle gekauften Module angeschlossen werden

Fragen:
Welches Protokoll wollen wir verwenden? (meiner läuft grad mit dem dmx4all)
Gamma-Tabelle im Controller? (mach ich grad so)

Grüße,
Simon

Hallo Simon,

Zitat

der TLC dürfte sowas um die 3€ kosten; ich hätte ihn nicht direkt die LEDs treiben lassen sonder wieder MOSFETs.

Hmm, ich dachte, das Interessante an dem Controller wäre der konstante Strom?!?

Zitat

Klar, wenn man für jeden RGB Kanal eine 162 nimmt gehts. Ohne spez. IC wärs mir auch lieber, da kanns wirklich jeder nachbauen.

Das mit der Beschaffung sehe ich auch als grosses Problem. Ich stimme Dir voll und ganz zu, daß wir uns auf "Standard-Komponenten" beschränken sollten.

Zitat

Mir wills nur noch nicht in den Kopf, warum wir einen Haufen Prozessoren verbauen sollten nur weil wir zu "faul" sind einen voll auszureizen .. preislich ist es wirklich egal.

Vielleicht kommen wir mit der SoftPWM-Lösung ja hin...

Zitat

Hast du schonmal AVR ASM Programmiert?

Nein, aber schon diverse andere... Eigentlich bin ich nur im Notfall für assembler, aber dies könnte einer sein

Zitat

Wir sollten uns mal darauf einigen, was so eine Ansteurplatine können soll, vielleicht hat auch sonst noch jemand was dazu zu sagen?
Meine Vorschläge:
a) 2..4 Kanäle RGB
b) Möglichkeit zur Versorgung mit 12..48V
c) Es sollte 2 Bestückungsvarianten geben: MOSFET in + oder in -, dann können alle gekauften Module angeschlossen werden

a) Ich wäre für 2, notfalls dann kaskadieren. Oben und unten kommt bei einem Röhren-TV eh nicht in Frage.
b) Ja, das sollte auf jeden Fall möglich sein.
c) Gute Idee!

Zitat

Fragen:
Welches Protokoll wollen wir verwenden? (meiner läuft grad mit dem dmx4all)
Gamma-Tabelle im Controller? (mach ich grad so)

Protokoll ist fast egal, da wir ja beide Seiten machen (müssen).
Wenn wir das mit der SoftPWM hinkriegen, wirds vielleicht in wenig eng mit der Rechenzeit.
Hab mir da mal folgenden Gedanken gemacht, ich bitte um Kommentare:
Die SoftPWM würde ich analog zur Hardware-PWM aufziehen wollen. Es gibt also pro Ausgang einen compare-value. Dann nehmen ich einen timer, der alle 12bit*50Hz oder so auslöst. In der ISR vergleiche ich dann den timer-value mit den compare-value und aktiviere den output-Pin bei Bedarf. Dann noch nen timer-reload bei Überlauf und fertig ist der Lack. Rechnerisch ergeben sich dann 4096 Schritte*50Hz, also 204800 timer-ISR-Aufrufe pro Sekunde. Bei einem Takt von 11,592MHz bleiben dann ca. 56 Takte für die compares und Pin-Umschaltungen. Ob das reicht?

Gruß,
Daniel

Hallo Daniel,

Zitat

Hmm, ich dachte, das Interessante an dem Controller wäre der konstante Strom?!?

Wäre schon interessant, aber dann kann man damit nur spezielle LED-Module steuern; klar, die 64 Einstellschritte für den Stom fallen dann weg. Es bleiben aber die 12Bit der PWM übrig und das sollte ja reichen. Einsatzgebiet des Chips sind ja LED-Videowände, da werden dann wohl nur wenige LEDs pro Ausgang angeschlossen und der Strom wird so kalibriert, dass diese dann gleich hell sind(->Streuung).

Hab mir grad das AVR ASM Tutorial durchgelesen, kompliziert kann das Programm ja nicht sein, ich werds wohl mal versuchen.

In C hab ich die Softpwm ja schon:

Hab 2 Möglichkeiten probiert:
Timerinterrupt in festen Intervallen, in der Interruptroutine wird der Zähler erhöht, Compares ausgeführt und dann auf den Port ausgegeben.

ODER

Das Timerintervall wird anhand eine Gamma-Tabelle eingestellt; so muss der Interrupt nur 256 mal pro PWM-Schritt aufgerufen werden, es bleiben längere Pausen in denen der AVR was anderes erledigen kann.
Problem in C: der Overhead war zu groß, die kurzen Schritte haben viel zu lange gedauert.

Zitat

a) Ich wäre für 2, notfalls dann kaskadieren. Oben und unten kommt bei einem Röhren-TV eh nicht in Frage.

Einverstanden!

Grüße, Simon

So, mußte mal kurz ne Runde Atmolight geniessen
Die Farben passen ziemlich gut, nur habe ich das Problem, daß blaue
Szenen zu grün sind. Die gamma-Korrektur habe ich schon durch
und auch der weiß-Abgleich ist ganz ok, wo der Grünstich herkommt,
ist mir schleierhaft.

Gruß,
Daniel

Hallo Daniel,

lass dir doch mal die Farben im Syslog ausgeben (Die Zeile is drin, musst nur den Kommentar entfernen) und stell die problematische Farbe im Gimp oä. ein; dann findest du ja gleich raus, obs am Algorithmus liegt oder an der "Ausgabe".

Grüße,
Simon

Hallo Simon,
gute Idee! Sag mal, wenn Du die Gamma-Korrektur im Controller machst,
fällt aber die Einstellmöglichkeit über das OSD flach, oder?

Gruß,
Daniel

Guten Morgen,

ja richtig erkannt
aber viell. kann man die Tabelle beim Start des AVR im RAM aufbauen, dann könnte man das Gamma im eeprom ablegen...aber so viel asm kann ich noch nicht
Programmgerüst hab ich schon, hakt grad nur ein bischen...
Grüße,
Simon

So,

mein ASM Programm funktioniert soweit,
liegt unter
http://canins.mine.nu/webpub/softpwm.asm
Die Farben sehen genausogut aus wie mit der Hardware-PWM.

Bei einem Takt von 16MHz läuft die PWM mit 111-222Hz bei 11bit Auflösung, und das reicht augenscheinlich.

Das Protokoll der seriellen Schnittstelle entspricht dem, das meine Pluginversion sendet.

Das Ganze sollte mit ein paar kleinen Änderungen auch auf einem atmega8 laufen (im Moment atmega162):
1) aus den Registern des USART eine "0" entfernen
2) statt auf PORTA auf PORTC schreiben
3) include auf m8def.inc ändern

werde mir selbst eine atmega8 kaufen und es ausprobieren.

Wenns jemand derweil schon mal probieren will wärs schön (->daniel?)

Das Programm ist keineswegs optimiert, und eine "Adresseinstellung" wie oben schon mal erwähnt fehlt auch noch...kommt noch.

Grüße,
Simon

Hallo Simon!

Zitat

Wenns jemand derweil schon mal probieren will wärs schön (->daniel?)

Jo, geht klar, sollte ich diese Woche hinbekommen. Ein 16 MHz-Quarz sollte ich sogar noch rumliegen haben. Ist das mono oder bereits stereo?
Die Lösung kommt gerade rechtzeitig, wollte mir diese Woche schon nen ATMega162 bestellen

EDIT: Wer lesen kann, ist klar im Vorteil: Ist natürlich Stereo, super!!!

Gruß,
Daniel

Hallo daniel,

hab auch grad Urlaub, werde bestimmt jeden Tag ein bischen weitermachen
Also musst dich ned beeilen!

Der Controller kann jetzt schon stereo, das Plugin aber noch nicht, da müssen noch aus den Farbvariablen ganze Arrays werden.

Hatte folgendes vor:
1) das Plugin gibt immer 5 RGB Werte aus: rechts links oben unten gesamt
2) Die Tabelle mit den HSV Werten muss 5 mal durchgegangen werden, bei jedem Durchgang wird ein anderer der obigen Werte berechnet (die Berechnung ist immer die selbe, aber es wird eine andere Gewichtung verwendet)
3) Die Ergebnisse werden an einen neunen Thread übergeben, der in einem festen Intervall läuft und das Überblenden realisiert.

Grüße,
Simon

Hallo Simon!

Zitat

hab auch grad Urlaub, werde bestimmt jeden Tag ein bischen weitermachen

Hmm, bei mir sinds noch 2 Wochen hin

Zu Deinen Fragen:
zu 1) von mir aus gern, wie machen wir denn eigentlich die Konfiguration der Controller
(also ob ich ein links-rechts oder oben-unten oder Mono-Controller bin)?
Die Konfiguration im EEPROM ablegen würde ich bevorzugen, das könnte man bestimmt
auch über die Programmierumgebung ins EEPROM kriegen, dann müßte man weder Plugin
noch Datentransfer erweitern.
zu 2) klingt gut
zu 3) Das finde ich klasse, denn dann bekommen wir auf jeden Fall "cremige" Übergänge

Gruß,
Daniel

Hallo,

nochmal zu 1):

dachte mir das so:

Wir bleiben beim dmx4all Protokoll, dann kann man auch auf DMX ausgeben, schadet ja nix.

Das Plugin gibt nicht nur, so wie jetzt 2x RGB aus, also 6 DMX-Kanäle, sondern 5x3 Kanäle, also links/rechts/oben/unten/gesamt.

Den Controller kann man einstellen per Jumper/Lötbrücke auf:
Kanal 1 und 2 ODER Kanal 3 und 4 ODER Kanal 5.

RS232 wird einfach durchgeschliffen von Platine zu Platine.

So wäre es ohne Einstellungen im Plugin möglich rechts/links, surround oder auch nur mono Atmolight herzustellen.

Ideen dazu?

zu 2)
Gut, dann muss es nur noch jemand implementieren, ich werds beizeiten schon machen, wenn jemand anders Lust hat, gerne!

zu 3)
siehe 2) In meinem Kopf wärs schon fertig, aber nur in C...

Aber wie gesagt hab ja Urlaub, mal sehen...

Ach ja, schließlich und endlich sollte noch 4) auf die Todo Liste:
Auswahl des Ausgabemoduls (LED/CCFL9

und 5):
Bessere Farbenerkennung, da waren wie ja schonmal, wenn die Ausgabe klappt ist es ja auch einfacher.

...und atmega8 hab ich heute gekauft....

Grüße,
Simon

Hallo Simon!

zu 1) Das mit dem dmx4all-Protokoll klingt gut, das ist dann schön universell. Was hälst Du von der Konfiguration über EEPROM? Ich dachte mir, wenn man nach dem Brennen des Flash noch die dmx-Kanäle in die ersten 2 EEPROM-Zellen schreibt, hat man eine sehr flexible Lösung. Dann könnte man auch Kombinationen links-oben oder rechts-unten machen (schön kurze Kabel ).

zu 4) Dann müßte aber noch jemand die Firmware für den CCFL-Controller machen, oder? Ein erste Version hatte ich mit Samael ja mal am laufen, von der war ich allerdings alles andere als begeistert. Planst Du die Verwendung von CCFLs?

zu 5) Stimmt, ich versuche gerade, Samael und einen weiteren Kumpel mit LED-Streifen auszustatten (CCFL-Version vom atmolight haben beide schon). Danach kommt dann noch ne große Optimierungsrunde...

Wie betreibst Du im Moment Deine LED-Streifen? Über die IRL540N? Die 1N4007 über den Mosfets brauche ich bei den LEDs gar nicht, oder?

Gruß,
Daniel

Hi Simon

Zitat

Original von samc

zu 2)
Gut, dann muss es nur noch jemand implementieren, ich werds beizeiten schon machen, wenn jemand anders Lust hat, gerne!

zu 3)
siehe 2) In meinem Kopf wärs schon fertig, aber nur in C...

werd versuchen dir ein wenig arbeit abzunehmen. Heute geht nichts mehr aber morgen habe ich auch frei

ich nehme an es gibt bereits eine intern weiterentwickelte version des atmo_0.0.1. Kannst du mir den aktuellen stand senden bzw. mir einen link geben zum downloaden? Werd micht dann morgen darüber her machen.

so long
Peter

PS: hab gestern noch mal gegoogelt bzgl.16bit DMX und du hattest recht. Eine bereits fertige lösung gibts zwar aber ist nicht zu bezahlen...

Hallo,

daniel:
zu 1)
Wunderbar, hab schon dmx4all Protokoll implementiert mit 5 RGB Kanälen, wie schon erklärt. Momentan Auswahl der gewünschten Kanäle noch über Jumper, das mit "einzeln" aussuchen wäre sicher praktisch. Werd nochmal drüber nachdenken...das mit dem EEPROM gefällt mir nicht so gut, weil da müsste ich die Adressen entweder jedesmal aus dem EEPROM lesen oder ins SRAM kopieren, momentan arbeite ich nur mit Prozessorregistern, die sind nun aber voll
Evtl. ein Jumperblock pro Kanal? IOs hab ich noch genug

zu 4)
Rein aus Forscherdrank hätt ich schon Interesse dran, klar. Nicht gleich aber gern später mal..aber wie gesagt, also Grundlage bräuchte es schon solche Trafos...

zu 5)
genau so wärs toll

Im Moment mach ichs mit einem ULN2003 als Treiber und dann über eine Z-Diode einen IRF9540 (ist quasi der Komplementärtyp zum 540er). Mach das deshalb so aufwendig, weil ich 48V+ Leitungen schalte, nicht Masse...geht bei meinen Streifen nicht anders.
Wollte aber eh neute Abend einen Schaltplan und eine Platine machen, dann wirds bestimmt klar.

fishbonev:
das wär super!
aktuelle Version liegt unter:
http://eden.canins.mine.nu/webpub/atmolight-0.0.1-1.tgz

Mein aktueller Stand:

Contollerfirmware ist soweit fertig, dass 5 RGB Kanäle mit 3 Controllern ausgegeben werden können, über dmx4all Protokoll.

Plugin kann diese 5 Kanäle ausgeben, berechnet wird aber momentan noch einer. Das müsste eben erweitert werden (->fishbonev?)

-Interessant ist die Funktion "Color cAtmoThread::CalcColors(void)":
-Es wird die gesuchte Farbe berechnen, mit Gewichtung über -"cAtmoThread::PixelRelevancy", letzendlich kommt ein hsv struct raus. -Stattdessen sollte ein Array aus structs rauskommen[0..4] für links rechts -oben unten mitte.
-Schaus dir doch einfach mal an, vielleicht wirds eh klar

Weiterhin habe ich eine Auswahlmöglichkeit eingebaut:
über die Konfig-Datei kann mit -o LED oder -o CCFL kann das Ausgabemodul ausgewählt werden. Momentan funktioniert nur "LED", CCFL gibt nur Nullen aus. ACHTUNG: default IST CCFL, also -o LED angeben!
Wenn das Plugin die 5 Kanäle berechnen kann, dann sollten wir uns die CCFL Ausgabe nochmal anschauen.

Grüße,
Simon

Hallo,

Zitat

das mit dem EEPROM gefällt mir nicht so gut, weil da müsste ich die Adressen entweder jedesmal aus dem EEPROM lesen oder ins SRAM kopieren, momentan arbeite ich nur mit Prozessorregistern, die sind nun aber voll

Das mit dem jedesmal lesen wäre nicht so wild, denke ich, sind auch nur 4 Befehle (Adresse High anlegen, Adresse Low anlegen, Lesen triggern, Daten abholen). Das mit dem Adresse anlegen könnte man sich sogar auch noch schenken, wenn man immer von der gleichen Adresse liest. Dann bleibt nur noch ein "sbi EECR, EERE" und ein "in rxx, EEDR" über. Das Lesen an sich kostet 4 Takte, aber das ist vertretbar, oder?

Zitat

Wollte aber eh heute Abend einen Schaltplan und eine Platine machen, dann wirds bestimmt klar.

Na, das klingt doch super!

Gruß,
Daniel

Mir fällt spontan folgendes ein:

Zitat

Bist du des Wahnsinns fetter Beute?

Warum in Assembler?

Ich habe selbst auch mitt Assembler angefangen und bin damit recht gut zurecht gekommen. Außerdem finde ich, dass es wichtig ist die Zielhardware kennen zu lernen.
Sobald man aber die Zielhardware kennt, gibt es absolut keinen Grund mehr in Assembler weiterzumachen. Irgendwelche Schleifen, Vergleiche und Mathematische Operationen die breiter als 8 Bit sind macht der Compiler genau so gut, wenn nicht sogar besser. Die Chancen das irgendein "Carry-Flag" nicht beachtet wird gehen gegen NULL.
Außerdem kann man mit C viel besser sich Code zusammenklauen da man nicht irgendwelche Register anpassen muss.....

Hallo,

BlackKing:
habs ungern gemacht, aber musste sein weil:
Das ASM Programm arbeitet komplett in den Prozessorregistern und benutzt den Stack nur für die Rücksprungadressen, es werden keine Register gesichert...und wie soll ich sowas einem C-Compiler beibringen? Mein Interrupt dauert < 70 Takte....aber ansonsten danke für den Tip empfehle ich wirklich nur für sehr zeitkritische Sachen.

daniel_k:
ja da hast du wohl schon recht, ging mir auch nich nur um die Ausführungszeit, sondern dass ich nicht mehr zu viele Variablen frei hatte. Habs jetzt so gelöst: für jeden der beiden RGB Kanäle gibts jeweils einen kleinen Jumperblock auf der Platine mit dem die Adresse von 0-4 eingestellt werden kann (3bit). Wenn du auf die EEPROM Sache bestehst dann läßt sich das schon noch implementieren...aber wie sollen die Werte ins EEPROM kommen?

Bis gerade eben habe ich die Platine designed, morgen werde ich mal ätzen und schaun ob so alles geht.

Habe folgende Features eingebaut:

a) durch Änderungen in der Bestückung und durch Verändern von Brücken läßt sich die Plus-Leitung oder die - Leitung schalten.

b) Als 5V Spannungsregler habe ich einen LM317 eingebaut; nicht weil er regelbar ist sondern weil ich einen Typ bekommen hab (LM317HVT) der mehr als 48V Eingangsspannung verträgt. Wenn man das nicht braucht kann man auch einen billigen LM317 (ohne HV) einbauen. Der HV hat mich was um die 4,- gekostet.
So ist ein Spannungsbereich von 5V(bei MOSFET in der Masse) bis 48V möglich. Einige Bauteile müssen jeweils angepasst werden.

c) eine 9pol SUBD Buchse kann auf die Platine gelötet werden; sollen mehrere Module, also mehr als 2 Kanäle auf einmal, auf einmal betrieben werden, so kann das RS232 Signal von der 1. Platine (Puffer vorhanden) auf die 2. durchgeschliffen werden und wird dort einfach statt der SUBD Buchse angelötet.

Zum Anschauen liegts unter:
http://eden.canins.mine.nu/webpub/Platine/

So und jetzt gute Nacht,
Simon

Hallo und guten Morgen,

Zitat

Wenn du auf die EEPROM Sache bestehst dann läßt sich das schon noch implementieren...aber wie sollen die Werte ins EEPROM kommen?

Bestehen nicht, aber ich fände es halt schöner
Die Programmierung des EEPROMs kannst Du mit dem Brenntool machen (Ponyprog und co.),
kann man dann in einem Rutsch mit der Flash-Programmierung machen.
Dann braucht man keinen Handshake über seriell.
Die Platine schaut gut aus, ich habe gestern auch mal ne Runde geroutet. Rausgekommen ist ne Platine ca. 60x60mm,
auf der sich außer dem Controller auch 6 Mosfets befindet, sodaß ich meine LED-Streifen direkt treiben kann.
An einem Layout für die LED-Streifen arbeiten wir noch, bis jetzt gibt es nur meine Lochrastervariante.
Stellst Du die Platinen selber her? Darüber habe ich auch schon nachgedacht, nur mit dem Bohren kann ich mich noch nicht anfreunden,
besonders bei den LED-Streifen...

zu a) Klasse, das ist schön universell!

zu b) Auch nicht schlecht, allerdings würde ich die 12v-Schiene vom PC verwenden wollen. Aber in Hinblick auf die Kauf-LED-Streifen natürlich absolut notwendig.

zu c) Hab in meinem Design 2 Sub-Ds drin, dann kann man die per Kabel einfach so zusammenstecken...

Gruß,
Daniel

Hallo Daniel,

Also zur EEPROM Sache wage ich zu sagen dass ich sowas erfahrunggemäß unpraktisch finde: Kenne da auch so Controller, denen nur seehr umständlich eine Startadresse zugewiesen werden kann, nur mit einem speziellen Programmiergerät. Das muss man dann immer zur Hand haben und, nur in diesem Fall, ist auch jeweils notwendig den jeweiligen Controller auszubauen und dann erst zu programmieren, sonst "springts" leicht kapazitiv auf benachbarte über..
Deshalb sage ich direkt: ich habe während der Anwendung verschiedenster DMX Geräte gelernt, dass Dipschalter schon was für sich haben.

Zur Platine:
Respekt zu 60x60! Hab zuerst auch 50x100 versucht, aber das ging nicht auf, jetzt ists 65x90 geworden. Liegt aber ua auch daran, dass für die Plus-Variante noch ein ULN2003 IC und ein paar disktere Bauteile notwendig sind.

Zusätzlich habe ich Wert darauf gelegt, dass die Platine nur einseitig ist, so kann sie der Eine oder Andere vielleicht schnell im Keller ätzen. Bohren is nicht so wild, wenn dus noch nie gemacht haben solltest: Bei Conrad gibts eine poplige Handbohrmaschine (->wie Dremel) für 15,- glaub ich und einen Bohrersatz für 7,- oder so.
Damit kann man schon mal zur Not eine Platine selber bohren, ansonsten empfehle ich eine Ständerbohrmaschine.
Sicher, wenn jetzt 10 Leute daherkommen und eine wollen, dann kann mans auch recht günstig machen lassen. Wusste da mal was, bin mir grad nicht mehr ganz sicher: http://www.bilex-lp.com
Für die LED-Streifen würd ichs auf jeden Fall machen lassen, du brauchst ja schmale längliche Platinen dazu. Beim selberherstellen brauchts da ja auch wieder entsprechendes Belichtungsgerät, Atzgerät, ect.

zu b) kannst du ja machen, wenn du die 5V auch gleich aus dem Rechner ziehst sparst dir den Regler ganz..

zu c) da lass ich mich nicht lumpen: hab jetzt auch 2 SUBD drin! Ging grad so noch...

So dann bin ich mal gespannt ob meine Platine auch funktioniert!

Grüße,
Simon