Forum: Mikrocontroller und Digitale Elektronik Ambilight selfmade, VGA signal auswerten?


von Paul H. (powl)


Lesenswert?

Hi!

Ich habe mir überlegt man könnte sich ja ein Ambilight nachbasteln :-) 
Habe da im Internet schon verschiedene Lösungsansätze gesehen aber 
nichts wirklich ausgereiftes. Das was mich am meisten stört ist dass 
sich noch niemand gedanken drüber gemacht hat wie man das bild in 
verschiedene bereiche aufteilen könnte.

Ich bin kein Spezialist in dem Bereich aber afaik kommt aus dem VGA ein 
analoges signal raus, und das für jede Farbe. Zeilenweise.

Das heißt um an einen bestimmten Bildbereich zu kommen müsste man nun 
jede Zeile auf verschieden aufteilen. Das kann ja ein µC übernehmen, 
vorrausgesetzt der ist schnell genug dazu, weiß ja nich wie schnell VGA 
so arbeitet..

Man hat nun zum beispiel 4 bereiche und jedem Bereich ist eine 
nachliegende Schaltung zugeteilt. Das gibt für jeden Farbkanal also 4 
Schaltungen.

Um nun den Durchschnittswert eines Kanals in einem Bereich zu bekommen 
schaltet man hinter einen widerstand einen kondensator. Der Widerstand 
wird so gewählt dass wenn der ganze bereich weiß sei der Kondi sich beim 
durchlaufen des bereichs von oben nach unten voll aufläd. Am ende des 
Durchlaufs misst man dann nur noch die Spannung des Kondensators um 
herauszufinden wie hell der kanal durchschnittlich in diesem bereich 
angesteuert wurde. Danach wertet ein weiter µC eben die spannungen aus 
und erzeugt eine PWM für 12 LED-leisten die hinter dem Bildschirm kleben 
und das ambilight erzeugen :-)

Was haltet ihr davon? Ist so ein Ansatz realistisch bzw einen Versuch 
wert?

mfg PoWl

von Randy N. (huskynet)


Lesenswert?

VGA...das soll für nen PC-Monitor werden, ja? Das is ja mal cool :-)

So schnell kommen die Signale meines Wissens nach nicht, also mit einem 
AVR sollte das schaffbar sein. Ich würde die drei Farbwerte über nen ADC 
direkt in  den AVR einlesen. Da ja immer 3 AD-Umwandlungen erforderlich 
sind könnte das mit dem AVR vielleicht auch knapp werden, aber man kann 
ja notfalls auch 3 externe ADCs nehmen. Und wenn du 8-bit Genauigkeit 
wählst (was voll ausreicht) hast du schöne Werte 0...255. Bei VGA gibts 
dann noch zwei Signale, die die aktuelle Position angeben - ok die 
müsste man auch digitalisieren, also schon sehr knapp. Ich würde den 
Bildbereich so unterteilen:

##         ##
  ##  1  ##
    ## ##
  4  ###   2
    ## ##
  ##  3  ##
##         ##

Du kannst dann anhand der Position immer berechnen, zu welchem Bereich 
der Farbwert gehört, und alle Farbwerte eines Bereiches addieren und 
damit den Mittelwert berechnen. Und das würde ich dann direkt am 
PWM-Ausgang ausgeben. Weiß nicht ob es µC mit 12 PWM-Ausgängen gibt, 
ansonsten eben paar per Software emulieren.

Ansonsten finde ich das realistisch, ja.

von Dietmar E (Gast)


Lesenswert?

Wenn das für einen PC ist (VGA), dann wäre es erheblich einfacher und 
sinnvoller, einen DirectShow-Filter zu schreiben und der 
Ambilight-Hardware das Ergebnis zu übergeben. Die Hardware würde sich 
dann nur noch um die LEDs kümmern.

von Randy N. (huskynet)


Lesenswert?

@Dietmar E:
Stimmt auch wieder. Allerdings funktioniert das dann nur bei Filmen, 
nicht beim normalen Windows-Desktop. Das wäre ja (besonders wenn mans 
hinter dem Arbeits-Monitor anbringt) das Interessante.

von Andreas L. (andi84)


Lesenswert?

VGA ist schon recht schnell - nehmen wir mal 1024x768 @ 80 Hz (overscan 
und ähnliche feinheiten vernachlässige ich jetzt hier bewusst!), was ja 
jetzt noch nichts weltbewegendes ist. Da werden dann also 768 Zeilen mit 
1024 Spalten 80 Mal pro Sekunde angezeigt. Ergibt also eine 
Zeilenfrequenz (H-Sync) von 768*80=62880 Hz. Damit ist die Pixelfrequenz 
rund 64MHz. Wollte man jedes Pixel auswerten bräuchte es also einen 
entsprechend schnellen ADC. Die gängigen Mikrocontroller dürften da auch 
nichts mehr bringen.

Da wir das Bild nun aber nicht anzeigen sondern nur in ein paar 
Bereichen auf seine Farbe hin analysiren wollen, teilen wir es nun 
horizontal in sagen wir mal 8 Bereiche auf. Die Mitte interessiert uns 
dabei weniger. Wir wollen nun aber auch gleich Nägel mit Köpfen haben 
und nehmen deshalb an, dass das Ding bis 1600x1200 @ 80 Hz laufen soll. 
as wären dann also 96kHz Zeilenfrequenz. Wegen der 8 Bereiche müssen wir 
dann auch 8 mal samplen (wir nehmen da jetzt mal ein schönes 
Tiefpassfilter vornedran und so weiter als gegeben und ideal an) Dann 
müssen wir also 768000 mal pro sekunde samplen - irgendwie immer noch 
erträglichm, wenn auch schon etwas schwerer mit einem avr. Daher jetzt 
mal mit richtig schöner analogtechnik:
Sagen wir mal, 4x4 Felder reichen uns, dann könnte man folgendes machen:
Mit dem HSync füttern wir eine PLL, die eine Phasensynchrone, 4 mal so 
hohe frequenz erzeugt. Mit dem VSync machen wir das gleiche. Zusätzlich 
nehmen wir das originale HSync, um damit zwei zähler zu resetten, immer 
wenn der Elektronenstrahl von oben neu startet. Wir haben nun mit den 
beiden Zählern ein insgesamt 4 bit breites adresswort. Das geben wir 
jetzt auf drei 16:1 Multiplexer, die wir mit den jeweils gepufferten 
RGB-Werten versorgen. Hintendran kommt dann ein RC-Tiefpass mit einer 
Grenzfrequenz von sagen wir mal 0,25-0,5 Hz. Wenn man den ganzen Kram 
jetzt am laufen hat, hat man die durchschnittliche Farbe in den 16 
Feldern analog vorliegen. Jetzt kann man da z.B. die äußeren 12 nehmen 
und die Werte in diesen mittels AVR o.ä. messen. (wären dann 36 
Analogwerte, also nochmal 3 16:1 Muxes). Der AVR hat dann nichts 
weiteres zu tun, als das ganze in eine hübsche PWM umzuformen.
GGf. kann man das dann noch vereinfachen, indem man die 4 Randdbereiche 
gleich hinter dem Mux zusammenrührt. Dann hat man nur noch 12 
Analogwerte zu messen.

Vorteil der Analogvariante ist, dass man, sobald man die PLLs am laufen 
hat, praktisch beliebige Auflösungen fahren kann, solange die 
entstehenden Frequenzen noch im Syncrange der PLLs liegen.
Die VSync PLL müsste folglich auf Eingangsfrequenzen von 50-100 Hz 
einrasten (entspricht Frequenzbereich 200-400 Hz, noch sehr gut 
machbar), die HSync PLL muss dann von 12-120 kHz einrasten können 
(=48-480 kHz) um einen Auflösungsbereich von 320x240@50Hz bis 
1600x1200@100Hz nutzen zu können.
All diese Angaben sind jetzt zunächst mal nur rein spekulativ und ohne 
berücksichtigung der Randbereiche, die ebenfalls im VGA Signal enthalten 
sind, sowie des Strahlrücklaufs, während dem irgendwie ein integrieren 
des Signals zu verhindern ist.
Am besten nimmt man wohl den Syncrange eines CRTs als Vorlage. Die 
Frequenzen müsste eigentlich allesamt mit billigen PLL-Bausteinen (der 
4046 wäre da evtl interessant) machbar sein. Die Theorie zu PLL sollte 
man sich vorher irgendwo mal nachgelesen haben.

von Randy N. (huskynet)


Lesenswert?

> VGA ist schon recht schnell

Ach stimmt, ist ja jetzt VGA. Bin irgendwie von der TV-Auflösung 
ausgegangen, weil ich mich vor kurzem damit beschäftigt hatte - und das 
ist noch schaffbar. Ok stimmt.

von Andreas L. (andi84)


Lesenswert?

Wenns natürlich für ein LCD Panel ist, dann reicht VSync von 50-60 Hz 
aus - supereasy.
Und HSync wäre dann wohl bei 12-62kHz, was schon wesentlich angenehmer 
ist, da der Frequenzbereich kleiner ist, in dem die PLL funktionieren 
muss.
Sollte wohl mit einer Portion Hühnerfutter nebst etwas CMOS Garnitur zu 
schaffen sein. Dürfte wohl noch auf eine Europlatte passen, wenn man 
geschickt routet. Muss mir mal die Signalformen vom VGA näheransehen - 
wäre mal ein lustiges Projekt für zwischendurch

von Andreas L. (andi84)


Lesenswert?

so rund 6 CMOS ICs, etwas Krams mit OPs für die Signalaufbereitung, evtl 
2 Flipflops mit etwas Gemüse garniert und der AVR dazu. Das sollte es 
sein.
Denke mal, Kosten sollten unter 20 Euro zzgl. LEDs liegen.

von Andreas L. (andi84)


Angehängte Dateien:

Lesenswert?

Im Anhang mal ne Idee, wie man aus den Sync-Impulsen die Position (in 
4/8/16/64 Feldern) ermitteln kann (muss man aber wohl erst noch genau 
testen), sollte allerdings vom Prinzip her klappen. Die 4046 PLLs gehen 
von 0Hz bis etwas über 1MHz. Das sollte wohl reichen. Die Position kann 
man dann aus den COunterwerten ablesen. Die Flipflops im Eingang sorgen 
für 50% Dutyfactor bei den Syncs, damit die PLLs schön einrasten können. 
Die Exors mit den Schmitt Triggern bereiten die Syncsignale auf und 
wandeln evtl. negative Sync-Polarität in positive um. Die Resets der 
Counter müsste man dann noch an den aufbereiteten H-Sync (pre flip-flop) 
anhängen, damit die Zähler immer mit 0 beginnen, wenn ein neuer frame 
kommt.

Das ganze passt übrigens bis jetzt auf eine einseitige Leiterplatte 
(derzeit 100x80). Mit den 15pol-HD Steckern wirds dann amber etwas eng 
mit einseitig, wenn man das Signal durchleiten will. Hier muss also 
evtl. eine Kabelpeitsche gelötet werden.

MfG
Andreas

von Dieter R. (drei)


Lesenswert?

Die Frage ist nur, sieht das dann auch nach was aus? Wenn in einem der 
ausgewerteten Felder z. B. ein irgendwie geartetes Pixelgemisch ist, 
dann sieht die langsame Auswerteschaltung dort graue Soße. Das Auge 
sieht sort aber unter Umständen Strukturen (das Pixelgemisch) und 
dominate Farbflächen. Eine intelligente Signal-Aufbereitung könnte mit 
wenig Rechenaufwand solche dominanten Flächen erkenne, müssste das 
Signal aber Pixel für Pixel (oder jedenfalls mit höherer Auflösung als 
nur 8 Abtastungen pro Zeile) auswerten.

Es wäre vielleicht doch hilfreich zu wissen, wie und mit welcher 
Abtastrate die Auswertung denn bei der kommerziellen Lösung erfolgt.

Frage: weiß das jemand, oder hat schon mal jemand in die Patente 
geschaut?

von Paul H. (powl)


Lesenswert?

ihr habt noch garnix zu meiner kondensatormethode gesagt :-D

von Andreas L. (andi84)


Lesenswert?

Das kommerzielle Ambilight von Philips dürfte auf digitaler 
Signalverarbeitung basieren, da ein LCD/Plasmagerät sowieso alles 
digitalisieren muss. Ein VGA Signal direkt zu digitalisieren halte ich 
allerdings für einen Overkill. Das originale Ambilight analysiert afaik 
nur den linken, den rechten und den oberen rand. Wenn man sich jetzt 
etwas mehr arbeit machen will, kann man ja hergehen und den Bildbereich 
in z.B. 8x8=64 Flächen unterteilen. Damit man jetzt hier nicht 64 
Tiefpaääse nebst der zugehörigen Analogschalter braucht, nimmt man einen 
1:16 Mux un einen schnellen ADC (12kSamples min.), so dass man immer 
während die nächste Zeile aus 8Blöcken gemittelt wird, die letzte 
auslesen kann. man kann sich ja dan auch schön die randbereiche 
raussuchen.
Das Signal komplett zu digitalisieren halte ich allerdings für mit 
"Hausmitteln" (also ohne DSP oder richtig schnellen µC, sowie die 
passenden ADCs für nur sehr bedingt durchführbar (ich sag jetzt nicht, 
dass das nicht geht, aber die knapp 3 mal 80 Megapixel die bei 
1280x1024@60Hz RGB pro Sekunde übers Kabel kommen direkt zu messen wird 
echt haarig)).

Wenn man denn wirklich mit 8x8 Feldern arbeitet, dann hat man schon ganz 
gute chancen, unterschiedliche Farbflächen zu erkennen. Wenn es halt 
keine dominante Farbe gibt, dann ists halt nur Hintergrundlicht mit 
angepasster Helligkeit. Und wer sagt eigentlich was von langsam? Bei 60 
Hertz Bildfrequenz müssen die Tiefpässe schon recht schnell sein.
Wenn man jetzt auch noch mehrere Ledmodule links, rechts un oben 
verwendet (z.B. jeweils 4), dann wirds schon ziemlich cool und geht über 
das normale Ambilight sogar noch hinaus.

Ich werde die PLL/Kondensatorvariante wohl mal bauen (vermutlich aber 
erst mal nur 4x4), da die Kosten für die ICs (abgesehen von 
LED-Treibern, AVR und soweiter, die sowieso vorhanden sind) wohl kleiner 
als 10 Euro sein werden und es somit nicht zu tragisch ist, wenn es dann 
doch nicht so cool war. Wenn man die ICs sockelt, hat man beim Scheitern 
des Projekts nur ein paas Rs und Cs verschwendet. Das ist grad noch zu 
verschmerzen.

MfG
Andreas

von Andreas L. (andi84)


Angehängte Dateien:

Lesenswert?

Wenn man einen Tiefpass nimmt, dann sieht's wirklich bäh aus. Wenn man 
stat dessen integriert, kommt schon was schöneres bei raus. GGf müsste 
man dann wohl noch in Software die Sättigung etwas verstärken.

von Andreas L. (andi84)


Lesenswert?

Wenn man dann noch mehrere LED-Module pro Rand nimmt, sollte das System 
dem Original durchaus etwas entgegenzusetzen haben.

von Paul H. (powl)


Lesenswert?

@ Andreas, ich scheine eine Lawine in dir in Gang gesetzt zu haben, wäre 
schön wenn du sowas sogar umsetzt :-)

Dennoch würde ich gerne noch wissen was ihr von meiner superanalogen 
Kondensatormethode haltet? Die wäre noch einfacher als die Geschichte 
mit deinen Digitalbausteinchen :-)

mfg PoWl

von Stefan (Gast)


Lesenswert?

Das muss ja nicht mit 60-100Hz laufen sondern würde auch mit 1/5 davon 
oder weniger reichen. d.h. der µC oder was auch immer könnte immer 
abwechselnd die signale sammeln, dann auswerten und danach "ausgeben". 
also massig freie zeit

von Andreas L. (andi84)


Lesenswert?

Zumindest eine PLL wäre eigentlich schon nötig, um den Bildbereich 
aufzuteilen. Damit muss das Programm dann auch keine exakten timings 
mehr einhalten. Nur Kondensator habe ich auch mal simuliert, allerdings 
sind die Pixel dann halt nicht gleichgewichtet, so dass man wohl um 
einen OP als Integrierer nicht rumkommt.

von Andreas L. (andi84)


Lesenswert?

Zumindest eine PLL wäre eigentlich schon nötig, um den Bildbereich 
aufzuteilen. Damit muss das Programm dann auch keine exakten timings 
mehr einhalten. Nur Kondensator habe ich auch mal simuliert, allerdings 
sind die Pixel dann halt nicht gleichgewichtet, so dass man wohl um 
einen OP als Integrierer nicht rumkommt.
Man kommt übrigens mit einem Integrator pro Farbkanal aus, es werden nur 
die Kondensatoren umgeschaltet. Hat den Vorteil, dass man nicht 3x16 
Integratoren aus je OP, Widerstand und Kondensator braucht, sondern 
"nur" 48 Kondensatoren, 3 OPs und 3 Rs.
Um den Integrierer in einen definierten Zustand zu bingen, kann man den 
C nach dem Samplen dann auch einfach per AVR-Portpin entladen.

von Randy N. (huskynet)


Lesenswert?

> Wenn man dann noch mehrere LED-Module pro Rand nimmt, sollte das System
> dem Original durchaus etwas entgegenzusetzen haben.

Auf die Idee kam Philips mit "Ambilight Full Surround" auch schon :-)
http://www.computerbase.de/news/consumer_electronics/beamer_fernseher/2006/september/ifa_philips_flat-tv_100_zoll/

Wies aussieht sind das oben und unten je 4, und an den Seiten je 2 
LED-Module, wobei die Farben dort nicht wirklich wie der Durchschnitt 
von denen aus dem Bild aussehen. Oben rechts: woher kommt das Orange und 
Grün? Irgendwie scheint da noch mehr miteinbezogen zu werden - z.B. die 
Frau dort.

von Andreas L. (andi84)


Lesenswert?

Hmm, im gegensatz zum Ursprünglichen Ambilight scheint hier ganz 
ordentlich Bildverarbeitung dahinter zu stecken. Ganz so doll wird 
homebrew dann wohl nicht, aber man kann ja mal sehen, was man mit einem 
AVR draus machen kann...

von Jochen (Gast)


Lesenswert?

Hi,
schaut mal bei vdr-portal.de vorbei und  sucht dort mal nach 
"atmolight".

Ich hoffe man kann das hier lesen. Hab mit PIE geschrieben.

Gruss

von Paul H. (powl)


Lesenswert?

diese neue philipslösung sieht meines erachtens nach auch nich grad so 
toll aus. dann hätten sie schon mal die ganze leiste durchgehend fein 
aufgelöst mit LEDs bestücken können. Ist ja kein problem für die.

Ich find es besser wenn man für jede seite ein Modul hat. Oder wie wärs 
für jede Ecke? Also für jeweils 2 halbe Seiten in der Ecke? Wäre 
vielleicht sogar sinnvoller was Filme betrifft. Naja die Ideale Lösung 
wird man nicht finden :-)

mfg PoWl

von Andreas L. (andi84)


Lesenswert?

Ich werde wohl doch die Variante mit 64 Feldern versuchen. Gegenüber der 
16er ist nämlich praktisch nur die Software aufwändiger. Die Elektronik 
is fast gleich. Allerdings muss man irgendwie einbauen, dass man die 
Integratoren in bezug auf ihren skalierungsfaktor programmieren kann 
(ist zumindest mal wegen der verschiedenen Wiederholraten nötig). Soweit 
ich mich jetzt nicht irre, müsste die gesamtzeit, in der ein Segment 
während eines Frames adressiert wird ja bei gleicher wiederholrate 
unabhängig von der auflösung sein. Das macht die Sache deutlich 
leichter. Man braucht dann nämlich nur ein paar Presets berechnen und 
kann die dann mittels Mux umschalten (jaja, ich weiß ja, dass das ein 
CMOS Massengrab wird). Den rest kann man dann auch noch per Software 
kompensieren, indem man ggf. die gesamthelligkeit eines Frames irgendwie 
mittelt oder den Peak ermittelt, wodurch das Umgebungslicht dann bei 
dunklen Szenen auch schön dunkel ist. Bei der Werbung von Philips hab 
ich irgendwie immer das Gefühl, dass das Licht auch bei dunklen Szenen 
immer noch recht hell ist. Kann mich da jetzt aber auch gewaltig irren, 
da ich keinen Plasma von Philips, sondern gar keinen Fernseher hab. 
Daher ja auch mein Interesse an der VGA Version.
Fernsehtauglich sollte man das aber doch bekommen können, wenn man das 
Composite FBAS mit einem PAL-Dekoder in RGB+Sync umwandelt. Man muss 
dann nur die Sync separieren und gut ist der Kuchen. Dank der PLLs 
stellt sich die Schaltung dann innerhalb kurzer Zeit auf das PAL-Bild 
ein. Das mit dem interlaced sollte eigentlich egal sein, weil ja eh 
große Mengen Pixel zusammengefasst werden.
Was da auf jeden Fall auch eine Zeit brauchen wird, ist das Berechnen 
Sinnvoller Zeitkonstanten und anderer Bauteilparameter.
Ich hätte jetzt halt gerne, dass wenn z.B. im Film eine Nachtszene 
gezeigt wird und irgendwas explodiert, dass das Licht dann auch schnell 
reagiert, andererseits sollte es nicht zu nerös rumzappeln. Da ich aber 
sowieso Blockweise arbeiten werde muss der ganze Kram ja dann ohnehin in 
Software passieren.
Das wird wohl doch aufwändiger als gedacht, aber ich denke mal, dass für 
die Steuerelektronik immer noch sehr moderate Bauteilokosten rauskommen. 
Würde mal sagen, ohne AVR und LEDs und Co. sollte es nicht wirklich mehr 
als 10€ werden. Logikgatter sind billig und der Rest auch. Jedenfalls 
wird das mehr als eine halbe Eurokarte ausfüllen. Hoffe jetzt nur, dass 
die Platine einseitig bleiben kann. Wäre dann echt cool als 
Selbstbaulösung, da halbwegs einfach aufzubauen und auch nicht teuer.

MfG
Andreas

von Andreas L. (andi84)


Angehängte Dateien:

Lesenswert?

Hier mal ein Schnappschuss vom noch nicht fertigen Board. Das links sind 
die beiden PLLs, rechts sind zwei von drei benötigten umschaltbaren 
Kondensatorbänken. Durch den jeweils zweiten 4067 kann man mit nur drei 
ADC-Ports alle Spannungswerte auslesen. Über das DDRx des AVR kann man 
dan auch gleich noch den Kondensator entladen, wenn man fertig gemessen 
hat. Die Kondensatoren werden wohl sowas um die 100nF sein.
Könnte sogar wirklich einseitig klappen.
Allerdings werden's wohl zwei Platinen, da ich zumindest mal die 
LED-Endstufen nicht mehr da drauf bekomm, wenn ich kleiner gleich 
160x100 mm bleiben will, aber es gibt ja auch noch größere Standardmaße, 
die man noch mit ner A4 Folie belichten kann. Mal sehen, was draus wird.

von Paul F. (zwanzischmark)


Angehängte Dateien:

Lesenswert?

gibt es was neues bei dir Andreas?

Ich würde es gerne für den TV bauen, aber ich habe auch so eine TV->VGA 
BOX hier rumlieren die ich eh nicht benutze. Damit wäre ich mit deiner 
Methode sogar variabel und könnte es sowohl für PC als auch TV benutzen.
Dein Fachliches Wissen scheint mir auf dem Gebiet enorm zu sein, da kann 
ich nicht viel beisteuern.
Ich fänd (um einfacher zu bleiben) die 4x4 Methode sehr Interessant, 
würde aber mehr Lichtquellen verwenden als oben,unten,links,rechts. Und 
zwar würde ich zusätzliche LEDs für die Ecken einsetzen und für 
links/rechts und oben/unten jeweils die Mittleren Felder zusammenfassen. 
Ich hab mal versuch das in einem Bild zu verdeutlichen.

Wenn du sagst mit FBAS bzw. RGB ist es "einfach", dann könntest du auch 
einfach den TV Ausgang, den viele Grafikkarten haben nehmen, oder so nen 
billigen VGA->TV Adapter an den zweiten Ausgang hängen. Die Qualität ist 
ja ziemlich wurscht. Damit hättest du dann ausserdem die Lösung für TV 
gleich mitgeliefert.

Ich hoffe du arbeitest weiter an diesem Projekt und wirst bald 
Schaltpläne veröffentlichen :P.

von René (Gast)


Lesenswert?

Hallo andi84,

bist Du mit deinem Projekt schon weitergekommen?
Ich suche nach sowas für Veranstaltungen mit DMX Ausgabe Skalierbar bis 
von 1 bis auf max 16 Scheinwerfer. Mir fehlen aber die Grundlagen im 
Bezug auf Signalverarbeitung, wie bekommen ich das RGB Signal in den 
Controller
DMX ist kein Thema RGB LED Scheinwerfer pro Seite.

von Andreas L. (andi84)


Lesenswert?

hmm,
bin noch dabei, aber habe leider weniger zeit als ich dachte. Läuft halt 
alles nach dem schema "rechnen, kaufen, löten, fluchen, erröten - und 
dann wieder von vorn...", wobei ich irgendwo beim Rechnen stehen 
geblieben bin.
Falls ich demnächst mal etwas zeit finde versuche ich mich mal an den 
PLLs, dann ist schon recht viel getan. Wenn jemand in dem Thema 
drinsteckt, kann er ggf. ja auch den kram weiter oben als denkanstoß 
nutzen.
Die Kondensator und Widerstandswerte für die PLLs kann ich mal 
berechnen. Hab halt nur grad meinen Bastelkram nicht greifbar.

MfG
Andreas

von Andreas Bresch (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,
im Rahmen eines Projektes an der Uni sind wir dabei, genau das zu 
entwickeln.
Wir sind "kurz vor fertig" und werden in den nächsten Tagen testen und 
optimieren.

Unser Ansatz:
Der Bildschirm wird in seine vier Quadranten aufgeteilt. Es gibt einen 
Integrator und vier Sample&Hold-Glieder (pro Farbe, also x3). Es wird 
immer über einen Quadranten integriert, dann gesampelt, entladen und 
dann der nächste Quadrant beim nächsten Bild... Nach fünf Bildern hat 
man die Daten für alle Quadranten (ein Bild wird zwecks 
Kondensatorentladung zwischen 4. und 1. Quadrant ausgelassen).
Integrator an/aus, Addressierung der S&H-Glieder, Resetten der 
Integratoren und Auswerten der H- und VSycns übernimmt ein ATmega16 mit 
min. 16MHz.
PWM der Dioden haben wir hingegen analog mit Dreieckgenerator und 
Comperator gelöst.
Ferner übernimmt der uC die Aufgabe, die Gesamthelligkeit der LEDs zu 
regeln, da die Integrierzeit von der Bildwiederholfrequenz abhängig ist.

Im obigen Bild sieht man (nach einer 20-stündigen Programmiersession das 
noch nicht optimierte) Integratorsteuersignal. Man erkennt, daß der 
rechte untere Quadrant integriert wird. Grün: Vsync, Gelb: HSync und 
Blau Integratorsteuersignal (High: Integrieren).

Obigen Ansatz mit der Frequenzverdoppelung per PLL hatten wir auch im 
Auge, nur muß man aufpassen, da die unsymmetrischen 
Synchronisationssignale je nach Auflösung negiert werden (high-low).

Unsere Projektseite: http://ele12.wikidot.com/

von Andreas Bresch (Gast)


Angehängte Dateien:

Lesenswert?

Falls es interessiert: Wir sind fertig. Es folgen nur noch kosmetische 
Korrekturen. Wir mußten uns zwar noch ganz schön quälen, einige Probleme 
konnten wir per Software patchen an anderen Stellen mußten wir nochmal 
zum Lötkolben greifen, aber das Ergebnis kann sich sehen lassen...
Grüße von
Andreas

von Patrick .. (raptorsworld)


Lesenswert?

Hey Andreas,
super geniales Projekt!
Ist noch ein Scarteingang angedacht?
Bzw. wir der Quellcode oder HEX-File veröffentlicht zum nachbau?

Gruß aus Dortmund
Patrick

von Siegfried H. (daclubkiller)


Lesenswert?

Ist es möglich eine Bauanleitung von diesem Projekt zu bekommen?
Ich suche schon ewig nach sowas und euer Ergebnis finde ich echt super!
Respekt!!!

Gruß Siggi!

von Papsi (Gast)


Lesenswert?

Hallo,

http://www.vdr-wiki.de/wiki/index.php/Atmo-plugin

lässt sich auch über Windows ansteuern...

Gruß
Papsi

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.