Hallo, ich möchte versuchen mit einem Arduino einen RGB LED Streifen in der Durchschnittsfarbe des Monitors leuchten zu lassen. Meine Grafikkarte hat einen DVI-I Anschluss. Deswegen dachte ich, das man einfach die Masse mit Ground vom Arduino und die drei Analogen Pins Rot, Grün und Blau mit je einem Analogen Eingang verbindet. Ich habe schon mal ein bisschen über DVI durchgelesen. Im Internet Stand, dass der Computer mit dem Monitor kommuniziert also ihm den Hersteller und unterstützte Videomodi etc. "mitteilt". Deswegen weiß ich nicht, ob der Pc dauerhaft ein Analoges Signal sendet oder nur wenn der "Monitor(bei mir dann also der Arduino)" das Analoge Signal überhaupt braucht. Und glaubt Ihr, dass mein Vorhaben Grundsätzlich funktioniert? Viele Grüße, Joschua
Joschua schrieb: > Und glaubt Ihr, dass mein Vorhaben Grundsätzlich funktioniert? nein was ist eine Durchschnittsfarbe? wie hoch ist die maximale Videofrequenz? welche Sampletrate kann ein Arduino? willst du als Farbe die vertikal oder horizontal Frequenz samplen? ist schon wieder Freitag?
Joschua schrieb: > ob der Pc dauerhaft ein Analoges Signal sendet 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.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ich vermute sehr, dass da auf dem analogen Port gar nie was rauskommt. wenn er eine Grafikkarte mit einen echten DVI-I Ausgang hat dann liegt da auch VGA analog an DVI-I https://de.wikipedia.org/wiki/Digital_Visual_Interface sowohl analoge wie auch digitale (DVI-I)
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.
Joschua schrieb: > Joachim B. schrieb: >> wie hoch ist die maximale Videofrequenz? > Mein Monitor hat 60Hz wenn das gemeint ist... ist nicht die Videofrequenz > 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 :( das ist das Problem Du kannst Vertikalfrequenz und Videofrequenz nicht unterscheiden. Du willst analog am DVI ausgeben OK aber wenn du zusätzlich am Displayport ausgibts dann siehst du am VGA ja nur den 2ten Monitor. Wenn du die Grafik auf beide Monitore spiegelst damit beide Ausgaben gleich sind bist du natürlich in der Pixelzahl eingeschränkt oder du drehst hoch dann alle Frequenzen und ann wirst du noch weniger vom ADC mitbekommem. Kurzum es wird nicht klappen oder wenn kaum so wie du denkst, irgendwas wird der Arduino schon wandeln, ich tippe auf Synchronimpulse
:
Bearbeitet durch User
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.
Horst schrieb: > 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. dann nenne es von mir aus Pixeltakt > Also einen RC-Filter pro Kanal und ab auf den AD-Eingang. > Geschwindigkeit ist egal, nur schneller als das Auge sollte es sein. ja irgendwas wird rauskommen, ob es das ist was der TO will.... > 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. ? dual Monitor spiegeln kann man doch einstellen wozu also ein I2C-EEPROM
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.
Horst schrieb: > Der HSync bestimmt wann ein neuer Pixel kommt, > der VSync beginnt eine neue Zeile. woher stammt diese Weisheit? ein echter Horst!
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.
soso... schrieb: > Nein. DVI ist meist digital. dann schaue mal genau hin, er schrieb DVI-I was das bedeutet kannst du nachlesen! Ob man ihm glauben kann das er wirklich einen echten DVI-I hat muss jeder selbst entscheiden, ich glaube es erstmal solange ich keine anderen Daten habe.
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: > Du musst dem DVI-Port schon mitteilen, dass du das analoge Signal haben > willst. interessant, wer macht das? wie läuft das bei DVI-I zu VGA Kabel im Kabel ein Chip oder wird das nur an einem Port weitergereicht zu VGA? Pin12/15 oder braucht man auch ID0? Ich kenne noch vGA Monitore die zeigten nur dumm was sie konnten oder nicht, jedenfalls kein Sync wenn die Frequenz nicht passte d.h. nicht im Monitorbereich lag.
:
Bearbeitet durch User
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
spess53 schrieb: > Und das was man in C machen kann, geht immer zu 100% in Assembler. Wie schätzt Du den Zeitaufwand der Portierung von Linux auf 100% Assembler? Wie lange für die verschiedenen unterstützten Prozessoren wie DEC Alpha, ARC, ARM, AVR32, C6x, H8/300, Hexagon, Itanium, m68k, MicroBlaze, MIPS, Nios II, OpenRISC, PA-RISC, PowerPC, RISC-V, s390, SuperH, SPARC, Unicore32, x86, x86-64, Xtensa, z Systems und alle anderen, die da noch herumschwirren? Wenn man die Mannjahrhunderte dann ausgerechnet hat, könnte man vielleicht zu der Einsicht gelangen, dass die obige Aussage so pauschal überhaupt nicht gelten kann. Oder anders ausgedrückt: Es lohnt sich nicht, damit anzufangen. Bis man mit einem Prozessor fertig wäre, gibts den gar nicht mehr.
:
Bearbeitet durch Moderator
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
Joschua 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. Ach, du willst nur komplett einfarbige Bilder unterstützen? Oder was ist, wenn links gelb ist und rechts blau? Dann käme bei einem Durchschnitt der 3 Grundfarben weiß raus. Oder grüne Wiese mit blauem Himmel -> türkis. Horst schrieb: > 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. Kann man übrigens auch fertig als Zwischenstecker kaufen. soso... schrieb: > Ä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. Der Ausgang geht auch ohne DDC, sofern er (vermutlich am Abschlusswiderstand) erkennt, ob ein Monitor dran hängt. Nur ist dann die Auflösung sehr begrenzt. > Und jeder halbwegs moderne Monitor wird nur ein digitales Signal > anfordern. Monitore fordern über DDC gar nichts an. Die informieren nur den Rechner darüber, was sie alles können.
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.
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.