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

Hallo Eberhard,

Zitat

Das ist schon klar, zuruecklesen brauche ich vermutlich nicht. Ich pack' die Kalibrierungswerte in das EPROM auf dem Controller.

Na dann könntest du das Protokoll schon auch verwenden...

Zitat

Wirklich groesser 1 ???

Sorry, bytes vertauscht:

0xFF = Startbyte immer 0xFF
0x00 = Startadresse des Blocks LSB kann alle Werte annehmen
0x00 = Startadresse des Block MSB nur 0x00 und 0x01 sind gültig
0x0F = Länge des Blocks

Wenn du also das 3. Byte auf Werte > 1 setzt, wird das Frame vom dmx4all controller ignoriert; unser RGB Controller mag nicht mal die 1, aber das sollte nicht ausschlaggebend sein um die Kompatibilität zum dmx4all zu bewahren.

Zusammenfassung:
das 3. Byte kann verwendet werden um besondere Modi für die CCFL zu implementieren.

Wenn ichs mir recht überlege kannst du so auch die anderen Modi realisieren...

Grundsätzlich könnte das Gerät auch einen ID-String zurücksenden, nur ist das momentan nicht vorgesehen (auch nicht auf dem Layout) da:
die Platinen dürfen von einer zur nächsten durchgeschliffen werden, Rückmeldungen müssten bei diesem Verfahren aber ja bei jedem Controller "durchgereicht" werden -> umständlich.

Vielleicht könnte sich der CCFL Controller ja auf Befehl selbst kalibrieren?
is ja auch nur Mathematik..

So jetzt hab ich dich endlich völlig verwirrt, oder ?

Grüße,
Simon

Zitat

So jetzt hab ich dich endlich völlig verwirrt, oder ?

Nö, ganz im Gegenteil!

Zitat

das 3. Byte kann verwendet werden um besondere Modi für die CCFL zu implementieren.

Gute Idee -> fuer spaeter. Eins nach dem anderen...

Gruss
Eberhard

Fuer die Jung's der LED Fraktion

weil ich gerade als alter Modellflieger ueber eine Seite gestolpert bin: Hier gibt's auch Hochleistungs- (SuperFlux) LED's: http://www.optotronix.de/

Eberhard

Hallo,

so, der Peter und ich haben gestern die Verbindung zwischen Plugin und Hardware getestet und schließlich zum Laufen gebracht.

daniel: einzig das Lesen aus dem EEPROM tut noch nicht, er liest da meistens nur FF. Wenn ich mit Ponyprog 00 reinschreibe und danach wieder lese kommt wieder FF, kann es da ein grundlegendes Problem geben? Muss man irgendwas freischalten?
So wirds gemacht in der Firmware:
Pointer setzen,
Lesebit setzen
Register auslesen.
Probiers doch mal aus, vielleicht kommst du dahinter: (mit Jumpern gehts einwandfrei jetzt)
Firmware
Damit alle Kanäle übetragen werden müssen die tcflush Befehle nach den writes auf die ttySxx gegen tcdrain(dev_handle); ausgetauscht werden, sonst verschluckt er den hinteren Teil der Telegramme.
Die Quarzfrequenz 14,75irgendwas MHz ist auch getestet.

@peter:
die Baud-Rate deines Controllers steht noch auf 19.2, das müssen wir dann noch ändern!

@Eberhard:
Danke für den Link, der hat aber leider nur R und G, kein B
Wär wohl eh zu teuer..
Ein bischen wirds wohl noch dauern, bis die aktuelle Plugin (alpha?)Version wieder was sinnvolles ausgibt, dann schreibe ich deine Ausgaberoutine mit rein, dann schau mer mal
-> und wenns tut dann kannst du ja mit aufs neue Protokoll aufspringen

...wird schon das Ganze

Grüße, Simon

Hallo Jungs (und Mädls falls es die im VDR Board gibt ),

hab gerad den Contoler von Simon in betrieb genommen und was soll ich sagen:

GEIL!!!!!!

jetzt mach das plugin schreiben gleich noch mehr spass.
Haben gestern auch festgestellt, das die verarbeitung so, na ja sagen wir mal eher suboptimal ist. sprich wir haben im moment 85% CPU usage auf 2Ghz systemen

Haben uns aber schon einige optimierungen einfallen lassen die halt jetzt noch gecoded werden müssen. Mal sehen was ich heute und morgen noch auf die reihe bekommen.

@Simon: Da muss ich halt noch mal zu dir kommen zum Flashen und anschliesen gehen wir dann in den Biergarten und Flashen uns selber

so long
Peter

Hallo,

Zitat

daniel: einzig das Lesen aus dem EEPROM tut noch nicht, er liest da meistens nur FF. Wenn ich mit Ponyprog 00 reinschreibe und danach wieder lese kommt wieder FF, kann es da ein grundlegendes Problem geben? Muss man irgendwas freischalten?

Wie, beim Auslesen mit Ponyprog? Sehe ich mir mal an, ich meine aber das ging bei mir...

Zitat

So wirds gemacht in der Firmware:
Pointer setzen,
Lesebit setzen
Register auslesen.
Probiers doch mal aus, vielleicht kommst du dahinter: (mit Jumpern gehts einwandfrei jetzt)

Schau ich mir bei Gelegenheit mal an, hab heute mit der "Serienproduktion" begonnen: 3 Controller und 15 LED-Streifen liegen nun auf dem Balkon zum trocknen. Fotos lege ich demnächst auf den Server.

EDIT: Fotos

Zitat

Haben gestern auch festgestellt, das die verarbeitung so, na ja sagen wir mal eher suboptimal ist. sprich wir haben im moment 85% CPU usage auf 2Ghz systemen Augen rollen
Haben uns aber schon einige optimierungen einfallen lassen die halt jetzt noch gecoded werden müssen. Mal sehen was ich heute und morgen noch auf die reihe bekommen.

Wow, 85%? Ganz schön heftig, das wird die Jungs der 500MHz-Klasse ja nicht gerade freuen... Liegt das an ImageMagick oder ist der Berechnung mittlerweile einfach so aufwendig?

Gruß,
Daniel

Hallo Simon,

Zitat

Ein bischen wirds wohl noch dauern, bis die aktuelle Plugin (alpha?)Version wieder was sinnvolles ausgibt, dann schreibe ich deine Ausgaberoutine mit rein, dann schau mer mal

jo, das machen wir so.

Gruss
Eberhard

Hi @ll,

also bzgl. Performance bin ich gerade am basteln.
Also zum einen ist IM einfach zu langsam. Das hab ich gelernt aber die arbeit
war jedenfalls nicht umsonst, denn jetzt hab ich endlich c
begriffen

des weitern war der code nicht optimal geschrieben weil er viele viele sachen doppelt und dreifach ausgeführt hat was gar nicht sein muss.

wie gesagt mach gerade ein rewrite. Bisher schauts ganz ordentlich aus. Mehr dazu die nächsten tage

so long
Peter

Halllo zusammen,

man glaubt es kaum, aber die CPU usage ist jetzt von 85% auf 7% runter

Morgen, sofern zeit müssen noch einige filter rein ....

Ich geh jetzt schlafen. Gute Nacht
Peter

Guten Morgen,

fishbonev:

sauber, bist immernoch bei IM?
Des mit dem Biergarten müssen wir unbedingt machen sobald das Wetter wieder mitmacht...

daniel:
Hmm, ja also bin da nicht so recht schlau draus geworden, war auch schon spät aber trotzdem..also:
1)im Simulator in AVTStudio hat er immer FF gelesen
2)mit Ponyprog ausgelsesen -> FF
3)Image in Ponyprog geändert, wieder reingeschrieben, dann "New" in Ponyprog und wieder ausgelesen-> FF

manchmal hat der Controlelr auf ein geschriebenes 00 reagiert, aber irgendwie nicht reproduzierbar.

saubere Sache deine "Serienproduktion"...der Reichelt Katalog hat ja wirklich eine ganze Menge Seiten

Grüße,
Simon

Zitat

[i]Original von ke2705
...Wir sollten die Jungs, die damals auf das CCFL Thema aufgesprungen sind, nicht vergessen!

Hallo,

das finde ich sehr lobenswert, da ich auch zur CCFL-Fraktion bzw. zu den
Besitzern der Röhren gehöre. Leider tut sich im Moment im anderen
Thread nicht viel.
Da ich zur elektrischen Seite nichts beitragen kann, wäre ich bereit
meine Röhren zu Testzwecken zur Verfügung zu stellen.

Gruß Kail

Hallo zusammen,

aktueller status ist, dass das plugin soweit funktioniert.

die farbbestimmung erfolg in abhängigkeit vom abstand zum rand. sprich farben am rand sind dominanter bei der auswertung als andere.
Dadurch entsteht der eindruck der fortführung des displays. Das soll ja auch so sein

Des weiteren ist die Saturation detection jetzt auch mit gewichtung (mit identischer funktionn wie bei Hue)
Dadurch wird die farbe des "randes" exakt weiterprojeziert und nicht nur der ungefäre farbton.

Des weiteren gibt es jetzt zur luminance berechenung entweder die
möglichkeit des mittelwertes. dadurch bleibt die beleuchtung (unter
einbeziehung eines darkness limits) immer auf einem mehr oder weniger
identischem level.

Weiter wird man auch die gewichtungsfunktion auf die luminanc anwenden, was folgende effekte bewirkt:
zum einen wird bei einem signal mit schwarzem rand oben und unten auch die beleuchtung oben und unten gedimmt (abhängig von randbreite).
Zum anderen ist der gesamteindruck "dynamischer", da die helligkeit einen größeren dynamikbereich erhält und somit bei "düsteren" bildern auch die beleuchtung zurück geht. Bei "grellen" hingegen ist die beleuchtung natürlich auch hell.

Der einzige Bug den ich noch drinnen habe ist, dass bei dominanter schwarzer farbe grün dargestellt wird. Ich denke das liegt daran, dass offensichtlich im "scharz" bereits ein "grünanteil" drinnen ist.
Bitte verlangt jetzt keine genau erläuterung. das muss ich noch testen und mir die histogramme genauer anschauen.

Werd morgen die Sourcen noch sauber machen und noch die hardgecodeten parameter ins OSD Setup übernehmen und wenn alles gut läuft dann kann ichs morgen online stellen

Bis die Tage
Peter

Hallo,

na das hört sich doch schon toll an!

Bin gespannt aufs Testen!

Zitat

Des weiteren gibt es jetzt zur luminance berechenung entweder die
möglichkeit des mittelwertes. dadurch bleibt die beleuchtung (unter
einbeziehung eines darkness limits) immer auf einem mehr oder weniger
identischem level.

gibts noch eine andere Möglichkeit ?

Zitat

Weiter wird man auch die gewichtungsfunktion auf die luminanc anwenden, was folgende effekte bewirkt:
zum einen wird bei einem signal mit schwarzem rand oben und unten auch die beleuchtung oben und unten gedimmt (abhängig von randbreite).
Zum anderen ist der gesamteindruck "dynamischer", da die helligkeit einen größeren dynamikbereich erhält und somit bei "düsteren" bildern auch die beleuchtung zurück geht. Bei "grellen" hingegen ist die beleuchtung natürlich auch hell.

Spielt das Darkness Limit nicht auch mit beim Berechnen des liminance Mittelwerts?

Kail:
Ich könnte mir vorstellen das Eberhard den nächsten Test macht, also ob diese neue LED-Version dann auch it den CCFLs tut.
Sollte es notwendig/wünschenswert sein die CCFLs in einem weiteren Bereich zu dimmen, dann muss wohl ein anderer Controller her. Hab da ja schonmal was dazu geschrieben. Sollte ich mal Zeit/Bauteile finden um was neues zu bauen komme ich gern auf dein Angebot zurück (oder jemand anders?)

Grüße,
Simon

Hallo,
das klingt ja klasse! Hoffentlich komme ich am Wochenende endlich mal dazu, mir die Sache mit dem EEPROM anzusehen.

Zitat

Der einzige Bug den ich noch drinnen habe ist, dass bei dominanter schwarzer farbe grün dargestellt wird. Ich denke das liegt daran, dass offensichtlich im "scharz" bereits ein "grünanteil" drinnen ist.
Bitte verlangt jetzt keine genau erläuterung. das muss ich noch testen und mir die histogramme genauer anschauen.

Die Erklärung ist wahrscheinlich die MPEG-Kompression. Diesen Effekt haben wir damals auch schon festgestellt und daraufhin das "Darkness Limit" erfunden. Bei den CCFLs war der Effekt richtig übel, denn die konnten wir nicht richtig runter dimmen und man hatte immer ein sattes grün.

Zitat

Werd morgen die Sourcen noch sauber machen und noch die hardgecodeten parameter ins OSD Setup übernehmen und wenn alles gut läuft dann kann ichs morgen online stellen

Immer her damit, freue mich schon tierisch aufs Testen!

Gruß,
Daniel

Hallo zusammen,

also, wie versprochen gibts heute mal einen neuen software download.

vdr-atmo-0.0.1.f.tgz

Bilder gibts auch

Für die Kanalbelegung am Controler:

0=Center
1=Left
2=Reight
3=Top
4=Bottom

Also frohes Testen
Peter

Hallo,

und nochmal eine aktualisierte Version des Plugins:

atmolight-0.0.1.g

Das "grün" Problem ist behoben; die ImageMagick lib ist nicht mehr erforderlich zum compilieren.

@Eberhard:
Das 4. Byte des Telegramms wird immernoch als 0x0F gesendet, bleibt erstmal so bis ich die Firmware angepasst habe, so dass sie einen beliebigen Wert akzeptiert -> wird also noch gemacht.

@Peter:
Mit der HSV Methode und dem 2. Histogramm funktionierts jetzt wieder so gut wie die 0.0.1-1 Version.
Dank deiner wunderbaren Histogrammanalyse aber sogar noch viel viel besser!! Die Farben werden sicherer erkannt, es gibt nur noch sehr wenig Flackern trotz des "schelchten" Filters. Gut gemacht!
Deinen Ansatz die Dominanz mit auszuwerten halte ich für sehr vielversprechend, auch wenn ich noch nicht genau weiss wies gemacht werden soll. Fällt dir vielleicht was dazu ein?
Für die Gewichtung des Kanals 0 ist mir folgendes eingefallen:
ein zentrales atmolight ist an allen 4 Kanten sichtbar. Deshalb finde ich es sinnvoll für den Kanal 0 eine Gewichtung nach allen 4 Seiten zu realisieren, also alle weight[1..4] zusammenzählen. Was hältst du davon?

daniel:
Bist du weitergekommen am WE? Hast meinen Fehler gefunden ?
Langsam könnten wir doch den Wiki-Eintrag angreifen, oder? Kann mir denken, dass einige Leute gern eine Zusammenfassung lesen würden...was meinst du?

Grüße,
Simon

Hallo,

Zitat

Bist du weitergekommen am WE? Hast meinen Fehler gefunden ?

Nein, bin am WE leider nicht zu testen gekommen, will ich aber heute nachholen.

Zitat

Langsam könnten wir doch den Wiki-Eintrag angreifen, oder? Kann mir denken, dass einige Leute gern eine Zusammenfassung lesen würden...was meinst du?

Das mit der Zusammenfassung finde ich eine gute Idee, da mache ich gerne mit. Wie wollen wir vorgehen?

Eine Frage hätte ich noch: Was haltet Ihr davon, statt direkt auf das video0-device zuzugreifen, die vdr-Funktion "grabImage" zu verwenden? Hintergrund: wenn ich mit atmo-Plugin starte, komme ich der vdradmin nicht mehr aufs device, da das plugin es schon geöffnet hat.

Gruß,
Daniel

Zitat

Originally posted by fishbonev
Weiter wird man auch die gewichtungsfunktion auf die luminanc anwenden, was folgende effekte bewirkt:
zum einen wird bei einem signal mit schwarzem rand oben und unten auch die beleuchtung oben und unten gedimmt (abhängig von randbreite).

Könnte man es ggf. konfiguierbar machen, ob die schwarzen Ränder oben und unten mit in die Berechnung mit eingehen oder nicht? Hintergrund: Viele Sender senden 16:9 Material nich anamorph, also mit schwarzem Rand, der (16:9) fernseher zoomt, das Bild dann entsprechend auf, so dass es die Bildfläche ausfüllt - die schwarzen Balken werden also nicht dargestellt, würden vom Plugin aber dennoch in die Berechnung mit einbezogen -> oben und untern wäre die Beleuchtung zu dunkel.

Ansonsten aber auch von mir ein gaaannnz riesen Lob in die Runde! Echt klasse, was hier in den letzen Wochen und Monaten aus dem Boden gestampft wurde!

Gruß
Skobi

Hallo,

skobi:
Konfigurierbar kann man ja alles machen :-).
Bei der g Version machts eh keinen Unterschied, was dir Zukunft bringt werden wir sehen...da gibts bestimmt eine einfache Lösung.

daniel:
Tja, ein guter Romanschreiber war ich nocht nie, aber versuchen wirs mal:
1) Einteilung in Software/Hardware:
Ich denke, dass es im Moment für die Meisten Leute interessant wäre, genau zu wissen was sie sich kaufen/bauen müssen um atmolight zu bekommen. Die Softwareseite können wir ja dann erklären, wenn wir mal eine 0.0.2 Version machen/der Erste Algorihtmus erstmal "abgenommen" ist.
2) Beschreibung der Hardware:
Erklären wie eben wie unsere Controller funktionieren, mit allen Vor- und Nachteilen, Anwendungsgebiet.
Dazu welche LEDs benötigt werden/verwendet werden dürfen.
Eberhard kann ja später seine CCFL Variante dazusetzen wenn sie befriedigend läuft.
3) Beschreibung der Software:
Downloadlink, Installationsanweisung, Beschreibung der div. OSD Parameter ect.
4) Dicker Hinweis darauf, dass die Hardware zwar "fertig" ist, die Software aber beta.
Was meinst du?

Grabimage:
Ja, wenn das gehen sollte wärs wahrscheinlich ideal...hast du da einen Einstieg?

Grüße,
Simon

Hallo Simon,
bin jetzt endlich zum Testen gekommen->Version G auf VDR, 1.5 auf den
Controller, 0x11 ins EEPROM an Adresse 0x2000 -> Erfolg!!!!!
Aber erst einmal ein riesen Lob an Euch für die Bilderkennung!
Funktioniert 1a! Fürs debugging würde ich mir mindestens im raw-mode
ne Einzelansteuerung der Kanäle wünschen, vielleicht baue ich das heute
noch mal ein.
Bzgl. Wiki-Eintrag: Wenn ichs schaffe, fange ich heute schon mal an und
schicke Dir nen ersten Entwurf.

Gruß,
Daniel