RGB LED streifen in Durchschnittsfarbe vom Monitor Leuchten lassen

RGB mit je 75Ohm abschliessen 1K/10n Tiefpass und an drei ADCs. Probiers 
aus. ganz einfach. kaputt geht jedenfalls nichts. DVI-Buchse/Adapter zum 
zwischenstecken würd ich mir zusätzlich besorgen.

Danke für die schnellen Antworten!

Joachim B. schrieb:

> was ist eine Durchschnittsfarbe?
Wenn auf dem Monitor komplett Rotes Bild ist soll der LED Streifen Rot 
Leuchten, bei Grün Grün, Bei Blau Blau und eben alles dazwischen.

> wie hoch ist die maximale Videofrequenz?
Mein Monitor hat 60Hz wenn das gemeint ist...

> welche Sampletrate kann ein Arduino?
maximal 10 000 mal pro Sekunde. aber wenn noch andere Sachen danach im 
Programm sind wahrscheinlich weniger. Aber der Arduino muss ja nicht 
wissen, wo die Farben angezeigt werden, sondern nur welche Farben 
insgesamt.

> willst du als Farbe die vertikal oder horizontal Frequenz samplen?
Sorry hab keine Ahnung davon :(


Lothar M. schrieb:
> Ich vermute sehr, dass da auf dem analogen Port gar nie was rauskommt.
> Du solltest da also erstmal nachmessen, ob überhaupt ein Videosignal
> drauf ist.
geht das mit einem normalen Multimeter? Hab leider kein Oszilloskop.


Joachim B. schrieb:
> wenn er eine Grafikkarte mit einen echten DVI-I Ausgang hat dann liegt
> da auch VGA analog an
Ja ist ein "echter" DVI-I Ausgang


ÄXl schrieb:
> RGB mit je 75Ohm abschliessen 1K/10n Tiefpass und an drei ADCs.
Sorry für die wahrscheinlich dumme frage aber warum kann ich es nicht 
direkt an den Arduino anschließen?

> Probiers aus. ganz einfach. kaputt geht jedenfalls nichts. DVI-Buchse/Adapter 
zum
> zwischenstecken würd ich mir zusätzlich besorgen.
ich hab mir einen DVI Stecker zum Löten gekauft. Den Monitor würde ich 
dann über Displayport anschließen.

Joschua schrieb:
>> RGB mit je 75Ohm abschliessen 1K/10n Tiefpass und an drei ADCs.
> Sorry für die wahrscheinlich dumme frage aber warum kann ich es nicht
> direkt an den Arduino anschließen?

Weil es sich um HF Signale handelt. Ohne die richtigen 
Abschlusswiderstände entstehen in der Leitung Reflexionen, die das 
Signal total verzerren.

Joachim B. schrieb:
> Du kannst Vertikalfrequenz und Videofrequenz nicht unterscheiden.

Das ist bei einem RGB-Signal, von den er nur die durchschnittliche 
Farb-Intensität pro Kanal haben will, vollkommen egal.
Also einen RC-Filter pro Kanal und ab auf den AD-Eingang. 
Geschwindigkeit ist egal, nur schneller als das Auge sollte es sein.

Das schwierigste dürfte sein, die Grafikkarte zu überreden auf dem VGA 
das gleiche wie auf dem digitalen Ausgang auszugeben. Ein passend 
programmiertes I2C-Eprom könnte helfen.

Joschua schrieb:
> ÄXl schrieb:
>> RGB mit je 75Ohm abschliessen 1K/10n Tiefpass und an drei ADCs.
> Sorry für die wahrscheinlich dumme frage aber warum kann ich es nicht
> direkt an den Arduino anschließen?

Weil dein Arduino nicht mit mit mehr als dem doppelten der höchsten im 
Videosignal vorhandenen Frequenz abtasten kann. Selbst die 
Zeilenfrequenz wird du wohl nicht hinkriegen, d.h. du handelst dir 
Aliasing-Effekte ein. Wenn du dabei nicht weisst, was du tust, kannst du 
dir üble Blinkmuster und Flackereien einfangen.

Wolfgang schrieb:
> Weil dein Arduino nicht mit mit mehr als dem doppelten der höchsten im
> Videosignal vorhandenen Frequenz abtasten kann.

Na und? Der RC-Filter integriert das Signal ausreichend, daß kein 
Flackern auftritt. Idealerweise ist die höchste danach noch vorkommende 
Frequenz die Änderung der durchschnittlichen Farbe und bei einer 
Bildwiederholfrequenz von 60Hz kann die auf keinen Fall höher sein.

Joachim B. schrieb:
> ? dual Monitor spiegeln kann man doch einstellen wozu also ein
> I2C-EEPROM

Damit Windows auch die passende Auflösung am VGA zur Verfügung stellt. 
Sonst muß man von Hand einen passenden Monitortreiber reinbasteln.

Sind in den analogen RGB Signalen nicht auch Synchronisationsimpulse mit 
drin, welche zusammen mit einfachen Tiefpässen zu falschen Ergebnissen 
führen?

Jain.  RGB kennt 'Sync on Green' aber bei VGH gibt es eigenen HSync und 
VSync Signale. Aktuelle Karten verzichten daher afaik auf Sync on Green.
Da der Sync aber ein konstantes Signal ist, bewirkt das nach dem Filter 
nur einen etwas zu hohen Grünpegel und den kann man ja rausrechnen.

Mann kann ganz leicht mit der "Windows Taste" und "P" einstellen, dass 
der Monitor gespiegelt werden soll. Dazu müsste der Arduino aber  als 
Monitor erkannt werden, weswegen das so wahrscheinlich nicht 
funktioniert. mein Monitor ist aber bis jetzt mit einem DVI-D zu Hdmi 
kabel angeschlossen. Das heißt wenn ich ein Kabel Bastel, bei dem die 
digitalen Signale zum Hdmi gehen und die Analogen zum Arduino, und der 
Pc nicht zu "Faul" ist mir die Analogen Signale zu geben, könnte es 
funktionieren. Aber dann wäre dieser Teil halt nicht abgeschirmt.

Hat die Vertikale und Horizontale Frequenz was mit Multiplexing zu tun?

Soll ich sowas vor jeden Kanal schalten?
https://upload.wikimedia.org/wikipedia/commons/e/e8/Tiefpass.svg

Würde ein Flackern entstehen, wenn sich irgendeine Frequenz mit der 
Abtastfrequenz vom Arduino überschneidet Ähnlich wie bei Kameras? Dann 
könnte ich ja einfach ein kleines Delay in das Programm machen.

Ich Denke ich warte einfach bis die bestellten Sachen da sind und weil 
niemand gesagt hat das ich dadurch meinen Pc in die Luft jage werde ich 
es einfach ausprobieren.

Joschua schrieb:
> Hat die Vertikale und Horizontale Frequenz was mit Multiplexing zu tun?

Nein, mit dem Bildaufbau. Der HSync bestimmt wann ein neuer Pixel kommt, 
der VSync beginnt eine neue Zeile.

Joschua schrieb:
> Soll ich sowas vor jeden Kanal schalten?

Ja.

Joschua schrieb:
> Würde ein Flackern entstehen, wenn sich irgendeine Frequenz mit der
> Abtastfrequenz vom Arduino überschneidet Ähnlich wie bei Kameras?

Probier es aus, bei passender RC-Kombination sollte kein Flackern 
entstehen.

Mein Gott sind hier Pessimisten unterwegs...

Das RGB Signal vom VGA zu nehmen klappt ganz einfach.

Oder du baust dir gleich Atomlight nach (also ein Phillips ambilight 
Klon). Dann hast du nicht nur eine Farbe sondern:
https://www.instructables.com/id/Cheap-Ambilight-Tutorial-for-PC-Using-Arduino/

Horst schrieb:
> Na und? Der RC-Filter integriert das Signal ausreichend, daß kein
> Flackern auftritt.

Der ist aber nicht da, wenn du die Frage mal liest.

Es ging darum, das Videosignal direkt an den Arduino anzuschließen - 
eben ohne Filter.

Horst schrieb:
> Nein, mit dem Bildaufbau. Der HSync bestimmt wann ein neuer Pixel kommt,
> der VSync beginnt eine neue Zeile.

Quatsch.
HSync sagt, wann eine neue Zeile kommt,
VSync sagt, wann ein neues Bild kommt.

Wolfgang schrieb:
> Der ist aber nicht da, wenn du die Frage mal liest.

Das der da hin soll ist doch schon geklärt.ÄXl hat doch auch schon Werte 
vorgeschlagen.

Wolfgang schrieb:
> Quatsch.
> HSync sagt, wann eine neue Zeile kommt,
> VSync sagt, wann ein neues Bild kommt.

Du hast natürlich Recht, ich war gedanklich noch beim Pixelclock des LCD 
das ich gestern hearbeitet habe.

Joschua schrieb:
> Sorry für die wahrscheinlich dumme frage aber warum kann ich es nicht
> direkt an den Arduino anschließen?

Dieses war die Frage, k.A. was du unter "direkt" verstehst.

Horst schrieb:
> Das der da hin soll ist doch schon geklärt.ÄXl hat doch auch schon Werte
> vorgeschlagen.

M. Keller schrieb:
> Mein Gott sind hier Pessimisten unterwegs...
> Das RGB Signal vom VGA zu nehmen klappt ganz einfach.

Ja Schlaumeier, er hat aber keinen VGA Anschluss!

Joschua schrieb:
> Und glaubt Ihr, dass mein Vorhaben Grundsätzlich funktioniert?

Nein. DVI ist meist digital. Da müsstest du schon "reinhorchen", und das 
ist nicht ganz untrivial, und mit dem Arduino (mangels TMDS-Eingang) 
nicht möglich.

Bei VGA sieht die Sache möglicherweise anders aus, aber da kenn ich mich 
nicht aus. Musst du in der Museumsecke fragen ;-)

Ich persönlich würde vorschlagen, du verwendest einen I2C RGB Farbsensor 
wie den hier:
https://ams.com/tcs34725

Und lässt den irgenwie auf den Bildschirm kucken.
Der liefert dir dann einen Wert für rot, grün, blau und Helligkeit, den 
man recht einfach auswerten kann.

am DVI kommt auch RGB analog mit raus. Ob die Karte das mit ausgibt, 
weiss ich nicht. Die Monitore "unterhalten" sich via I2C mit der Graka. 
Wenn dort kein Monitor drann ist, kommt auch nix raus. Muss man eben 
ausprobieren. kaputt gehen wird wohl nix.
ich schrieb oben selbst: mit 75Ohm abschliessen und mit 1K/10n weiter.
Du schriebst etwas weiter unten mit einem Verweiss auf ein RC-Tiefpass 
(wikipedia), ob Du "sowas" vor den ADC schalten sollst:

lass es.

man muss ich von allem Ahung haben. Ist nicht schlimm.
Aber wenn ich oben schrieb, wie Du es probieren köntest und du im 
Nachgang die gleiche frage nochmal stellst: was soll ich denken?

ÄXl schrieb:
> RGB mit je 75Ohm abschliessen 1K/10n Tiefpass und an drei ADCs.


Joschua schrieb:
> Soll ich sowas vor jeden Kanal schalten?
> https://upload.wikimedia.org/wikipedia/commons/e/e8/Tiefpass.svg

Joachim B. schrieb:
> wenn er eine Grafikkarte mit einen echten DVI-I Ausgang hat dann liegt
> da auch VGA analog an

soso... schrieb:
> Nein. DVI ist meist digital. Da müsstest du schon "reinhorchen", und das
> ist nicht ganz untrivial, und mit dem Arduino (mangels TMDS-Eingang)
> nicht möglich.

Liest der, der antwortet, sich den Thread durch?
Es werden ständig alle infos gegeben, angezweifelt und der nächste 
wiederholt alles nocheinmal...

ÄXl schrieb:
> Liest der, der antwortet, sich den Thread durch?
> Es werden ständig alle infos gegeben, angezweifelt und der nächste
> wiederholt alles nocheinmal...

ich wollte jetzt nicht mit langmächtigen Erklärungen kommen, aber es ist 
so:
Du musst dem DVI-Port schon mitteilen, dass du das analoge Signal haben 
willst.

Auch das wurde schon erwähnt - über die DDC. Und jeder halbwegs moderne 
Monitor wird nur ein digitales Signal anfordern.

Wenn du nicht an der EDID des Monitors herumfummeln willst (auch 
untrivial ;-)) wird nichts anderes übrigbleiben, als sich in die 
LVDS-Leitungen einzuklinken.

sehr gut.


(was machen die Moderatoren eigentlich? dafür sind es zu wenige.)

soso... schrieb:
> Wenn du nicht an der EDID des Monitors herumfummeln willst (auch
> untrivial ;-))

Naja, ein I2C-Prom (24C02) beschreiben ist inzwischen schon trivial und 
mehr braucht VGA nicht, aber auch das wurde oben schon erwähnt.
Da der Thread jetzt im Kreis läuft bin ich raus.

Nochmal danke für die vielen Antworten, auch wenn vieles wiederholt 
werden musste, weil manche nicht lesen können.

Wie gesagt ich werde es einfach mal auf die verschiedene Arten 
ausprobieren.
Und ja es immer noch ist ein echter DVI-I Anschluss zumindest laut 
Nvidia.

M. Keller schrieb:
> Oder du baust dir gleich Atomlight nach (also ein Phillips ambilight
> Klon). Dann hast du nicht nur eine Farbe sondern:
> https://www.instructables.com/id/Cheap-Ambilight-Tutorial-for-PC-Using-Arduino/

Diese Anleitung ist auch sehr interessant für mich.

Joschua schrieb:
> Hallo,
>
> ich möchte versuchen mit einem Arduino einen RGB LED Streifen in der
> Durchschnittsfarbe des Monitors leuchten zu lassen

Schreib einfach "Ambilight" - das verstehen fast alle. Du kannst mal bei 
Philipps anfragen - die haben (denke ich) ein Patent darauf.

Dieter F. schrieb:

> Schreib einfach "Ambilight" - das verstehen fast alle. Du kannst mal bei
> Philipps anfragen - die haben (denke ich) ein Patent darauf.

Ja, dessen claims gehen aber deutlich über das hinaus, was der TO will. 
Und das aus gutem Grund. Falls der TO es nämlich jemals gebacken 
bekommt, seinen Plan umzusetzen (woran ich sehr ernsthaft zweifele, 
obwohl es technisch natürlich möglich und nichtmal allzu kompliziert 
ist, bloß für Arduino-Software wird es hier schon "etwas" eng...), wird 
er nämlich feststellen, dass das Ergebnis seines Ansatzes in vielen 
Fällen schlicht Scheisse "aussieht" (im Kern: nicht den erwünschten 
Eindruck einer "Erweiterung" des Bildinhalts produziert)...

Und um das umzusetzen, was Ambilight tatsächlich bedeutet, muss man 
schon deutlich schwerere Geschütze auffahren, als ein wenig 
Arduino-Gestümpere. Mit Asm auf AVR8 klappt das schon hinreichend gut. 
Damit kann man nicht nur den I2C-Kram bedienen, sondern auch ein paar 
Samples von definierten Positionen gewinnen. Natürlich immer noch sehr 
weit weg von der tatsächlichen Auflösung des Videos, aber immerhin dicht 
genug, um tatsächlich ein Ambilight mit Philipps-Qualität erzeugen zu 
können...

Asm rules, nothing else...

c-hater schrieb:
> Mit Asm auf AVR8 klappt das schon hinreichend gut.

Nichts anderes hätte ich von Dir erwartet :-)

Dieter F. schrieb:

> Nichts anderes hätte ich von Dir erwartet :-)

Und ich nichts anderes von dir. Dein Weg ist: nehmen wir doch einfach 
eine Maschine, die 1000..10000mal mehr Energie verbraucht, dann klappt 
das auch mit C/C++ ohne jegliche Probleme...

c-hater schrieb:
> Mit Asm auf AVR8 klappt das schon hinreichend gut.
> Asm rules, nothing else...

95% was man mit Assembler machen kann, kann man z.B. mit C ebenso gut. 
Wenn man einen etwas leistungsstärkeren µC wählt, kann man 99% mit C 
umsetzen.

Es ist sicher nicht schlecht, sich mal mit Assembler zu beschäftigen. 
Wer aber die Linie verfolgt, dass man gefälligst alles in Assembler zu 
programmieren hat, steht auch auf Faustkeile und schmiedet sich jedes 
Metallteil selbst im Kohleofen.

Warum gibst Du dich eigentlich mit einem Computer ab, der überwiegend in 
C programmiert wurde?

Ich verschwende meine Zeit auf wesentlich angenehmere Art, zum Beispiel 
hier.

Hi

>95% was man mit Assembler machen kann, kann man z.B. mit C ebenso gut.

Und das was man in C machen kann, geht immer zu 100% in Assembler.

MfG Spess

Hi

>Wie schätzt Du den Zeitaufwand der Portierung von Linux auf 100%
>Assembler?

Ist doch uninteressant, denn das macht meine Aussage nicht falscher.

Es sei denn es tauchen Prozessoren auf, die ohne Compiler/Linker etc. 
C-Code direkt verarbeiten.

MfG Spess

Wenn Assembler grundsätzlich besser wäre, als Hochsprachen, sind dann 
auch

...Taschenrechner besser als Tabellenkalkulationen wie Excel?

...Kett-Karts besser als Go-Karts?

...Arbeitspferde besser als Traktoren?

...Zeichenbretter mit Tusche-Stiften besser als CAD Programme?

Es hat schon seinen Grund, warum wir Maschinen erfunden haben, die uns 
einen großen Teil der Arbeit abnehmen. Und ich bin davon überzeugt, dass 
dieser Weg im Groben und Ganzen eine gute Idee war

Du kannst im ADC-Interrupt ein Portpin setzen und diesen mit 22pF auf 
"R", "G" oder "B" klemmen. dann siehst Du sehr schön anhand der kleinen 
Punkte auf dem Monitor (ich hatte zusätzlichen einen Monitor an den 
Leitungen drann), wann der ADC wandelt. Denn: er darf tatsächlich nicht 
in den Sync-Pausen wandeln, oder diese besoders tiefen Werte ignorieren 
oder als Startbedingung nutzen, die Wandlung einzuleiten. So schnell 
muss man da auch nicht wandeln. Wenn man immer ein wenig später 
einsetzt, hat man auch irgendwann viele Pixel einer Zeile in einem 
deterministischem Abstand erwischt. Man ist zwar nicht topaktuell am 
Zeitgeschehen drann (also nicht bildgenau), quasi sowas wie ne 
Unterabtastung, aber bei weitem schnell genug, linken und rechten, 
oberen und unteren Bildanteil in vier Arrays zu halten.
RGB ist ja noch einfach. Ich hatte damals(tm) den FBAS (gelber 
chinc-Stecker) ausgewertet. War bissl komplizierter...

Ich habe gerade eben ausprobiert, den Monitor über Displayport und den 
Arduino an die Analogen RGB Pins vom DVI anzuschließen. Zuerst kam kein 
Signal bei DVI raus aber in den Einstellungen kann man einstellen, dass 
der Pc trotzdem ein VGA Signal senden soll und dann hat es funktioniert. 
Komischerweise konnte ich keine Pinbelegungstabelle finden, die damit 
übereinstimmt, wie ich es gerade angeschlossen habe. Nach diesen 
Tabellen habe ich Rot und Blau vertauscht und Grün an Hsync.
Wie einige schon gesagt haben flackert es noch sehr. Ich werde es noch 
mit einem Rc filter versuchen und vielleicht hilft es auch ein 
abgeschirmtes USB kabel dafür zu verwenden.